9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

Syllabus item F2 is broad and practical. It requires: knowledge of recent or commonly found Linux vulnerabilities with public exploit code; use of remote exploit code and local exploit code to gain root access; and the common post-exploitation activities — exfiltrate password hashes, crack password hashes, check patch levels, derive the list of missing security patches, and revert to the previous state.

This section ties together the enumeration from 9.1–9.5 into the exploitation and post-exploitation phases. Everything here assumes the host is in scope and the activity is authorised: gaining root on a client system is exactly what the Rules of Engagement and the Computer Misuse Act govern.

---

1. Remote vs Local Exploitation

The two words carry precise meaning:

• Remote exploit — code delivered over the network against a listening service, requiring no prior access. It yields an initial foothold, typically as the unprivileged account the service runs as (www-data, postgres, nobody).
• Local exploit — code that must be run on the host by an already-present user, abusing a kernel flaw, a SUID binary or a misconfiguration to escalate privilege, usually to root.

The canonical chain is remote-to-root:

  Internet / network
        |
        v
  [ Remote exploit against a service ]  --> shell as www-data (unprivileged)
        |
        v
  [ Local privilege-escalation exploit ] --> shell as root (uid 0)
        |
        v
  [ Post-exploitation: harvest, assess, revert ]

A well-patched host may be immune to the remote step but still vulnerable to the local step, which is why a credentialed assessment (given a low-privileged account) is so productive: it starts you where a remote exploit would land and tests the escalation surface directly.

---

2. Notable Linux Vulnerabilities With Public Exploits

The syllabus wants awareness of the classes and the landmark examples, not an exhaustive list.

Local Privilege Escalation (kernel and userland)

Remote Service Vulnerabilities

The workflow is always the same: enumerate the exact version, match it to public exploit data, verify applicability, then exploit. searchsploit <product> <version>, the Exploit-DB, and linux-exploit-suggester / les.sh automate the matching against a captured uname -a and package list.

---

3. Post-Exploitation: Harvesting Credentials

Once root is obtained, the priority is credential material that enables lateral movement.

Exfiltrate the Hashes

# The credential files (readable as root)
cp /etc/passwd /etc/shadow /tmp/loot/          # then exfiltrate
unshadow /etc/passwd /etc/shadow > /tmp/loot/unshadowed.txt

The $id$ prefix in /etc/shadow identifies the hashing scheme, which determines cracking speed and tooling:

Crack the Hashes

hashcat -m 1800 unshadowed.txt wordlist.txt      # -m 1800 = sha512crypt ($6$)
john --format=sha512crypt unshadowed.txt --wordlist=wordlist.txt

The mode number must match the prefix (500 for $1$, 7400 for $5$, 1800 for $6$, 3200 for bcrypt). Beyond /etc/shadow, harvest SSH private keys (~/.ssh/id_*), history files (.bash_history, .mysql_history), application configs with database and API credentials, and cached cloud credentials (~/.aws, ~/.kube, instance metadata).

---

4. Post-Exploitation: Patch-Level Assessment and the Missing-Patch List

The same host-audit techniques from section 7.4 apply here, now with root:

uname -a                              # kernel version and build
rpm -qa --last | head                 # RHEL family: installed packages, newest first
dpkg -l                               # Debian family
yum updateinfo list security          # outstanding security advisories (RHEL)
apt list --upgradable                 # available updates (Debian/Ubuntu)

Deriving the missing-patch list means comparing installed package versions against the distribution's security advisory feed (RHSA/DSA/USN). Remember the backporting paradox from 7.4: on enterprise Linux the upstream version is frozen while fixes are added to the package release, so the missing-patch judgement must be made from the package build string and changelog, not the banner. The missing-patch list is what confirms, retrospectively, which of the public exploits above would actually have worked.

---

5. Post-Exploitation: Reversion to Previous State

"Reversion to previous state" is an explicit F2 requirement and a professional obligation. A penetration test must not leave the host weakened or littered with tooling:

• Remove uploaded tooling and payloads — enumeration scripts, exploit binaries, netcat listeners, the /tmp/loot directory.
• Restore any modified files — if you appended a line to /etc/passwd, backed up and edited a config, or replaced a binary during exploitation, restore the original. Keep a record of exactly what you changed (this is why record-keeping runs alongside exploitation).
• Remove created accounts, cron jobs, SSH keys and SUID backdoors placed for persistence during the test.
• Restore file permissions and ownership you altered.
• Note anything that cannot be cleanly reverted — a rebooted host, a crashed daemon, a rotated log — and report it, so the client can verify state.

Crucially, preserve rather than destroy evidence: reversion means removing your artefacts and undoing your changes, not wiping logs to hide activity. Deleting the client's logs would both destroy the evidence trail the engagement depends on and cross the line from testing into anti-forensics. If an interim critical finding warrants it, escalate before continuing (see the record-keeping and escalation section).

---

6. The End-to-End Workflow

 1. Enumerate service + version   (9.2-9.5)      -> attack surface
 2. Match to public exploits      searchsploit    -> candidate remote/local exploits
 3. Remote exploit                over the network-> foothold as service account
 4. Local enumeration             LinPEAS, les.sh -> escalation candidates
 5. Local exploit                 kernel/SUID     -> root
 6. Harvest credentials           shadow, keys    -> lateral movement material
 7. Assess patch level            package manager -> missing-patch list
 8. Document + revert             notes, cleanup  -> host left as found

Each transition is evidence for the report: the exact exploit used, the account obtained at each step, the hashes recovered and cracked, and the missing patches that explain the exposure. That evidence — not the mere fact of "we got root" — is what lets the client prioritise remediation.