The report is the deliverable the client pays for — they never see most of your testing, so they judge the work through this document. This page is how to assemble the report once the evidence is captured: the section skeleton, the executive summary, the attack chain, the recommendations, the appendices, and the production/QA discipline around them. Capture happens in Reporting_Documentation; finding write-ups live in Reporting_Findings_Types and Finding_Library; this page is the glue that turns those into a defensible report.
🛡️ Methodology Checklist
- Start the report on day 1 — fill static sections (scope, dates, source IPs) while scans run
- Sort findings by severity and business impact; group low-impact items into themes
- Decide whether an attack-chain section is needed (multiple findings combining into bigger impact)
- Write the executive summary in plain language for a non-technical budget owner
- Map every recommendation back to a finding ID (short / medium / long-term)
- Include the required appendices (scope, methodology, severity, + dynamic ones that apply)
- Redact every secret; remove console clutter (
<SNIP>) - Run QA (second reviewer if possible); issue Draft → review → Final
🎯 Operational Context
Use when: Assembling the report after (or during) an assessment — turning captured evidence into the executive summary, attack chain, findings, recommendations, and appendices. Think Dumber First: Start on day 1, not day 9. The report is your highlight reel — write findings while context is fresh, draft the attack chain as compromise progresses, and fill recommendations as themes emerge. Every section must have a purpose; cut console dumps and irrelevant screenshots. Skip when: N/A — a deliverable is always required. (Report type selection lives in Reporting_Findings_Types.)
⚡ Tactical Cheatsheet
| Report section | Purpose | Audience |
|---|---|---|
| Executive Summary | What happened, why it matters, what to improve — no jargon | Non-technical leadership |
| Attack Chain | How separate weaknesses combined into real compromise | Technical + management |
| Findings | Per-issue detail: validate, reproduce, remediate | Technical teams |
| Summary of Recommendations | Remediation roadmap, each mapped to a finding | Management + technical |
| Appendices | Supporting detail without cluttering the body | Technical / audit |
Build order (fast workflow): sort findings → group themes → attack chain → executive summary → recommendations → technical findings → static appendices → dynamic appendices → redact → QA.
🔬 Deep Dive & Workflow
Report Skeleton
A strong internal/AD report is structured around business value and technical reproducibility:
1. Executive Summary ← non-technical risk story
2. Attack Chain ← how findings combined into compromise
3. Findings ← per-issue technical detail (see Reporting_Findings_Types)
4. Summary of Recommendations ← remediation roadmap mapped to findings
5. Appendices ← static + dynamic supporting detailPrioritise high-impact issues (RCE, credential compromise, privilege escalation, lateral movement, domain compromise, auth bypass, weak/default creds, excessive permissions). Group low-impact items (TLS hardening, missing headers, version disclosure, non-exploitable scanner noise) so they don’t distract from what materially affects risk. Report everything relevant — but don’t let low-impact issues bury the findings that matter.
Executive Summary
Written for non-technical decision makers (C-level, IT management, security leadership, audit, board, budget owners). Goal: explain what happened, why it matters, and what needs to improve without requiring technical background. Keep it to 1.5–2 pages.
Do: be specific with numbers · explain business impact · describe what systems/data were reached · group findings into themes · give general remediation direction · acknowledge what the client does well. Don’t: use unnecessary acronyms · recommend specific vendors · overload with technical terms · spend more words on low-impact issues than high-impact risk · use inflammatory language · speak in absolutes when evidence is partial.
Translate technical terms to plain language:
| Technical term | Executive-friendly explanation |
|---|---|
| Kerberoasting | Weak service-account configuration allowing offline password guessing |
| DCSync | Abuse of directory-replication permissions to retrieve password data |
| NTLM hash | Cryptographic form of a Windows password |
| Password cracking | Converting protected password data back into readable form |
| LLMNR/NBT-NS spoofing | Abusing unnecessary name-lookup traffic to capture login material |
| SQL injection | Input flaw allowing manipulation of application database logic |
| Remote command execution | Ability to run commands on a system without authorization |
| SMB signing disabled | Network setting that can allow credential-relay attacks |
| OSINT | Publicly available information about the company and its employees |
Group findings into themes before writing (weak authentication, excessive permissions, insecure defaults, insufficient hardening, poor credential hygiene, limited monitoring visibility).
Use careful qualifiers — never overstate:
| Overstated | Defensible |
|---|---|
| ”The client did not detect our activity." | "Testing activities appeared to go mostly unnoticed based on information available to the tester." |
| "The client has no hardening process." | "The issues identified suggest gaps in configuration management and system hardening." |
| "The security team failed to detect us." | "The assessment identified opportunities to improve visibility and alerting for internal attack activity.” |
Template:
During the [ASSESSMENT_TYPE] against [CLIENT_NAME], [CONSULTING_COMPANY] identified [N] findings
affecting the confidentiality, integrity, or availability of [CLIENT_NAME]'s systems: [HIGH] high-risk,
[MEDIUM] medium-risk, and [LOW] low-risk.
The assessment found that [POSITIVE_OBSERVATION]. However, the highest-impact findings related to
[THEME_ONE], [THEME_TWO], and [THEME_THREE]. These weaknesses allowed the tester to [BUSINESS_IMPACT],
demonstrating that an attacker with [STARTING_POSITION] could [FINAL_IMPACT].
To reduce risk, [CLIENT_NAME] should prioritize [SHORT_TERM_ACTIONS]. Longer term, [CLIENT_NAME]
should review [PROCESS_AREA] to prevent recurrence. Once remediation is complete, a focused retest
should validate that the attack paths in this report have been closed.Attack Chain
Include an attack chain when multiple findings combine into larger impact (internal AD compromise, external-to-internal, web-exploit-to-server, credential-issue-into-lateral-movement). It shows how the tester moved from initial position to final impact, and tells the client which fix would break the path.
Three layers, in order:
- Narrative paragraph — one short story:
During the internal penetration test against [CLIENT_NAME], the tester gained a foothold in the internal network, moved laterally, and ultimately compromised the [DOMAIN] Active Directory domain. The chain shows the path of least resistance and how several configuration and authentication weaknesses combined to enable domain compromise. - Bullet flow — concise step list before detailed evidence:
1. Captured NTLMv2 hash for [USER] using Responder. 2. Cracked [USER] hash offline with Hashcat. 3. Enumerated AD with BloodHound; found [SVC_ACCT] had local admin on [HOST]. 4. Kerberoasted [SVC_ACCT], cracked offline, dumped LSA secrets from [HOST]. 5. Recovered [SRV_ADMIN] creds; logged into [HOST2] where [PRIV_USER] was logged in. 6. Dumped [PRIV_USER] TGT, pass-the-ticket, used DCSync rights to dump the Administrator hash. 7. Authenticated to the DC and dumped NTDS — full domain compromise. - Per-step evidence — each major step shows: tool used · command run · redacted output ·
why it matters · which finding it supports. Keep output tight and redacted (
<SNIP>,<HASH REDACTED>,<KERBEROS TICKET REDACTED>).
Summary of Recommendations
Turns findings into a remediation roadmap. Answer: what to fix first, what’s quick, what needs process change, what needs long-term investment — and which finding each maps to.
## Summary of Recommendations
### Short-Term
- [ACTION] — addresses [FINDING_ID]
### Medium-Term
- [ACTION] — addresses [FINDING_IDS]
### Long-Term
- [ACTION] — supports broader security maturity, reduces recurrence| Strong (tied to findings) | Weak (generic) |
|---|---|
| “Disable LLMNR and NBT-NS across the workstation fleet to address F-001." | "Improve security." |
| "Deploy unique local administrator passwords (LAPS) to address F-003 and reduce reuse risk." | "Use better passwords.” |
Example tiers: Short — disable unnecessary name-resolution protocols, rotate compromised passwords, remove default creds, restrict file-share permissions. Medium — review service-account password policy, deploy unique local-admin passwords, improve delegation review, increase auth/lateral-movement logging. Long — baseline hardening templates, formalize configuration management, improve password policy/onboarding, schedule periodic AD security reviews.
Appendices
Static (almost every report):
| Appendix | Must contain |
|---|---|
| Scope | IP ranges, URLs, applications, domains, facilities, testing dates, exclusions |
| Methodology | Repeatable process: enumeration → exploitation → validation → reporting |
| Severity Ratings | Definitions + criteria for Critical/High/Medium/Low/Informational (not just labels) |
| Biographies | Tester qualifications/experience (useful for PCI/compliance/client confidence) |
Dynamic (only when relevant):
### Exploitation Attempts & Payloads
| Timestamp | Host | Payload | Path | SHA256 | Cleanup Status |
|-----------|------|---------|------|--------|----------------|
| [TIME] | [HOST] | [PAYLOAD] | [PATH] | [HASH] | Removed / Left for client |
### Compromised Credentials
| Account | Type | Source | Action Required |
|---------|------|--------|-----------------|
| [DOMAIN]\[USER] | Password / Hash / Ticket | [SOURCE] | Rotate password |
### Configuration Changes
| Timestamp | Host | Change | Approval | Reverted |
|-----------|------|--------|----------|----------|
| [TIME] | [HOST] | [CHANGE] | [APPROVAL_REF] | Yes/No |
### Additional Affected Scope
| Finding ID | Affected Host | Evidence |
|------------|---------------|----------|
| [FINDING_ID] | [HOST] | [EVIDENCE_PATH] |- Information Gathering (external pentests) — whois, domain ownership, subdomains, public emails, breach-data references, TLS analysis, exposed ports/services.
- Domain Password Analysis (after domain compromise) — hashes obtained, number/percentage cracked, privileged accounts cracked, top passwords, length distribution, reuse. Generate it with DPAT (Domain Password Analysis Tool) from the cracked NTDS hashes.
These dynamic appendices are fed directly by the Reporting_Documentation trackers (Payload Log → Exploitation Attempts; System Modifications → Configuration Changes; Credentials note → Compromised Credentials).
Report Production & QA
- Start during testing. Fill static sections (client, scope, dates, source IPs, environment names) while scans run. Draft each finding and attack-chain note while the context is fresh.
- Use blank templates, never clone a client’s old report — copying risks leaking another client’s
name/dates/scope/findings. Keep placeholders (
[CLIENT_NAME],[ASSESSMENT_TYPE],[TESTER_NAME],[START_DATE],[END_DATE],[SCOPE],[SOURCE_IP]). - Findings database — don’t rewrite common findings each time. The site’s reusable set is Finding_Library; tailor each to the client environment before use.
- Word efficiency (if delivering in Word): use styles (Title/Heading/Finding/Body/Code/Caption)
not direct formatting; built-in Insert Caption so figures auto-renumber; ToC + page numbers;
custom numbering (
F-001,Appendix A); disable spell-check on code/console style; useful keysF9(update fields/ToC),Shift+F5(last edit),F4(repeat). Macros/.dotmcan auto-fill placeholders and strip sections by report type. - Reporting tools — this site standardises on SysReptor (see Reporting_SysReptor); other options the field uses: Ghostwriter, Dradis, WriteHat (free); AttackForge, PlexTrac, Rootshell Prism (paid).
- QA process — every report through QA if possible:
Author Draft → QA (technical) → QA (style, optional) → Client Draft → Review meeting → Final. Solo minimum: sleep on it, re-read with fresh eyes. Use track changes; QA fixes small issues, sends structural problems back to the author.
## QA Checklist (remove before delivery)
- [ ] Client name correct throughout - [ ] Severity labels consistent
- [ ] Dates correct throughout - [ ] Executive summary matches findings
- [ ] Scope matches signed scope - [ ] Finding IDs unique
- [ ] Screenshots cropped + readable - [ ] Sensitive data redacted
- [ ] Captions numbered correctly - [ ] ToC updated, hyperlinks tested
- [ ] Grammar/spelling checked - [ ] Draft/Final status correct- Archive after final acceptance (retain until retest at minimum, per retention policy):
tar -czvf [CLIENT]_[ASSESSMENT_TYPE]_archive.tar.gz [ENGAGEMENT_FOLDER]/
Client Communications
- Start-of-testing notification (kickoff): tester name, engagement type/scope, source IP(s), testing dates, primary/secondary contacts.
- End-of-day notification: testing window, source IPs, optional high-level notes, expected next steps / draft-delivery date — helps the client correlate alerts and avoid surprises.
- During the engagement, contact the client for: newly discovered subnet/subdomain worth scoping, critical external RCE, suspected outage, reaching Domain/Enterprise Admin, permission before high-risk actions, clarification on sensitive systems to avoid.
Subject: Start of Testing Notification — [CLIENT_NAME] [ASSESSMENT_TYPE]
Tester: [TESTER_NAME] Dates: [START]–[END] Source IP(s): [SOURCE_IPS]
Scope Summary: [SCOPE_SUMMARY] Primary/Secondary Contact: [CONTACTS]Ethical boundary: if the client asks for a change that alters the truth, do not falsify severity, status, affected assets, or technical facts. Acknowledge the concern, clarify what can change, preserve accuracy, offer alternatives:
We cannot mark this finding as resolved without evidence of remediation. We can include a management
response describing the remediation plan, owner, compensating controls, and expected completion date.Report-Type Differences (brief)
Report structure shifts by assessment type — internal/AD emphasises attack chain + compromised-creds + domain-password-analysis appendices; external emphasises OSINT + attack surface; web app emphasises OWASP mapping + role-based testing; purple team emphasises detection coverage + ATT&CK mapping. The full report-type catalogue, deliverable decision tree, and finding template live in Reporting_Findings_Types — pick the type there, assemble it here.
🛠️ Troubleshooting & Edge Cases
| Pitfall | Fix |
|---|---|
| Executive summary too technical | Rewrite for a non-technical budget owner; cut acronyms |
| 50 pages of console output | Concise evidence + <SNIP>; move large tables to a spreadsheet |
| No attack chain when findings combine | Add one; show the path and which fix breaks it |
| Attack chain with no evidence | Include command, redacted output, and which finding each step supports |
| Recommendations are generic | Tie each to a finding ID (short/medium/long-term) |
| Severity ratings vague | Define severity criteria in an appendix, not just labels |
| Redacting with blur/pixelation | Use <REDACTED> / solid redaction (blur is reversible) |
| Overstating conclusions | Use qualifiers — “appeared”, “suggests”, “based on information available” |
| Reused another client’s report | Start from a blank template with placeholders; QA checklist catches leftovers |
| Delivered only a draft | Issue Final after review — some auditors won’t accept a draft |
📝 Reporting Trigger
Finding Title: N/A — report-assembly methodology, not a vulnerability finding. Impact: A clear, well-structured report lets the client understand business risk, reproduce findings, and prioritise remediation — the difference between a finding that gets fixed and one that gets ignored. Root Cause: N/A — operational documentation. Recommendation: Assemble every report around business value and technical reproducibility: an executive summary in plain language, an attack chain that connects findings into a realistic compromise path, recommendations mapped to findings, and appendices that preserve detail without clutter. Start the report on day 1 and QA before delivery.
🔗 Related Nodes
- Reporting_Documentation — evidence discipline, folder structure, logging, and the trackers that feed the appendices
- Reporting_Findings_Types — report types, deliverable decision tree, and the per-finding template
- Finding_Library — reusable finding write-ups seeded from the manual’s
📝 Reporting Triggerblocks - Reporting_SysReptor — the SysReptor production workflow and report-readiness checkpoints
- Engagement_Cockpit — the live trackers (host tracker, credential ledger) that become appendix data