What Is Privilege Escalation? Types, Examples and Defense

Privilege escalation is when an attacker, or a flawed process, gains permissions beyond what it was granted. Vertical escalation climbs from a standard user to administrator, root, SYSTEM or a cloud admin role. Horizontal escalation reaches another user's data at the same permission level, which in web apps usually means an IDOR flaw. MITRE ATT&CK tracks the vertical kind as tactic TA0004, with 13 techniques. Most escalations come from misconfigured services, weak permissions, unpatched kernels, reused credentials or over-permissive cloud IAM, so least privilege, patching and monitoring stop most of them.

What Is Privilege Escalation?

Every account, process and service is supposed to hold a fixed set of permissions. A help desk user can reset passwords but not change domain policy. A web app user can see their own invoices but not someone else's. A Linux service account can read its configuration file but not the password database. Privilege escalation is any way of breaking that boundary.

Wikipedia's definition is a useful starting point: exploiting a bug, a design flaw or a configuration oversight to gain elevated access to resources that are normally protected. The MITRE ATT&CK Privilege Escalation tactic puts it from the attacker's side: "The adversary is trying to gain higher-level permissions." ATT&CK lists the usual targets as SYSTEM or root level, local administrator, accounts with admin-like access, and accounts that can reach a specific system or perform a specific function.

Privilege escalation matters because initial access is usually cheap and low-privileged. A phished employee, a reused password or a vulnerable web form gives an attacker a foothold, but a standard account cannot disable security tools, read the credential store, deploy ransomware across servers or change cloud policies. Escalation is the step that turns a contained incident into a serious one.

How a privilege escalation attack unfolds

A typical privilege escalation attack follows the same rough sequence, whatever the platform:

1. Foothold. The attacker controls something with limited rights: a user session, a web shell running as the web server account, a container, or a cloud access key.
2. Discovery. They look for anything that runs with more privilege than they have and that they can influence: services, scheduled jobs, setuid programs, writable files, stored credentials, group memberships or IAM permissions.
3. Abuse. They use a misconfiguration, a vulnerability or a credential to run code or act as the more privileged identity.
4. Consolidation. With higher rights they harvest more credentials, create accounts or add roles, and often move laterally to the next system, where the cycle repeats.

The rest of this guide explains each part conceptually. It does not include commands or exploit steps.

Vertical vs Horizontal Privilege Escalation

Privilege escalation comes in two directions, and they need different defenses.

Vertical privilege escalation, also called privilege elevation, means gaining a higher permission level than the account was given: a standard user becoming local administrator, a web server account becoming root, an application user reaching admin functions, or a limited cloud identity becoming account administrator. This is what ATT&CK tactic TA0004 describes and what most people mean by "privilege escalation."

Horizontal privilege escalation means reaching resources that belong to another account at the same level: User A reading User B's orders, or one tenant seeing another tenant's files. The permission level does not change, but the scope of data does. The OWASP Web Security Testing Guide (test WSTG-ATHZ-03) uses the same split, with an online banking example for the horizontal case.

Where IDOR and lateral movement fit

In web applications and APIs, horizontal privilege escalation is usually caused by an insecure direct object reference: the server accepts an object ID from the user and returns the object without checking who owns it. Our guide to IDOR vulnerabilities explains how that flaw happens and how testers find it with multi-account testing. The OWASP Top 10 2025 A01: Broken Access Control category lists both IDOR and "elevation of privilege" among its common access control failures.

Some vendor explainers call horizontal escalation "lateral movement." They are related but not the same thing. Lateral movement, ATT&CK tactic TA0008, is about reaching other hosts and services, and our explainer on what lateral movement is covers its techniques and detection.

In real intrusions these steps chain. A horizontal step exposes an account or host where a vertical step is possible, and each new privilege level opens new lateral movement paths.

Privilege Escalation in MITRE ATT&CK (TA0004)

ATT&CK is the most widely used public catalog of attacker behavior. In version 20, the Enterprise matrix has 15 tactics, and Privilege Escalation (TA0004) sits between Persistence (TA0003) and the new Stealth tactic (TA0005). The tactic page notes that its techniques often overlap with Persistence, because operating system features that let an adversary persist can also execute in an elevated context. Our MITRE ATT&CK framework guide explains how tactics, techniques and sub-techniques fit together.

TA0004 currently contains 13 techniques. The table summarizes each in plain terms.

The most cited techniques in the examples later in this guide are Exploitation for Privilege Escalation (T1068), Valid Accounts (T1078), Abuse Elevation Control Mechanism (T1548) and Account Manipulation: Additional Cloud Roles (T1098.003).

One detail is worth knowing if you map findings to ATT&CK. Version 20 split the old Defense Evasion tactic into Stealth (TA0005) and Defense Impairment (TA0112), and Hijack Execution Flow (T1574), which includes weak service file and registry permissions, is now listed under Stealth and Execution rather than Privilege Escalation. Older reports and detection rules may still tag those weaknesses as TA0004.

Common Causes of Privilege Escalation

Almost every privilege escalation, on any platform, comes back to one of five root causes. The descriptions below explain why each one works so defenders can find it. They are deliberately conceptual.

Misconfigured services

Services and daemons often run as SYSTEM on Windows or root on Linux because they need to manage hardware, networking or other users. If a low-privileged user can change anything the service depends on, such as its executable file, its configuration, the folder it loads libraries from, or its startup settings, then whatever the user puts there runs with the service's privileges. ATT&CK covers service creation and modification under Create or Modify System Process: Windows Service (T1543.003).

Over-privileged services are a design problem as much as a configuration one. A web application that runs as root, or a database service that runs as SYSTEM, hands its full privilege to anyone who finds a code execution bug in it. PrintNightmare, covered below, is a case where a privileged Windows service itself performed unsafe operations on behalf of ordinary users.

Weak file, folder and policy permissions

Operating systems include deliberate ways to elevate: Windows User Account Control, sudo rules on Linux and macOS, and setuid or setgid programs that run as their owner rather than the caller. Each is safe only if it is configured tightly. A sudo rule that lets a user run an editor or interpreter as root, a setuid program that was never meant to be setuid, a scheduled task or cron script that ordinary users can edit, or a shared folder with write access for everyone can all hand over higher privileges. ATT&CK groups these under T1548 and Scheduled Task/Job (T1053).

The same pattern appears in directory services. Overly broad rights on Active Directory objects or Group Policy can let a regular user change who belongs to an administrative group or what runs on every machine. The NSA and CISA list of the ten most common misconfigurations, published October 5, 2023 from red team, blue team, hunt and incident response work, includes improper separation of user and administrator privilege and insufficient access control lists on network shares and services.

Unpatched kernels, drivers and system components

The kernel and system drivers run with the highest privilege on a machine. A memory safety or logic bug in them, or in a privileged system component, lets any local user who can trigger it run code as SYSTEM or root. ATT&CK records this as T1068, and its procedure examples list groups from APT28 and APT29 to ransomware operations such as BlackByte exploiting specific CVEs to escalate.

Local privilege escalation bugs are often rated lower than remote code execution because the attacker needs a foothold first. In practice, attackers chain them: initial access through phishing or an exposed service, then a local escalation to take full control. That is why the CISA Known Exploited Vulnerabilities catalog contains so many of them, as the next section shows.

Credential reuse and exposed secrets

The simplest escalation needs no bug at all. If the same local administrator password is set on every laptop, one stolen hash unlocks all of them. If a privileged account logs on to an ordinary workstation, its credentials may be left behind on that host. If a script, configuration file or code repository contains a service account password or cloud key, anyone who can read it inherits that account's rights. ATT&CK records the use of stolen legitimate credentials as Valid Accounts (T1078).

Our guide to pass-the-hash attacks explains how reused Windows credentials are abused and detected. The NSA and CISA misconfiguration list includes poor credential hygiene for the same reason.

Cloud IAM misconfiguration

In the cloud, privilege is a policy document rather than a group on a server, and escalation usually means finding a permission that lets an identity grant itself, or something it controls, more permissions. Common patterns include identities allowed to edit their own policies, create new access keys for more privileged users, attach roles to accounts, or launch compute with a more privileged role attached. ATT&CK covers these with Additional Cloud Roles (T1098.003) and Temporary Elevated Cloud Access (T1548.005), alongside Valid Accounts: Cloud Accounts (T1078.004).

AWS's own documentation on passing roles to services warns administrators to make sure a user cannot pass a role that has more permissions than the user should have, because the service then acts with the role's permissions on the user's behalf. Our AWS penetration testing guide includes a section on AWS privilege escalation paths and the CloudTrail events that reveal them, and the Azure penetration testing methodology covers the Microsoft cloud equivalent.

Real Privilege Escalation Vulnerabilities (Dated CVEs)

The vulnerabilities below are all in the CISA Known Exploited Vulnerabilities (KEV) catalog, meaning CISA has evidence of exploitation in the wild. Dates, scores and descriptions come from the NVD and the KEV catalog, checked November 5, 2026.

NVD records are linked here for each entry: CVE-2021-34527, CVE-2021-36934, CVE-2021-4034, CVE-2022-0847, CVE-2023-28252 and CVE-2024-1086.

PrintNightmare (CVE-2021-34527): a privileged service doing unsafe work

PrintNightmare is the clearest example of the misconfigured-service pattern at operating system scale. The Windows Print Spooler runs as SYSTEM and, according to the NVD description, improperly performed privileged file operations. An attacker with an ordinary domain account could use it to run code as SYSTEM, locally or on a remote machine, including domain controllers, where the spooler often ran by default.

CISA treated it as an emergency. Emergency Directive 21-04, issued July 13, 2021, cited active exploitation by multiple threat actors and required federal civilian agencies to stop and disable the Print Spooler on all Active Directory domain controllers by July 14, 2021 and to apply the July 2021 cumulative updates by July 20. The directive also required either disabling the spooler or restricting printer driver installation to administrators on other hosts. CISA closed the directive on January 8, 2026 and moved its requirements under Binding Operational Directive 22-01. The defensive lesson outlived the bug: services that do not need to run on critical servers should not run there.

Dirty Pipe (CVE-2022-0847): a kernel bug any local user could reach

Dirty Pipe is a Linux kernel flaw. The NVD description explains that a structure member was not properly initialized, so an unprivileged local user could write to pages in the page cache backed by read-only files and thereby escalate privileges. The researcher who found it, Max Kellermann, wrote in his Dirty Pipe disclosure that the bug existed since kernel 5.8 and was fixed in 5.16.11, 5.15.25 and 5.10.102. It was added to the KEV catalog on April 25, 2022.

Dirty Pipe illustrates why "local only" is not a reason to delay kernel patches on shared servers, container hosts and appliances. Any foothold, including a compromised web application running as a low-privileged account, becomes root.

PwnKit, HiveNightmare and the Windows CLFS zero-day

Three more KEV entries show the other causes in action. PwnKit (CVE-2021-4034) was a flaw in pkexec, a setuid program that ships with many Linux distributions, which turned a standard elevation mechanism into an escalation path. HiveNightmare (CVE-2021-36934) was a weak-permissions bug: the NVD description cites overly permissive access control lists on system files, including the Security Accounts Manager database, and ATT&CK records that APT29 exploited it to escalate privileges on a compromised host.

CVE-2023-28252 shows how ransomware crews use escalation. Kaspersky's Securelist analysis reported that a cybercrime group exploited this Windows Common Log File System driver flaw as a zero-day and attempted to deploy Nokoyawa ransomware; Microsoft patched it on April 11, 2023, the same day CISA added it to the KEV catalog.

What the KEV catalog says about privilege escalation

To see how common these bugs are among actively exploited vulnerabilities, we analyzed the KEV catalog feed (version 2026.11.04, 1,768 entries). 173 entries, about 10%, have "privilege" in CISA's vulnerability name, such as "Privilege Escalation Vulnerability" or "Elevation of Privilege Vulnerability." Of those 173:

• 127 are Microsoft products, mostly Windows components and drivers.
• 57 are flagged by CISA as known to be used in ransomware campaigns.
• New additions peaked in 2022 (83 entries), when CISA was still backfilling older exploited bugs, and continued in every year since, including 9 so far in 2026.

This is a conservative count. Many vulnerabilities that attackers use to escalate, including PrintNightmare itself, are named "Remote Code Execution" in the catalog and are not included. The practical conclusion is the same either way: privilege escalation bugs are a steady share of what attackers actually exploit, and the KEV list is a ready-made priority list for patching.

How to Detect Privilege Escalation

Privilege escalation leaves different traces depending on the technique, but most of them involve a change in who holds which rights, a process running at a higher level than its parent, or a privileged identity doing something it has never done before.

Microsoft documents event 4672, event 4732 and event 4697. For Kubernetes-specific escalation paths, see our Kubernetes penetration testing guide.

Four detections give most teams the best early return:

1. Privileged group changes. Alert on any addition to Domain Admins, Enterprise Admins, local Administrators on servers, or cloud admin roles, and require a matching change ticket.
2. Elevation without a reason. Flag processes that run as SYSTEM or root but descend from a user session, web server or other low-privileged parent.
3. New services, tasks and setuid files on servers. These are rare in steady state and common in escalation.
4. Self-granted cloud permissions. Flag identities that edit their own policies, create keys for other users or pass roles more privileged than their own.

How to Prevent Privilege Escalation

Prevention works best when it removes the conditions escalation depends on rather than chasing individual exploits. The CWE-269 Improper Privilege Management entry sums up the underlying weakness: privileges that are not properly assigned, modified, tracked or checked, which creates an unintended sphere of control.

Enforce least privilege everywhere

Least privilege means each user, process and service gets only the access it needs. In practice: remove local administrator rights from everyday user accounts, run services under dedicated low-privileged accounts, review sudo rules and setuid binaries, and scope cloud policies to specific actions and resources. In AWS, IAM Access Analyzer helps identify unused and over-broad access, and the AWS IAM best practices start from the same principle.

Manage privileged access deliberately

Privileged access management (PAM) is the set of controls that make admin rights rare, temporary and watched: vaulted credentials, just-in-time elevation, approval workflows and session recording. Microsoft Entra Privileged Identity Management is one example of time-bound, approval-based role activation in the cloud. On premises, Microsoft's enterprise access model separates control-plane, management-plane and workload administration so that a compromise of a lower tier does not hand over a higher one, and Windows LAPS gives each device a unique, rotated local administrator password.

Patch privilege escalation bugs on a KEV-first schedule

Because local escalation bugs are routinely chained with initial access, treat KEV-listed escalation flaws as urgent even when they are rated "local." Prioritize kernels on shared Linux hosts and container nodes, Windows drivers and system services, and any component on domain controllers or management servers. CISA's misconfiguration advisory names poor patch management among the ten most common weaknesses, and our explainer on what patch management is covers building a process around it.

Harden services and remove what is not needed

Disable services that are not required, as ED 21-04 required for the Print Spooler on domain controllers. Lock down file and registry permissions on service executables and folders, avoid running containers as privileged or with host mounts, and keep application servers from running as root or SYSTEM.

Protect credentials and remove reuse

Never log on to ordinary workstations with domain admin accounts, rotate service account passwords, store secrets in a vault rather than scripts, and require phishing-resistant MFA for administrative and cloud console access. Scan code repositories and configuration files for embedded secrets.

Keep EDR and logging on the systems that matter

Endpoint detection and response tools catch many exploitation and token manipulation techniques, but only where they are installed. Confirm coverage on servers, domain controllers and Linux hosts, and send the logs from the detection table above to a central system with alerting.

Which control closes which cause

How Penetration Tests Measure Privilege Escalation

Configuration reviews show what should be locked down. A penetration test shows what an attacker can actually reach from a realistic starting point. Privilege escalation is one of the core things a test measures, on four kinds of target:

• Web applications and APIs. Testers build a role matrix and check whether each role can reach functions or data that belong to a higher role (vertical) or another user (horizontal), as OWASP WSTG-ATHZ-03 describes.
• Windows and Linux hosts. Testers start as a standard user and look for paths to local administrator, SYSTEM or root.
• Active Directory. From an assumed-breach position, testers map paths from a domain user to Domain Admins and other Tier 0 access. Our internal penetration testing methodology explains how those tests are scoped and run.
• Cloud IAM. Testers start from a limited identity and check whether policies allow it to reach account or tenant administration.

What a good test records

• Starting point. The account, host, role and network position the test began from, so results can be compared over time.
• Each escalation step. From which privilege level to which, by which mechanism, described clearly enough for defenders to reproduce in a lab.
• Root cause. Whether the step depended on a misconfiguration, missing patch, reused secret or IAM policy, because the fix differs for each.
• ATT&CK mapping. Each step tagged with a TA0004 technique ID so findings line up with detection engineering.
• Detection outcome. Whether EDR, the SIEM or cloud logs recorded or alerted on the step.
• Fix and retest. A specific remediation and a retest that proves the path is closed.

Tests are run under written authorization with agreed rules of engagement; NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, describes the planning and execution practices behind them. A red team engagement goes further by pursuing an objective while measuring whether defenders notice the escalation.

The scorecard below is an illustrative example of how results can be reported. It does not describe a real engagement.

Lab-safe ways to check your own exposure

Teams can measure part of the picture without an attacker's toolkit. Audit who holds administrative rights in Active Directory, on servers and in each cloud account. Inventory setuid binaries, sudo rules, services running as SYSTEM or root, and scheduled tasks on a sample of hosts. Match your asset inventory against KEV entries that mention privilege escalation. In the cloud, review any policy that allows editing policies, creating keys for other users or passing roles. Run any technique simulation only in an isolated lab or with written approval for the systems involved.

When you choose a provider, ask how they report escalation paths, whether each step is mapped to ATT&CK technique IDs, whether they record detection outcomes, and how retesting confirms that fixes worked.

Frequently Asked Questions

What is a privilege escalation attack?

A privilege escalation attack is any attempt to gain permissions beyond those an account or process was given, usually after an initial foothold. Attackers use misconfigurations, vulnerable software, stolen credentials or over-permissive cloud policies to become an administrator, root, SYSTEM or a cloud admin, or to reach other users' data.

What is the difference between vertical and horizontal privilege escalation?

Vertical privilege escalation raises the permission level, for example from a standard user to administrator. Horizontal privilege escalation keeps the same level but reaches another account's data or functions, for example one customer viewing another customer's orders.

Is IDOR a type of privilege escalation?

Yes, in most cases. An IDOR lets a user access objects that belong to someone else by changing an identifier, which is horizontal privilege escalation. If the exposed object or function belongs to an administrator, the same flaw causes vertical escalation.

Is privilege escalation the same as lateral movement?

No. Privilege escalation changes how much permission the attacker holds; lateral movement changes which system or account they control. Attackers alternate between the two, because each new host can expose more powerful credentials.

What are common Windows and Linux privilege escalation causes?

On Windows: services and drivers running as SYSTEM with weak permissions or known flaws, shared local administrator passwords and over-broad group memberships. On Linux: loose sudo rules, unnecessary setuid programs, writable cron jobs and unpatched kernel flaws such as Dirty Pipe and the nf_tables bug CVE-2024-1086.

How do you prevent privilege escalation?

Apply least privilege to users, services and cloud identities; manage admin access with PAM and just-in-time elevation; patch KEV-listed escalation flaws quickly; remove unneeded services and shared passwords; and keep EDR and centralized logging on critical systems. Then test regularly to confirm the controls hold.

Next Step: Find Your Privilege Escalation Paths Before Attackers Do

Privilege escalation is what turns a single compromised account into control of a server, a domain or a cloud account. Most paths come from fixable causes: an over-privileged service, a loose permission, a missed patch, a reused password or an IAM policy that can grant itself more. Start with the control table in this guide, then verify the result from an attacker's point of view.

DeepStrike's penetration testing services include manual penetration testing, cloud penetration testing and red team engagements, with reports that give reproduction steps, root causes and remediation guidance for every validated finding.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

Sources and References

• MITRE ATT&CK: Privilege Escalation, Tactic TA0004
• MITRE ATT&CK: Enterprise tactics
• MITRE ATT&CK: Updates (v20)
• MITRE ATT&CK: Exploitation for Privilege Escalation, T1068
• MITRE ATT&CK: Valid Accounts, T1078
• MITRE ATT&CK: Valid Accounts: Cloud Accounts, T1078.004
• MITRE ATT&CK: Abuse Elevation Control Mechanism, T1548
• MITRE ATT&CK: Temporary Elevated Cloud Access, T1548.005
• MITRE ATT&CK: Account Manipulation: Additional Cloud Roles, T1098.003
• MITRE ATT&CK: Create or Modify System Process: Windows Service, T1543.003
• MITRE ATT&CK: Scheduled Task/Job, T1053
• MITRE ATT&CK: Hijack Execution Flow, T1574
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Emergency Directive 21-04, Mitigate Windows Print Spooler Service Vulnerability (July 13, 2021; closed January 8, 2026)
• CISA AA23-278A: NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations (October 5, 2023)
• NVD: CVE-2021-34527
• NVD: CVE-2021-36934
• NVD: CVE-2021-4034
• NVD: CVE-2022-0847
• NVD: CVE-2023-28252
• NVD: CVE-2024-1086
• Max Kellermann: The Dirty Pipe Vulnerability
• Kaspersky Securelist: Nokoyawa ransomware attacks with Windows zero-day (April 11, 2023)
• OWASP Web Security Testing Guide: Testing for Privilege Escalation (WSTG-ATHZ-03)
• OWASP Top 10 2025: A01 Broken Access Control
• MITRE CWE-269: Improper Privilege Management
• NIST CSRC Glossary: Least Privilege
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• Wikipedia: Privilege escalation
• AWS: Grant a user permissions to pass a role to an AWS service
• AWS: IAM Access Analyzer
• AWS: Security best practices in IAM
• Microsoft Learn: Microsoft Entra Privileged Identity Management
• Microsoft Learn: Enterprise access model
• Microsoft Learn: Windows LAPS overview
• Microsoft Learn: Event 4672, special privileges assigned to new logon
• Microsoft Learn: Event 4732, a member was added to a security-enabled local group
• Microsoft Learn: Event 4697, a service was installed in the system