What is Privilege Escalation?

Privilege escalation is the transition from limited access to permissions that a user or process should not possess. Attackers commonly use it after an initial foothold to bypass security controls, reach more data, establish persistence or compromise further systems.

Vertical or horizontal?

Horizontal escalation overlaps with broken access control and IDOR in particular. The attacked role is not necessarily more powerful, but access crosses an authorized object or tenant boundary.

How does privilege escalation arise?

• Software vulnerabilities: Flaws in an operating-system kernel, privileged service, driver or management agent permit code execution with higher rights.
• Misconfiguration: Writable scripts, unsafe service paths, broad sudo rules, dangerous SUID files or weak file permissions.
• Credentials and tokens: Passwords, API keys, session tokens or cloud credentials are exposed in files, processes, metadata or backups.
• Faulty authorization: The application checks a role or owner in the interface but not server-side for each action.
• Trust relationships: A service account can assume other roles, alter deployment pipelines or remotely control privileged systems.

Escalation frequently emerges from a chain of smaller issues. A readable configuration file, reused password and overprivileged service account may be more critical together than any individual finding.

How does it differ by environment?

Why is privilege escalation important?

Initial access often has few permissions. Escalation enables disabling security software, reading other secrets, creating accounts or manipulating backups. Elevated rights then facilitate lateral movement. Local administrator access should not automatically mean domain administrator, however; good trust boundaries prevent one escalation from deciding the entire environment.

How can it be prevented?

1. Least privilege: Users, services, pipelines and automation accounts receive only necessary, timely permissions.
2. Separate administration: Dedicated accounts and hardened devices for privileged work, with just-in-time elevation where possible.
3. Patch and harden: Keep operating systems, drivers and privileged tools current and remove unsafe default permissions.
4. Protect secrets: Avoid credentials in scripts and images; prefer short lifetimes, rotation and managed identities.
5. Create boundaries: Administrative tiers, segmentation and separate backup identities contain impact.
6. Authorize server-side: Check every function and object against the current identity and tenant.

How can it be detected?

Relevant signals include new group membership and role bindings, unusual sudo or UAC use, changes to services and scheduled tasks, access to credential stores, newly created keys, and role assumption from an unusual context. Individual events may be legitimate; preceding login, process tree, device and approved change provide necessary context. Critical permission changes should also require approval and periodic recertification.

How is it tested?

Testing starts from the low-level access actually obtained and inventories permissions, trust relationships, files, services and tokens. Paths are verified with the least possible risk. Kernel exploits, credential dumping and changes to production roles can disrupt systems and require explicit authorization. The report should describe the complete chain, prerequisites, achieved rights and effective interruption points rather than only the final exploit.