Cross-cutting methodology
Writing the report
All 9 HTB certifications require a professional report in English, submitted once. It is often what makes candidates fail. This page covers note-taking, structure, writing findings, rating severity and proofreading.
Every certificationPentest reportIncident report
Taking notes during the exam
A good report is written during the exam, not after. Notes are its raw material.
Organisation
- One folder per host: services, access obtained, credentials, screenshots.
- A single file for the credentials found and where they work.
- A timestamped timeline of every important action.
- A network map kept up to date as you go.
Tools
- SysReptor: ready-made HTB templates, PDF export.
- Obsidian or CherryTree: hierarchical note-taking.
- Log your terminal (for instance with the
scriptcommand) so no output is lost. - Notes stored outside the Pwnbox, which disappears after 4 days.
Screenshot ruleA useful screenshot shows the command, the result and something that identifies the machine (hostname, IP). Crop it, and highlight what matters.
Structure of a pentest report
| Part | Content | Reader |
|---|---|---|
| Executive Summary | One or two pages: context, overall risk, major findings, action priorities. | Management |
| Scope & Methodology | Targets, dates, test type, method followed, limitations met. | Everyone |
| Attack Narrative | The step-by-step story, from initial access to the final objective. | Technical teams |
| Findings | One finding per vulnerability, from most to least severe. | Technical teams |
| Remediation Summary | Actions ranked: short, medium and long term. | Management and technical |
| Appendices | Compromised hosts and accounts, files dropped and cleaned up, tools used. | Technical teams |
Writing a finding
A reviewer must be able to reproduce every finding from the text alone. Template ready to copy:
## [Severity] Finding title **CVSS v3.1:** 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) **Affected hosts:** 10.10.10.5 (WEB01) ### Description What the issue is, in two or three sentences. ### Impact What an attacker can achieve, in business terms. ### Evidence Screenshots and command output, each with a one-line caption. ### Steps to Reproduce 1. ... 2. ... ### Remediation Concrete fix first, then defence-in-depth measures. ### References Vendor advisory, CWE, OWASP or MITRE ATT&CK links.
Common mistakeA vague remediation (“apply patches”, “improve security”) is worthless. Give the precise fix: version to install, setting to change, permission to remove.
Rating severity
Two approaches, often combined: the technical CVSS score, and risk, which weighs in the organisation's context.
CVSS v3.1
- Base metrics: AV, AC, PR, UI, S, then impact C, I, A.
- Always give the full vector, not just the score.
- Official calculator: the FIRST website.
- Scale: see the Reference frameworks cheat sheet.
Risk = likelihood × impact
- A critical flaw on an isolated machine can be less urgent than a medium one exposed to the Internet.
- Explain the reasoning in one sentence within the finding.
- Stay consistent from one finding to the next.
The incident report
For the defensive part (CJCA, CDSA, CDEP), the structure changes: you tell the story of an attack suffered, not an attack carried out.
| Part | Content |
|---|---|
| Executive Summary | What happened, the impact, the current status. |
| Timeline | Timestamped chronology (UTC): initial access, attacker actions, detection, response. |
| Scope | Affected hosts, accounts and data. |
| Technical Analysis | Evidence step by step: SIEM queries, events, artefacts, with the matching ATT&CK technique. |
| Root Cause | How the attacker got in and why it was possible. |
| Indicators of Compromise | IPs, domains, hashes, accounts, file paths. |
| Recommendations | Containment, eradication, new detections, hardening. |
Classifying an alertFor each SIEM alert: verdict (true or false positive), the evidence supporting it, and the query used to check.
Professional wording
Simple, precise English beats elaborate English. Short sentences, active voice, past tense for the narrative.
| Informal | Professional wording |
|---|---|
| We found… | During the assessment, the tester identified… |
| So an attacker can… | This allows an attacker to… |
| No login needed | Without authentication / unauthenticated |
| You should… | It is recommended to… / We recommend… |
| Quickly | In the short term |
| We checked it with… | This finding was confirmed by… |
| First way in | Initial access / initial foothold |
| Got admin | Privilege escalation |
| Fake alert | False positive |
| Temporary fix | Workaround / mitigation |
Certification specifics
| Certification | Good to know |
|---|---|
| CJCA | Two parts in a single report: the penetration test and the SIEM alert analysis. |
| CDSA, CDEP | Incident or analysis report: timeline, evidence and detections come first. |
| CWEE | Submitted as Markdown (.md) files in a ZIP archive protected by the password given in the instructions. |
| Others | Unencrypted PDF or ZIP, 20 MB maximum. |
Checklist before submitting
- Executive summary readable by a non-technical person
- Every finding has a severity, a CVSS vector and a precise remediation
- Every finding has verifiable reproduction steps
- Every screenshot is readable and captioned
- Findings sorted from most to least severe
- Timeline consistent with the evidence
- No needlessly sensitive data (passwords masked where possible)
- English spelling and grammar proofread
- Format, size and file name match the instructions
- A full proofread with fresh eyes, at least a few hours after writing