T1548.005: Temporary Elevated Cloud Access
Adversaries may abuse permission configurations that allow them to gain temporarily elevated access to cloud resources. Many cloud environments allow administrators to grant user or service accounts permission to request just-in-time access to roles, impersonate other accounts, pass roles onto resources and services, or otherwise gain short-term access to a set of privileges that may be distinct from their own.
Just-in-time access is a mechanism for granting additional roles to cloud accounts in a granular, temporary manner. This allows accounts to operate with only the permissions they need on a daily basis, and to request additional permissions as necessary. Sometimes just-in-time access requests are configured to require manual approval, while other times the desired permissions are automatically granted.[1]
Account impersonation allows user or service accounts to temporarily act with the permissions of another account. For example, in GCP users with the `iam.serviceAccountTokenCreator` role can create temporary access tokens or sign arbitrary payloads with the permissions of a service account, while service accounts with domain-wide delegation permission are permitted to impersonate Google Workspace accounts.[2][3][4][5] In Exchange Online, the `ApplicationImpersonation` role allows a service account to use the permissions associated with specified user accounts.[6]
Many cloud environments also include mechanisms for users to pass roles to resources that allow them to perform tasks and authenticate to other services. While the user that creates the resource does not directly assume the role they pass to it, they may still be able to take advantage of the role's access -- for example, by configuring the resource to perform certain actions with the permissions it has been granted. In AWS, users with the `PassRole` permission can allow a service they create to assume a given role, while in GCP, users with the `iam.serviceAccountUser` role can attach a service account to a resource.[7][2]
While users require specific role assignments in order to use any of these features, cloud administrators may misconfigure permissions. This could result in escalation paths that allow adversaries to gain access to resources beyond what was originally intended.[8][9]
**Note:** this technique is distinct from Additional Cloud Roles, which involves assigning permanent roles to accounts rather than abusing existing permissions structures to gain temporarily elevated access to resources. However, adversaries that compromise a sufficiently privileged account may grant another account they control Additional Cloud Roles that would allow them to also abuse these features. This may also allow for greater stealth than would be had by directly using the highly privileged account, especially when logs do not clarify when role impersonation is taking place.[10]
Security context for executives and security teams
T1548.005: Temporary Elevated Cloud Access describes Adversaries may abuse permission configurations that allow them to gain temporarily elevated access to cloud resources. Many cloud environments allow administrators to grant user or service accounts permission to request just-in-time access to roles, impersonate other accounts, pass roles onto resources and services, or otherwise gain short-term access to a set of privileges that may be distinct from their own. Just-in-time access is a mechanism for granting additional roles to cloud accounts in a granular, tempora...
Executive priority
T1548.005: Temporary Elevated Cloud Access is an official MITRE ATT&CK technique. Glexia treats it as defensive behavior context for prioritizing monitoring, control validation, and response planning without using the object by itself as an attribution claim.
Technical view
Security teams should validate T1548.005: Temporary Elevated Cloud Access by reviewing the official ATT&CK relationships, mapped tactics (privilege-escalation), supported platforms (IaaS, Office Suite, Identity Provider), and available local telemetry before making detection or mitigation decisions.
Likely telemetry
- Official ATT&CK relationships and object metadata
- Identity, privilege, and authentication events
- Cloud control-plane, SaaS audit, and container platform logs
Detection direction
- Validate whether T1548.005: Temporary Elevated Cloud Access appears in your detection coverage and tabletop scenarios.
- Use the object to align executive risk language with SOC, incident response, and detection engineering work.
- Do not treat ATT&CK relationship context as attribution without corroborating evidence.
Mitigation priorities
- Map the object to existing controls and identify missing telemetry or response ownership.
- Prioritize mitigations that reduce exposure on the listed platforms and tactics.
- Review adjacent ATT&CK relationships before changing policy, detections, or reporting language.
Additional notes and limits
Baseline Glexia take generated from the official MITRE ATT&CK STIX object, source hash, tactics, platforms, and detection fields. It is safe to replace with a richer model-generated take for the same source hash later.
This baseline take is source-grounded and schema-validated, but it does not include environment-specific telemetry, incident evidence, or threat-intelligence corroboration.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Temporary Elevated Cloud Access
Adversaries may abuse permission configurations that allow them to gain temporarily elevated access to cloud resources. Many cloud environments allow administrators to grant user or service accounts permission to request just-in-time access to roles, impersonate other accounts, pass roles onto resources and services, or otherwise gain short-term access to a set of privileges that may be distinct from their own.
Just-in-time access is a mechanism for granting additional roles to cloud accounts in a granular, temporary manner. This allows accounts to operate with only the permissions they need on a daily basis, and to request additional permissions as necessary. Sometimes just-in-time access requests are configured to require manual approval, while other times the desired permissions are automatically granted.[1]
Account impersonation allows user or service accounts to temporarily act with the permissions of another account. For example, in GCP users with the `iam.serviceAccountTokenCreator` role can create temporary access tokens or sign arbitrary payloads with the permissions of a service account, while service accounts with domain-wide delegation permission are permitted to impersonate Google Workspace accounts.[2][3][4][5] In Exchange Online, the `ApplicationImpersonation` role allows a service account to use the permissions associated with specified user accounts.[6]
Many cloud environments also include mechanisms for users to pass roles to resources that allow them to perform tasks and authenticate to other services. While the user that creates the resource does not directly assume the role they pass to it, they may still be able to take advantage of the role's access -- for example, by configuring the resource to perform certain actions with the permissions it has been granted. In AWS, users with the `PassRole` permission can allow a service they create to assume a given role, while in GCP, users with the `iam.serviceAccountUser` role can attach a service account to a resource.[7][2]
While users require specific role assignments in order to use any of these features, cloud administrators may misconfigure permissions. This could result in escalation paths that allow adversaries to gain access to resources beyond what was originally intended.[8][9]
**Note:** this technique is distinct from Additional Cloud Roles, which involves assigning permanent roles to accounts rather than abusing existing permissions structures to gain temporarily elevated access to resources. However, adversaries that compromise a sufficiently privileged account may grant another account they control Additional Cloud Roles that would allow them to also abuse these features. This may also allow for greater stealth than would be had by directly using the highly privileged account, especially when logs do not clarify when role impersonation is taking place.[10]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1548 | Abuse Elevation Control Mechanism | This object subtechnique of Abuse Elevation Control Mechanism. |
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Imported snapshots across ATT&CK releases(2)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.2 | 2.0 | Current bundle | edcc5f5831f5… | ||
| 19.1 | 2.0 | Older bundle | edcc5f5831f5… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
- [1]Azure Just in Time Access 2023
Microsoft. (2023, August 29). Configure and approve just-in-time access for Azure Managed Applications. Retrieved September 21, 2023.
Open source URL - [2]Google Cloud Service Account Authentication Roles
Google Cloud. (n.d.). Roles for service account authentication. Retrieved July 10, 2023.
Open source URL - [3]Hunters Domain Wide Delegation Google Workspace 2023
Yonatan Khanashvilli. (2023, November 28). DeleFriend: Severe design flaw in Domain Wide Delegation could leave Google Workspace vulnerable for takeover. Retrieved January 16, 2024.
Open source URL - [4]Google Cloud Just in Time Access 2023
Google Cloud. (n.d.). Manage just-in-time privileged access to projects. Retrieved September 21, 2023.
Open source URL - [5]Palo Alto Unit 42 Google Workspace Domain Wide Delegation 2023
Zohar Zigdon. (2023, November 30). Exploring a Critical Risk in Google Workspace's Domain-Wide Delegation Feature. Retrieved January 16, 2024.
Open source URL - [6]Microsoft Impersonation and EWS in Exchange
Microsoft. (2022, September 13). Impersonation and EWS in Exchange. Retrieved July 10, 2023.
Open source URL - [7]AWS PassRole
AWS. (n.d.). Granting a user permissions to pass a role to an AWS service. Retrieved July 10, 2023.
Open source URL - [8]Rhino Google Cloud Privilege Escalation
Spencer Gietzen. (n.d.). Privilege Escalation in Google Cloud Platform – Part 1 (IAM). Retrieved September 21, 2023.
Open source URL - [9]Rhino Security Labs AWS Privilege Escalation
Spencer Gietzen. (n.d.). AWS IAM Privilege Escalation – Methods and Mitigation. Retrieved May 27, 2022.
Open source URL - [10]CrowdStrike StellarParticle January 2022
CrowdStrike. (2022, January 27). Early Bird Catches the Wormhole: Observations from the StellarParticle Campaign. Retrieved February 7, 2022.
Open source URL - [11]mitre-attackT1548.005Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.