| name | post-exploit |
| description | Post-exploitation methodology mapped to MITRE ATT&CK tactics — privilege escalation, credential access, discovery, lateral movement, persistence and defense evasion across Windows/Linux/cloud. Pattern-level technique categories with D3FEND defensive counters and a detection opportunity per step. |
Post-Exploitation Playbook
RoE-only and lab discipline: post-exploitation is by definition post-foothold, which means the attacker is already through the front door. The RoE must explicitly allow the next steps: which commands, on which systems, within which time window, with which limits on data access and persistence cleanup. Do not run techniques on production without that agreement on file. Specific EDR-bypass recipes, ready-to-run beacons, and version-targeted privilege-escalation exploits do not live in this skill — those belong in the engagement workspace.
When to use
A successful initial access marks the beginning, not the end, of a red-team / pentest engagement. This skill provides the structural lens for what happens after foothold: which questions you answer, which techniques map to which tactic, what the defensive counterpart is, which detection opportunity you must document for purple-ops and detection-engineer.
Triggers on:
- A question like "what do we do after initial access", "which privesc techniques on Linux", "Kerberoasting in scope", "lateral movement without Mimikatz", "a persistence mechanism visible enough for detection tuning".
- A red-team engagement where Initial Access via
phishing-sim or web-exploit-triage has been gained and you are moving to the next ATT&CK tactic.
- A purple-team exercise where you plan deliberate attack steps so the blue team can tune detection —
purple-ops drives that planning.
- A cloud engagement where the foothold is a stolen IAM credential and you do discovery + privesc + persistence in cloud context.
When NOT (handoff)
- Initial access (phishing, web exploit) →
phishing-sim, web-exploit-triage, exploit-chain. This skill begins after the first foothold.
- AD-specific deep-dive (BloodHound paths, Kerberos abuse, ADCS attacks) →
ad-attacks. Lots of overlap with this skill; this is the overarching lens, AD-attacks the domain-specific implementation.
- C2 infrastructure and beacon tuning →
c2-hygiene. This skill names C2 as an ATT&CK tactic; that skill provides the operational setup.
- Payload crafting for discovery/escalation shellcode →
payload-crafter at pattern level.
- Detection side (sigma rules, KQL queries on these techniques) →
detection-engineer. This skill provides the attack side, which is why purple-ops is often the counterpart.
- IR/forensics after exploit →
ir-runbook, forensics-assist.
- Final reporting →
pentest-reporter.
Approach
Seven phases. Phase 1 (foothold validation + scope) and phase 7 (cleanup) are the discipline bumpers; phases 2–6 cover ATT&CK tactics.
1. Foothold validation and scope check
Before doing anything post-exploit:
- Document foothold status: which user context, which system, which privileges. An unprivileged web shell on a container is a different starting point than root on a jumphost.
- Re-confirm RoE scope: what else can you do? Some engagements stop at initial access (boundary test). Others permit lateral movement up to specific target systems ("trophies"). Others are full red-team without restriction within the assigned scope.
- Out-of-scope systems: which systems are reachable but not in scope. Pivot paths that go through them are off-limits even when technically possible.
- Time window: post-exploit steps are usually noisy. Schedule on the agreed slot, log start/end for blue-team coordination.
- Trophy criteria: what counts as "done" in the engagement? Specific file access, domain admin, cloud admin, exfil confirmation via a known channel? Define up front, write down non-negotiable lines.
2. Privilege Escalation (ATT&CK TA0004)
From foothold to higher privilege. Per platform:
- Linux (class level):
- Kernel exploit (version-specific; CVE check via
uname -a + cve-triage handoff). Class name, no specific exploit here.
- Misconfigured sudo (
sudo -l as a probe), wildcards in sudoers, suid binaries.
- Cron jobs writable by the current user.
- Capability misconfig (file caps that put
cap_sys_admin on a binary).
- Path hijack via a writable PATH directory.
- SSH key in a user home that grants root access elsewhere.
- Windows (class level):
- Unquoted Service Path, weak service permissions (BINARYPATH overwrite), DLL hijacking.
- AlwaysInstallElevated registry.
- Token impersonation (SeImpersonate, SeAssignPrimaryToken — "potato"-class techniques map to T1134).
- JuicyPotato/RoguePotato/PrintSpoofer-class — pattern name, no version-specific executable here.
- Stored credentials in registry/files.
- Cloud:
- IAM-policy misconfig (overly permissive role chained into admin).
- Metadata-service credential extraction (see SSRF in
web-exploit-triage).
- Lambda/Cloud Function with a high-privilege role for which you hold
iam:PassRole.
- GCP equivalent: service-account impersonation ladders.
D3FEND counterpart: kernel patching, least privilege, EDR rules on token impersonation, IAM monitoring.
Log a detection opportunity per technique for handoff to detection-engineer/purple-ops.
3. Credential Access (TA0006)
- OS credential stores:
- Linux:
/etc/shadow (after privesc), SSH keys, .bash_history, .netrc, .aws/credentials, .kube/config.
- Windows: SAM/LSASS memory, DPAPI-protected secrets, browser-stored creds, RDP history. Pattern name: LSASS dumping (T1003.001) — defensive counterpart: Credential Guard, EDR LSASS protection.
- Application credential stores:
- Memory scraping for in-app secrets.
- Config files with hardcoded creds (see also
secrets-scanner-style discovery, but now post-foothold).
- Web-app auth cookies via local files or memory.
- Network-based:
- LLMNR/NBT-NS poisoning (Responder-class) on networks with legacy name resolution. Pattern name; tool execution belongs in a lab.
- Kerberoasting + AS-REP roasting →
ad-attacks.
- Cloud:
- Instance-metadata service for instance credentials.
- Cross-account-trust misuse via assumed-role chain.
- Secret-manager API with an overly permissive role.
Discipline: extracted credentials are not reused outside the engagement scope (e.g. not Have-I-Been-Pwned-checked against production mailboxes). Storage in an encrypted local-engagement vault, deletion after report delivery.
4. Discovery (TA0007) and Lateral Movement (TA0008)
- Discovery:
- System info: users, groups, processes, services, scheduled jobs, network config, mounted shares.
- Network discovery: ARP cache, routing table, internal DNS queries, port scans on internal networks (note: this is internal action, the scope check still applies).
- Cloud discovery: enumerate roles, policies, buckets, pubsub topics — read-only API calls, no modifications.
- AD discovery: BloodHound
SharpHound-class collection (see ad-attacks).
- Lateral Movement:
- SSH-key reuse (stolen key + another host).
- WMI/PsExec-class execution (Windows native admin paths).
- Pass-the-Hash, Pass-the-Ticket (Windows + AD; see
ad-attacks).
- SMB relay within the network.
- Cloud lateral via assumed-role chain.
Discipline: lateral movement is high-impact. Per-step confirmation of scope; track which new systems you touch so the blue team knows where to look.
5. Persistence (TA0003) — only where the engagement goal demands it
Persistence is a red-team-specific question. In a standard pentest it is usually not needed (engagement is point-in-time). In a red-team it may be required to simulate realistic APT behavior.
- Windows: scheduled tasks, service installation, registry run keys, WMI subscription, COM hijack, BITS jobs.
- Linux: cron, systemd unit, .bashrc / .profile, init scripts, malicious package install, SSH authorized-keys add.
- Cloud: a new IAM user / service account, a long-lived access key, a Lambda trigger on event, cross-account trust.
- Application layer: web shell, scheduled job in app, modified config file.
Cleanup discipline is required. Persistence created for demonstration is removed after the engagement: scheduled tasks deleted, registry keys removed, IAM users/keys revoked. The pentest report documents what was created and the proof of removal.
6. Defense Evasion (TA0005) — defensive lens
For red-team realism and for blue-team feedback. Per technique class, what the attacker does and what the defender can see.
- Process injection (T1055-class): EDR sees thread injection, defensive D3FEND supports detection.
- Obfuscated/encoded payloads: AMSI-bypass-class (Windows), encoded base64/string-concatenation shapes, packed binaries. Pattern name; working AMSI-bypass recipes are EDR-vendor-specific and belong in an engagement vault.
- Living-off-the-land binaries (LOLBAS/GTFOBins): native admin tools used for goals that malware normally pursues. PowerShell, MSHTA, Certutil. Pattern name.
- Timestomping, log clearing: cleanup of your own footprints. Do not do this in standard engagements without an explicit "we may erase traces" clause.
- Cloud-specific: disable CloudTrail logging (high impact, almost always out of scope), region hopping, ephemeral resources that clean themselves up.
Detection-opportunity discipline: your report must mention, for every evasion technique, which signal it left behind so the detection engineer can tune for it.
7. Cleanup, documentation, handoff
- Cleanup checklist: all persistence removed, all test accounts/keys revoked, all created files removed (where the engagement allows — sometimes they are kept as evidence).
- Per-step documentation for
pentest-reporter:
- Tactic + technique + ATT&CK T-ID.
- Timestamp.
- From which system, to which system, with which credential.
- Detection opportunity (signal shape).
- Cleanup status.
- Handoff to
purple-ops for detection tuning: which techniques the blue team missed, which signals they could have caught.
- Handoff to
detection-engineer for concrete sigma/KQL rule ideas based on the techniques you used.
Verification-loop
Layer 1: scope (all steps within RoE, no out-of-scope systems touched?), assumptions (foothold context remains as started, not silently elevated through techniques you did not consciously execute?), gaps (cleanup checklist 100%, no leftover persistence?). Layer 2: ATT&CK T-IDs correct (T1003 LSASS dumping, T1055 process injection, T1078 valid accounts, etc.), no invented techniques, D3FEND counter-mappings real, detection-opportunity claims supported.
Output
Post-exploitation log — <engagement>
Foothold: <user context, system, privileges, date/time>
Trophy goal: <what counts as "done">
RoE scope: <which systems permitted for next steps>
Per step (chronological):
| Time | Tactic (TA-ID) | Technique (T-ID) | From | To | What | Cleanup status | Detection opportunity |
Privilege Escalation: <reached level + path>
Credential Access: <which creds, how obtained, where stored during engagement>
Discovery: <inventory: users/systems/cloud resources>
Lateral Movement: <which new systems, with which creds>
Persistence: <if created: what, with cleanup evidence>
Defense Evasion: <which techniques, signals left behind>
D3FEND mapping (defensive recommendations):
Per technique used: counter + detection-rule shape.
Cleanup evidence:
- <persistence-X removed at time Y, screenshot/log ref>
- <test account Z revoked at time W>
- ...
Handoffs:
pentest-reporter: <findings + ATT&CK mapping for the report>
purple-ops: <missed detection opportunities>
detection-engineer: <concrete sigma/KQL rule suggestions>
Verification-loop: ...
No extracted credentials or found data in this log beyond redacted refs. Raw materials in an encrypted engagement vault, not in report delivery.
References
Categories
