10.2 Exploit Selection, Customization, and Attack Documentation
Key Takeaways
- After 4.1 names the target, capability selection is tool choice, exploit selection, and code-analysis customization — not paste-and-pray against every critical CVE.
- Customization on PT0-003 means reading exploit comments, confirming version, and changing a callback IP or named function; it does not mean writing a working exploit proof of concept.
- Document the attack path, a low-level diagram (hosts, IPs, ports), and a storyboard with abort conditions before firing so PBQs and live tests do not hit the wrong host.
- Dependencies such as credentials from host A before host B must be on the path; a missing dependency sends you back to recon, not into a random neighbor.
- Scope limitations still veto a beautiful path, and RoE-labeled sensitive systems stay on the diagram with gentler handling rather than being used as unconstrained hops.
Once 4.1 prioritization has named the target — in the last section, the domain controller, not the 9.8 lab printer — the objective is still not finished. The second half is capability selection: tool selection; exploit selection and customization (code analysis); documentation of the attack path, a low-level diagram, and a storyboard; dependencies; consideration of scope limitations; and labeling sensitive systems. This is how professional testers and PT0-003 performance-based items avoid shooting the wrong host.
Domain 4 remains 35 percent of the exam. Capability selection is the last planning step before network, authentication, host, web, and cloud attacks in 4.2–4.9. If you skip it, you will pick a noisy exploit for a labeled medical device, fire a Windows payload at a Linux box, or pivot into an excluded payment VLAN because the path "looked connected" on a whiteboard.
Tool selection
Pick the smallest tool that matches the asset, the protocol, the network position, and the RoE noise budget. A domain controller with SMB and default credentials may need a credentialed remote-admin capability, not a web fuzzer. A REST API with CWE-89 needs an intercepting proxy, not an SMB relay. Match four constraints:
- Operating system and service — Windows Active Directory versus Linux SSH versus an HTTPS API are different tool families.
- Where you sit — same VLAN, through a jump host, or only through a web application.
- Stealth versus overt — RoE may forbid flooding, kernel exploits that panic a host, or anything that looks like ransomware.
- Evidence needs — can you prove impact with a read-only query instead of a crash?
Exam trap: answering with a single framework brand on every stem. A given tool may be valid later under 4.2–4.4. On 4.1 the scored move is selecting a capability that fits, not naming a favorite. If RoE says no weaponized exploits against OT, the selected capability might be a version check and a screenshot of default credentials, not a module launch. If the only in-scope surface is an API, a host-exploit toolkit is the wrong capability even when a CVE exists on an out-of-reach printer.
Exploit selection and customization (code analysis)
Exploit selection means matching a public or local exploit to the validated finding: same product, same version, same configuration, same architecture. Domain 3 already taught you not to treat a scanner plugin as proof. Here you ask a harsher question: does this exploit's documented target list include the build I actually have? Read the comments and header. Authors routinely write that the code was tested on one build, that it requires authentication, that it crashes the service, or that you must change the callback address before use.
Customization on PT0-003 is code analysis, not writing a new weapon. Typical, exam-safe edits:
- Change the callback IP and port (payload listener) from the author's lab address to your in-scope tester host.
- Confirm a version check or banner string matches the target.
- Point the exploit at a different function or named endpoint if the comments say the vulnerable routine was renamed between minor versions.
- Disable a destructive option and keep a proof that only demonstrates control, when RoE requires it.
What you do not do: paste an unreviewed exploit from a random mirror, invent shellcode in the answer box, or treat "customize" as "bypass RoE." This study guide will not provide exploit proof-of-concept code. The scored skill is reading the exploit before it runs. If the comments say the module needs local credentials you do not have, that is a dependency, not a suggestion to brute-force an out-of-scope account. If the version string does not match, you do not "customize" by aiming the same file at every host in the prefix.
Public exploit selection as a validation tactic already appeared under objective 3.2. Objective 4.1 assumes the finding is real and asks whether this exploit, on this host, with this listener, is the capability you should fire — after the diagram says so.
Documentation: attack path, low-level diagram, storyboard
CompTIA names three documentation artifacts, and they exist before you fire, not only in the Domain 1 report afterward. PBQs punish testers who skip them.
Attack path. A sequenced chain from your current position to the high-value asset: foothold host → credential or session you will reuse → next host → objective. Write the dependency on each hop ("need the jump-host local admin before the DC"). If hop 2 is out of scope, the path is illegal even if hop 3 is a domain controller. The printer from 10.1 is not on this path; drawing it in because it had a 9.8 is how you waste the window.
Low-level diagram. Not a pretty marketing picture. Label IP addresses, hostnames, ports, protocols, credential types, and VLAN or subnet boundaries. A low-level diagram is how you notice that the "DC" you are about to hit is actually the OT historian on the same subnet, or that your callback would hairpin through an excluded firewall. Callbacks that land on the author's home lab IP, or on a cloud redirector the SoW never named, are out-of-scope infrastructure even when the target is in scope.
Storyboard. A shot list: numbered steps, expected evidence at each step, and abort conditions. Example: (1) confirm SMB and the default account from the jump host; (2) if the hostname is not the labeled DC, stop; (3) set the payload listener to the tester address recorded in RoE; (4) attempt a non-destructive proof; (5) if the host becomes unstable, execute the emergency stop. Storyboards are how you avoid clicking the printer because it was the next icon, and how a second tester can take over if you escalate.
| Artifact | What it captures | Failure if skipped |
|---|---|---|
| Attack path | Ordered hops and what each hop unlocks | You exploit a dead-end host with a pretty CVE |
| Low-level diagram | Addresses, ports, trusts, VLANs, callback | Pivot or listener lands out of scope |
| Storyboard | Steps, evidence, abort rules | You fire before confirming the hostname |
Dependencies
A dependency is a fact you must have before the next action works: credentials from host A before host B, a pivot through the jump host before the DC is reachable, a valid session cookie before an object-level request, DNS influence before an on-path attempt, or a library version the exploit checks. Document dependencies on the path. If a dependency is missing, you go back to recon or to a different path — you do not "just try the exploit" against a random neighbor. Default credentials on the DC that you can use only after jump-host admin is a two-step capability, not a single click from the tester laptop on another VLAN.
Scope limitations and labeled sensitive systems
Scope limitations still win after you have a beautiful path. An exploit that needs to bounce through a third-party payment processor, an excluded CIDR, or a testing window that already closed is out. Technique bans (no denial-of-service, no phishing customers, no kernel exploits on production) are scope, not suggestions. The 9.8 printer remains in scope as a finding; it is not an excuse to ignore the DC. An out-of-scope DC is not a target no matter how high the EPSS. If the only path to the HVA is an excluded hop, you document the limitation and stop — that is still 4.1, not cowardice.
Labeling sensitive systems is the RoE practice of tagging HVAs that need extra care: production payment switches, clinical devices, safety PLCs, executive laptops, or the crown-jewel database you may identify but not crash. Label them on the low-level diagram in a different annotation. For a labeled system you may lower intensity, require a live client owner on the escalation path, stop at proving access without dropping a noisy payload, or record "not exploited per RoE label" so the report does not look like you missed it. High value plus a sensitive label means prepare more, fire less, not "skip identification."
Worked scenario: prepare the DC, leave the printer
Return to Finding D-1 (DC, CVSS 7.5, high EPSS, default credentials, no SMB signing, no EDR) versus Finding P-1 (lab printer, CVSS 9.8, isolated).
Tools. Credentialed Windows remote administration from the in-scope jump host, plus a packet capture for evidence. Not a printer firmware exploit pack, and not a generic "run everything in the framework" pass.
Exploit / capability. You may never need the CVE exploit. Default credentials plus missing signing may be enough to prove forest impact. If you do use a public module, open it, read the comments, confirm the Windows build, and set the callback to the tester listener named in the SoW — do not leave the author's lab address in the payload. Do not rewrite the module into a new weapon to impress a PBQ.
Path. Tester laptop → jump host (already has local admin) → DC. Dependency: jump-host admin is required. The printer is not on this path. The OT historian that shares a nearby subnet is labeled sensitive and is not a hop, even if it also has a default password.
Low-level diagram. Jump host 10.4.12.8, DC 10.4.0.10, SMB 445, tester listener 10.4.200.2. Historian 10.4.80.5 is marked sensitive. Excluded payment VLAN is drawn with a red stop, not as a clever pivot.
Storyboard. Confirm hostname equals the labeled DC; abort if DNS returns the historian; if the host locks the account, stop and escalate; do not touch the printer first just because 9.8 sorts higher.
Before launching a capability against the prioritized domain controller, what documentation does PT0-003 objective 4.1 expect?
A public exploit's comments say it was tested on one build and that the listener address is hardcoded to the author's lab. What is the correct 4.1 customization step?
The low-level diagram shows a path to the domain controller through a jump host, plus an OT historian labeled sensitive in the rules of engagement. Default credentials work on both. What should the tester do?