Privilege Escalation Attacks in Cloud and Identity Systems

Privilege escalation is an attack in which an adversary turns the access they already hold into higher-level permissions or into access to another account's resources. In cloud and identity environments it frequently needs no exploit: a role assignment, a policy version, an application secret, or a help-desk reset can hand an attacker more authority than the identity they compromised.

The same API call serves administrators and attackers, and that makes these cases hard to investigate. Take a deployment role that assigns Owner to a service principal after a sign-in through another system. The log shows that the change succeeded. It does not show who approved it or how the caller came to hold the authority to make it. Investigators get further by tracing who can modify a privileged identity's credentials, permissions, or execution environment.

TL;DR:

• Effective permissions decide the escalation path. Workload execution rights, application ownership, and delegated access can expose authority well beyond an identity's visible role.
• Horizontal escalation can pass without any admin-role alert, so access to a peer account's resources needs its own questions about which data and systems changed hands.
• Role grants and permission changes are useful starting signals, and their legitimacy depends on the caller, the target, the approval path, and what happens next.
• Containment has to stop renewed access by revoking compromised credentials and sessions and removing the trust, permissions, or persistence that could issue replacements.

What Privilege Escalation Means Across Identity Boundaries

MITRE ATT&CK defines the Privilege Escalation tactic as the techniques adversaries use to gain higher-level permissions on a system or network. Escalation is also classed as vertical or horizontal.

Vertical escalation increases authority, such as moving from a restricted account to an administrator role. Horizontal escalation reaches another account or its resources at a similar privilege level, through either a permission change or an authorization flaw that lets one user act on another user's resources. A peer account may expose different customer records or business systems without holding a higher administrative rank.

"Identity escalation" is working shorthand, with no formal standard definition, for escalation through accounts, tokens, roles, applications, and trust relationships.

Credential theft and escalation need separate findings. Stealing a restricted token is credential access; using its permissions to obtain a more privileged identity can produce escalation. Escalation differs from lateral movement, where an attacker reaches other systems without gaining new authority, and many intrusions chain the two.

How Privilege Escalation Works in Windows, Cloud IAM, and IdPs

Across Windows domains, cloud identity and access management (IAM), and identity providers (IdPs), attackers gain authority through credential recovery, permission changes, or control of something that already runs with greater privileges. Each path depends on prerequisites, and a technique name alone says little about whether it works in a particular environment.

Windows and Active Directory

Active Directory (AD) escalation often turns on delegated permissions and authentication settings.

Kerberoasting lets an authenticated user request service tickets and attack them offline to recover a service account's password. The escalation only lands if the password cracks and the account holds useful privileges. AS-REP roasting targets accounts with Kerberos pre-authentication disabled.

In October 2024, Microsoft recommended managed service accounts, AES encryption for service tickets, and removing service principal names (SPNs) from accounts that don't need them. Microsoft's April 2026 Kerberos update made patched domain controllers default to AES for service accounts that don't explicitly allow RC4. RC4 tickets on a current domain point to accounts or policies still configured for it.

Active Directory Certificate Services (AD CS) abuse can turn certificate enrollment rights or certificate-infrastructure misconfigurations into authentication as another identity. Researchers label these paths ESC1 through ESC17, each with its own prerequisites, and broadly they involve template settings, certification authority settings, certificate mapping, and relay paths. ESC1, for example, depends on a template that lets low-privileged users enroll, lets the requester supply the subject alternative name, and allows client authentication without manager approval.

Delegation and directory permission abuse expose authority through control of directory objects. Resource-based constrained delegation can depend on permission to write the delegation attribute msDS-AllowedToActOnBehalfOfOtherIdentity on the target computer. DCSync requires replication rights and abuses replication APIs to obtain credential material. Group Policy abuse uses policy-edit rights to affect systems in the policy's scope. In 2025 SharePoint intrusions, Storm-2603 modified Group Policy Objects to distribute Warlock ransomware.

Local Windows escalation has its own constraints. Token impersonation depends on process integrity and privileges such as SeImpersonatePrivilege, and Potato-family exploits that worked on older Windows builds may fail on patched ones.

BadSuccessor, disclosed by Akamai in May 2025, abused delegated Managed Service Account (dMSA) migration in Windows Server 2025 domains. Microsoft's August 2025 update for CVE-2025-53779 closed the original path. A narrower variant still works for an attacker who already controls the target account's object and links it to a dMSA from both sides, so restrict who can create or modify dMSAs. A finding that cites BadSuccessor therefore needs the domain controllers' patch level and the attacker's actual object permissions before anyone treats it as exploitable.

Cloud IAM

Cloud escalation can run entirely through legitimate APIs. Role-name inventories miss much of it, because the authority sits in execution rights, trust policies, and permission combinations that a role name rarely reveals. The investigation starts in the control-plane logs, as most cloud incident response does.

In AWS, an identity with iam:CreatePolicyVersion can publish a new policy version and, with --set-as-default, make it the operative version for every attached identity. Policy attachment and inline-policy permissions can also expand authority.

Another path combines iam:PassRole with permission to create or modify a workload that runs under a more privileged role. AWS requires PassRole on the specific role, plus a trust policy that lets the service assume it, and the permission can be limited by role and by iam:PassedToService. PassRole has no API call of its own, so CloudTrail shows it only inside the event that created or updated the resource receiving the role, such as a Lambda function.

Control over an existing privileged workload can be enough. In a February 2026 intrusion, the compromised IAM user had UpdateFunctionCode and UpdateFunctionConfiguration. The attacker overwrote the code of an existing Lambda function that ran with an administrative execution role and used it to create access keys for an admin user, about eight minutes after initial access.

In Azure, roleAssignments/write lets a principal assign roles at the scope where it holds that permission. Workload control creates indirect paths: code running on a VM can request tokens for the managed identities attached to it and act with their permissions.

Directory roles and Azure resource roles are separate control planes, but privileged operations can connect them, as a 2025 Storm-0501 intrusion showed. The attackers used a compromised Directory Synchronization Account for reconnaissance, then took over a separate synced identity that held Global Administrator by resetting its on-premises password and registering their own MFA method. From there they called elevateAccess and assigned themselves Owner on all available Azure subscriptions.

In GCP, a principal with iam.serviceAccounts.getAccessToken can impersonate a service account, and the Service Account Token Creator role that grants it also includes signJwt. Impersonation can also run through delegation chains across several service accounts. iam.serviceAccounts.actAs lets a principal attach a service account to a resource and, combined with permission to deploy workloads, can expose that account's authority. Public incident reports seldom break GCP intrusions down to these permissions, which makes the frequency of each path hard to judge.

Identity Providers

Identity escalation through an IdP can begin with recovery procedures. Scattered Spider actors have talked help-desk staff into resetting passwords and MFA tokens, then enrolled their own.

A reset becomes an escalation path when it transfers control of a more privileged account, and it can start with a vishing call to the help desk. Investigators should tie the recovery action to the authenticator enrollment and administrative activity that follow it.

Application credentials provide another route. An identity with rights to add credentials to a privileged application may authenticate with that application's authority. OAuth consent can grant durable application access, although consent by itself is not evidence of malicious activity.

Federation changes can extend the compromise further. Attackers in a 2023 campaign against Okta customers used compromised Super Administrator accounts to remove MFA requirements from authentication policies and configure a second identity provider. Investigating only administrator-group membership would miss that trust change.

Detection Signals Need Permission and Session Context

Terraform deployments, onboarding, and emergency administration produce the same permission-change events an attacker would, so detection logic should keep the exact caller, target, scope, and changed permissions. The table pairs each environment's common starting signal with what an investigator has to resolve before calling it escalation.

‍

Blanket exclusions for automation identities can quietly break escalation detections, because an attacker who compromises a deployment role inherits its exemption. Check whether the execution came through the expected deployment path and whether the resulting authority matches the approved change.

Identity Threat Detection Signals Need Cross-System Investigation

ITDR tools, short for identity threat detection and response, contribute identity-specific findings, but an escalation's scope can reach workloads and applications outside those tools' view. Coverage varies by product; check which directories and control planes yours actually covers.

In Entra ID, Microsoft recommends alerting when an application receives a privileged role or when an administrator consents to highly privileged permissions. In Okta, useful events include user.mfa.factor.reset_all and system.idp.lifecycle.create, both tied to that cross-tenant campaign.

Connect those events to sign-ins, session activity, credential additions, and downstream use. An approval record explains why a change was made; the sign-ins and API calls after it show what the principal did with it.

How to Contain a Privilege Escalation Attack

A password reset alone rarely contains identity escalation, because application secrets, federation trust, and assumed-role sessions keep working after it. NIST SP 800-61 Rev. 3, published in April 2025, calls for collecting and retaining incident evidence under the organization's preservation procedures. Preserve audit records and volatile evidence where you can without holding back urgent action, and coordinate across identity, endpoint, and cloud owners.

Restrict the Compromised Principal and Hosts

Disable or constrain affected accounts, deactivate exposed keys, and isolate compromised hosts where appropriate. Record current permissions and configuration before reversing changes, because the investigation needs them to reconstruct the path.

Revoke Sessions and Credentials

Entra ID revocation covers disabling the user, revoking refresh tokens, and disabling registered devices. Access tokens already issued keep working until they expire, by default after a randomized 60 to 90 minutes.

Okta removes OAuth tokens along with a user's sessions only when the request includes the oauthTokens parameter. Downstream application sessions may need separate action.

Remove the Paths Back to Authority

Review added authenticators, application secrets, consent grants, federation settings, role assignments, and trust policies. In AWS, role-session revocation denies only credentials issued before the revocation time. It does not stop a principal the trust policy still allows from assuming the role again or touch long-term IAM user access keys. Tighten the role's trust policy and deactivate compromised keys separately.

Before restoring access, test whether the original permission path still works and inspect activity generated after containment began.

Reset KRBTGT When Domain Secrets Are Exposed

A routine privilege alert doesn't call for rotating KRBTGT, the account whose key signs Kerberos tickets in the domain; that belongs to domain recovery. Microsoft calls for two resets at least 10 hours apart, matching the default maximum ticket lifetimes, and a longer wait where those policies are set higher.

How to Prioritize Escalation Controls

Start with the condition that matches your environment:

• If AD service accounts have crackable passwords, move them to managed service accounts and harden Kerberos encryption, testing service dependencies first.
• If deployment identities can run privileged workloads, review code-update rights alongside IAM permissions.
• If administrators can change application credentials or federation, monitor those operations alongside role grants and include help-desk recovery procedures in access reviews.
• If legitimate IAM changes dominate alerts, compare permission deltas and approval paths before adding broad exclusions.
• If response spans several teams, preauthorize specific containment actions and name the people who can suspend accounts, revoke sessions, and restrict workloads.

Run a tabletop on one cross-system escalation scenario and record which containment actions still need another team's approval.

Why Cross-System Context Changes Escalation Investigations

Privilege escalation follows authority across systems, so closing one alert in one console often misses it. A new session might trace back to an MFA reset, and cloud API activity to an application credential. One analyst may close an Okta reset in the IdP console while another closes a role grant in the cloud console and a third reviews the API activity separately. Each event can look benign even when the sequence describes one escalation.

Agentic investigation can assemble that evidence, check it against approved exceptions, and route ambiguous or high-impact decisions to experienced practitioners. Organizational context, such as approved change paths, and telemetry context, such as known automation identities, let an investigation tell a sanctioned roleAssignments/write call from a hijacked one.

Daylight is a MASS company, meaning it offers managed agentic security services for Security Operations. Its AI-native managed detection and response (MDR) service investigates identity, cloud, and SaaS activity together, and its security experts handle the decisions that need human judgment.

Frequently Asked Questions About Privilege Escalation

What Tools Map Privilege Escalation Paths Before Attackers Use Them?

Attack-path tools show who can reach which privileged identity, and policy analyzers flag the access that makes those paths possible. BloodHound maps attack paths through Active Directory and Entra ID, and AWS IAM Access Analyzer validates policies and identifies unused access. Run them on a schedule, since one role change can open a path that didn't exist last month.

How Is Privilege Escalation Different From Privilege Abuse?

Privilege escalation gains authority the attacker didn't hold, while privilege abuse misuses authority an account already has, such as an administrator exporting data they're allowed to read. Escalation leaves a permission, credential, or trust change to trace. Abuse often leaves only unusual use of existing access, so investigating it depends more on knowing what normal activity looks like for that account.

Does Phishing-Resistant MFA Prevent Identity Escalation?

It protects the sign-in, but authorization paths remain. Attackers can replay tokens issued after a user satisfied MFA. Application credentials, delegated permissions, and compromised workloads offer other routes to authority that never prompt a new MFA challenge.

Can GCP Service Account Impersonation Go Unlogged?

Yes, unless Data Access logging has been turned on. GenerateAccessToken calls are recorded only as Data Access audit logs, which Google disables by default for most services, and they have to be enabled for the IAM API. The IAM policy change that grants impersonation rights still appears in Admin Activity logs. Check logging coverage before reading anything into an absent event.

What Should an Escalation Handoff Contain?

Include the original principal, the acquired authority, the affected scope, relevant sessions, and unresolved credential paths. Attach the permission or trust change, the authorization evidence, completed containment actions, and the next action that needs an identity or cloud owner.