OSCP report writing requires a structured approach to document penetration testing findings effectively and professionally.
A well-written OSCP report demonstrates technical expertise while presenting complex security vulnerabilities in a clear, actionable format for clients and stakeholders.
This guide covers essential elements of OSCP report writing, including templates, formatting guidelines, and best practices for documenting your penetration testing results.
Report Structure and Components
- Executive Summary
- Methodology
- Information Gathering
- Vulnerability Assessment
- Exploitation
- Post Exploitation
- Risk Analysis
- Recommendations
Executive Summary Tips
The executive summary should be written last, despite appearing first in the report.
Focus on business impact rather than technical details in this section.
- Include scope of assessment
- Highlight critical findings
- Summarize risk levels
- Present key recommendations
Documentation Best Practices
- Take screenshots of every significant step
- Document command outputs
- Record timestamps of activities
- Maintain a chronological log
- Save terminal outputs
Evidence Collection Guidelines
Evidence Type | Required Information |
---|---|
Screenshots | Timestamp, tool output, system information |
Commands | Full command syntax, output, error messages |
Vulnerabilities | CVE numbers, impact rating, exploitation proof |
Writing Style Requirements
- Use clear, professional language
- Avoid technical jargon in executive sections
- Include detailed technical information in appropriate sections
- Write in third person perspective
- Use passive voice for technical descriptions
Tools for Report Writing
- Screenshot Tools: Greenshot, Flameshot
- Documentation: KeepNote, Cherry Tree
- Report Templates: Microsoft Word, LaTeX
- Terminal Recording: asciinema, terminator
Risk Rating System
Severity | Description |
---|---|
Critical | Direct system compromise possible |
High | Significant security impact |
Medium | Limited impact vulnerabilities |
Low | Minimal risk to systems |
Moving Forward with Your Report
Review your report multiple times for accuracy and completeness before submission.
Consider having a peer review your report for technical accuracy and clarity.
Keep detailed notes during testing to ensure nothing is missed in the final report.
Contact Offensive Security Support for specific reporting guidelines and templates.
Report Validation and Quality Checks
- Verify all vulnerability claims with evidence
- Check for consistency in risk ratings
- Ensure all screenshots are clear and properly labeled
- Validate technical accuracy of findings
- Review grammar and formatting
Appendix Guidelines
Required Attachments
- Raw scan outputs
- Detailed exploitation logs
- System information dumps
- Network diagrams
- Tools and scripts used
Optional Supporting Materials
- Video documentation
- Additional technical screenshots
- Source code snippets
- Referenced CVE details
Common Reporting Pitfalls
Issue | Solution |
---|---|
Missing evidence | Document all steps with screenshots |
Unclear descriptions | Use precise technical language |
Inconsistent formatting | Follow template guidelines strictly |
Delivering Professional Results
A comprehensive OSCP report serves as testament to both technical ability and professional documentation skills. Focus on clarity, completeness, and actionable recommendations to provide maximum value to stakeholders.
- Maintain professional tone throughout
- Ensure findings are reproducible
- Provide clear remediation steps
- Include all required supporting evidence
- Follow Offensive Security’s formatting requirements
FAQs
- What sections must be included in an OSCP penetration testing report?
An OSCP report must include Executive Summary, High-Level Summary, Methodologies, Information Gathering, Vulnerability Assessment, Exploitation, Post-Exploitation, and Recommendations sections. - What format should proof-of-concept screenshots follow in an OSCP report?
Screenshots must clearly show command execution, obtained shells, proof.txt/local.txt contents, and include proper timestamps. Each screenshot requires clear descriptions and must be numbered sequentially. - How should vulnerabilities be rated in the OSCP report?
Vulnerabilities should be rated using the Common Vulnerability Scoring System (CVSS), including the base, temporal, and environmental metrics with clear justification for each score. - What details are required in the post-exploitation section?
Post-exploitation documentation must include privilege escalation methods, credential harvesting results, lateral movement techniques, persistence mechanisms established, and any sensitive data accessed. - How should remediation recommendations be structured?
Recommendations should be prioritized by risk level, include specific technical steps for remediation, reference industry best practices, and provide both short-term and long-term solutions. - What reporting templates are acceptable for OSCP?
Offensive Security provides an official report template that must be used. The template is available in both Microsoft Word and OpenOffice formats, and deviating from this template may result in failing the exam. - What are the formatting requirements for the OSCP report?
The report must use clear heading structures, consistent formatting, professional fonts (Arial or Times New Roman), proper paragraph spacing, and include a table of contents and page numbers. - How should network diagrams be presented in the report?
Network diagrams must show compromised hosts, attack paths, network segments, and relevant services. They should be created using professional tools and include a clear legend explaining all symbols used. - What is the maximum allowed length for an OSCP report?
The report should not exceed 100 pages, including screenshots and appendices. Content must be concise while maintaining technical accuracy and completeness. - How should failed exploitation attempts be documented?
Failed attempts should be briefly mentioned in an appendix, including the vulnerability tested, method attempted, and reason for failure, to demonstrate thoroughness in the testing process.