Detection rules › Panther

GCP iam.roles.update Privilege Escalation

Severity
high
Compliance
TA0004 T1548
Log types
GCP.AuditLog
Tags
GCP
Reference
https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/
Source
github.com/panther-labs/panther-analysis

If your user is assigned a custom IAM role, then iam.roles.update will allow you to update the “includedPermissons” on that role. Because it is assigned to you, you will gain the additional privileges, which could be anything you desire.

Rule body yaml

AnalysisType: rule
RuleID: "GCP.iam.roles.update.Privilege.Escalation"
DisplayName: "GCP iam.roles.update Privilege Escalation"
Description:
  If your user is assigned a custom IAM role, then iam.roles.update will allow you to update
  the “includedPermissons” on that role. Because it is assigned to you, you will gain the additional privileges,
  which could be anything you desire.
Enabled: true
Filename: gcp_iam_roles_update_privilege_escalation.py
LogTypes:
  - GCP.AuditLog
Tags:
  - GCP
Severity: High
Reports:
  TA0004:
    - T1548
DedupPeriodMinutes: 60
Threshold: 1
Reference: https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/
Runbook:
  Confirm this was authorized and necessary behavior. This is not a vulnerability in GCP, it is a vulnerability
  in how GCP environment is configured, so it is necessary to be aware of these attack vectors and to defend against
  them. It’s also important to remember that privilege escalation does not necessarily need to pass through the
  IAM service to be effective. Make sure to follow the principle of least-privilege in your environments to help
  mitigate these security risks.
Tests:
  - Name: Test-876cde
    ExpectedResult: false
    Log:
      p_enrichment: null
      protoPayload:
        authorizationInfo:
          - granted: true
            permission: iam.roles.dunno
            resource: projects/some-research/roles/CustomRole
            resourceAttributes: {}
  - Name: Test-ffdf6
    ExpectedResult: true
    Log:
      p_enrichment: null
      protoPayload:
        authorizationInfo:
          - granted: true
            permission: iam.roles.update
            resource: projects/some-research/roles/CustomRole
            resourceAttributes: {}

Detection logic

Condition

protoPayload.authorizationInfo is_not_null
protoPayload.authorizationInfo array_any

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

FieldKindValues
protoPayload.authorizationInfois_not_null
  • (no value, null check)

Output fields

Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.

FieldSource
projectresource.labels.project_id
principalprotoPayload.authenticationInfo.principalEmail
caller_ipprotoPayload.requestMetadata.callerIP
methodNameprotoPayload.methodName
resourceNameprotoPayload.resourceName
serviceNameprotoPayload.serviceName