Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

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]

EnterpriseT1548.005Sub-techniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Temporary Elevated Cloud Access matters because it turns “controlled” cloud privilege elevation into a potential escalation path. If just-in-time access, impersonation, service account delegation, or role-passing permissions are too broadly granted or poorly reviewed, a compromised user or service account may reach resources beyond its normal authority without creating a permanent role assignment.

Executive priority

Treat this as an identity and cloud governance priority, not only a SOC alerting problem. Leaders should ask whether temporary elevation paths in IaaS, office suites, and identity providers are inventoried, approved, logged, and regularly reviewed. The business risk is that an attacker can use legitimate cloud control-plane features to expand access while leaving fewer obvious signs than permanent privilege changes, which affects incident scoping, audit evidence, and resilience of critical cloud resources.

Technical view

For SOC, detection engineering, and IR teams, validate visibility into temporary privilege mechanisms across supported platforms: IaaS, Office Suite, and Identity Provider. Focus on events involving just-in-time role activation, account impersonation, domain-wide delegation, service account token creation, Exchange Online ApplicationImpersonation, AWS PassRole-style activity, and GCP service account attachment or impersonation permissions. Because ATT&CK provides no official detection text for this object, coverage should be derived from local cloud audit logs, identity logs, and the related DET0393 detection strategy where available. Analysts should also distinguish this sub-technique from Additional Cloud Roles: this behavior abuses existing temporary elevation structures rather than assigning permanent roles.

Likely telemetry

  • Cloud audit/control-plane logs for role activation, role passing, service account attachment, and token creation
  • Identity provider logs showing privileged access requests, approvals, activations, and impersonation events
  • Office suite audit logs for delegated or impersonated mailbox/account access, including Exchange Online ApplicationImpersonation where applicable
  • IAM configuration snapshots showing users, service accounts, roles, delegation settings, and privilege relationships
  • Administrative approval records for just-in-time access requests

Detection direction

  • Baseline who can request or approve just-in-time access and alert on unusual activations, repeated requests, or activations outside expected administrative workflows.
  • Review impersonation and delegation events for accounts that do not normally act on behalf of users or service accounts.
  • Correlate role-passing or service-account attachment events with subsequent resource actions performed under the passed role’s authority.
  • Tune detections to account for legitimate administrative automation, emergency access, and approved maintenance windows to reduce false positives.
  • Validate that logs clearly identify both the initiating principal and the effective impersonated or delegated principal; ATT&CK notes stealth can increase when logs do not clarify impersonation.

Mitigation priorities

  • Prioritize User Account Management and least privilege for users and service accounts that can request temporary elevation, impersonate accounts, pass roles, or attach service accounts to resources.
  • Require approval, justification, time limits, and review for just-in-time privileged access where the platform supports it.
  • Regularly audit IAM permissions and delegation settings for escalation paths involving PassRole-like permissions, service account token creation, domain-wide delegation, and application impersonation.
  • Separate approval authority from request authority so a compromised account cannot self-escalate through temporary access workflows.
  • Retain and test audit evidence for temporary elevation events to support incident response and compliance review.
Analyst notes and limits

This technique is a sub-technique of T1548 Abuse Elevation Control Mechanism and is scoped to privilege escalation in enterprise cloud-related platforms. The supplied ATT&CK description specifically references IaaS, Office Suite, and Identity Provider environments, with examples from AWS, Azure, GCP, Google Workspace, and Exchange Online. The key defensive question is whether temporary elevation is governed and observable as tightly as permanent privilege assignment.

The official ATT&CK object does not provide detection guidance. This take is based on the supplied description, external references, and relationships only; local cloud architecture, IAM configuration, logging retention, and approval workflows are required to determine actual exposure or detection coverage. No active exploitation or attribution is implied.

Official MITRE ATT&CK definition

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]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1548 Abuse Elevation Control Mechanism This object subtechnique of Abuse Elevation Control Mechanism.
Relationship explorer

All related ATT&CK context

detects · Detection Strategy DET0393: Detection Strategy for Temporary Elevated Cloud Access Abuse (T1548.005) Enterprise subtechnique of · Technique T1548: Abuse Elevation Control Mechanism Enterprise mitigates · Mitigation M1018: User Account Management Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

Change history

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 .

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
edcc5f5831f59d47...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle edcc5f5831f5…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [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. [2]
    Google Cloud Service Account Authentication Roles

    Google Cloud. (n.d.). Roles for service account authentication. Retrieved July 10, 2023.

    Open source URL
  3. [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. [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. [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. [6]
    Microsoft Impersonation and EWS in Exchange

    Microsoft. (2022, September 13). Impersonation and EWS in Exchange. Retrieved July 10, 2023.

    Open source URL
  7. [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. [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. [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. [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. [11]
    mitre-attack T1548.005
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use