Skip to content

Project — Internal Network Pentest

This project simulates an internal penetration test: you've been given a foothold on an organisation's internal network (as if an attacker phished a workstation, or you're testing from a network drop) and your objective is to see how far an attacker could get — ideally to high-privilege access or sensitive data — documenting every step. It exercises the whole of Level 3: scanning, validation, exploitation, privilege escalation, pivoting, and (if you built one) Active Directory. Run it entirely in your lab.

This is the closest the course comes to a realistic engagement, and the point is the attack chain and its documentation, not a single clever exploit. A good internal pentest report tells a story: "from an ordinary foothold, these specific weaknesses chained into this much access, and here is how to break the chain."

Lab setup

Build a small internal network in your lab (host-only/internal networking, Level 1 lesson 2):

  • An attacker VM (Kali/Parrot).
  • At least two targets — ideally a vulnerable Linux box (Metasploitable or a VulnHub image) and, if you can, a small AD lab (a Domain Controller + a joined workstation, Level 3 lesson 6).
  • Optionally a dual-homed host so you can practise pivoting (lesson 7) to an internal-only segment.

Snapshot every target "clean" before you start.

Scope & rules (practise the discipline)

In scope:  <your internal lab CIDR(s)>
Objective: demonstrate maximum realistic impact from the given foothold
Out of scope: the host's real LAN, the internet, anything not in the lab
Rules: snapshot before destructive steps; note (don't skip) anything fragile; no real data exfiltration

The workflow

1. Discovery & enumeration (Level 1)

From your foothold, discover live hosts and enumerate services on each (nmap -sn, then -sC -sV -p-). Build the per-host attack-surface table. If AD is present, enumerate the domain (users, groups, computers; run BloodHound as your foothold user).

2. Vulnerability analysis & validation (lesson 1)

For each host, identify candidate vulnerabilities (version→CVE, misconfigurations, weak services) and validate the promising ones. Separate real from false-positive. Prioritise by severity × reachability.

3. Exploitation — initial foothold expansion (lesson 2)

Gain access to a target via a validated vulnerability (snapshot first). Record the technique, the session, and the privilege level you landed at.

4. Privilege escalation (lessons 4 & 5)

On each foothold, escalate to root/SYSTEM via enumeration and a misconfiguration vector. Capture before/after id/whoami and the exact vector.

5. Credential gathering & lateral movement (lessons 3, 6, 7)

Harvest credentials/hashes/keys from each compromised host. Reuse them (pass-the-hash, reused passwords, SSH keys) to reach further hosts. Pivot into any segment your attacker box can't reach directly. If AD is present, work a BloodHound path toward Domain Admin (Kerberoast a weak service account, move to a box with privileged sessions, dump, pass).

6. Objective

Reach the defined objective (Domain Admin, the DC's NTDS.dit, a sensitive database, or whatever your lab represents as "crown jewels") — or document how far you got and what blocked you.

Keep an engagement log

Throughout, maintain a timestamped log: each command, each result, each decision. This is both your evidence trail and the skeleton of the report. A good entry:

2026-… 14:12  nmap -sC -sV -p- 10.10.0.20  -> open 22,445,3306; Samba <ver>, MySQL <ver>
2026-… 14:40  validated CVE-… on Samba (check positive); snapshot taken
2026-… 14:55  exploited -> shell as 'daemon' on 10.10.0.20 (evidence: id output saved)
2026-… 15:10  sudo -l reveals <binary> NOPASSWD -> root via GTFOBins escape (id=0 saved)
2026-… 15:25  found reused DB password in /var/www/config -> works for 'svc' on 10.10.0.30

Deliverable: the internal pentest report

  1. Executive summary — the story in plain language: starting point, worst outcome reached, overall risk, top recommendations. Readable by leadership.
  2. Scope & methodology — lab targets, tools, dates, the given foothold.
  3. Attack narrative / kill chain — the step-by-step path from foothold to objective, so the client sees exactly how the hops chained. This is the heart of an internal report.
  4. Findings — each weakness that enabled a hop, with severity (CVSS vector), evidence, impact, and remediation. Group by host or by theme.
  5. The single highest-value fixes — which one or two changes would have broken the chain earliest (e.g. "LAPS would have stopped lateral movement at the first hop").
  6. Findings table — sorted by severity.

Self-check

  • The attack narrative is reproducible from your engagement log.
  • Every hop names the specific weakness that enabled it, with evidence.
  • Severities have CVSS vectors and environment-adjusted reasoning.
  • You identified which fix breaks the chain earliest/most cheaply.
  • You stayed in scope, snapshotted before destructive steps, and exfiltrated no real data.
  • A leader could read the executive summary and a developer/admin could act on the findings.

How It Actually Works

Why is the chain the deliverable in an internal pentest, rather than the list of individual vulnerabilities? Because internal risk is multiplicative, not additive. On their own, most of the weaknesses you'll chain are unremarkable: an out-of-date service here, a reused local-admin password there, a service account with a weak password, a Domain Admin who logs into workstations. A vulnerability scanner would rate each "Medium" and move on. But security is only as strong as the path an attacker can walk, and these mediums compose: the out-of-date service gives a foothold, the reused password gives the second host, the Domain Admin's cached credential on that host gives the domain. The whole is catastrophically worse than the sum of its parts, and no per-finding tool can see it because each tool evaluates findings in isolation. The human tester's unique contribution is to walk the path and reveal that four "mediums" equal one "you lose the domain." That's why the narrative matters: it's the only artefact that communicates multiplicative risk, and it's what justifies fixing a "medium" that, in isolation, a client might defer.

It also reframes remediation economically. Because the risk is a chain, you don't have to fix everything to dramatically reduce risk — you have to break the chain, ideally at its earliest or cheapest link. If LAPS (unique local-admin passwords) would have stopped lateral movement at hop one, that single control neutralises the whole path even if the individual host vulnerabilities remain. This is the most valuable thing an internal report can tell a client: not just "here are twenty findings," but "here is the one or two changes that collapse the attack path." Identifying those chokepoints requires having walked the chain, which is exactly what this project trains. The discipline of the timestamped log, the snapshots, the harmless proofs and the in-scope rigour is what makes the resulting narrative trustworthy — a story the client can act on because every step is evidenced and reproducible.

Exercise

  1. Build the internal lab (two targets minimum; add AD and a pivot segment if you can) and snapshot everything clean.
  2. Run the full workflow from discovery to objective, maintaining a timestamped engagement log. Reach the objective or document what stopped you.
  3. Write the internal pentest report with all six sections, leading with the attack narrative.
  4. Identify the single fix that would have broken your attack chain earliest. Justify it over simply patching the first host.
  5. In your own words, explain why internal risk is "multiplicative, not additive," and why that means the attack narrative — not the findings list — is the core deliverable.