Red Team Report Generator¶
Professional penetration testing reports are the primary deliverable of any red team engagement, yet they remain one of the most time-consuming and inconsistent aspects of the process. Security teams spend 30-40% of engagement time on report writing, often producing documents that vary wildly in quality, structure, and actionability.
This interactive report generator solves that problem by providing a structured, repeatable workflow for building professional-grade pentest reports. It includes CVSS 3.1 scoring, MITRE ATT&CK mapping, executive summary auto-generation, and remediation tracking — all in a single tool.
How to Use This Tool
- Engagement Setup — Define scope, methodology, and team details
- Finding Builder — Add individual findings with CVSS scores and evidence
- Executive Summary — Auto-generate a management-ready overview
- Technical Report — Export the full technical report
- Remediation Tracker — Track fix status across all findings
Synthetic Data Only
All example data uses RFC 5737 IP addresses (192.0.2.x, 198.51.100.x, 203.0.113.x), .example.com domains, and testuser/REDACTED credentials. Never use real client data in this tool* — it runs entirely in your browser with no server-side storage.
Engagement Information
Scope Definition
Testing Window
Team Members
Rules of Engagement
Findings (0)
No findings yet. Add your first finding or use a template to get started.
Executive Summary
Add findings in the Finding Builder tab, then generate the executive summary.
Technical Report
Add findings and engagement details first, then generate the full technical report.
Remediation Progress
No findings to track. Add findings in the Finding Builder tab first.
No findings yet. Add your first finding or use a template to get started.
Risk Distribution
'; html += 'Top ' + top5.length + ' Critical Findings
'; html += '| # | Finding | CVSS | Severity | Status |
|---|---|---|---|---|
| ' + (t + 1) + ' | ' + top5[t].title + ' | ' + '' + top5[t].cvssScore.toFixed(1) + ' | ' + '' + top5[t].severity + ' | ' + '' + top5[t].status + ' |
Key Recommendations
'; html += '- '; if (counts.CRITICAL > 0) html += '
- Immediate Action Required: Address all ' + counts.CRITICAL + ' critical findings within 48 hours. These vulnerabilities pose an immediate risk of exploitation. '; if (counts.HIGH > 0) html += '
- High Priority: Remediate ' + counts.HIGH + ' high-severity findings within 7 business days. '; if (counts.MEDIUM > 0) html += '
- Medium Priority: Schedule remediation of ' + counts.MEDIUM + ' medium-severity findings within 30 days. '; html += '
- Security Program: Implement regular vulnerability assessment and penetration testing on a quarterly basis. '; html += '
- Verification: Schedule a retest engagement to verify remediation of all findings. '; html += '
Engagement Overview
'; html += '| Client | ' + (eng.client || 'Not specified') + ' |
| Test Type | ' + (eng.testType || 'Not specified') + ' |
| Methodology | ' + (eng.methodology || 'Not specified') + ' |
| Testing Period | ' + (eng.startDate || '?') + ' to ' + (eng.endDate || '?') + ' |
| Lead Tester | ' + (eng.leadTester || 'Not specified') + ' |
| Open Findings | ' + openCount + ' of ' + findings.length + ' |
PENETRATION TEST REPORT
'; html += '| Client: | ' + (eng.client || 'Not specified') + ' |
| Engagement ID: | ' + (eng.engagementId || 'N/A') + ' |
| Classification: | ' + (eng.classification || 'CONFIDENTIAL') + ' |
| Version: | ' + (eng.version || '1.0') + ' |
| Report Date: | ' + (eng.reportDate || new Date().toISOString().split('T')[0]) + ' |
| Lead Tester: | ' + (eng.leadTester || 'Not specified') + ' |
| Team: | ' + (eng.teamMembers || 'Not specified') + ' |
Table of Contents
'; html += '1. Executive Summary
2. Methodology
3. Scope
4. Rules of Engagement
5. Findings Summary
'; for (var t = 0; t < findings.length; t++) { html += ' 5.' + (t + 1) + ' ' + findings[t].title + '
'; } html += '6. Conclusion
7. Appendices
1. Executive Summary
'; var counts = { CRITICAL: 0, HIGH: 0, MEDIUM: 0, LOW: 0, NONE: 0 }; for (var c = 0; c < findings.length; c++) { if (counts.hasOwnProperty(findings[c].severity)) counts[findings[c].severity]++; } html += '' + (eng.client || 'The client') + ' engaged the security assessment team to perform a ' + (eng.testType || 'penetration test') + ' of their environment. Testing was conducted between ' + (eng.startDate || '[start date]') + ' and ' + (eng.endDate || '[end date]') + ' using the ' + (eng.methodology || 'PTES') + ' methodology.
'; html += 'A total of ' + findings.length + ' findings were identified: ' + counts.CRITICAL + ' Critical, ' + counts.HIGH + ' High, ' + counts.MEDIUM + ' Medium, and ' + counts.LOW + ' Low severity. '; if (counts.CRITICAL > 0) { html += 'The presence of critical-severity findings indicates that immediate remediation action is required to prevent potential compromise.
'; } else if (counts.HIGH > 0) { html += 'High-severity findings should be addressed within the defined SLA to reduce organizational risk.'; } else { html += 'The overall security posture is reasonable, though identified findings should still be addressed in a timely manner.'; } // Section 2: Methodology html += '2. Methodology
'; html += 'The assessment followed the ' + (eng.methodology || 'PTES') + ' framework and included the following phases:
'; html += 'Phase 1 — Reconnaissance: Passive and active information gathering to identify the target attack surface, including DNS enumeration, port scanning, service fingerprinting, and OSINT collection.
'; html += 'Phase 2 — Vulnerability Analysis: Systematic identification of vulnerabilities through automated scanning (Nessus, Burp Suite) and manual testing. Each potential vulnerability was verified to eliminate false positives.
'; html += 'Phase 3 — Exploitation: Controlled exploitation of confirmed vulnerabilities to demonstrate business impact. All exploitation was conducted within the agreed rules of engagement.
'; html += 'Phase 4 — Post-Exploitation: Assessment of the potential impact following successful exploitation, including lateral movement possibilities, privilege escalation paths, and data access.
'; html += 'Phase 5 — Reporting: Documentation of all findings with evidence, risk ratings, and actionable remediation recommendations.
'; // Section 3: Scope html += '3. Scope
'; html += 'In-Scope Systems
'; html += '' + (eng.scopeIn || 'Not defined').replace(/'; html += '
Out-of-Scope Systems
'; html += '' + (eng.scopeOut || 'Not defined').replace(/'; // Section 4: Rules of Engagement html += '
4. Rules of Engagement
'; html += '' + (eng.roe || 'Standard rules of engagement apply.').replace(/'; // Section 5: Findings html += '
5. Detailed Findings
'; html += '| ID | Title | CVSS | Severity | Status |
|---|---|---|---|---|
| ' + findings[s].id + ' | ' + findings[s].title + ' | ' + findings[s].cvssScore.toFixed(1) + ' | ' + findings[s].severity + ' | ' + findings[s].status + ' |
5.' + (d + 1) + ' ' + fi.title + '
'; html += '| Finding ID: | ' + fi.id + ' |
| Severity: | ' + fi.severity + ' (CVSS ' + fi.cvssScore.toFixed(1) + ') |
| CVSS Vector: | ' + fi.cvssVector + ' |
| Affected Systems: | ' + fi.affected + ' |
| Component: | ' + fi.component + ' |
| CWE: | ' + fi.cwe + ' |
| MITRE ATT&CK: | ' + fi.mitre + ' |
| Status: | ' + fi.status + ' |
Description
' + fi.description.replace(/\n/g, '
') + '
Steps to Reproduce
' + fi.steps.replace(/'; if (fi.evidence) html += '
Evidence
' + fi.evidence.replace(/'; if (fi.screenshot) html += '
' + fi.screenshot + '
'; html += 'Remediation
' + fi.remediation.replace(/'; } // Section 6: Conclusion html += '
6. Conclusion
'; html += 'This penetration test identified ' + findings.length + ' security findings across the in-scope environment. '; if (counts.CRITICAL > 0) { html += 'The discovery of ' + counts.CRITICAL + ' critical-severity vulnerabilities indicates significant security gaps that require immediate attention. '; } html += 'It is recommended that all findings be remediated according to the priority levels outlined in this report, followed by a verification retest to confirm successful remediation.
'; html += 'The assessment team is available to provide additional context, answer questions, and support the remediation process as needed.
'; // Section 7: Appendices html += '7. Appendices
'; html += 'Appendix A: Tool List
'; html += 'The following tools were used during this engagement:
'; html += '| Tool | Purpose | Version |
|---|---|---|
| Nmap | Port scanning and service enumeration | 7.94 |
| Burp Suite Professional | Web application testing | 2024.1 |
| Nessus Professional | Vulnerability scanning | 10.7 |
| sqlmap | SQL injection testing | 1.8 |
| Hydra | Authentication testing | 9.5 |
| Metasploit Framework | Exploitation framework | 6.4 |
| Nikto | Web server scanning | 2.5 |
| CrackMapExec | Active Directory assessment | 5.4 |
Appendix B: CVSS 3.1 Scoring Reference
'; html += '| Score Range | Severity | Recommended SLA |
|---|---|---|
| 9.0 - 10.0 | Critical | 24-48 hours |
| 7.0 - 8.9 | High | 7 days |
| 4.0 - 6.9 | Medium | 30 days |
| 0.1 - 3.9 | Low | 90 days |
| 0.0 | Informational | Best effort |
| ID | Finding | Severity | Status | Owner | Due Date | Actions |
|---|---|---|---|---|---|---|
| ' + fi.id + ' | ' + '' + fi.title + ' | ' + '' + fi.severity + ' | ' + '' + fi.status + ' | ' + '' + (fi.owner || '—') + ' | ' + '' + (fi.dueDate || '—') + ' | ' + '' + '' + ' | ' + '
Finding Templates¶
The following pre-built finding templates cover the most commonly identified vulnerabilities during penetration testing engagements. Each template includes a detailed description, realistic evidence, CVSS scoring, and actionable remediation guidance.
1. SQL Injection (SQLi)¶
| Field | Value |
|---|---|
| CWE | CWE-89: Improper Neutralization of Special Elements in SQL Command |
| CVSS | 9.8 (Critical) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| ATT&CK | T1190 — Exploit Public-Facing Application |
Description: SQL injection occurs when user-supplied data is included in SQL queries without proper sanitization or parameterization. Attackers can manipulate queries to extract data, modify records, bypass authentication, or execute system commands.
Key Indicators:
- Error messages revealing database structure
- Unexpected data returned when injecting SQL metacharacters
- Authentication bypass via tautology (
' OR 1=1--) - Time-based blind injection via
WAITFOR DELAYorSLEEP()
Remediation Checklist:
- [ ] Implement parameterized queries / prepared statements
- [ ] Use ORM frameworks for database interaction
- [ ] Apply input validation (allowlists preferred)
- [ ] Deploy WAF rules for SQL injection patterns
- [ ] Implement least-privilege database accounts
- [ ] Enable database query logging and monitoring
2. Cross-Site Scripting — Stored (XSS)¶
| Field | Value |
|---|---|
| CWE | CWE-79: Improper Neutralization of Input During Web Page Generation |
| CVSS | 6.1 (Medium) — AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N |
| ATT&CK | T1059 — Command and Scripting Interpreter |
Description: Stored XSS occurs when malicious scripts are permanently stored on the target server (in a database, message forum, comment field, etc.) and served to other users who view the affected page.
Remediation Checklist:
- [ ] Implement context-aware output encoding
- [ ] Deploy Content Security Policy (CSP)
- [ ] Sanitize HTML input with DOMPurify or equivalent
- [ ] Set HttpOnly and Secure flags on cookies
- [ ] Validate input on both client and server side
3. Insecure Direct Object Reference (IDOR)¶
| Field | Value |
|---|---|
| CWE | CWE-639: Authorization Bypass Through User-Controlled Key |
| CVSS | 6.5 (Medium) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N |
| ATT&CK | T1078 — Valid Accounts |
Description: The application exposes direct references to internal objects (database records, files) through user-controllable parameters without verifying that the requesting user is authorized to access the referenced object.
Remediation Checklist:
- [ ] Implement server-side authorization checks on every request
- [ ] Use indirect object references (UUIDs instead of sequential IDs)
- [ ] Implement access control middleware
- [ ] Log and alert on access pattern anomalies
- [ ] Apply rate limiting on sensitive endpoints
4. Broken Authentication¶
| Field | Value |
|---|---|
| CWE | CWE-307: Improper Restriction of Excessive Authentication Attempts |
| CVSS | 9.8 (Critical) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| ATT&CK | T1110 — Brute Force |
Description: The application's authentication mechanism fails to adequately protect against credential stuffing, brute-force attacks, or session management weaknesses. Missing account lockout, absent MFA, and weak password policies compound the risk.
Remediation Checklist:
- [ ] Implement progressive account lockout
- [ ] Deploy multi-factor authentication (MFA)
- [ ] Add CAPTCHA after failed attempts
- [ ] Enforce strong password policies
- [ ] Implement rate limiting on auth endpoints
- [ ] Use secure password hashing (bcrypt/argon2)
5. Sensitive Data Exposure¶
| Field | Value |
|---|---|
| CWE | CWE-200: Exposure of Sensitive Information to an Unauthorized Actor |
| CVSS | 7.5 (High) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N |
| ATT&CK | T1005 — Data from Local System |
Description: The application exposes sensitive data through verbose error messages, debug endpoints left in production, excessive API response data, or inadequate encryption of data at rest and in transit.
Remediation Checklist:
- [ ] Remove debug endpoints from production
- [ ] Implement response filtering for sensitive fields
- [ ] Remove server version headers
- [ ] Encrypt sensitive data at rest and in transit
- [ ] Implement secrets management solution
- [ ] Classify data and apply appropriate protections
6. Security Misconfiguration¶
| Field | Value |
|---|---|
| CWE | CWE-16: Configuration |
| CVSS | 6.5 (Medium) — AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N |
| ATT&CK | T1190 — Exploit Public-Facing Application |
Description: Default configurations, unnecessary services, overly permissive access controls, and missing security hardening create an expanded attack surface that attackers can exploit without requiring sophisticated techniques.
Remediation Checklist:
- [ ] Close unnecessary ports and services
- [ ] Change all default credentials
- [ ] Implement restrictive CORS policies
- [ ] Disable directory listing
- [ ] Enforce TLS 1.2+ with strong ciphers
- [ ] Audit against CIS benchmarks regularly
7. Missing Security Headers¶
| Field | Value |
|---|---|
| CWE | CWE-693: Protection Mechanism Failure |
| CVSS | 4.3 (Medium) — AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N |
| ATT&CK | T1190 — Exploit Public-Facing Application |
Description: The application fails to implement critical HTTP security headers, leaving users vulnerable to clickjacking, MIME sniffing, and other client-side attacks.
Required Headers:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; script-src 'self'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
8. Privilege Escalation¶
| Field | Value |
|---|---|
| CWE | CWE-269: Improper Privilege Management |
| CVSS | 8.8 (High) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| ATT&CK | T1068 — Exploitation for Privilege Escalation |
Description: A low-privileged user can elevate their access to administrative privileges through improper access control enforcement, client-side role management, or exploitable misconfigurations.
Remediation Checklist:
- [ ] Implement server-side role validation
- [ ] Use RBAC middleware on every request
- [ ] Remove role fields from user-modifiable endpoints
- [ ] Apply principle of least privilege
- [ ] Log and alert on privilege changes
- [ ] Include access control tests in CI/CD
9. Default Credentials¶
| Field | Value |
|---|---|
| CWE | CWE-798: Use of Hard-Coded Credentials |
| CVSS | 9.8 (Critical) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| ATT&CK | T1078 — Valid Accounts |
Description: Systems and services remain accessible with vendor-default or commonly-known credentials, providing trivial unauthorized access to administrative interfaces.
Remediation Checklist:
- [ ] Change ALL default credentials on all systems
- [ ] Implement credential management policy
- [ ] Disable SNMPv1/v2c — use SNMPv3
- [ ] Restrict management interfaces to management VLAN
- [ ] Deploy privileged access management (PAM)
- [ ] Conduct regular default credential audits
10. Unpatched Software¶
| Field | Value |
|---|---|
| CWE | CWE-1104: Use of Unmaintained Third-Party Components |
| CVSS | 9.8 (Critical) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| ATT&CK | T1190 — Exploit Public-Facing Application |
Description: Systems running outdated software with known CVEs and publicly available exploits. Failure to maintain current patch levels represents one of the most common and easily exploitable security weaknesses.
Remediation Checklist:
- [ ] Upgrade all identified outdated components
- [ ] Implement automated vulnerability scanning
- [ ] Establish patch management policy with SLAs
- [ ] Subscribe to vendor security advisories
- [ ] Track software inventory with SBOM
- [ ] Include dependency checking in CI/CD pipeline
Report Writing Best Practices¶
Effective penetration testing reports bridge the gap between technical findings and business decision-making. Following the PTES Reporting Guidelines, every report should serve two audiences: executives who need risk context, and engineers who need remediation details.
Structure and Format¶
Executive Summary (1-2 pages)
- Written for non-technical leadership
- Focus on business risk, not technical details
- Include overall risk rating with clear justification
- Highlight top 3-5 findings by business impact
- Provide strategic recommendations
- Never use jargon without explanation
Technical Findings (bulk of report)
Each finding should include:
- Unique Identifier — Consistent ID for tracking (e.g., FINDING-001)
- Title — Clear, concise vulnerability name
- Severity Rating — CVSS 3.1 score with vector string
- Description — What the vulnerability is and why it matters
- Affected Systems — Specific hosts, URLs, or components
- Evidence — Screenshots, command output, HTTP requests/responses
- Steps to Reproduce — Detailed instructions for verification
- Business Impact — What an attacker could achieve
- Remediation — Specific, actionable fix recommendations
- References — CVE, CWE, OWASP, MITRE ATT&CK mappings
Writing Quality Guidelines¶
| Do | Don't |
|---|---|
| Use specific, measurable language | Use vague terms like "could be better" |
| Include evidence for every finding | Make claims without proof |
| Provide actionable remediation steps | Simply say "fix this vulnerability" |
| Explain business impact | Only describe technical impact |
| Use consistent terminology | Mix terms (vulnerability/weakness/flaw) |
| Write for your audience | Assume technical knowledge |
| Include positive findings | Only report negatives |
| Use RFC 5737 IPs in examples | Use real client IPs in report templates |
Evidence Standards¶
- Screenshots — Annotated with highlights and captions
- HTTP Requests/Responses — Include full headers, redact sensitive data
- Command Output — Show complete tool output, not fragments
- Chain of Evidence — Document the full exploitation path
- Timestamps — Record when each finding was discovered
Common Pitfalls¶
- Over-classification — Rating everything as Critical undermines credibility
- Missing context — CVSS score without environmental context is misleading
- Copy-paste findings — Generic descriptions reduce report value
- No positive findings — Not mentioning what works well creates adversarial dynamics
- Tool dump — Including raw scanner output without analysis is unprofessional
Remediation Tracking¶
Effective remediation tracking ensures that identified vulnerabilities are actually fixed, not just documented. The following methodology provides a structured approach to tracking fixes from discovery through verification.
Remediation SLAs by Severity¶
| Severity | CVSS Range | Remediation SLA | Verification |
|---|---|---|---|
| Critical | 9.0 - 10.0 | 24-48 hours | Immediate retest |
| High | 7.0 - 8.9 | 7 business days | Retest within 14 days |
| Medium | 4.0 - 6.9 | 30 calendar days | Retest within 45 days |
| Low | 0.1 - 3.9 | 90 calendar days | Next scheduled assessment |
| Informational | 0.0 | Best effort | Next scheduled assessment |
Remediation Workflow¶
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ OPEN │────>│ IN PROGRESS │────>│ REMEDIATED │────>│ VERIFIED │
│ (Finding │ │ (Fix being │ │ (Fix │ │ (Retest │
│ reported) │ │ developed) │ │ deployed) │ │ passed) │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
│ │
│ ┌─────────────┐ │
└───────────>│ ACCEPTED │ │
│ RISK │ │
│ (Risk owner │ │
│ sign-off) │ │
└─────────────┘ │
│
┌─────────────┐
│ RE-OPENED │
│ (Retest │
│ failed) │
└─────────────┘
Tracking Metrics¶
Monitor these KPIs to measure remediation program effectiveness:
- Mean Time to Remediate (MTTR) — Average days from finding to fix, by severity
- Remediation Rate — Percentage of findings fixed within SLA
- Reopen Rate — Percentage of findings that fail verification
- Risk Accepted Rate — Percentage of findings accepted without fix
- Aging Findings — Count of findings past their SLA deadline
Verification Testing¶
After remediation, verification testing should confirm:
- The specific vulnerability is no longer exploitable
- The fix does not introduce new vulnerabilities
- The fix does not break application functionality
- Similar vulnerabilities in other components have also been addressed
- Detection/monitoring capabilities cover the attack vector
Cross-References¶
This report generator integrates with several other Nexus SecOps resources:
| Resource | Relevance |
|---|---|
| Detection Engineering at Scale | Build detection rules for the vulnerabilities you find |
| Application Security & SDLC | Integrate security testing into the development lifecycle |
| Network Security Architecture | Network-layer remediation for infrastructure findings |
| Identity & Access Security | Authentication and authorization finding remediation |
| ATT&CK Technique Reference | Map findings to MITRE ATT&CK techniques |
| Detection Query Library | Detection queries for common vulnerability exploitation |
| Purple Team Exercises | Validate remediation through purple team testing |
Advance Your Career¶
Professional penetration testing requires both technical skill and the ability to communicate findings effectively. These industry-recognized certifications validate your expertise:
Recommended Certifications
Offensive Security Certified Professional (OSCP) The gold standard for penetration testing. Demonstrates hands-on ability to identify vulnerabilities, develop exploits, and write professional reports. Learn more about OSCP
GIAC Penetration Tester (GPEN) Validates ability to conduct penetration tests using best practices, including reconnaissance, exploitation, and professional reporting. Learn more about GPEN
Certified Ethical Hacker (CEH) Covers penetration testing methodologies, tools, and techniques. Widely recognized in enterprise environments. Learn more about CEH
Offensive Security Web Expert (OSWE) Advanced web application security certification focusing on source code review and exploit development. Learn more about OSWE
GIAC Web Application Penetration Tester (GWAPT) Focused specifically on web application penetration testing methodology and reporting. Learn more about GWAPT