July 2, 2026

VAPT Series Part 5: Post-Exploitation & Reporting

A practical, ethics-first walkthrough of what happens after you get a shell — and how to turn that access into a report that actually gets…

By Muhammad Badhusha Muhyideen Qadiri J

4 min read

A practical, ethics-first walkthrough of what happens after you get a shell — and how to turn that access into a report that actually gets vulnerabilities fixed.

Where We Left Off

In Part 5, we walked through exploitation in our lab environment and landed an initial foothold — a low-privileged shell on a domain-joined workstation. That shell is not the finish line. It's the starting point for the phase most junior testers underinvest in: post-exploitation, and the phase most testers dread: reporting.

A vulnerability that isn't escalated, documented, and communicated clearly might as well not have been found. This post covers both halves of that equation.

⚠️ Reminder: Everything below assumes you are operating in a lab environment or under a signed, scoped engagement with explicit written authorization. Post-exploitation actions — credential dumping, lateral movement, persistence — are exactly the kind of activity that turns a legal pentest into a crime the moment scope or consent is missing.

Part A: Post-Exploitation

Post-exploitation generally follows four goals: situational awareness, privilege escalation, credential harvesting, and lateral movement mapping. You're not trying to "own everything" — you're trying to demonstrate realistic business impact within your defined scope.

1. Situational Awareness

Before touching anything else, orient yourself:

  • Who am I? (whoami /all on Windows, id on Linux)
  • What privileges/tokens do I hold?
  • What's installed, what's running, what talks to what?
  • Is this box monitored (EDR, AV, logging agents)?

This is the "look before you leap" step. Skipping it is how testers trip alarms unnecessarily or waste time attacking a dead end.

2. Credential Harvesting

This is where tools like Mimikatz and LaZagne come in.

  • Mimikatz pulls credentials, hashes, and Kerberos tickets directly from LSASS memory on Windows — the classic sekurlsa::logonpasswords and sekurlsa::tickets are usually the first commands run.
  • LaZagne is broader but shallower: it sweeps dozens of applications (browsers, mail clients, WiFi, password managers) for locally stored credentials rather than digging into memory.

Together they answer: what does this machine already know that gets me further?

3. Domain Awareness with BloodHound

Once you have any valid domain credentials — even low-privileged ones — BloodHound turns raw AD data into an attack-path graph. It answers the question that matters most to a client: "if an attacker compromises this one laptop, how many hops are they from Domain Admin?"

This is usually the single most impactful visual in a VAPT report. Clients understand a graph showing "IT-Helpdesk-User → 3 hops → Domain Admin" far faster than they understand a CVE number.

4. Ticket Abuse with Rubeus

Rubeus operates on the Kerberos layer — requesting, harvesting, and replaying tickets (TGTs/TGSs), and supporting attacks like Kerberoasting or pass-the-ticket. It's typically used once BloodHound has identified a promising path that runs through Kerberos delegation or service accounts.

5. Command and Control for Sustained Access

If the engagement scope calls for demonstrating sustained access (not just a snapshot), a C2 framework like Merlin lets you simulate what a real intrusion looks like over time — beaconing, tasking, and exfil channels — rather than a single smash-and-grab shell.

6. Memory Forensics as a Dual-Use Skill

Worth noting: everything above generates artifacts. Running Volatility against a memory image of a compromised host (yours or the client's, with permission) is how you validate — from the defender's side — what an attacker action actually left behind. Good pentesters think about detectability, not just exploitability.

A Simple Post-Exploitation Flow

Initial Foothold
      │
      ▼
Situational Awareness (whoami, privileges, AV/EDR check)
      │
      ▼
Credential Harvesting (Mimikatz, LaZagne)
      │
      ▼
Domain Mapping (BloodHound)
      │
      ▼
Path Validation (Rubeus, Kerberoasting, ticket abuse)
      │
      ▼
Lateral Movement / Privilege Escalation
      │
      ▼
Evidence Capture ── screenshots, hashes, command output, timestamps

Every arrow in that chain needs to be documented as you go, not reconstructed from memory afterward. This is the bridge into reporting.

Part B: Reporting

A technically brilliant test with a weak report gets the finding closed as "won't fix." A mediocre test with a clear report gets budget allocated. Reporting is not an afterthought — it's the deliverable.

Core Report Structure

  1. Executive Summary — one page, no jargon. What was tested, what was found, overall risk posture, and top 3 business-impact statements. This is the only section most executives read.
  2. Scope & Methodology — what was in/out of scope, testing window, standards followed (e.g., PTES, OWASP), and any limitations.
  3. Risk Summary Table — findings sorted by severity (Critical/High/Medium/Low), with CVSS scores if used.
  4. Detailed Findings — one per vulnerability, using a consistent sub-structure:
  • Title & Severity
  • Affected Asset(s)
  • Description (what it is)
  • Impact (why it matters, tied to business risk — e.g., "allows domain-wide compromise from a standard user account" rather than just "privilege escalation")
  • Evidence (screenshots, command output, the attack path from BloodHound)
  • Reproduction Steps (clear enough that a developer can replicate without you present)
  • Remediation (specific, actionable — not just "patch the system")

5. Attack Narrative — optional but powerful: a chronological story of the engagement ("Compromised low-priv user via phishing simulation → dumped local creds with Mimikatz → identified Kerberoastable service account via BloodHound → cracked hash offline → obtained Domain Admin"). This is often what makes leadership actually feel the risk.

6. Appendices — raw tool output, full command logs, IOCs if relevant.

Writing Findings That Get Fixed

A few habits separate reports that drive remediation from reports that get filed away:

  • Write impact in business terms first, technical terms second. "An attacker with access to a single low-privileged laptop can obtain full domain control within four steps" lands harder than "LSASS credential dumping via Mimikatz was possible."
  • Never inflate or deflate severity. CVSS scoring should be consistent and defensible — your credibility as a tester rests on this.
  • Remediation must be specific and prioritized. "Disable unconstrained delegation on Server X" beats "improve AD hardening."
  • Screenshots need context, not just raw terminal output — annotate what the reader is looking at.
  • Redact real sensitive data (actual passwords, PII) even in an internal report unless the client specifically wants it preserved for validation.

A Minimal Reporting Ethics Checklist

  • All findings map to something explicitly in scope
  • No credentials or sensitive data are exposed beyond what's needed for evidence
  • Attack paths are reproducible by the client's own team
  • Severity ratings are consistent and justified
  • The executive summary can stand alone without technical background

Closing Thoughts

Exploitation gets the adrenaline; reporting gets the budget approved. A VAPT engagement's real value isn't the shell you popped — it's whether the organization walks away with a clear, prioritized, actionable understanding of their risk. Post-exploitation shows how bad it could get; reporting is what convinces someone to actually fix it.

Next up in the series: Part 7 — Remediation Validation & Retesting, where we close the loop and confirm fixes actually hold.