Report Creation
Objectives: By the end of this topic, you will be able to…
- Properly document a technical activity
- Organize findings with clarity and order
- Produce reproducible and exportable reports
- Recognize the importance of professional reports in audits and pentests
Why is it important to know how to write cybersecurity reports?
- An excellent technical analysis loses value if it is not communicated well
- In cybersecurity, reports are the primary means of:
- Documenting findings in audits, pentests, or forensic analysis
- Recommending mitigation actions
- Communicating risks to non-technical individuals (executives or management)
- Reports serve as evidence records in legal or regulatory contexts
“If it is not documented, it does not exist.”
Structure of a cybersecurity technical report
| Section | Contents |
|---|---|
| Cover / Title | Name of analysis, author, date, confidentiality |
| Table of contents | For fast navigation of the document |
| Introduction | Objective of the analysis, scope, client context |
| Methodology | Techniques, tools and sources used |
| Findings | Detailed list of vulnerabilities with description, evidence, impact, severity, and mitigation |
| Conclusions | Technical summary of the security status |
| Appendices | Extensive details, complete outputs, scripts, configuration |
Differences between technical and executive reports
| Characteristic | Technical Report | Executive Report |
|---|---|---|
| Audience | Security teams, sysadmins | Managers, directors, customers |
| Language | Specific, with technical terminology | Clear, simplified, impact oriented |
| Contents | Technical details, commands, evidences | Summary of findings and business implications |
| Length | Long (may include appendices) | Short (2-4 pages max.) |
Both reports may be derived from the same work, but should be written with different objectives in mind.
Best practices for technical writing
- Clarity: use precise, direct, and unambiguous language
- Consistency: use consistent terminology throughout the document
- Objectivity: base your work on facts and evidence, avoiding judgments or speculation
- Professional format: clean structure, tables, numbering, styles
- Reproducibility: include exact commands, tools, versions, configurations
- References: cite CVEs, standards (OWASP, MITRE), tool documentation
A good report not only shows a problem, but also how it was discovered and how to solve it.
Evidence collection and organization
Types of technical evidence:
- Screenshots of terminals, browsers, or tools
- File hashes, traffic logs, or activity logs
- Configuration files or scripts used
- Command output (
nmap,whois,dig, etc.)
Best practices:
- Name files clearly and in an orderly manner
- Include a timestamp or context for each piece of evidence
- Avoid altering the evidence (capture it at the moment)
- Use SHA256 hash to ensure the integrity of relevant files
- Include a screenshot accompanied by explanatory text
Tools for generating professional reports
| Tool | Description |
|---|---|
| Markdown | Lightweight language ideal for reproducible technical documentation |
| Typora / Obsidian / VS Code | Markdown-friendly editors with PDF export |
| LaTeX | For academic reports or reports with complex formatting |
| LibreOffice / Word | Visual templates for executive or formal reports |
| CherryTree | Structured technical notes during the analysis |
| Flameshot | Quick screenshots with annotations |
Document from the beginning of the analysis, not at the end. The report is a process that runs parallel to the technical investigation.
Hands-on lab
Requirements: Kali Linux, Metasploitable 2 (deployment guide), CherryTree
Part 1: Structure and analysis of technical reports
- Review the example of a simulated technical report
- With your partner, identify and discuss the purpose of each section
Part 2: Capturing and documenting evidences
- Deploy the Metasploitable 2 machine using the attached guide
- Execute a controlled network scan:
nmap -sS -A -T4 192.168.1.10 -oN nmap_scan.txt- Analyze and highlight findings: open ports, service versions, known vulnerabilities
- Create a findings table:
| Port | Service | Short description | Estimated risk |
|---|---|---|---|
| 22 | SSH | Service accessible from local network | Medium |
| 80 | HTTP | Website with possibly sensitive information | High |
Part 3: Organization with CherryTree
- Create a
.ctdfile with the following hierarchy:
Project: Host scanning and analysis
-- Methodology
-- Results
-- Evidences
-- Recommendations
-- Notes by tool
- Insert screenshots, text snippets with tool outputs, notes and observations
- Export to
.pdfor.html
Part 4: Best practices for technical writing
- Review a draft of a technical finding with your partner and improve clarity, objectivity, and references
- Write at least one full finding using:
Finding title
---------------------
Summary:
Technical description:
Attached evidence:
Recommendations:
Submission
- PDF report generated using CherryTree (or original
.ctdfile) - Screenshots used as evidence
- Generated
nmap_scan.txtfile - Technical findings table
- Personal reflection (max. 1 paragraph)
Key concepts
| Term | Definition |
|---|---|
| CVE | Standardized identification system for known vulnerabilities |
| Pentesting | Authorized security assessment that simulates real attacks |
| Hash | Function that generates a unique fingerprint of a file to verify its integrity |
| Nmap | Network scanning tool for host and service discovery |
Test yourself
-
Structure: What sections are essential in a pentest technical report? What is the key difference between a technical report and an executive report?
-
Evidence: Why is it important to calculate the SHA256 hash of evidence files? What would happen if the evidence were altered?
-
Practice: Given a finding of open port 21 (FTP) with anonymous access, write a complete finding entry with description, evidence, impact, and recommendation.