Post-Exploitation: Measuring Persistence & Responsible Cleanup

Prerequisites

• PEN-K010: Exploitation & Privilege Escalation

Why This Lesson Matters

Post-exploitation in a pentest is not the same as in a red team operation. You are not trying to maintain long-term access — you are demonstrating what an attacker could do if they wanted to. Every persistence mechanism you install must be documented, limited in duration, and removed at engagement close. This lesson is as much about professional responsibility as it is about technique.

1. Why Post-Exploitation Is Tested

Clients need to know: if an attacker got in, what could they do next?

Post-exploitation objectives in a scoped pentest:

1. Demonstrate privilege level achieved (user / admin / SYSTEM / root)
2. Demonstrate data access (read sensitive files — minimum necessary)
3. Demonstrate persistence capability (install one mechanism, document it, remove it)
4. Demonstrate lateral movement capability (see PEN-K011)
5. Map the blast radius: what additional systems are reachable from here?

None of these require exfiltrating real data, installing permanent backdoors, or causing service disruption.

2. Documenting What You Could Have Done

Sometimes the most professional approach is to describe the impact rather than fully execute it:

Finding: Root-level access obtained on SRV-001

Demonstrated:
  ✓ Privilege level: root (uid=0)
  ✓ Sensitive file access: /etc/shadow read (password hash of admin account extracted)
  ✓ Persistence capability: installed a cron job at /etc/cron.d/test-beacon
    (runs every 5 minutes; removed at 16:45 UTC on 2026-06-08)

Not demonstrated (to limit impact):
  → Did not attempt to crack the shadow hashes
  → Did not attempt lateral movement to database cluster
     (would likely succeed via credential reuse — see Recommendation R-003)

This approach shows professionalism and respects the client's production environment.

3. Persistence Techniques (For Testing, Not Permanent Use)

3.1 Linux — Cron Job (Test Persistence)

# Add a cron job as proof of persistence capability
echo "*/5 * * * * root echo 'pentest-beacon' > /tmp/pentest_proof.txt" 
  > /etc/cron.d/pentest-beacon-001

# Verify it runs (wait 5 minutes)
cat /tmp/pentest_proof.txt
# "pentest-beacon" → persistence confirmed

# REMOVE IMMEDIATELY after confirmation (same session if possible)
rm /etc/cron.d/pentest-beacon-001
rm /tmp/pentest_proof.txt

3.2 Windows — Scheduled Task (Test Persistence)

# Install test persistence (Windows)
schtasks /create /sc minute /mo 5 /tn "PentestBeacon001" 
  /tr "cmd.exe /c echo pentest > C:WindowsTempproof.txt" /ru SYSTEM

# Verify
Get-Content "C:WindowsTempproof.txt"

# REMOVE
schtasks /delete /tn "PentestBeacon001" /f
Remove-Item "C:WindowsTempproof.txt"

4. The Engagement Cleanup Checklist

At the end of every engagement, run through this checklist before declaring the test complete:

ENGAGEMENT CLEANUP CHECKLIST

[ ] All test user accounts removed
[ ] All persistence mechanisms removed:
    - Cron jobs added: (list them)
    - Scheduled tasks added: (list them)
    - Registry run keys added: (list them)
    - Services installed: (list them)
    - Web shells uploaded: (list them)
    - SSH authorized_keys added: (list them)
[ ] All staging/upload directories cleaned
[ ] All SOCKS proxies / tunnels terminated
[ ] All downloaded sensitive data securely deleted
[ ] All Metasploit sessions closed

If anything cannot be removed:
  → Notify the emergency contact immediately
  → Document the item and its location in the final report
  → Provide manual removal instructions

5. Common Mistakes

Mistake 1: Forgetting about persistence you installed three days ago. Keep a running log of every action taken during the engagement, with timestamps. At close, reference the log for cleanup — not your memory.

Mistake 2: Exfiltrating real sensitive data "to prove the risk." Extract one clearly identifiable sample (e.g., the first row of a table with only non-PII columns, or a file named "test_flag"). Never take real PII, financial data, or credentials off the system beyond what the RoE explicitly permits.

6. Practice Exercises

1. After installing a test cron job, you lose your session before removing it. What do you do?

2. You have root on a Linux server. The client asks you to prove you could exfiltrate their database. Describe the minimum action that proves the claim without copying any actual customer data.

3. Your cleanup checklist shows a web shell at /var/www/html/uploads/sh3ll.php that you uploaded on day 1. Write the cleanup action and the chain-of-custody note for the final report.

7. Lab

Assessment mode: quiz

5 scenario questions: identify missing cleanup items, determine what "minimum necessary" looks like for three impact demonstrations, and review a final cleanup log for gaps.

8. Framework Alignment

9. Further Reading

• PTES Post-Exploitation section — http://www.pentest-standard.org/index.php/Post_Exploitation
• Covenant C2 documentation — Reference for understanding what post-exploitation infrastructure looks like in practice

["Produce a post-exploitation summary that documents privilege level, data access proof, and persistence capability while explicitly noting what was NOT done to limit impact", "Execute a test cron job persistence mechanism on Linux, verify it runs, then remove all traces and document the cleanup action in chain-of-custody format", "Complete an engagement cleanup checklist from a provided list of actions taken during a test and identify three items that must be removed before the engagement is declared closed"]

Prerequisites → Why this matters → Post-exploitation objectives in a pentest → Documenting what you could have done → Persistence techniques (Linux cron, Windows scheduled task) with install + verify + immediate removal → Engagement cleanup checklist → Common mistakes → Practice exercises → Quiz lab → Framework alignment → Further reading