Elevation controls such as UAC, sudo, setuid, macOS privacy consent and cloud just-in-time roles exist to keep privilege temporary and deliberate, and T1548 is what happens when an attacker uses those same mechanisms to get privilege without the deliberate part. MITRE ATT&CK tracks this as T1548 Abuse Elevation Control Mechanism, in the Privilege Escalation tactic, with six sub-techniques across Windows, Linux, macOS, IaaS, Office Suite and Identity Provider platforms. This page is the technique-level view: what each sub-technique abuses, which telemetry the DET0345 analytics rely on, and how to prioritise controls. It goes deepest on T1548.005 Temporary Elevated Cloud Access, the identity-heavy sub-technique that the operating system guides do not cover. Endpoint detail lives in the Windows Privilege Escalation Techniques Guide and the Linux Privilege Escalation Techniques Guide. It is written for detection engineers, cloud and identity engineers and endpoint administrators.
Key takeaways
- One technique, six mechanisms. Setuid and setgid, UAC bypass, sudo caching, macOS elevation prompts, cloud temporary elevation and TCC manipulation all sit under T1548. Each needs its own telemetry.
- The control is working as designed. T1548 abuses legitimate elevation paths, so detection looks for elevation in the wrong context (wrong parent process, wrong user, wrong role chain) rather than for a malicious file.
- Cloud elevation is identity elevation. T1548.005 covers just-in-time role activation, impersonation of other accounts and passing roles to resources. Misconfigured permissions create escalation paths that never touch an endpoint.
- Some cloud steps leave thin logs. AWS documents that iam:PassRole is a permission, not an API call, so there is no PassRole event: you see it only in the call that created the resource.
- Least privilege beats bypass hunting. ATT&CK's top mitigations are removing local admin rights, strict sudoers, highest UAC enforcement and limiting who may assume, impersonate or pass roles, with approval for just-in-time elevation.
The six sub-techniques at a glance
ATT&CK v20 lists the following sub-techniques. The right-hand column points to where each is covered in depth.
| Sub-technique | Platform | Mechanism abused | Deep coverage |
|---|---|---|---|
| T1548.001 Setuid and Setgid | Linux, macOS | Binaries that run as their owner or group, including root | Linux Privilege Escalation Techniques Guide |
| T1548.002 Bypass User Account Control | Windows | Auto-elevating binaries and COM objects that skip the UAC prompt below the highest setting | Windows Privilege Escalation Techniques Guide |
| T1548.003 Sudo and Sudo Caching | Linux, macOS | Permissive sudoers entries and the cached sudo timestamp | sudo and sudoers Security Guide |
| T1548.004 Elevated Execution with Prompt | macOS | The deprecated AuthorizationExecuteWithPrivileges API, which prompts for credentials without checking the caller's origin or integrity | This page; macOS Detection and Response Guide |
| T1548.005 Temporary Elevated Cloud Access | IaaS, Office Suite, Identity Provider | Just-in-time role activation, account impersonation and passing roles to resources | This page (below) |
| T1548.006 TCC Manipulation | macOS | Apps already granted privacy permissions such as Full Disk Access, or the TCC database when System Integrity Protection is off | macOS TCC and Privacy Permissions Management Guide |
T1548.005 Temporary Elevated Cloud Access in depth
ATT&CK describes three families of cloud elevation that attackers abuse when permissions are misconfigured. It also draws a line: T1548.005 is abuse of existing temporary elevation structures, while T1098.003 Additional Cloud Roles is assigning permanent roles. The two often appear together, because an attacker with enough privilege may grant a second account the right to impersonate or activate, which ATT&CK notes can be stealthier where logs do not make impersonation clear.
| Family | Examples named by ATT&CK | Misconfiguration to look for | What to log |
|---|---|---|---|
| Just-in-time access | Eligible roles activated on request; some configured for automatic grant, some for manual approval | High-impact roles that activate without approval, justification or strong MFA | Role activation, approval decision, justification, duration |
| Account impersonation | GCP iam.serviceAccountTokenCreator creating tokens for a service account; domain-wide delegation impersonating Workspace users; Exchange Online ApplicationImpersonation | Token Creator granted at project or organisation level rather than on one service account; broad delegation scopes | Token creation and the impersonated identity (Google Cloud documents that most impersonation audit logs record both identities) |
| Passing roles to resources | AWS iam:PassRole; GCP iam.serviceAccountUser attaching a service account to a resource | PassRole with Resource "*" or without an iam:PassedToService condition; Service Account User on privileged service accounts | The resource creation call (for example a function or instance create) and the role it carries |
Platform controls for temporary elevation
Platforms are listed alphabetically. Confirm current names in each vendor's documentation.
- AWS: scope iam:PassRole to specific role ARNs and add the iam:PassedToService condition so a role can be passed only to the intended service. AWS also advises against controlling PassRole with ResourceTag conditions, which it says do not give reliable results. Because PassRole produces no CloudTrail event of its own, monitor the creation calls of services that accept roles. See the AWS IAM Policies and Roles Guide.
- Google Cloud: grant Service Account Token Creator on individual service accounts, not on projects or folders, and review who holds it. Prefer impersonation over service account keys, because impersonation logs show both the caller and the service account, while key use shows only the service account. See the Google Cloud IAM and Service Accounts Guide and the Google Workspace Domain-Wide Delegation Security Guide.
- Microsoft Entra ID: in Privileged Identity Management role settings, set "Activation maximum duration" (1 to 24 hours) to the shortest workable value and turn on "On activation, require multifactor authentication" or "On activation, require Microsoft Entra Conditional Access authentication context", "Require justification on activation" and, for the most sensitive roles, "Require approval to activate". Avoid "Allow permanent active assignment" for those roles. See the Privileged Identity Management (PIM) Guide.
The design principle behind all three is the one in the JIT Access Guide: temporary elevation reduces standing privilege only if the right to elevate is itself narrow, approved and logged.
Detection: the DET0345 analytics
ATT&CK v20 detection strategy DET0345 has five platform analytics for the parent technique, and each sub-technique has its own strategy as well (for example DET0388 for UAC bypass, DET0395 for the macOS elevation prompt, DET0393 for temporary elevated cloud access and DET0534 for TCC manipulation).
| Analytic | Platform | What to correlate | Telemetry named by ATT&CK |
|---|---|---|---|
| AN0975 | Windows | Registry changes linked to UAC bypass, unusual parent and child processes (for example control.exe spawning cmd.exe), unsigned processes running elevated | Security 4688 and 4672; Sysmon 13 and 14 |
| AN0976 | Linux | Setuid or setgid bit changes, executions where UID differs from EUID, sudo or pkexec invocations by unexpected users | auditd SYSCALL |
| AN0977 | macOS | Execution of security_authtrampoline or use of AuthorizationExecuteWithPrivileges, and GUI apps launched with escalated privileges | macOS unified log; process execution |
| AN0978 | Identity Provider | Unexpected elevation through assertion manipulation, role injection or identity mapping changes | IdP sign-in logs |
| AN0979 | IaaS | Sudden role privilege expansion, cross-account or unexpected role assumption | AWS CloudTrail |
Rules that work across estates
- Elevated child of an unprivileged parent (Windows): a high-integrity process whose parent ran at medium integrity without a consent prompt, filtered against known installers.
- Setuid change outside packaging (Linux and macOS): a chmod that sets the setuid or setgid bit, made by anything other than the package manager.
- Sudo from a service account: sudo or pkexec run by an account that has no interactive role. Non-human accounts with sudo rights are a common path; see Root, sudo and superuser accounts on Linux and Unix.
- Elevation then new identity (cloud): a role activation or impersonation followed within minutes by creation of keys, users, role assignments or resources carrying a role. This is the hand-off from T1548.005 to persistence.
- Activation outside pattern (cloud): just-in-time activation outside working hours, from a new location, or by a user who has not activated that role in 90 days. The 90-day window is our suggestion.
- Token creation for a privileged service account: Google Cloud token generation for a service account by a principal outside its expected set.
Prevention priorities
ATT&CK maps eight mitigations to T1548. In order of impact for most organisations:
- M1026 Privileged Account Management: remove users from local Administrators; manage the remaining local admin passwords with the Local Administrator Password Solution (LAPS) Guide approach.
- M1018 User Account Management: limit who can assume, create or impersonate roles and policies in cloud, and require manual approval for just-in-time elevation where enabled.
- M1052 User Account Control: use the highest UAC enforcement level where workable. Microsoft documents that "Run all administrators in Admin Approval Mode" must stay enabled for the other UAC policies to take effect.
- M1022 Restrict File and Directory Permissions and M1028 Operating System Configuration: require passwords in sudoers, avoid setuid on programs with known shell escapes, and keep the number of setuid binaries low. ATT&CK notes that setting the sudo timestamp_timeout to 0 requires a password each time.
- M1038 Execution Prevention: allow only signed applications from trusted sources, which blunts the macOS prompt abuse and many UAC bypass payloads.
- M1047 Audit and M1051 Update Software: check for known UAC bypass weaknesses and keep systems patched. For macOS, routinely review apps holding Automation and Full Disk Access.
For roll-out, start with discovery: list local admins, sudoers entries, setuid binaries, eligible and active cloud role assignments, impersonation grants and PassRole permissions. Then pilot changes on one business unit or account, watch help desk volume and elevation failures for two weeks (our suggestion), and keep a documented rollback (restoring a removed admin right or an eligible assignment) before widening. The Endpoint Privilege Management Guide covers the tooling that makes removing local admin practical.
Decision guidance
- Approval or no approval for just-in-time roles? Approval adds friction but turns a stolen eligible account into a request someone must accept. Use it for roles that can change identity configuration, billing or security settings; allow self-activation with MFA and justification for lower-impact roles.
- Endpoint first or cloud first? If most users are local admins, fix that first: it removes the need for most UAC bypasses. If endpoints are already standard-user, cloud elevation paths are usually the larger unmanaged risk.
- Small organisations: remove local admin, set strict sudoers, and turn on approval and MFA for the handful of cloud admin roles.
- Large organisations: add escalation path analysis across cloud accounts. See the Cloud PAM and CIEM Guide.
Where identity fits
Every T1548 sub-technique ends with an identity holding more privilege than intended. On endpoints that identity is a local account or token; in cloud it is a role session, an impersonated service account or a resource carrying a passed role. Service accounts and workload identities are frequent targets because they often hold impersonation or PassRole rights for automation. Record who can elevate to what, and treat the right to elevate as a privileged entitlement in access reviews.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | T1548 and T1548.001 to T1548.006 (TA0004 Privilege Escalation); related T1098.003 | Technique, sub-techniques and the permanent-role counterpart |
| NIST SP 800-53 Rev. 5 | AC-6(1) Authorize Access to Security Functions; AC-6(2) Non-privileged Access for Nonsecurity Functions; AC-6(9) Log Use of Privileged Functions; AC-6(10) Prohibit Non-privileged Users from Executing Privileged Functions | Least privilege, standard-user operation, logging elevation |
| NIST SP 800-53 Rev. 5 | AC-2(7) Privileged User Accounts; CM-7 Least Functionality | Role-based privileged accounts; removing unnecessary setuid and features |
| NIST CSF 2.0 | PR.AA-05 (access permissions managed, least privilege); DE.CM-03 (personnel activity monitored) | Entitlement management and elevation monitoring |
Measuring progress
- Percentage of endpoints where standard users hold no local admin rights.
- Number of setuid and setgid binaries outside the distribution baseline.
- Share of privileged cloud roles assigned as eligible rather than permanently active.
- Share of high-impact just-in-time roles requiring approval and MFA on activation.
- Number of principals holding impersonation or PassRole rights on privileged identities, trending down.
Common failure patterns
- UAC at the default with everyone an admin: the default administrator prompt behaviour combined with admin rights for all users leaves room for auto-elevation bypasses.
- Wildcard PassRole: developers granted iam:PassRole on all roles so pipelines work, which lets them launch resources carrying any role.
- Project-wide Token Creator: impersonation granted broadly for convenience instead of on one service account.
- Just-in-time without friction: eligible roles that self-activate for 24 hours with no approval or justification behave much like standing access.
- Only watching endpoints: endpoint detection tuned for UAC and sudo while cloud role assumption and impersonation go unmonitored.
Practitioner checklist
- Inventory local admins, sudoers rules, setuid binaries and cloud elevation rights in one list.
- Remove local admin from standard users and set UAC to the highest workable level.
- Require passwords in sudoers and review NOPASSWD entries.
- Scope PassRole by role ARN with iam:PassedToService, and Token Creator by service account.
- Require MFA, justification and approval for high-impact just-in-time roles.
- Build the DET0345 analytics for each platform you run.
- Alert on elevation followed by creation of keys, users or role assignments.
- Review macOS apps holding Full Disk Access and Automation each quarter.
Standards and references
- MITRE ATT&CK: Abuse Elevation Control Mechanism (T1548)
- MITRE ATT&CK: Temporary Elevated Cloud Access (T1548.005)
- AWS: Grant a user permissions to pass a role to an AWS service
- Google Cloud: Service account impersonation
- Microsoft Learn: Configure Microsoft Entra role settings in Privileged Identity Management
- Microsoft Learn: User Account Control settings and configuration
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Windows Privilege Escalation Techniques Guide · Linux Privilege Escalation Techniques Guide · JIT Access Guide · Privileged Identity Management (PIM) Guide · T1068 Exploitation for Privilege Escalation