The report is the main deliverable clients pay for during penetration tests. It must demonstrate work performed, provide maximum value, and be free of extraneous data. Everything included should have a clear purpose and help clients prioritize remediation efforts.
# Purpose:
- Written for non-technical stakeholders
- Budget allocation decision makers
- Board of Directors presentation
- Funding justification support
# Key principles:
- 1.5-2 pages maximum
- No technical jargon or acronyms
- Specific metrics (not "several" or "multiple")
- Business impact focus
- Remediation effort estimates# Purpose:
- Demonstrate exploitation path
- Show finding interconnections
- Justify severity ratings
- Evidence for individual findings
# Structure:
1. Summary of complete attack path
2. Step-by-step walkthrough
3. Supporting command output
4. Screenshots for GUI interactions
5. Impact demonstration# Content:
- Technical vulnerability details
- Exploitation evidence
- Reproduction steps
- Remediation recommendations
- Risk assessment justification
# Organization:
- Severity-based ordering
- Clear finding titles
- Consistent formatting
- Complete evidence packages# Timeframe categories:
- Short-term: Immediate patches/fixes
- Medium-term: Process improvements
- Long-term: Strategic security enhancements
# Requirements:
- Tie back to specific findings
- Actionable recommendations only
- Effort level estimates
- Business impact consideration# Content guidelines:
- Use specific numbers instead of vague terms
- Describe accessible systems/data types
- Explain general improvement areas
- Include remediation effort estimates
- Focus on high-impact findings
# Writing style:
- Non-technical language
- Clear, concise sentences
- Business impact focus
- Universal understanding
- Attention-grabbing content# Avoid:
- Specific vendor recommendations
- Technical acronyms (SNMP, MitM)
- References to technical sections
- Obscure vocabulary
- Excessive detail on minor findings
# Common mistakes:
- More than 2 pages length
- Technical jargon usage
- Assumption of technical knowledge
- Ambiguous metrics
- Overwhelming detail# Professional vocabulary conversion:
VPN/SSH → "secure remote administration protocol"
SSL/TLS → "secure web browsing technology"
Hash → "cryptographic password validation"
Password Spraying → "automated weak password testing"
Buffer Overflow → "remote command execution attack"
OSINT → "public information gathering"
SQL Injection → "database manipulation vulnerability"# Attack progression:
1. LLMNR/NBT-NS Poisoning → bsmith user hash
2. Offline hash cracking → domain foothold
3. BloodHound enumeration → privilege mapping
4. Kerberoasting attack → mssqlsvc account
5. Credential extraction → srvadmin cleartext
6. Lateral movement → pramirez TGT ticket
7. Pass-the-Ticket → DCSync privileges
8. Domain compromise → Administrator hash
9. Full domain control → NTDS database dump
# Evidence components:
- Responder output (hash capture)
- Hashcat results (password cracking)
- BloodHound graphs (privilege paths)
- GetUserSPNs output (Kerberoasting)
- CrackMapExec LSA dumps (credential extraction)
- Rubeus ticket operations (Pass-the-Ticket)
- Mimikatz DCSync (domain compromise)# Scope:
- Assessment boundaries
- Network ranges/URLs
- Facilities tested
- Auditor requirements
# Methodology:
- Repeatable process documentation
- Testing approach explanation
- Tool usage justification
- Quality assurance measures
# Severity Ratings:
- Risk level definitions
- Scoring criteria
- CVSS mapping (if applicable)
- Defensible rating system
# Biographies:
- Tester qualifications
- Relevant experience
- Certifications
- PCI compliance requirements# Exploitation Attempts:
- Payload deployment log
- File locations and hashes
- Cleanup status tracking
- Forensics team reference
# Compromised Credentials:
- Account listing
- Privilege levels
- Password change requirements
- Monitoring recommendations
# Configuration Changes:
- System modifications made
- Reversion procedures
- Risk mitigation steps
- Approval documentation
# Additional Affected Scope:
- Extended host listings
- Service enumeration results
- Large-scale finding impacts
- Supplementary evidence
# Information Gathering (External):
- OSINT data collection
- Domain ownership information
- Subdomain enumeration
- Breach data analysis
- SSL/TLS configuration review
# Domain Password Analysis:
- NTDS database statistics
- Hashcat cracking results
- Privileged account analysis
- Password policy recommendations
- DPAT report integration# Question 1: Non-technical report component
# Answer: Executive Summary
# Question 2: Vendor recommendations in Executive Summary
# Answer: False# Target audience:
- Budget decision makers
- Non-technical executives
- Board of Directors
- Internal audit teams
# Success criteria:
- Funding allocation support
- Clear business impact
- Actionable recommendations
- Professional credibility# Focus areas:
- Remote code execution flaws
- Sensitive data exposure
- Authentication bypasses
- Privilege escalation paths
# Noise filtering:
- Consolidate minor findings
- Remove false positives
- Group related vulnerabilities
- Focus on exploitable issues# Essential elements:
- Clear reproduction steps
- Complete command output
- Relevant screenshots
- Business impact demonstration
- Remediation guidance
# Formatting standards:
- Consistent presentation
- Proper redaction
- Professional appearance
- Client-friendly language- Executive Summary is the most critical section for non-technical audiences
- Attack chains demonstrate finding interconnections and impact
- Specific metrics more effective than vague terms
- No vendor recommendations in executive sections
- Appendices provide comprehensive supporting documentation
- Professional language essential for stakeholder communication
- Evidence quality determines report credibility and usefulness
Effective report components balance technical accuracy with business communication, ensuring all stakeholders can understand and act on penetration testing findings.