SY0-701 · Threats, Vulnerabilities, and Mitigations · Updated July 25, 2026
Privilege Escalation: Vertical, Horizontal, and How Attackers Get There
Privilege escalation is when an attacker gains access rights beyond what their account was granted. It comes in two flavors. Vertical privilege escalation (privilege elevation) moves up — a standard user gains administrator, root, or higher-role permissions. Horizontal privilege escalation moves sideways — an account reaches the data or functions of another account at the same level, such as one customer viewing a different customer’s records. Distinguishing the two, and recognizing them in a scenario, is a recurring Security+ SY0-701 skill.
What “privilege” means here
Every account operates under an authorization model: a set of permissions and a role that says what it may do and what data it may touch. Privilege escalation is any successful move outside that boundary. The direction of the move — up to a more powerful role, or across to a peer’s resources — is what names the attack. Both are authorization failures, and both usually happen after an attacker already has some foothold (through phishing, a stolen credential, or a low-privilege account). Escalation is what turns a small breach into a serious one.
Vertical privilege escalation
Vertical escalation raises the account’s own privilege level. The attacker starts as a limited user and ends as admin/root or an equivalent high-privilege role. Common real-world techniques:
- Exploiting a vulnerable privileged process. A local exploit against a service running as SYSTEM/root — a buffer overflow, an unsafe
setuidbinary, or a kernel bug — lets attacker code inherit that process’s high privileges. - Abusing misconfigurations. Weak file or service permissions (a world-writable service binary, an unquoted service path, a
sudorule that’s too broad) let a normal user run code as a privileged account. - Token or credential theft. Stealing an admin’s access token, session, or cached credentials and reusing them (pass-the-hash, token impersonation).
- Application-layer role tampering. In a web app, changing a role or privilege field the server trusts — for example intercepting a request and switching a
role=userparameter torole=admin, or flipping an “isAdmin” flag — so the server grants administrative functions the account never had. This is both a vertical escalation and an insecure-authorization/broken-access-control flaw, because the server failed to enforce authorization on the server side.
The countermeasures are least privilege, prompt patching, secure configuration, and — critically for the web case — server-side authorization checks that never trust client-supplied role data. Host-based intrusion prevention adds a local backstop by blocking exploit behavior against privileged processes.
Horizontal privilege escalation
Horizontal escalation keeps the same privilege level but crosses into another user’s scope. The classic web example is an insecure direct object reference (IDOR): a user authorized only to see their own invoice changes an ID number in the URL (/invoice?id=1001 → 1002) and successfully views another customer’s invoice. No admin rights were gained — the account simply reached a peer’s data because the server checked authentication (“are you logged in?”) but not authorization (“is this record yours?”).
Other horizontal patterns include session hijacking — session tokens are classically snatched over unsecured public Wi-Fi — to act as another same-level user, or reusing a predictable password-reset token for a peer account. The defining trait is always: same level, someone else’s resources.
The fix is object-level authorization — the server must verify, on every request, that the authenticated user actually owns or is permitted to access the specific object being requested.
| Vertical escalation | Horizontal escalation | |
|---|---|---|
| Direction of gain | Upward — higher privilege/role | Sideways — same level, another account |
| Typical example | Standard user becomes admin/root | User views another user’s invoice via changed ID (IDOR) |
| What the attacker gains | More powerful permissions | Another peer’s data or functions |
| Underlying flaw | Missing/weak privilege enforcement, exploitable privileged process, role tampering | Missing object-level authorization (broken access control) |
| Primary defense | Least privilege, patching, server-side role checks | Per-object ownership checks on every request |
The relationship to broken access control
Both escalation types are, at root, broken (or improper) access control — the umbrella weakness where the system fails to enforce what an authenticated user is allowed to do. That’s why a single finding often has two correct labels on the exam: an intercepted request whose role parameter is flipped from user to admin is both privilege escalation (vertical) and an access-control/authorization flaw. Recognizing that a finding satisfies more than one true statement is exactly what “choose two” questions probe. Escalation is frequently the sequel to credential theft — see keyloggers for a common way attackers get the initial foothold.
How the SY0-701 exam tests this
- Classify the direction. Given two findings side by side — a limited help-desk account that altered a domain admin’s group membership (upward = vertical), and a user who read another customer’s record by changing a URL ID (sideways = horizontal) — the question asks you to label each. Match the direction of the gain to the term.
- The “choose two” role-tampering item. A tester flips an intercepted
role=userrequest torole=adminand gets admin functions. Two statements are correct: it’s privilege escalation, and it’s a broken/insecure access-control (authorization) vulnerability. Pick both; don’t stop at one. - IDOR by name or by behavior. A scenario where changing a numeric identifier exposes another user’s object is horizontal escalation via insecure direct object reference — the fix is server-side authorization on the object, not stronger passwords or encryption.
- Best remediation. For the web cases the answer is almost always “enforce authorization checks on the server side,” never a client-side control the attacker can bypass.
“Choose two” items punish partial knowledge — the reliable fix is working realistic practice questions until spotting both correct labels becomes habit.
Quick reference
- Privilege escalation = gaining access beyond what the account was granted; two directions.
- Vertical = upward to higher privilege (user → admin/root); horizontal = sideways to a peer’s data/functions.
- Vertical techniques: exploiting privileged processes, misconfigurations, token theft, and trusting client-supplied role data.
- Horizontal’s signature is IDOR — changing an ID to reach someone else’s record because the server skipped object-level authorization.
- Both are forms of broken/improper access control, so a single finding can be correctly labeled two ways.
- Vertical defense: least privilege, patching, secure config, server-side role enforcement. Horizontal defense: per-object ownership checks.
- Escalation usually follows an initial foothold — least privilege limits how far any single compromised account can go.