Common technical vectors: CVEs in the Linux or Windows kernel, unpatched drivers, vulnerable SUID binaries, privileged services with flaws and public exploits (Dirty COW, PetitPotam, PrintNightmare).
What is privilege escalation
Privilege escalation is the technique by which a user or process without administrative rights gains administrator, root or SYSTEM access inside a system that has already been compromised. It is almost always the step immediately after initial access and turns a contained intrusion into a full-blown compromise of the host and, in cascade, of the wider network. It exploits local operating system vulnerabilities, weak permission configurations or credentials carrying more privilege than they should.
Why it matters
Privilege escalation is the moment an intrusion shifts from nuisance to crisis. A compromised employee account limits damage to what that user could already do; root or domain admin gives full control over the host, its data and the rest of the network. With administrative privileges an attacker can disable antivirus and EDR, install rootkits, create hidden accounts for persistence, reach system directories and databases, steal encryption keys and prepare large-scale data exfiltration. It also opens lateral movement to other servers and bypasses logical access controls: ACLs, RBAC and application-level security are all defeated once root is obtained. That is why frameworks like ISO 27001, NIS2 and DORA insist on regular patching, separation of duties and strict control of administrative privileges: most severe incidents stop being severe when escalation is blocked in time.
Key points
Frequent misconfigurations: world-writable system files, permissive sudoers, plaintext credentials inside configuration files and shared root or admin passwords.
Classic attack pattern: initial access as a standard user (phishing, exposed RDP, leaked credential) that needs to escalate because the real objective requires administrative rights.
Most exploit known CVEs: vendor patches have been available for months and the exploits are public; not applying them is equivalent to leaving the door open.
Enforce least privilege on servers and workstations: services must run under the least-privileged account possible so that an initial compromise does not become an administrative one.
Detectable signals: ACL changes, modifications to administrative groups, creation of privileged accounts and unusual use of sudo, RunAs or elevated PowerShell.
Real-world example
An IT engineer receives a phishing email mimicking the corporate single sign-on portal and hands their password to the attacker's server. With the standard domain account compromised, the intruder gains RDP access to an internal server using tools and paths found in a shared repository. On that server they act as a normal user with no access to critical databases, so escalation becomes the priority: they spot that the Linux kernel has been unpatched for six months and launch a public Dirty COW exploit to obtain root.
With administrative privileges they disable local log collection, add a hidden service account for persistence, reach the database encryption keys stored on the server and start preparing data exfiltration. The security team catches it because the SIEM correlates the creation of a new administrative account with changes to sensitive file permissions; the investigation that follows reconstructs the path from lateral movement to escalation and forces an urgent kernel patch, credential rotation and privilege hardening across the whole domain.
Common mistakes
- Delaying operating system updates for fear of breaking services leaves known escalation paths open for months; the risk of not patching almost always exceeds the risk of patching.
- Granting local administrator rights to employees on their workstations turns any malware infection into trivial escalation.
- Failing to audit or alert on changes to sudoers, administrative groups or the creation of privileged accounts lets an attacker dig in without making any noise.
- Running exposed services as root or under domain accounts with broad privileges: a web server or a CI/CD runner should only have access to what it strictly needs.
- Reusing shared administrative accounts: a single compromised credential affects every system and seriously hampers forensic investigation.
- Not monitoring the use of sudo, RunAs or elevated PowerShell from SIEM and EDR: most escalations leave a trail if someone is actually watching.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
What is the difference between horizontal and vertical privilege escalation?
Vertical escalation is becoming administrator/root on the SAME system (standard user → root). Horizontal escalation is accessing another user's data or resources without changing your privilege level. Both are dangerous; vertical is more critical because it gives total system control.
How does privilege escalation relate to the principle of "least privilege"?
The principle of least privilege reduces the attack surface for escalation. If users lack administrative rights, attackers must exploit OS vulnerabilities rather than simply reusing stolen credentials. If services run with minimal privileges, even if compromised, damage is limited.
Why is patching so critical for preventing privilege escalation?
Most escalations exploit publicly known OS kernel, driver, or service CVEs. A patch available for 6 months but not applied is equivalent to leaving the backdoor open. Attackers use automated tools that scan for unpatched systems and execute public exploits.
How does a SIEM or EDR detect privilege escalation?
By monitoring ACL and permission changes, execution of privileged commands (sudo, RunAs, UAC bypass), creation of administrative accounts, changes to administrative groups, and anomalous process behaviour (system binaries executed from unusual locations). EDR should alert on attempts using known escalation techniques.