Analyze Cloud IAM Privilege Escalation
Trace how the attacker obtained, expanded, and used cloud IAM privileges. Typical escalation paths: access-key leak, AssumeRole chaining, service-principal over-permission, workload-identity abuse, OAuth scope creep.
Actions
- 1
Build a "session graph": from the initial access event, walk STS AssumeRole chains / OAuth token exchanges / service-principal sign-ins until the highest-privilege identity reached.
- 2
Identify over-permissioned roles: role permissions broader than function need (e.g., Lambda with `*:*`, service principal with Global Admin).
- 3
Hunt for privilege-escalation primitives: iam:PassRole to higher-privilege role, sts:AssumeRole into cross-account, Entra ID app-consent phishing grant paths, Google Workspace super-admin role assignment.
- 4
Correlate IAM activity with resource impact: what data was accessed or modified via the escalated privilege? Evidence of exfiltration? Secret retrieval?
- 5
Document the full escalation path as a narrative with specific evidence pointers for each hop.
Queries
AWSCloudTrail | where eventName in ("AssumeRole","GetSessionToken","GetFederationToken") and errorCode == "" | project eventTime, userIdentity.arn, requestParameters.roleArn, sourceIPAddressAuditLogs | where OperationName has_any ("Add role assignment","Update application","Consent to application") | project TimeGenerated, InitiatedBy, OperationName, TargetResourcesCloudAuditLogs | where protoPayload.methodName has_any ("setIamPolicy","grantRole") | project timestamp, protoPayload.authenticationInfo.principalEmail, protoPayload.methodName, protoPayload.resourceNameNotes
Cloud IAM escalation is often the primary value of a cloud-native compromise; document thoroughly.
Session graphs are more useful than event lists; a graph view surfaces unreasonable leaps in privilege that event-list views hide.
Over-permission is frequently pre-existing; the investigation should distinguish attacker-exploited over-permission from attacker-created over-permission.