🛡️ Methodology Checklist
- Classify every finding: Critical / High / Medium / Low / Info
- Write title as an impact statement (not just a vulnerability name)
- Complete all template sections: Overview, Evidence, Risk, Recommendation
- Provide reproduction steps a junior tester can follow exactly
- Give specific, actionable remediation — avoid generic advice
- Select correct testing perspective: Black / Grey / White box + Evasion level
- Review good/bad finding examples from this node before finalizing
🎯 Operational Context
Use when: Classifying findings for the report — understand the difference between vulnerability, misconfiguration, informational, and positive finding categories. Think Dumber First: Every finding needs: Title, Severity (Critical/High/Medium/Low/Info), Affected Asset, Business Impact, Technical Description, Evidence (screenshot + command), and Remediation. Missing any field = incomplete finding. Skip when: N/A — reference document.
⚡ Tactical Cheatsheet
| Report Type | When to Use |
|---|---|
| Vulnerability Assessment | Mostly automated scanning, no/limited exploitation |
| Internal Penetration Test | Tested from inside network, AD compromise focus |
| External Penetration Test | Public-facing assets, anonymous attacker simulation |
| Web App Penetration Test | Application as primary target (OWASP-style) |
| Purple Team | Red+blue collaboration, detection evaluation |
| Post-Remediation Report | Retest only original findings on original hosts |
| Attestation Letter | Third-party proof (1-2 pages, no sensitive technical detail) |
| Vulnerability Notification | Urgent critical finding during active assessment |
🔬 Deep Dive & Workflow
Finding Structure (Every Finding Must Answer)
1. What is the issue?
2. Where is it? (host/URL/application)
3. Why does it matter? (business impact)
4. How did you prove it? (evidence)
5. How does the client fix it? (specific remediation)
Finding Template
# [FINDING TITLE]
## Severity
Critical / High / Medium / Low / Informational
## Affected Scope
- [HOST / URL / DOMAIN / APPLICATION]
## Description
Client-specific description — name the real service, real host, real exposure path.
## Impact
What an attacker can do if unresolved. Business consequence.
## Evidence / Reproduction Steps
### Step 1 — Discovery
[command]
What this shows.
### Step 2 — Validation/Exploit
[command or screenshot]
What this proves.
### Step 3 — Proof of Impact
[output/screenshot]
Why this matters.
## Remediation
Specific actionable guidance — exact registry paths, settings, or steps.
Warn about operational risks (e.g., "test on limited systems first").
Provide immediate workaround AND durable fix where possible.
## References
- [MITRE/OWASP/vendor doc link]Good vs Bad Finding Examples
Weak: "Default Credentials can allow compromise."
Strong: "The Tomcat Manager on [IP] accepted weak credentials, allowing deployment of a malicious WAR file and remote command execution as the service account. Administrative interfaces must not rely on guessable credentials and should be restricted to trusted management hosts."
Weak remediation: "Reconfigure registry settings."
Strong remediation:
Update HKLM\<PATH>\<VALUE> from <OLD> to <NEW>.
Test on a limited group of systems before broad deployment.
Evidence Quality Rules
| Situation | Required Evidence |
|---|---|
| Cleartext creds in traffic | Screenshot of login prompt + packet capture showing base64/plaintext |
| SUID/sudo privesc | whoami before + id after + command used |
| RCE via web vuln | Request (Burp) + response showing command output + hostname proof |
| AD compromise | whoami /priv + Domain Admins group membership screenshot |
Proof of target ownership: Always include URL, hostname, or IP in evidence. Without this, any screenshot can be challenged.
Redaction format: Use <REDACTED> or <HASH REDACTED> — not blur/pixelation (easily reversed).
Report Deliverable Workflow
1. Draft report → client review
2. Hold readout call → capture feedback
3. Adjust: accept factual corrections, reject severity downgrades without evidence
4. Final report → official deliverable
5. Post-remediation (if requested) → retest only original findings on original hosts
6. Attestation letter → for auditors/vendors requiring proof-of-testing
Key rule: Never change technical truth under client pressure. Can accept: wording adjustments, management responses, clarifications. Cannot accept: severity changes without evidence, removing valid findings.
Deliverable Decision Tree
Mostly scanner output, no exploitation? → Vulnerability Assessment Report
Exploited, demonstrated impact? → Penetration Test Report
Tested from internet? → External Pentest Report
Tested from inside/AD? → Internal Pentest Report
Detection evaluation with blue team? → Purple Team Report
Only verifying fixes? → Post-Remediation Report (scope = original findings only)
Third party just needs proof testing happened? → Attestation Letter
Leadership needs a briefing? → Slide Deck
Found critical issue right now during test? → Vulnerability Notification (urgent, concise)
Testing Perspective Labels
| Label | Meaning |
|---|---|
| Black Box | Minimal info (company name / network access only) |
| Grey Box | Partial info (IP ranges, URLs, limited creds) |
| White Box | Full info (source code, configs, credentials, diagrams) |
| Non-Evasive | Noisy — comprehensive discovery |
| Hybrid Evasive | Stealthy then noisier — evaluate detection thresholds |
| Fully Evasive | Stay undetected as long as possible |
🛠️ Troubleshooting & Edge Cases
| Problem | Cause | Fix |
|---|---|---|
| Severity rating inconsistent | No severity framework | Use CVSS 3.1 base score as baseline; adjust for environment context (DA impact = Critical) |
| Duplicate findings | Same vuln on multiple hosts | Group: one finding, list all affected hosts in asset field; note most critical instance |
| Informational findings overwhelming report | Too many low-severity items | Separate appendix for Info findings; executive section covers only Critical/High |
| Remediation advice too generic | Not actionable | Include: specific configuration change, exact command/GPO, vendor documentation link, and estimated effort |
| Positive findings neglected | Only documenting weaknesses | Include security controls that worked: MFA preventing spray, EDR blocking payload — shows what to maintain |
📝 Reporting Trigger
Finding Title: N/A — Reporting Classification Reference Impact: Proper finding classification ensures remediation prioritization focuses on highest-risk items first, enabling efficient resource allocation for security improvement. Root Cause: N/A — operational documentation. Recommendation: Adopt a consistent finding classification framework (CVSS + contextual adjustment). Ensure all findings include reproducible evidence, affected assets, and specific remediation guidance. Review findings with client before finalizing report to correct misunderstandings about scope or context.