Practice — exploit and escalate privileges on a HackTheBox-style VM

What You'll Build

In this exercise you will carry an authorized, intentionally vulnerable lab VM through the full exploitation arc: recon a foothold, gain limited access using documented tooling, enumerate for privilege escalation, escalate to administrative control, and document every step with evidence. The deliverable is a compact engagement narrative, how initial access was gained, how privileges were escalated, and exactly how each step is remediated, mirroring the core loop of a real internal penetration test end to end.

Analogy🏏Cricket

🎬 Think of it like movies: Producing a film means running every department, scouting, shooting, editing, sound, then delivering one coherent final cut a distributor can actually screen, not a pile of loose reels. Just as the producer is judged by that single assembled cut, this exercise judges you by one consolidated, prioritized inventory drawn from passive discovery, active scanning, enumeration, and vulnerability triage. Just as no scene is shot without the studio's sign-off, none of this runs outside your authorized lab range. This reveals the recon sweep as delivering the final cut, not a heap of unassembled footage.

Prerequisites

A signed authorization for the lab VM and a clear scope, from Lesson 1, rehearsing the habit of confirming permission before any active step.
The recon workflow from Module 1, passive discovery, Nmap scanning, and service fingerprinting, to identify the foothold service.
Familiarity with the Metasploit workflow, from Lesson 7, including reading a module before running it and managing sessions responsibly.
Comfort with Linux and Windows privilege escalation enumeration, from Lessons 9 and 10, and the enumerate-verify-report loop.
Awareness of safe practice, from Lesson 8, preferring non-destructive demonstrations over crash-prone techniques on any host.

Setup & Project Structure

Run everything inside an isolated lab environment you are explicitly authorized to attack, never against systems you do not own or have written permission to test. Create a working directory to capture each phase's output and evidence, because in a real engagement the documentation is the product. Dated, named files make your narrative reproducible and let a teammate follow the exact path from foothold to escalation without repeating your work or guessing what you did.

Analogy🏏Cricket

💪 Think of it like fitness: Serious athletes train in a controlled gym they are cleared to use and keep a meticulous logbook, dating every set and weight so progress is reproducible and any coach can pick up exactly where they left off. Just as that controlled environment and dated logbook make training safe and auditable, working inside an authorized lab and saving each phase's output in dated, named files makes the recon sweep safe and reproducible. Just as an undocumented workout teaches nothing repeatable, an undocumented sweep produces findings no teammate can trust. This reveals disciplined setup as the training log that makes every result traceable.

bash

# Isolated, authorized lab only. Set up a documented workspace.
mkdir vm-engagement && cd vm-engagement
mkdir recon foothold privesc evidence

# Record scope and target up front as your reference of record.
cat > scope.txt <<'EOF'
AUTHORIZED LAB TARGET
  vm:     intentionally-vulnerable practice VM (isolated network)
  ip:     10.10.10.50
  rule:   this VM only; nothing outside the isolated lab network
EOF
cat scope.txt

Step 1 — Recon the Foothold

Begin by mapping the target, reusing Module 1's workflow. Discover open ports, fingerprint service versions, and identify a service whose version corresponds to a known, documented weakness suitable for gaining initial access. The goal here is not to exploit yet but to build the same precise service map a real test relies on, so that any later action targets a confirmed, in-scope service rather than a guess. Save all output as evidence for the narrative.

Analogy🏏Cricket

🎬 Think of it like movies: Before filming an action sequence, the director scouts the location and studies every angle, mapping exactly where each shot will work, so the shoot itself targets known, planned setups rather than improvising on the day. Just as that scouting precedes any camera rolling, mapping open ports and fingerprinting service versions precedes any exploitation, identifying a service whose version matches a documented weakness. Just as the goal at this stage is a precise plan, not a finished scene, the goal is a confirmed, in-scope entry point, not a foothold yet. This reveals that thorough recon is what lets every later action target a verified service instead of a guess.

bash

# Map the target and fingerprint services (authorized VM only).
nmap -sV -oA recon/services 10.10.10.50

# Identify a service whose version maps to a KNOWN, documented weakness.
grep -E 'open' recon/services.nmap

# Research that exact version -> confirm a suitable, in-scope entry point
# BEFORE any exploitation. Record the target service in your notes.

Step 2 — Gain Initial Access

With a confirmed vulnerable service identified, gain a limited foothold using documented tooling, following the disciplined Metasploit workflow from Lesson 7: read the module, inspect its options, verify applicability where possible, then execute against the in-scope target and manage the resulting session. This should yield low-privileged access, exactly the starting point real engagements face. Capture evidence of the access and note precisely what defenders could have observed during the attempt.

Analogy🏏Cricket

♟️ Think of it like chess: A strong player opens with a prepared, well-understood move aimed at a specific weakness in the opponent's setup, not a random lunge hoping something works. Just as that deliberate opening is played only after studying the position, initial access is gained only after reading the module, inspecting its options, and verifying applicability, then executing against the in-scope target and managing the session. Just as a single good opening move improves the position without winning the game, a low-privileged foothold opens the host without granting full control. This reveals that disciplined, understood execution, not a blind gamble, is what secures the first step.

bash

# Deliberate, understood exploitation of the confirmed service.
# Follow the Lesson 7 discipline; run only within scope.

# msfconsole
# use <module_for_the_confirmed_weakness>
# show options ; set RHOSTS 10.10.10.50 ; set LHOST <lab_ip>
# check              # verify applicability where supported
# run                # execute against the authorized VM
# sessions -l        # you now hold a LOW-PRIVILEGED session

# Evidence: capture 'whoami' / 'id' showing limited access.

Step 3 — Enumerate & Escalate Privileges

From your low-privileged foothold, run the enumerate-verify-report loop from Lessons 9 and 10. Enumerate SUID binaries or service permissions, scheduled jobs, sudo rights or privileges, and versions; verify each promising lead by hand; then choose the least disruptive confirmed path to escalate toward root or SYSTEM. Prefer a safe misconfiguration route over any crash-prone technique. Capture evidence at each stage so the escalation path is fully reconstructable in your report.

Analogy🏏Cricket

🎮 Think of it like gaming: Having entered a level, a skilled player systematically probes every wall and ledge for the one exploitable seam, then takes the safe, verified route to the objective rather than a reckless jump that ends the run. Just as the player picks the genuine weak point over a risky leap, a tester enumerates SUID binaries, permissions, sudo rights, and versions, verifies each lead by hand, and escalates by the least disruptive confirmed path rather than a host-crashing technique. Just as a completionist records each discovery, the tester captures evidence at every stage. This reveals that patient probing and verification, not brute force, drive a clean escalation.

bash

# Enumerate from the foothold, verify, then escalate least-disruptively.

# Linux example enumeration:
find / -perm -4000 -type f 2>/dev/null      # SUID candidates
sudo -l 2>/dev/null ; cat /etc/crontab      # sudo rights, scheduled jobs
uname -a                                    # version context

# (Windows equivalent: whoami /priv ; sc query ; icacls on service bins)

# Verify the most promising lead by hand -> escalate via that path ->
# capture 'id'/'whoami' proving root/SYSTEM. Prefer safe misconfig paths.

Step 4 — Document & Remediate

Finish by turning your captured evidence into a concise engagement narrative. For both the foothold and the escalation, record the vulnerability, the exact step taken, the proof of impact, and, most importantly, the specific remediation, patch the service, tighten permissions, remove the privilege. Confirm the write-up is clear enough that a defender could both understand the attack and close every step. This documentation, not merely reaching root, is the true product of the exercise.

Analogy🏏Cricket

💼 Think of it like business: A consulting engagement is judged not by the dramatic problems uncovered but by the clear final report, findings, evidence, and concrete recommendations a client can act on. Just as that write-up, not the discovery itself, is what the client pays for, the true product here is a concise narrative pairing each step, foothold and escalation, with the vulnerability, the proof of impact, and the exact remediation. Just as a good report lets a manager both grasp the issue and fix it, yours should let a defender understand the attack and close every step. This reveals that reaching root is only the setup; the remediable documentation is the deliverable.

bash

# Consolidate the chain into ONE remediable narrative -- the deliverable.
cat > evidence/report.md <<'EOF'
# Engagement Narrative — VM 10.10.10.50 (authorized lab)

## Foothold
- Vulnerability: <service + version> (known documented weakness)
- Step: exploited via <module>, gained low-priv session
- Proof: id -> low-privileged user
- Fix: patch/upgrade the service; restrict its exposure

## Privilege Escalation
- Vulnerability: <misconfig, e.g. writable root cron script>
- Step: verified by hand, escalated via that path
- Proof: id -> root / SYSTEM
- Fix: correct permissions; apply least privilege
EOF
cat evidence/report.md

Warning: Everything here is confined to your authorized, isolated lab VM. Running these exploitation and escalation steps against any system you do not own or lack written permission to test is unauthorized access and can be a crime. The tooling is identical regardless of target; only authorization makes it lawful. Prefer non-destructive demonstrations throughout, and never carry techniques practised in the lab onto real systems without a signed engagement behind them.

Extension Challenge: Strengthen the engagement three ways. First, for each step write both what you did and what a defender's logs or EDR would have shown, practising the detection-awareness Module 5 formalizes. Second, redo the escalation via an alternate confirmed path to show the host had multiple weaknesses. Third, draft a one-paragraph executive summary translating the technical chain into business risk for a non-technical reader.

A full exploitation exercise runs the real engagement loop: recon a foothold, gain limited access, enumerate, escalate privileges, and document with evidence.
Everything stays inside an authorized, isolated lab VM, since identical tooling is only lawful when a signed authorization and clear scope stand behind it.
Recon fingerprints services to identify a confirmed, in-scope weakness, so initial access targets a known entry point rather than a blind guess.
Initial access follows the disciplined Metasploit workflow, read the module, verify, execute, manage the session, and yields a low-privileged foothold.
Escalation applies the enumerate-verify-report loop, preferring the least disruptive confirmed misconfiguration path over any crash-prone technique.
The true deliverable is a clear, remediable narrative pairing each step with proof of impact and the specific hardening that closes it, not merely reaching root.