Skip to content

Post-Exploitation & Evidence Handling

Getting a shell is the middle of the engagement, not the end. Post-exploitation is what you do after access: determining the real impact, collecting just enough proof, and doing it all without causing harm or overstepping scope. This is where the ethical discipline of the whole course is tested hardest — you now have power over the target, and professionalism is defined by what you don't do with it. Lab and authorized engagements only.

The goals of post-exploitation

  1. Assess impact — what does this access actually mean? What data, systems and privileges are reachable from here? This is what turns "I got in" into a business-risk statement.
  2. Gather evidence — enough proof that the access and its impact are undeniable, and no more.
  3. Enable the next phase — collect credentials and intel that support privilege escalation and lateral movement (Level 3), if in scope.
  4. Maintain access if required — some engagements (especially red teams) want persistence to test detection; most pentests do not. The RoE decides.

Assessing impact (the real deliverable)

Once in, methodically establish reach — within scope:

  • Who am I and what can I do? Privilege level, groups, what this account accesses.
  • What sensitive data is here? Note that it exists and is accessible (file names, database tables, a count of records) — you generally do not copy it out.
  • What else can I reach? Other hosts, internal services, network segments.
  • What credentials are available? For escalation/lateral movement, if scoped.

The output is a clear statement: "From this foothold, an attacker could read the customer database, reach the internal finance subnet, and obtain domain credentials." That sentence, backed by evidence, is worth more than any individual exploit.

Evidence: prove impact, don't cause it

The guiding rule from Level 1 lesson 1 reaches its sharpest point here. Good evidence:

  • Screenshots of id/whoami, of a directory listing proving access, of a redacted record proving reach.
  • Command output saved with timestamps.
  • A proof token — e.g. creating a single harmless file like pentest-proof-<date>.txt in a location only a successful attacker could write, then showing it. This proves write access without touching real data.
  • For sensitive data, prove access with the minimum: the table exists, you can query its row count, one record with PII redacted. Do not exfiltrate the dataset.

What you must not do: download real customer/PII data beyond a redacted sample, read personal communications out of curiosity, modify or delete production data, degrade the service, or go outside scope because a pivot looks tempting. Every one of these is a breach of ethics and usually of law, even mid-engagement.

Data handling

You will inevitably see real data. Handle it per the RoE:

  • Store evidence encrypted; access it on a controlled machine.
  • Redact PII in the report (show enough to prove the finding, not the data itself).
  • Destroy collected data after the engagement per the agreement, and say so in the report.
  • Treat any genuinely sensitive discovery (evidence of a prior breach, illegal content, safety issues) via the pre-agreed escalation path immediately — this is why the RoE names an emergency contact.

Persistence & cleanup

  • Persistence (backdoors, scheduled tasks, added accounts) is only for engagements that explicitly test detection/response, and everything you plant must be documented and removed.
  • Cleanup — remove tools, shells, proof files (except as agreed), added accounts, and tunnels. Leave the target as you found it. An engagement that leaves a live backdoor behind has created a vulnerability.
  • Log your changes so the client can verify the environment is clean.

A worked example (reasoning)

You reach root on a lab database server. Post-exploitation, in scope: you run id (screenshot), confirm the MySQL data directory is readable, connect and run SELECT COUNT(*) FROM customers (proof the data is reachable — you record the count, not the rows), and note one record with all PII redacted as a sample. You create pentest-proof-2026-…​.txt in /root/ to prove write access. You find a reused DB password that also works for a system account (captured for the lateral-movement finding). You do not dump the customers table. You document: full host + database compromise, evidence (screenshots, the count, the proof file), impact (all customer records exposed), and the fix. Afterwards you remove the proof file and report that you did.

How It Actually Works

Why is "prove impact, don't cause it" not just an ethics slogan but the thing that makes a finding valid and safe at once? Because a penetration test is a measurement, and a good measurement disturbs the system as little as possible while still being conclusive. The client needs to believe the finding — a vague "I think I could have read the database" is arguable and gets dismissed — so you need undeniable evidence. But the client also needs the test to be safe — a pentest that exfiltrates the customer database has, in the act of proving the risk, realised the risk: that data is now copied, and copying is the very harm the client feared. The resolution is to find the minimum sufficient proof: the row count and a redacted sample prove the data is reachable (the risk is real) without copying it (the harm doesn't happen). A proof file proves write access without altering anything that matters. id proves privilege without using it. Each piece of evidence is chosen to be conclusive about the capability while being inert about the consequence — which is exactly the distinction between demonstrating that a door is unlocked and actually robbing the house.

This also explains why scope discipline bites hardest in post-exploitation. The whole point of authorization (Level 1 lesson 1) is that permission, not harmlessness, is what makes the work legal — and now that you have power over the system, the temptation to "just check" an out-of-scope host or "just look" at interesting data is strongest precisely when acting on it does the most damage to trust and legality. The professional's restraint here is not timidity; it's the understanding that the engagement's value is destroyed the moment the tester becomes a second attacker. Cleanup follows the same logic: a test is supposed to measure the system's security, not change it, so any artefact you leave (a backdoor, an added account, a live tunnel) converts your measurement into a new vulnerability — you would have made the client less secure by testing them, the opposite of the job.

Common mistakes and pitfalls

  • Exfiltrating real data to "prove" a finding. The row count and a redacted sample prove it; the copy is the harm. Don't.
  • Scope creep under temptation. A reachable out-of-scope host is still out of scope. Note it; don't touch it.
  • Reading personal data out of curiosity. You'll see things; look only as far as the finding requires.
  • Leaving artefacts behind. Undocumented shells, accounts, proof files or tunnels left running are new vulnerabilities you created. Clean up and log it.
  • Modifying or risking production data/service. A pentest must not degrade what it measures.
  • Sitting on a critical/urgent discovery. Evidence of an active breach or a safety issue goes up the agreed escalation path now, not in the final report.

Exercise

  1. On a lab host you've compromised, perform an ethical post-exploitation pass: capture id, prove data reachability with a count (not a dump), and create a harmless proof file. Save the evidence.
  2. Write the impact statement for that foothold in one or two sentences a manager would understand.
  3. List three things you saw or could have done that you deliberately did not, and explain why each would have crossed an ethical or scope line.
  4. Perform cleanup: remove your proof file and any artefacts, and write the cleanup log entry.
  5. Explain, in your own words, how "minimum sufficient proof" lets a finding be conclusive and safe at the same time, using the unlocked-door analogy.