Cloud platforms give you ways to hold few permissions day to day and borrow more when needed. Those features are good design. They are also a route to more access than anyone intended if the permissions around them are loose. MITRE tracks this as T1548.005, Temporary Elevated Cloud Access, a Privilege Escalation technique for IaaS, Office Suite and Identity Provider platforms.
How attackers use it
MITRE describes three families of feature that can be abused.
Just-in-time access. An account can request extra roles for a limited time. Some requests need manual approval, others are granted automatically.
Account impersonation. A user or service account temporarily acts with another account's permissions. MITRE's examples: in GCP, users with the iam.serviceAccountTokenCreator role can create temporary access tokens or sign arbitrary payloads with a service account's permissions, and service accounts with domain-wide delegation can impersonate Google Workspace accounts. In Exchange Online, the ApplicationImpersonation role lets a service account use the permissions of specified users.
Passing roles to resources. A user who creates a resource can hand it a role. They do not directly assume the role, but they may still use its access, for example by configuring the resource to perform actions with the permissions it holds. In AWS, the PassRole permission lets a user allow a service they create to assume a role. In GCP, the iam.serviceAccountUser role lets a user attach a service account to a resource.
Users need specific role assignments to use any of this. The danger MITRE names is administrators misconfiguring permissions, which creates escalation paths beyond what was intended.
MITRE draws a line between this and Additional Cloud Roles, which assigns permanent roles. But an adversary who compromises a sufficiently privileged account may grant another account they control those roles, which then enables this technique. It can also be stealthier than using the privileged account directly, especially when logs do not make role impersonation obvious.
How to detect it
MITRE's detection strategy lists three analytics.
- AWS: multiple CloudTrail events that show temporary escalation through
PassRoleandAssumeRole, aimed at newly created services or non-interactive infrastructure. - GCP and Workspace: token creation or delegation where a user impersonates a higher-privileged service account, or performs domain-wide delegation actions such as the
serviceAccountTokenCreatorrole or Workspace impersonation. - Exchange Online: assignment of the
ApplicationImpersonationrole, or delegated mailbox access to service principals or rarely used users, especially outside normal hours or geographic norms.
The common thread is a chain: a principal creates a thing, passes it a role, and the thing then acts. Detection works best when you can follow the chain, not just alert on single events.
How to reduce the risk
MITRE lists one mitigation, User Account Management: limit the privileges of cloud accounts to assume, create or impersonate additional roles, policies and permissions to only those required. Where just-in-time access is in use, consider requiring manual approval for temporary elevation.
Three ways to apply that.
- Inventory who holds pass role and impersonation permissions, and remove them from anyone who does not build infrastructure.
- Scope those permissions to specific roles instead of a wildcard.
- Treat service accounts that can impersonate users or other service accounts as privileged accounts, with owners and reviews.
Check your own environment
A read-only AWS CLI query of recent role assumptions. It needs CloudTrail event history access.
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole --max-results 20
Look at who assumed which role, from which address, and whether the pairing is normal. Then review IAM policies for iam:PassRole grants with a wildcard resource.
Connecting your cloud accounts to a single inventory makes the "who can assume what" question easier to answer. The interactive demo below shows what that looks like.
Click through it at your own pace, or open it full screen.
Quick check
Why is PassRole risky if the user never assumes the role?
The user can configure a resource they create to act with the role's permissions, so they benefit from its access indirectly.
What is the single MITRE mitigation for this technique?
Limit which cloud accounts can assume, create or impersonate roles, and consider manual approval for just-in-time elevation.
Sources
- MITRE ATT&CK, Abuse Elevation Control Mechanism: Temporary Elevated Cloud Access: https://attack.mitre.org/techniques/T1548/005
