Introduction: Why Documentation Matters
Strong documentation is the difference between a script kiddie and a professional consultant. You might be excellent at pwning boxes and getting Domain Admin, but without the soft skills to report it, your value to a client drops significantly.
A penetration test is a snapshot in time. A key principle of reporting is stating clearly that the report reflects the security posture only during the specific testing window.
The Golden Rule: The report is the only tangible deliverable the client receives. To them, the quality of the report equals the quality of the test.
—
Phase 1: Preparation and Organization
Before you run a single Nmap scan, you must have a system. Chaos in notes leads to chaos in reporting.
The Notetaking Hierarchy
There is no “one size fits all,” but a structured approach is mandatory. Recommended tools include Obsidian (great for local storage/Markdown), CherryTree, or Notion.
Sample Folder Structure for Every Engagement:
Admin: Scope of Work (SoW), Kickoff notes, contact info.
Deliverables: Draft reports, slide decks.
Evidence:
*Findings:* Dedicated subfolder for each finding.
*Scans:* Nmap, Nessus, Burp state files.
*AD Enumeration:* BloodHound data, secrets dumps.
*Logging:* Tmux logs (Critical!).
Misc: Payloads, scripts used.
The “Snapshot” Disclaimer
Always include an overview section stating:
Who performed the work.
Source IP addresses used.
Crucial Disclaimer: “Testing was performed between [Date A] and [Date B]. Changes to systems outside this window are not captured.”
—
Phase 2: Evidence Gathering & Logging
Never rely on your memory. If a client asks, “Did you scan Server X on Tuesday?”, you need proof.
1. Tmux Logging
This is non-negotiable. Use tmux-logging to save every command and output.
Why? If you crash a server, you need to prove exactly what you sent. If you find an exploit, you need the raw output for the report.
Tip: If you forgot to turn it on, use the “Retroactive Logging” feature to save the current buffer.
2. Screenshots vs. Text
Terminal Output: Prefer copying text over screenshots. It’s cleaner, easier to redact, and allows clients to copy/paste commands.
Screenshots: Use for GUI apps (Web, RDP).
**Do:** highlight relevant areas (red boxes/arrows).
**Do:** include the address bar/IP to prove it's the client's system.
**Don't:** use full-screen captures with your messy desktop visible.
3. Redaction
PII & Credentials: ALWAYS redact passwords, hashes, and PII.
Method: Use solid black bars. Never use pixelation or blur (these can be reversed).
—
Phase 3: The Executive Summary
This is the most important part of the report. It is read by the C-Suite (CISO, CEO) who control the budget.
The “Do’s”
Be Specific: Don’t say “several vulnerabilities.” Say “We identified 7 vulnerabilities: 5 High, 1 Medium, 1 Low.”
Focus on Impact: Explain business risk, not just technical flaws. “We accessed HR records” hits harder than “We found an IDOR.”
Describe Root Causes: Don’t just list bugs; explain why they exist (e.g., “The patch management process is immature”).
The “Don’ts”
No Acronyms: Avoid “RCE,” “XSS,” or “LLMNR” without plain-English explanations.
No Vendor Sales: Do not recommend specific products (e.g., “Buy Splunk”). Recommend capabilities (e.g., “Implement centralized logging”).
Keep it Short: 1.5 to 2 pages maximum.
—
Phase 4: Writing Technical Findings
This section is for the SysAdmins and Developers. It must be reproducible.
Anatomy of a Finding
-
Description: What is the issue?
-
Impact: What happens if it’s exploited? (Confidentiality, Integrity, Availability).
-
Affected Systems: List IPs/URLs.
-
Evidence: The “Proof of Concept.”
-
Remediation: How to fix it.
-
References: Links to vendor patches or OWASP articles.
Writing Better Remediation
Bad: “Fix the registry key.”
Good: “Update the following registry hive: HKLM\SYSTEM\CurrentControlSet... to Value: 1. Note: Test in a staging environment first.”
Bad: “Buy a WAF.”
Good: “Implement a Web Application Firewall. If budget is restricted, apply the vendor-supplied workaround found here: [Link].”
The Attack Chain
If you compromised the domain, write a narrative Attack Chain. Connect the dots:
-
Spoofed LLMNR to get a user hash.
-
Cracked hash to get a foothold.
-
Used BloodHound to find a path to DA.
-
Kerberoasted a Service Account.
-
DCSync to dump hashes.
This shows the client how low-risk findings can be chained together to cause a catastrophe.
—
Phase 5: Pro Tips & Best Practices
1. The “Bus Factor” (Backup Your Data)
Scenario: Your VM corrupts on day 29 of a 30-day engagement.
Solution: Sync your notes and evidence to a backup location (encrypted) daily. If your VM dies, you should be back up and running in minutes, not days.
2. Client Communication
Start/Stop Emails: Notify the client when you begin and end testing daily.
Critical Findings: If you find RCE or exposed PII, stop testing and notify the client immediately. Don’t wait for the report.
Transparency: If you think you crashed a service, tell them. Don’t hide it.
3. QA Process
Never send a report without QA.
Self-QA: Sleep on it. Read it with fresh eyes the next day.
Peer-QA: Have a teammate review it. They will catch typos and logic gaps you missed.
4. Microsoft Word Mastery
Styles: Use “Heading 1”, “Heading 2” styles rather than manual formatting. This makes generating a Table of Contents automatic.
Captions: Use the “Insert Caption” feature for images so figures update automatically if you move them.
Templates: Create a master template. Never “Save As” an old client report—you will accidentally leave the old client’s name in it.
—
Conclusion
Reporting isn’t the “boring part”—it’s the product you sell. By maintaining rigorous organization, logging everything, and writing for both executive and technical audiences, you turn a hacking exercise into a professional consulting engagement.