We closed Module 4 with one or more footholds in TechNova, almost always with limited privileges: a shell as www-data on the store, a service account on the internal Linux server, an unprivileged account on a Windows workstation. The question that opens Module 5 —how far does this compromise really reach?— begins to be answered here. Privilege escalation is the step that turns minor access into full control of the host: from www-data to root, from an ordinary domain user to Administrator or SYSTEM. Without this jump, many findings look harmless; with it, a "minor" flaw is demonstrated as a complete compromise.

The framing does not loosen here—quite the opposite. Post-exploitation is where a professional pentest sets itself apart from an abuse manual. Everything happens in TechNova's authorized lab, within scope and within the Rules of Engagement (RoE). Escalation has a single purpose: to measure and demonstrate real impact for the Module 6 report, not to harm anyone. And the golden rule we will repeat in every lesson of this module: the pentester documents every action and every artifact they create, and reverts it when finished. Here, moreover, each offensive technique comes paired with its remediation, because the goal is for TechNova to close the gap, not to collect paths to root.

1. What privilege escalation is and why it matters
2. Vertical vs. horizontal escalation
3. Enumeration: 90% of the work (linPEAS/winPEAS)
4. Linux vectors
5. Windows vectors
6. Low-impact PoC and evidence capture
7. The defensive side: hardening and least privilege
8. Common mistakes and tips
9. Exercises
10. Conclusion

Escalating privileges means moving from the access level the foothold grants to a higher one. It matters for three reasons that feed straight into the report:

• It measures real impact. An RCE as www-data is serious; the same RCE that ends up as root means control of the server, its data, and its credentials. That difference is exactly what the client needs in order to prioritize.
• It enables everything else. With high privileges you can reach credential hashes, configurations, and other hosts. Persistence (05-02) and pivoting (05-03) usually require this step.
• It reveals hardening flaws. Every escalation path is a specific, fixable misconfiguration: an unnecessary SUID, an overly permissive sudo, a service with weak permissions.

Two distinct moves worth keeping straight:

Horizontal escalation looks less severe, but it is often the springboard: the contable account may have access to sensitive data or a sudo rule that devapp did not. Both are documented. And note: moving to another machine is no longer escalation—it is lateral movement, which is 05-03 and not covered here.

Escalation is rarely a spectacular exploit; it is almost always finding the misconfiguration that is already there. That is why the star phase is local enumeration from the foothold: understanding the system from the inside. It is automated with specialized scripts that run through hundreds of known checks.

These scripts highlight the interesting findings (in linPEAS, in red/yellow). They do not replace judgment: you have to understand why each finding is exploitable. A professional note: linPEAS/winPEAS are noisy and any decent EDR detects them—which, in a pentest, is also useful information: if TechNova's SOC does not react, that is a defensive finding in its own right.

The classic paths from user to root on a Linux host. Each with what makes it exploitable and how it is remediated.

SUID — the most instructive vector. A binary with the SUID bit runs with the privileges of its owner, not those of whoever launches it. If that owner is root and the binary can run commands (or read/write arbitrary files), we have root. The GTFOBins project catalogs which common binaries are abusable this way.

The uid=0(root) output is the proof. We do not open a persistent root shell or touch /etc/shadow: demonstrating the escalation is enough for the report. Remediation: that find should never have had SUID; remove it with chmod u-s /usr/bin/find and audit the rest.

Misconfigured sudo. Check with sudo -l. If something like (root) NOPASSWD: /usr/bin/vim appears, it is exploitable: vim can launch a shell from within, so running it as root grants root. Remediation: grant via sudo only commands that do not allow a shell escape, with specific arguments, avoiding wildcards.

On Windows the target is usually SYSTEM or Administrator. The paths change names but the logic—a weak configuration that grants more than it should—is identical.

Example — weak service permissions. If a service runs as SYSTEM and our account can reconfigure its binary, we can make it run something of ours with SYSTEM privileges.

The poc.txt file containing nt authority\system demonstrates execution as SYSTEM. Immediately afterward the original binPath is restored (we note it down before touching it) so as not to leave the service broken: reverting is mandatory. Remediation: fix the service ACL so ordinary users cannot reconfigure it; audit with accesschk.

High-level credentials. Once holding administrator privileges, an attacker would dump secrets from the LSASS process memory (Mimikatz-style tools) or from insecure configurations. Here we only name it as an impact to document: using those credentials to jump to other hosts is lateral movement (05-03), not escalation.

The principle of the whole module: demonstrate, do not destroy. A correct escalation PoC:

• Runs the minimum action that proves the privilege: id (Linux) or whoami (Windows), with time and hostname.
• Does not open backdoors, does not touch sensitive data, does not leave permanent root shells.
• Reverts any temporary change (an altered binPath, a PoC file): the state is restored and noted in the engagement log.
• Captures clear evidence for Module 6: command, output (uid=0/SYSTEM), timestamp, and the specific vector (which SUID, which sudo rule, which service).

The message the report will carry to TechNova. Almost every escalation path is configuration, not an irreparable flaw:

• Least privilege everywhere: services with the least possible privilege, users without unnecessary sudo, admin accounts separate from daily use.
• Audit SUID/capabilities/services: periodic reviews of find -perm -4000, getcap -r /, service ACLs; remove anything without justification.
• Restricted sudo: specific rules, no wildcards, no binaries with a shell escape.
• Kernel and OS patching: closes local escalation exploits.
• Modern Windows: LAPS (unique, rotated local administrator passwords), Credential Guard, high UAC, correct NTFS permissions.
• Detection: EDR and monitoring of anomalous process creation, service configuration changes, execution of linPEAS/winPEAS or of known tools.

• Reaching for a kernel exploit first. These are the most likely to bring down the host (kernel panic = an unagreed denial of service). Exhaust SUID, sudo, cron, and services first; leave the kernel for last and only by agreement.
• Not reverting a temporary change. Leaving an altered binPath or a stopped service breaks production and breaks the golden rule. Note the state before touching it and always restore it.
• Escalating and then rummaging through data. The PoC ends at uid=0/SYSTEM. Reading payroll or email exceeds the demonstration unless the RoE explicitly calls for it.
• Dismissing horizontal escalation as "not serious". Moving to another account at the same level is often the springboard to root or to sensitive data; document it.
• Reporting the path without the remediation. "Escalated to root" without saying which SUID or which sudo rule allowed it is of no use to the client. The value is in the specific fix.
• Forgetting that linPEAS/winPEAS are noisy. If the EDR does not detect them, that too is a finding (insufficient defense) that goes into the report.
• Tip: enumerate exhaustively before attempting anything. 90% of escalations are handed to you in the linPEAS/winPEAS output if you know how to read it.

Exercise 1. From your foothold as www-data on the TechNova store, find / -perm -4000 reveals that /usr/bin/find has SUID root. Explain why that allows escalation, write a low-impact PoC that only demonstrates the privilege, and give the exact remediation. How would the blue team detect this abuse?

Exercise 2. On a Windows workstation you have an ordinary user account. accesschk shows that you can reconfigure a service that runs as SYSTEM. Describe the escalation sequence while respecting impact control and reversion, what evidence you would capture, and two hardening measures that would have prevented it.

Exercise 3. Distinguish, with a TechNova example of each, vertical and horizontal escalation, and explain why horizontal—although it looks less severe—is documented just the same. Also state where escalation ends and what would already be the subject of lesson 05-03.

Solution 1. find with SUID root runs with the privileges of its owner (root), and find can launch commands with -exec; therefore it can run any command as root. Low-impact PoC (per GTFOBins), demonstrating only the privilege: find . -exec /bin/sh -p -c 'id' \;, whose output uid=0(root) is the proof—no persistent shell is opened and no files are touched. Remediation: that find should never have had SUID; remove it with chmod u-s /usr/bin/find and periodically audit SUID binaries with find / -perm -4000. Detection (blue team): kernel auditing (auditd) or the EDR alert on a child /bin/sh process with EUID 0 launched by find from an unprivileged account, an anomalous pattern characteristic of SUID abuse.

Solution 2. Sequence: (1) confirm with accesschk that the service is reconfigurable by our account; (2) note the original binPath before touching anything; (3) temporarily reconfigure it to a harmless command (cmd /c whoami > C:\Windows\Temp\poc.txt); (4) restart the service and read poc.txt, which shows nt authority\system as proof of execution with SYSTEM privileges; (5) immediately restore the original binPath with sc config and delete poc.txt, noting it in the engagement log. Evidence: the whoami as SYSTEM, time, and name of the affected service. Hardening that would have prevented it: (a) fix the service ACL so ordinary users cannot reconfigure it; (b) apply least privilege and audit services with accesschk periodically.

Solution 3. Vertical: from www-data (a service account) to root on the store server—rising in privilege level. Horizontal: from devapp to the contable account, both ordinary users without root privileges—moving from one account to another at the same level. Horizontal escalation is documented because it is often the springboard: contable may have access to sensitive data or a sudo rule that devapp did not, later enabling a vertical escalation. Escalation ends at control of the host (root/SYSTEM on that machine); using the obtained credentials or access to jump to other machines on the 10.10.10.0/24 network is already lateral movement (05-03), outside the scope of this lesson.

We have taken the first step of post-exploitation: turning a limited-privilege foothold into control of the host. We saw the difference between vertical and horizontal escalation; that the bulk of the work is enumerating (linPEAS/winPEAS) to find the misconfiguration already there; and we walked through the classic vectors on Linux (SUID, sudo, cron, capabilities, PATH, kernel) and on Windows (services, tokens, UAC, credentials), each with a low-impact PoC that only demonstrates the privilege, reverting every temporary change, and with its specific remediation. The defensive counterpart was constant: least privilege, hardening, and patching, with EDR-based detection.

We are now root/SYSTEM on one or more TechNova hosts, with the evidence captured. The attacker's next natural question—and therefore the pentester's, measuring their capability—is how to retain that access without having to re-exploit every time. That is 05-02 Maintaining Access: the persistence mechanisms, but understood as a demonstration of impact in an authorized engagement, with the defensive counterpart in the foreground and the golden rule more present than ever: everything created is documented and reverted.