Writing Exploit Code to Prove Access
Domain 5 tests whether you can write code that proves a vulnerability is exploitable, not just suspected. The proof must be minimal, attributable to your testing host, and reversible.
From crash to working proof of concept
For memory-corruption targets the workflow is fixed. Reproduce the crash, attach a debugger, and find the offset to the instruction pointer using a cyclic pattern (msf-pattern_create -l 3000, then msf-pattern_offset). Identify bad characters byte by byte, excluding \x00 and often \x0a, \x0d. Locate a control-transfer gadget such as JMP ESP with mona or a debugger search, check for pointer protection - DEP, ASLR, stack canaries - and fall back to a ROP chain when DEP is enforced. SEH overwrites use a POP POP RET address instead. For application-layer bugs, the PoC is usually a short Python script using requests: authenticate, set the header or parameter, send one payload, and print the response.
Rules for a defensible PoC
Use the least harmful proof available: whoami, hostname, or id rather than a reverse shell, unless the reverse shell is the only way to demonstrate reachability. Never run destructive commands, install persistence, or touch data you were not authorised to read. Make the script deterministic - fixed timing, explicit timeouts, retry logic that does not hammer the target. Log every request with a timestamp so the client's SOC can correlate. Include cleanup and a rollback note.
Worked example
A parameterised reporting endpoint is suspected of command injection. A one-line PoC sends ;id in the report_name field. The response body contains uid=33(www-data) gid=33(www-data) groups=33(www-data), which confirms OS command execution under the web account. The tester stops there, does not attempt a reverse shell, documents the exact request and response, and recommends input validation plus running the service as a non-privileged account. In a binary case, the equivalent proof is a controlled EIP overwrite with a breakpoint (\xcc) payload, not a full shellcode execution.
Traps that cost marks
- Using a destructive payload to prove impact, which can end the engagement.
- Claiming remote code execution from reflected input that never reaches an interpreter.
- Hardcoding real production credentials into the PoC script.
- Forgetting architecture and calling convention differences between x86 and x64 shellcode.
- No cleanup, no logging, no note about which host the exploit was launched from.