Technical Report Template
The full technical report for security teams and developers. Contains detailed findings, proof-of-concept code, and step-by-step remediation guidance.
Technical Report Template
Hackers Manifest - hackersmanifest.com
Report Structure
# PENETRATION TEST TECHNICAL REPORT **Document Classification:** [Confidential / Internal Use Only] **Version:** 1.0 **Client:** [Company Name] **Assessment Period:** [Start Date] - [End Date] **Report Date:** [Date] --- ## TABLE OF CONTENTS 1. Executive Summary 2. Scope and Methodology 3. Risk Rating Methodology 4. Summary of Findings 5. Detailed Findings 6. Appendices --- ## 1. EXECUTIVE SUMMARY [Reference or include the Executive Summary document] --- ## 2. SCOPE AND METHODOLOGY ### 2.1 Engagement Scope **In-Scope Assets:** | Asset | Type | Description | |-------|------|-------------| | app.company.com | Web Application | Customer portal | | api.company.com | API | REST API v2 | | 10.0.0.0/24 | Network | Internal corporate network | **Out-of-Scope:** - Production database servers (read-only testing on staging) - Third-party integrations - Denial of Service testing ### 2.2 Testing Methodology This assessment followed the [OWASP Testing Guide v4.2 / PTES / OSSTMM] methodology. **Phases Completed:** - [x] Reconnaissance and Information Gathering - [x] Vulnerability Assessment - [x] Exploitation - [x] Post-Exploitation - [x] Reporting ### 2.3 Tools Used | Tool | Version | Purpose | |------|---------|---------| | Burp Suite Pro | 2024.x | Web application testing | | Nmap | 7.94 | Network scanning | | SQLMap | 1.8 | SQL injection testing | | Nuclei | 3.x | Vulnerability scanning | ### 2.4 Testing Limitations - [Any limitations encountered during testing] - [Time constraints] - [Access restrictions] --- ## 3. RISK RATING METHODOLOGY Findings are rated using CVSS 3.1 combined with business context: | Severity | CVSS Score | Description | |----------|------------|-------------| | Critical | 9.0 - 10.0 | Immediate exploitation possible, severe business impact | | High | 7.0 - 8.9 | Significant risk, should be addressed urgently | | Medium | 4.0 - 6.9 | Moderate risk, plan remediation | | Low | 0.1 - 3.9 | Minor risk, address when convenient | | Informational | N/A | Best practice recommendations | --- ## 4. SUMMARY OF FINDINGS ### 4.1 Findings by Severity | Severity | Count | |----------|-------| | Critical | X | | High | X | | Medium | X | | Low | X | | Info | X | | **Total** | **XX** | ### 4.2 Findings Overview | ID | Title | Severity | CVSS | Status | |----|-------|----------|------|--------| | VLN-001 | SQL Injection in Login Form | Critical | 9.8 | Open | | VLN-002 | Missing Security Headers | Medium | 5.3 | Open | | ... | ... | ... | ... | ... | --- ## 5. DETAILED FINDINGS [Repeat this section for each finding] --- ### VLN-001: SQL Injection in Login Form **Severity:** Critical | **CVSS:** 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) **Affected Asset:** https://app.company.com/login **OWASP Category:** A05:2025 - Injection #### Description A SQL injection vulnerability was identified in the login form's username parameter. This allows an unauthenticated attacker to bypass authentication, extract sensitive data from the database, or potentially execute commands on the underlying system. #### Evidence **Request:****Response:**POST /api/login HTTP/1.1 Host: app.company.com Content-Type: application/json {"username": "admin'--", "password": "anything"}**Screenshot:** [Insert screenshot showing successful bypass] #### Impact - Authentication bypass allowing access to any user account - Full database access including customer PII - Potential remote code execution via xp_cmdshell (MSSQL) #### Remediation **Immediate:** 1. Implement parameterized queries / prepared statements 2. Add input validation for username field **Code Example (Before - Vulnerable):**HTTP/1.1 200 OK Content-Type: application/json {"status": "success", "user": "admin", "token": "eyJ..."}**Code Example (After - Secure):**query = f"SELECT * FROM users WHERE username = '{username}'" cursor.execute(query)**Long-term:** - Implement Web Application Firewall (WAF) rules - Enable SQL query logging and alerting - Conduct code review of all database queries #### References - OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection - CWE-89: https://cwe.mitre.org/data/definitions/89.html --- ## 6. APPENDICES ### Appendix A: Scan Results [Nmap output, vulnerability scanner results] ### Appendix B: Screenshots [Additional evidence screenshots] ### Appendix C: Remediation Priority Matrix | Finding | Effort | Impact | Priority | |---------|--------|--------|----------| | VLN-001 | Low | Critical | 1 - Immediate | | VLN-002 | Low | Medium | 2 - This Sprint | ### Appendix D: Retesting Information Remediated findings should be verified through retesting. Contact [email] to schedule. --- **END OF REPORT**query = "SELECT * FROM users WHERE username = %s" cursor.execute(query, (username,))
Key Sections Explained
Evidence Section
Always include reproducible evidence: HTTP requests/responses, screenshots, and command output. This proves the vulnerability exists and helps developers understand the issue.
Remediation Section
Provide specific, actionable fixes. Include code examples when possible. Separate immediate fixes from long-term improvements.
CVSS Scoring
Use CVSS 3.1 for consistent severity ratings. Include the vector string so readers can understand the scoring rationale. Adjust for business context if needed.
Generated from Hackers Manifest | For authorized security testing only | hackersmanifest.com
Evidence to Attach
Every finding in the report has to survive a developer trying to reproduce it without you in the room.
Reproduction chain: The exact request, command or interaction that reaches the vulnerable state, in order, starting from a fresh session rather than from a half-prepared one.
Response pair: The server response that proves the state changed, not only that the request was accepted.
Correlation data: Timestamp, account or session used, and the request identifier, so the client can find the same event in their own logs.
Screenshot pairing: One annotated capture per request/response pair, with the host or URL visible in frame.
Environment: Target build or version, and the tool versions from the tools table, so a failed reproduction can be attributed to drift rather than to a wrong finding.
Redacted raw copy: The unredacted original retained under the engagement retention rule, with only the redacted version inside the document.
Likely False Positives
A technical report can overstate a finding to the team that has to fix it just as easily as an executive summary can overstate it to a board.
- Vector does not match the impact: A vector claiming C:H while the impact paragraph describes metadata disclosure, or PR:N on an endpoint that required credentials, is the most common reason a client rejects a finding.
- Scanner output presented as confirmed: A tool result with no manual reproduction belongs in the appendix as an observation, not in the detailed findings.
- Severity taken from the scanner: A tool score reflects the template, not the target. Any environmental adjustment has to be stated where it was made.
- PoC that proves the tool works: A payload returning a generic error, or a redirect that would happen anyway, demonstrates nothing about the vulnerability.
- Retest claimed without a reproduction: Marking a finding remediated on the client statement alone converts their fix claim into your finding.
- Duplicates merged silently: One root cause at several endpoints is one finding with an affected-endpoint list, not two IDs carrying the same remediation text.
- Impact inherited from the category: Copying the impact of a similar CVE onto a target that cannot reach that path overstates what the client actually faces.
Pre-Delivery Checklist
Structure
- ☐ Metadata block carries classification, version, client and assessment period
- ☐ Scope table lists each asset with type and description, and the out-of-scope list is explicit
- ☐ Methodology names the standard and the phases actually completed
- ☐ Testing limitations recorded, including access restrictions and time
- ☐ Tools table lists the versions actually used
Findings
- ☐ Each detailed finding has description, evidence, impact, remediation and references
- ☐ Finding IDs match the summary table and the executive summary counts
- ☐ OWASP and CWE mappings agree with the weakness described
- ☐ CVSS vector recomputed from the stated impact
- ☐ Remediation separates immediate, root-cause and detection measures
Evidence
- ☐ Request and response paired for every finding
- ☐ Screenshots annotated and legible at print resolution
- ☐ Client data redacted, raw originals retained
- ☐ Timestamps and account identifiers recorded so the client can correlate
Appendices
- ☐ Scan output included with tool and version noted
- ☐ Remediation priority matrix completed for every finding
- ☐ Retest process and contact stated
- ☐ Document renders as PDF with no clipped tables or lost page breaks
Fixing the Artefact
Scoring and severity
- • Recompute each CVSS vector against the impact text until the two agree
- • State any environmental adjustment and the reason for it
- • Demote observations that were never reproduced to the appendix
Traceability
- • Regenerate the summary counts from the detailed findings instead of retyping them
- • Reconcile the executive summary, summary table and detailed sections in one pass
- • Confirm every screenshot referenced in a finding exists in the appendix
Reproduction
- • Add the missing first step so a developer can start from a clean state
- • Replace bare tool output with a manual reproduction, keeping the tool result as corroboration
- • Note the target build in every finding whose behaviour is version-dependent
Handling
- • Re-run the redaction pass over the body and the appendices separately
- • Restore the correct client name everywhere after copying from a template
- • Bump the version and date, and record what changed and why