| name | tradecraft-complex-engagements |
| description | Structure and discipline for complex, multi-stage targets — where the path is a chain of several bugs across multiple hosts, needs source review / custom exploit work, and spans sessions. Load when a foothold needs chaining, work spans multiple hosts, you're deep in dead-ends, or "stuck", "chain", "multi-host", "hard target".
|
| domain | tradecraft |
| type | methodology |
| stability | locked |
| modes | ["pentest","bugbounty"] |
| schema_version | 1 |
Complex, multi-stage engagements
Hard targets differ in kind, not just difficulty. The path is usually a chain of 2–4 bugs
wrapped in deliberate dead-ends — sometimes needing source review, custom exploit work,
reversing, or a crypto attack — and it often spans multiple hosts and sessions. Wins come from
disciplined enumeration and ruthless dead-end tracking, not a bigger exploit. In-scope,
authorized targets only (see tradecraft-scope-roe).
Keep a working record (per engagement)
engagement/
state.md # live status + a "haven't tried yet" list
deadends.md # ruled-out leads WITH the reason each was dropped ← the key habit
chains/ # working exploit chains / PoC drafts, one link at a time
findings/ # confirmed findings + evidence
hosts/<host>/ # one subdir per internal host reached
Extended method
- Exhaustive recon. Every port, vhost, parameter, version string. The lead is often in
the thing you skipped (
recon-arsenal, recon-content-discovery).
- Clue harvesting. Log everything, including what looks irrelevant — odd headers, unusual
filenames, custom apps, strange responses.
- Foothold by chain. Expect to combine bugs (e.g. SSRF → internal service →
deserialization → RCE). Build it in
chains/, verifying each link before adding the next
(exploit-chaining).
- Stabilize + situational awareness. Get a stable shell, then map users/services/internal
network before moving.
- Pivot / lateral. Enumerate internal reachability; one
hosts/<host>/ per host; repeat
the loop per host (network-pivoting-tunneling).
- Privilege escalation (often custom). Standard checks first, but be ready for a
target-specific vector — a custom SUID binary, a bespoke service, an ACL path (
privesc-arsenal).
- Write up the chain. Document it end to end; each link needs reproduction steps and evidence
(
reporting-bug-bounty-writeup).
Dead-end discipline (the skill that separates good operators)
- The moment a lead dies, write it in
deadends.md with why it's ruled out. This stops you
re-walking dead-ends over a multi-day engagement and reveals what you actually haven't tried.
- Keep a live "haven't tried yet" list in
state.md. When stuck, work that list before reaching
for exotic exploits.
- Truly stuck? Re-run enumeration on the least-examined service, diff against earlier output, and
re-read the clue log. The path is usually already in your notes.
Custom-exploit workflow
Read any public PoC fully before running it and note the source (exploit-poc-development). When
a PoC needs adapting, keep a clear record of what changed and why — that becomes report content
and a capture-worthy new skill. Review application source when you have it: auth logic, input
handling, serialization, crypto (code-review-methodology).
Capture what you learn
When an engagement teaches a reusable technique (a novel chain, a bespoke privesc, a crypto
attack), add it as a new stability: learning technique skill under the right domain so future
work benefits (see the library README.md).
Working style: enumerate first, track dead-ends, build chains incrementally, and explain your
reasoning — on complex targets the reasoning is the skill.
