What Is Privilege Escalation?

Last verified on Nov 8, 2026.

Privilege escalation is gaining a higher level of permissions on a system or network than you were given. MITRE ATT&CK describes it as the techniques adversaries use to gain higher-level permissions. Examples of elevated access are SYSTEM or root, local administrator, and a user account with admin-like access.

Attackers can often enter and explore a network with unprivileged access, but they need elevated permissions to follow through on their objectives. Escalation is how a small foothold becomes full control. It usually alternates with lateral movement: move to a new host, escalate there, move again.

Common Ways It Happens

ATT&CK says common approaches take advantage of system weaknesses, misconfigurations, and vulnerabilities. The tactic includes these techniques:

Many of these are not exploits. A stolen admin credential or an over-broad role needs no vulnerability, which is why escalation is also an identity problem and not just a patching problem.

What It Looks Like in Logs

On a cloud account. An identity grants itself or another identity broad rights. The IAM operation AttachUserPolicy attaches a managed policy to a user, and CloudTrail records each call with fields like userIdentity, eventSource, eventName, sourceIPAddress, and requestParameters. An illustrative event:

{
  "eventTime": "2026-11-08T03:12:44Z",
  "eventSource": "iam.amazonaws.com",
  "eventName": "AttachUserPolicy",
  "userIdentity": { "type": "IAMUser", "userName": "ci-reader" },
  "sourceIPAddress": "203.0.113.50",
  "requestParameters": {
    "userName": "ci-reader",
    "policyArn": "arn:aws:iam::aws:policy/AdministratorAccess"
  }
}

A read-only CI user attaching administrator access to itself, from an address it has not used before, is an escalation whatever the intent.

On a Linux host. ATT&CK's detection strategy for sudo abuse correlates sudo command executions with an elevated effective user ID of 0. An illustrative line:

Nov  8 02:15:13 build-3 sudo: deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/bin/bash

A shell as root is routine for some people and a red flag for others. What makes it a signal is who ran it, when, and what led up to it. A login from a new place that is followed minutes later by a root shell is stronger than either event alone.

Preventing It

• Limit standing permissions. Accounts and services get what they need and no more, so a compromised one cannot reach far.
• Control who can change roles and policies. The permission to attach a policy is itself a privileged permission.
• Harden elevation tools. For sudo, ATT&CK's mitigations are to keep tty_tickets enabled, require a password, set timestamp_timeout to 0 so the password is requested each time, and edit the sudoers file strictly.
• Patch software, because exploitation of a flaw is one route. Check CISA KEV for what is being used now.
• Protect the credentials that grant elevation. See account takeover.

Detecting It

This entry defines the term. For the working queries, which IAM and role events to watch, how to filter expected actors, and what to do when one fires, read detecting privilege changes. For the identity side, see access anomalies and authentication anomalies.

Sazabi and Audit Logs

Sazabi, an AI-native observability and security platform, can stream CloudTrail through CloudWatch Logs and keeps CloudTrail's JSON fields searchable, so a role change like the one above is a query against fields you already have.