Post-Exploitation & Privilege Escalation

Penetration Testing Methodology

Chapter 8 · Post-Exploitation & Privilege Escalation

pentest1-7 proved a candidate was real, stopping deliberately at proof-of-concept. But a single confirmed foothold rarely answers the full question a client actually cares about: if a real attacker got exactly this same foothold, what could they genuinely reach from there? This chapter asks that question directly — with pentest1-7's own discipline still fully in force.

Privilege Escalation

Privilege escalation means gaining a higher level of access than the initial foothold provided — moving from a low-privilege web application user to administrative access on the underlying server, or from a standard database account to a database administrator. This is usually called vertical escalation, since it moves upward within the same general context. A related but distinct concept, horizontal movement, means reaching a different account at roughly the same privilege level (another user's own data, rather than a genuinely higher-privileged role) — worth distinguishing by name even though both matter to a real assessment.

A genuine, if distant, echo of assembly2-8's own privilege rings
assembly2-8 formalized privilege levels in hardware terms — ring 0 (full, kernel-level access) versus ring 3 (restricted, user-mode access) — and the real, hardware-enforced page-fault boundary between them. Privilege escalation in a real assessment is a genuine conceptual echo of exactly that boundary: an application typically runs in a deliberately restricted context, and successful privilege escalation means finding a way across into a genuinely more privileged one. Most real-world privilege escalation happens at the OS-account level (a regular user account reaching root/administrator) rather than literally crossing a hardware protection ring — but in the most severe cases, an OS-level exploit can achieve genuine kernel-level access, which is the literal crossing assembly2-8 described in hardware terms. The parallel is real, not just a name reused — a lower-privileged context is structurally unable to do certain things until it crosses a boundary into a higher one — but it's a conceptual echo, not a claim that every privilege escalation is literally a ring transition.

Lateral Movement

Lateral movement means using an established foothold on one system to reach other systems on the same network that weren't directly reachable or vulnerable from outside — directly relevant to the Internal engagement category from pentest1-2. A single compromised low-value system can become a stepping stone deeper into a network that was otherwise well-defended at its own perimeter. Credential reuse is a common enabler here: a credential surfaced during pentest1-4's own breach-database OSINT, or captured live on one system, can turn out to work on entirely different systems — a real, practical extension of bc1's own password-security material.

The "Assumed Breach" Mentality

Assumed breach engagements deliberately start from a different position: rather than asking "can an attacker get in at all," the tester is given an already-compromised low-privilege account or workstation access from the start, and the engagement asks "given that a foothold already exists, how much access can genuinely be reached from here." This connects directly to pentest1-2's own Gray Box (partial starting access) and Internal engagement categories.

This mentality matters because real breaches rarely start with a sophisticated zero-day — they usually start with something mundane, like a phishing email or a single leaked credential. Understanding what happens after that ordinary, unglamorous initial foothold is very often more operationally valuable to a real organization than one more confirmation that a perimeter can theoretically be breached at all.

pentest1-7's own discipline applies here with even higher stakes
Post-exploitation activity happens deeper inside a network, frequently touching systems and data that were never the original vulnerable target at all. The proof-of-concept-not-full-exploitation line from pentest1-7 matters just as much here — arguably more, since lateral movement risks touching far more systems than the single original vulnerability ever did. Confirming that lateral movement to another system is possible is the goal; actually rummaging through that system's real data is not.

Hands-On Exercises

Exercise 1

Explain the difference between vertical privilege escalation and lateral movement, using this chapter's own definitions, with one concrete example of each.

📄 View solution
Exercise 2

Explain the conceptual connection between privilege escalation and assembly2-8's own ring 0/ring 3 material — and explain the honest limit this chapter places on that connection.

📄 View solution
Exercise 3

Explain the "assumed breach" testing philosophy and why it's often more operationally valuable to a real organization than a traditional test starting entirely from the outside, tying your answer to pentest1-2's own Gray Box and Internal engagement categories.

📄 View solution

Chapter 8 Quick Reference

  • Vertical privilege escalation — reaching a genuinely higher privilege level (user → admin/root) · Lateral movement — using one foothold to reach other systems on the same network
  • Privilege escalation is a genuine, honest, distant echo of assembly2-8's own ring 0/ring 3 boundary — most real cases are OS-account-level, not literal hardware ring transitions
  • Lateral movement often relies on credential reuse — ties directly to bc1's password material and pentest1-4's own breach-database OSINT
  • Assumed breach — starting from an already-compromised foothold (a Gray Box/Internal variant per pentest1-2) rather than testing the perimeter itself; often more operationally valuable since real breaches usually start with something mundane
  • pentest1-7's PoC-not-full-exploitation discipline applies here with even higher stakes — more systems are at risk of unnecessary exposure
  • Next chapter: Reporting — The Actual Deliverable