What Is Privilege Escalation? Types, Examples, and Prevention

Privilege escalation is a technique attackers use to raise the access rights of an account inside a system, for example from a regular user to an administrator or root account.

It happens because of software vulnerabilities, misconfigurations, or accounts that were granted more rights than they need. As a result, an attacker can read, modify, or delete data they were never supposed to touch.

Every operating system divides access rights into tiers. There are guest accounts, standard user accounts, administrator accounts, and a root account with almost unlimited power.

Systems are built this way so most users never have to touch sensitive configuration. The gap opens when a person or a process inside the system obtains rights beyond its scope without authorization.

Key takeaways:

• Privilege escalation raises a regular account to admin or root, through vulnerabilities, misconfigurations, or excess rights.
• There are two forms of privilege escalation: vertical escalation that moves up a tier, and horizontal escalation that reaches equivalent accounts.
• Detection and prevention rest on least privilege, patching, MFA, PAM, and privileged account monitoring.

What Is Privilege Escalation?

In security literature, privilege escalation is the exploitation of weaknesses in access control so that an account obtains higher rights than it was ever meant to have.

The NIST National Vulnerability Database groups the vulnerabilities that lead to this condition under access control weaknesses, while MITRE ATT&CK lists it as the end goal of several attack techniques rather than a single exploit. In other words, privilege escalation is a stage in an attack chain, not an isolated event.

To picture it simply, imagine an internet banking application. Customer A should only be able to see customer A’s own account. When customer A can open customer B’s account just by changing a number in the URL, they hold rights that are not theirs. If customer A can open the bank’s admin page, they have moved up a tier.

Those two situations are two different forms of privilege escalation, and both appear in almost every security reference:

• Vertical escalation (vertical privilege escalation or elevation of privilege): a low-rights account moves up to higher rights.
• Horizontal escalation (horizontal privilege escalation): the account stays on the same tier but reaches resources belonging to an equivalent account.

Vertical escalation is the one attackers want most, because once an account reaches root or administrator level, there is almost no technical boundary left. They can disable antivirus, delete logs, create new accounts, or install software that persists in the system.

Whether horizontal or vertical, what makes privilege escalation hard to spot is its end state: elevated activity looks like ordinary administrator activity. Running sudo, reading system files, and adding users to the admin group are all routine IT work, so an attacker who has already raised their rights can blend into normal operations before anyone notices.

The Difference Between Horizontal and Vertical Escalation

These two forms are frequently confused in casual discussion. The difference becomes clear when both paths are compared line by line:

Dimension	Horizontal Escalation	Vertical Escalation
Definition	Moves to another account on the same tier	Moves up to a higher tier of rights
Attacker goal	Access data belonging to someone else	Gain full control of the system
Example techniques	Credential theft, session hijacking, IDOR	Vulnerability exploitation, misconfigured sudo, UAC bypass
Example scenario	Customer A opens customer B’s account	Regular user runs commands as root
MITRE ATT&CK terms	Valid Accounts (T1078), Lateral Movement	Exploitation for Privilege Escalation (T1068), Access Token Manipulation (T1134)
Immediate impact	Data leakage between users	Loss of control over the entire system

Horizontal escalation does not add rights; it widens the reach. The attacker steals the credentials of one account and moves to other equivalent accounts. On a large scale, this technique is called lateral movement.

The 2013 Target credit card breach followed precisely this pattern, and its full sequence is covered in the real-world examples below. The point is simple: not a single account moved up a tier, everything moved sideways.

Vertical escalation is the form that turns a small incident into a disaster. The attacker starts from an account with minimal rights and finds a path to administrator.

The most common path is a loose sudo configuration. sudo is supposed to grant extra rights only for specific commands, but a NOPASSWD ALL entry for an entire user group lets anyone in that group become root without a password.

A more technical example is PwnKit, a vulnerability in the Linux pkexec utility (CVE-2021-4034) published in January 2022. Qualys noted that exploiting it takes only a few lines of code and worked on every Linux distribution they tested.

How Privilege Escalation Works

Privilege escalation is almost never the first step. Attacks follow a consistent sequence:

1. Initial access. The attacker gains a foothold through phishing, credentials leaked from a third-party service, or a vulnerability exposed to the internet.
2. Mapping. From inside the system, they map the rights they hold, look for credential files, check sudo entries, and hunt for unpatched vulnerabilities.
3. Escalation. They exploit what they found, whether it is a software vulnerability, wrong permission configuration, or an unguarded privileged account.
4. End goal. With administrator rights, the attacker extracts data, installs persistence, or stages a ransomware deployment.

Real-World Examples of Privilege Escalation

Target (2013), the horizontal path. Credentials belonging to vendor Fazio Mechanical Services were stolen through phishing. Those credentials opened the vendor billing portal, and from there the attacker moved laterally across the internal network and point-of-sale servers.

The pattern shows that a limited account is still dangerous when it sits in the wrong network.

Capital One (2019), a cloud misconfiguration. An engineer misconfigured a Web Application Firewall, opening an SSRF path that was then used to retrieve IAM role credentials from the AWS metadata service. Those credentials gave read access to S3 buckets containing data of tens of millions of customers.

This incident is often mentioned alongside privilege escalation because the root cause is the same: an identity granted too much. Classically it is categorized as a misconfiguration failure, but the lesson is identical: access rights that are disproportionate to the risk will eventually blow up, sooner or later.

Privilege Escalation Techniques in Linux and Windows

On Linux

• Loose sudo configuration. Overly broad NOPASSWD entries, or unrestricted commands that open an interactive shell.
• Misconfigured SUID binaries. Files with the SUID bit run with the rights of the file owner. If a regular user can modify such a file, the road to root is open.
• Writable files and directories. Root-owned cron scripts sitting in public directories, or an /etc/passwd file that a regular user can edit.
• Kernel and application exploits. PwnKit in pkexec, plus unpatched kernel vulnerabilities.
• Environment manipulation. Variables such as LD_PRELOAD or a weak PATH setting make legitimate processes load libraries chosen by the attacker.

On Windows

• User Account Control (UAC) bypass. UAC asks for confirmation before a process raises its rights. Loose configuration lets a process skip that confirmation.
• Access token manipulation. Tokens carry a process identity and rights. The technique recorded by MITRE ATT&CK as T1134 manipulates tokens so a process runs with another process’s rights.
• DLL hijacking. The attacker places a fake DLL file in a directory that a legitimate application searches first, so malicious code loads with that application’s rights.
• Sticky keys. Replacing sethc.exe with cmd.exe lets anyone open a command prompt at the login screen by pressing Shift five times.
• AlwaysInstallElevated. When this policy is active, .msi files can be installed with administrator rights even when launched by a standard user.

[IMAGE 3 – The most common escalation techniques on Linux and Windows]
Spec visual: two side-by-side columns. The left column, titled “Linux”, contains five short cards: loose sudo configuration, misconfigured SUID binaries, writable files and directories, kernel and application exploits, environment manipulation. The right column, titled “Windows”, contains five short cards: UAC bypass, access token manipulation, DLL hijacking, sticky keys, AlwaysInstallElevated. Alt text: “Infographic comparing five privilege escalation techniques on Linux and five on Windows”.

The Most Common Root Causes of Privilege Escalation

The techniques in the previous section explain how attackers raise access rights. The organizational side explains why those paths are open in the first place. Four root causes appear repeatedly in every security audit:

Access that is never reviewed

Access rights accumulate over years. Employees change departments while their old rights stay active, vendor contracts end while remote accounts remain live, and recertification is never scheduled as a routine agenda item. Every unreviewed account is a candidate escalation path.

Patches that are never prioritized

Many privilege escalations require no sophisticated technique, only an old vulnerability whose exploit is already public. What is usually missing is not technical skill but a process that decides which vulnerability gets fixed first.

Rights granted too broadly from the start

Service accounts with full admin rights, application accounts whose passwords are never rotated, or shared accounts used by dozens of people. These accounts are born from decisions to grant the widest possible access so work is never blocked, and they are rarely touched again. The same pattern applies in the cloud: an IAM role with an overly broad policy acts like an admin account nobody reviews, and every compromised workload automatically inherits its rights.

Ignored credential hygiene

Phishing, third-party database breaches, and credential stuffing remain the most common entry points. What is usually missing is the response once a breach is known, such as mass password resets and revoking old sessions. Once valid credentials are in hand, the escalation stage becomes far easier.

The Impact of Privilege Escalation

Undetected data theft. The IBM Cost of a Data Breach Report 2026 records an average global breach cost of USD 4.99 million, with an average of 247 days to identify and contain a breach. That window gives attackers plenty of time to move slowly and avoid attention.

A gateway to ransomware. Almost every modern ransomware deployment passes through an access rights escalation stage before encrypting victim data. Backups determine whether a company pays the ransom, but access management determines whether the incident happens at all.

Regulatory and compliance failures. Regulations such as the European Union’s General Data Protection Regulation (GDPR) require organizations to protect personal data and report qualifying breaches within strict deadlines.

An access control failure that ends in a breach opens the door to supervisory fines, on top of reputational damage and lost customer trust. The exact obligations differ by jurisdiction, as our comparison of GDPR, CCPA, and Indonesia’s PDP Law sets out.

How to Detect Privilege Escalation

Effective detection does not depend on a single tool. The following combination is enough to build basic visibility:

Per-account behavior baseline. Collect authentication logs and administrator activity, then establish what normal looks like. Activity that deviates from the baseline is far easier to notice than activity judged “suspicious” with no reference point.

UEBA and SIEM, properly configured. User and Entity Behavior Analytics detects pattern deviations, such as an account that normally operates during business hours suddenly running at midnight. Default configurations are usually too noisy, so tune for 30 to 60 days before switching to strict mode.

The indicators that show up most often:

• sudo or su commands from an unusual host
• New users added to the admin group outside a change window
• /etc/shadow or /etc/passwd reads by non-admin users
• Creation of new SUID files
• Registry AlwaysInstallElevated changes or sethc.exe replacement outside a change window
• UAC confirmation prompts appearing without genuine user activity
• Logging services stopped without a change ticket

Quick checks on a Linux server. The four commands below take under five minutes and give you a picture of the server’s condition:

# 1. Find passwordless sudo entries
grep -r "NOPASSWD" /etc/sudoers.d/

# 2. Find non-root accounts with UID 0
awk -F: '($3 == 0) {print}' /etc/passwd

# 3. Find recently created SUID binaries
find / -perm -4000 -type f -mtime -1

# 4. Make sure logging services are still running
systemctl status rsyslog auditd

Any unusual result from these four commands deserves same-day follow-up.

How to Prevent Privilege Escalation

Apply least privilege for real. The principle of least privilege only works if it covers old accounts as well as new ones. Use just-in-time access for admin rights, for example active for 4 to 8 hours while a task is in progress, then revoked automatically. Pair it with recertification every 90 days so managers revalidate each subordinate’s rights.

Fix configurations on a schedule. Audit sudo entries, critical file permissions, and cluster roles regularly. Watch for standard findings such as a Docker socket writable by regular users or a Kubernetes service account carrying cluster-admin.

Enable built-in operating system controls. ASLR and DEP on Windows, and SELinux or AppArmor on Linux, shrink the room an escalation exploit has to work in. These features cost nothing extra but are often found disabled or running in permissive mode. Kernel module signing adds one more verification layer before new code may run with high rights.

Risk-based patching. Patch critical and high vulnerabilities within 7 days, medium within 30 days. Test in staging before production. NIST SP 800-40 emphasizes prioritizing by exploitability rather than by schedule.

MFA that cannot be skipped. Multifactor authentication based on hardware tokens or push notifications with number matching is far safer than SMS. SMS can be transferred by an attacker through social engineering against the phone provider.

PAM for critical accounts. Privileged Access Management isolates admin accounts from everyday workstations. Logging in through a bastion host with recorded sessions produces an audit trail that is hard to tamper with.

Configuration audits and targeted pentests. A pentest focused on a single vector, such as privilege escalation on production Linux servers, produces sharper, more actionable results than a comprehensive once-a-year check.

The most common prevention mistakes: applying least privilege only to new accounts, relying on EDR as the single defense, and ignoring service accounts. EDR excels at detecting malware, but it does not see an overly broad sudo configuration.

Conclusion

Privilege escalation succeeds because of how access rights inside a system relate to each other, not only because of a single software vulnerability waiting to be patched.

There are two forms, horizontal that moves sideways and vertical that moves up, and both are almost always a mandatory stage before a major incident.

What makes the difference is not the number of tools installed, but the discipline to limit rights, review configurations on a schedule, and monitor privileged account activity.

The four commands in the detection section can be run today as a starting point. From there, build a baseline, close the escalation paths that are open, and treat every administrator account as one whose safety still needs to be proven.

FAQ: Privilege Escalation