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 analyses, recommending mitigation actions, and communicating risks to non-technical stakeholders such as executives or management. They also serve as evidence records in legal or regulatory contexts.
A report is the deliverable of an engagement, so it inherits that engagement’s shape. A typical assessment moves through reconnaissance, scanning and enumeration, analysis of what was found, exploitation where the rules of engagement allow it, and finally reporting. Each earlier phase produces the raw material the report later has to defend, and class 09 covers that methodology in full. What matters for this class is the consequence: the quality of your report is largely fixed before you start writing it, by how carefully you recorded what you did while you were doing it.
“If it is not documented, it does not exist.”
From passive reconnaissance to active scanning
In class 01 you built a picture of a target without ever contacting it: whois registrations, DNS answers, published documents and the metadata inside them. That is passive reconnaissance, and it reads sources that are already public. This class asks you to do something categorically different. A port scan sends packets to a host and draws conclusions from how the host answers, which is active reconnaissance, and in most jurisdictions it is lawful only against systems you own or have written authorization to test.
That authorization is what the Scope and Rules of Engagement section of a report exists to record. Class 01 asked what you are permitted to look at; rules of engagement answer what you are permitted to touch, by which techniques, and within which window. A scope defined this way is narrow by design: the hosts named in it, by the techniques named in it, and nothing else that happens to be reachable from where you are standing.
Scope also determines what counts as a finding at all. An unchanged default credential, a service left listening on an interface nobody meant to expose, an internal segment reachable from a network that should not touch it: these are reportable in their own right, and they are easy to walk past precisely because you used them to get your work done rather than tripping over them as obstacles. Part of writing a report is noticing what you took for granted while producing it.
A port scan is a single command, and you should be able to account for every part of it before you run it. Taking the widely used invocation nmap -sS -A -T4 <target> -oN <file> as the example:
| Flag | What it does |
|---|---|
-sS | TCP SYN scan. Sends a connection request and judges the port from the reply without completing the handshake |
-A | Aggressive mode. Enables service and version detection, OS fingerprinting, default NSE scripts, and traceroute |
-T4 | Timing template 4 of the six available (-T0 to -T5, default -T3). Shorter timeouts, more probes in parallel |
-oN <file> | Writes nmap’s normal, human-readable output to a file |
-sS builds TCP packets directly instead of asking the operating system to open a connection for it, which requires raw socket access and therefore root privileges. Run it as an unprivileged user and nmap refuses the scan type rather than silently substituting a different one. Class 15 explains the three-way handshake this rests on, how a SYN scan interprets the response, and why the technique was historically considered stealthy. You do not need that depth today, only the ability to say what you ran and why it needed privilege.
-A is the flag everything downstream depends on. It is what turns 80/tcp open http into 80/tcp open http Apache httpd 2.2.8, because it switches on version detection. Without a version string there is nothing to look a vulnerability up against, and a findings table degrades into a list of open ports rather than a list of findings.
-T4 trades stealth for speed. On an isolated network that trade costs nothing. Against a monitored network it costs a great deal, since a burst of connection attempts from a single source is one of the oldest detection signatures in existence, and class 15 covers the detection side of that exchange.
-oN writes the scan to a file that is timestamped and records the exact command that produced it in its header line, which makes it the artifact every row of a findings table has to be traceable back to. Treat that output as evidence from the moment it exists.
When you read the output, three port states account for nearly everything you will see. open means a service accepted the probe. closed means the host replied but nothing is listening there. filtered means nmap received no usable reply at all, which usually indicates a firewall or filter discarding the probe rather than an absent service. The distinction between closed and filtered is the one most often collapsed in student reports, and it matters because one of them describes the target while the other describes the path to it.
Structure of a cybersecurity technical report
| Section | Contents |
|---|---|
| Cover / Title / Table of contents | Name of analysis, author, date, confidentiality classification, and a navigable index |
| Introduction | Objective of the analysis, scope, client context |
| Scope & Rules of Engagement | Testing boundaries, authorized targets, exclusions, legal constraints, and agreed-upon limitations |
| 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 |
The report template in class 01 is a simplified instance of this structure, filled in for an OSINT engagement.
Anatomy of a finding
The Findings row of the table above is the one that expands. A report has sections, a findings section holds findings, and each individual finding has an internal structure of its own. That structure is what you will be assessed on, so it is worth stating in full.
| Field | What goes in it |
|---|---|
| Title | One line naming the issue and the affected component |
| Severity | Low, Medium, High or Critical, with the reasoning available if challenged |
| Summary | Two or three sentences a reader can act on without reading further |
| Technical description | What you ran, what it returned, and what that output means |
| Evidence | Pointers to specific artifacts: file names, appendix identifiers, line numbers |
| CVE reference | The identifier where the issue maps to a published vulnerability, or an explicit statement that it does not |
| Impact | What an attacker gains, stated concretely |
| Recommendation | The specific change that fixes it, rather than the goal that change serves |
Templates present this structure at different granularities. A full report template spells all eight fields out separately; a compact one may give you four boxes, collapsing title and severity into the heading and folding impact into the technical description. They are the same content at different resolutions, so when a template hands you four boxes the remaining four fields still have to appear inside them. A finding that omits its severity, omits its CVE reference, or gestures at evidence instead of naming it is incomplete regardless of which template it was written against.
Severity, exploitability, and the version-to-CVE chain
The version strings that -A produced are lookup keys, and treating them as such is the step that separates a report from a scanner dump. vsftpd 2.3.4, Samba 3.0.20 and Apache httpd 2.2.8 are not findings on their own. They become findings once you look them up and establish that a specific published vulnerability affects that specific version. A finding that skips this step reads as an opinion rather than a result, and it is the single most common way an otherwise competent scan turns into an indefensible report.
A CVE identifier is the standard key for that lookup. The glossary defines it as a standardized identification system for known vulnerabilities, which is accurate but does not tell you what to do with one. In practice you take the product and version nmap reported, search the CVE Program catalogue at https://www.cve.org or the NIST National Vulnerability Database at https://nvd.nist.gov, and read the entries for two things: whether the version you found falls inside the affected range, and what conditions the vulnerability requires. That second point is where student findings most often overreach. The Samba 3.0.20 command injection through the username map script option (CVE-2007-2447) applies only where that non-default option has been configured, so a version match is a hypothesis you still have to confirm. The backdoor that was introduced into the vsftpd 2.3.4 source tarball (CVE-2011-2523) sits in the build itself and requires no particular configuration on the target’s side, so the same scanner output supports a confirmed claim in one case and only a hypothesis in the other.
NVD publishes a CVSS score alongside most entries: a number from 0.0 to 10.0 produced by a documented formula, banded by current CVSS versions as Low (0.1 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9) and Critical (9.0 to 10.0). Rather than computing a CVSS vector yourself, which this course does not ask of you, know that the number exists, that it is comparable across findings because it comes from a published method rather than from an individual’s impression, and that citing it is stronger than asserting a severity of your own invention.
Plenty of real findings have no CVE and therefore no CVSS score: plaintext Telnet, an unchanged default password, an over-permissive share. For those you rate the finding yourself, which is what any “estimated risk” or “severity” column is asking of you. A defensible rating answers two questions. The first is impact: if this is exploited, what does the attacker obtain, expressed against confidentiality, integrity and availability, the same three properties class 01 introduced as the CIA triad. Reading data an attacker should not see is generally worse than degrading a service, and executing arbitrary code is worse than either, because it subsumes both. The second is exploitability: is the affected service reachable from where an attacker would realistically stand, does the attack require valid credentials, does it depend on a non-default configuration, and does a working public exploit already exist. A flaw that yields root but needs local access and an unusual configuration is not the same risk as one that yields root to anyone who can reach the port.
Combining the two questions gives you a scale you can defend when challenged.
| Rating | Typical shape |
|---|---|
| Critical | Unauthenticated remote code execution or full data disclosure, reachable across the network, with a public exploit available |
| High | Serious impact behind one precondition: credentials needed, a non-default configuration required, or no reliable public exploit yet |
| Medium | Real but bounded impact, such as information disclosure that assists a later attack, or an exposure requiring an attacker already on the local segment |
| Low | Minor information leakage or a hardening gap with no direct path to compromise |
Two habits follow from this. Pre-filled example rows in a template show you the format, not the reasoning, since their ratings are not derived from anything in your engagement; read them as a layout and derive your own. And when someone asks whether an open port is “actually exploitable”, the vocabulary above is the answer: reachability, authentication requirement, configuration precondition, and the existence of a public exploit are the additional information you would need in order to say.
Rating by structured judgement is where this course starts rather than where it ends. Class 04 introduces DREAD, which scores five named criteria from one to ten, two of which are damage and exploitability, the same dimensions you are weighing informally here.
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) | Typically short, often 2-4 pages |
Both documents are built from the same evidence, but they make different claims from it. The technical report establishes what is true about the systems; the executive report translates that into what it costs the organization and what should be funded first. The finding that reads “Samba 3.0.20 is affected by CVE-2007-2447” in one becomes “an attacker already on the internal network can take full control of the file server without credentials” in the other. Writing the executive version is a translation problem rather than a summarizing one, which is why it is usually harder than it looks.
Best practices for technical writing
Good technical writing demands clarity, consistency, and objectivity: use precise, unambiguous language; apply consistent terminology throughout; and base all statements on facts and evidence rather than speculation or personal judgment. On the formatting side, maintain a clean structure with tables, numbering, and styles that aid navigation, include exact commands, tool versions, and configurations for full reproducibility, and cite the relevant CVE identifiers, the OWASP guidance that applies, MITRE’s CWE weakness catalogue or ATT&CK technique identifiers where they fit, and the documentation of the tools you relied on.
A good report not only shows a problem, but also how it was discovered and how to solve it.
Evidence collection and organization
Technical evidence takes many forms: screenshots of terminals, browsers, or tools; file hashes, traffic logs, and activity logs; configuration files or scripts used; and raw command output from tools like nmap, whois, and dig. Regardless of type, every piece of evidence should be named clearly and stored in an orderly structure, captured at the moment of discovery without alteration, timestamped or annotated with context, and accompanied by a SHA-256 hash to verify its integrity later. Each screenshot should appear alongside explanatory text so that anyone reading the report can understand what it shows without having to ask.
The SHA-256 requirement deserves a sentence of its own, because its purpose here is not the one you are used to. You already use hashes to detect accidental corruption. In an evidentiary context the party best placed to alter the evidence is usually the party holding it, which is you, so a hash carries weight with a third party only if it was computed at the moment of collection and then recorded somewhere you cannot quietly revise afterwards: an email to the client, a signed manifest, a commit in a repository the client can read. A digest you generate a week after the engagement establishes that the file has not changed in the week since, which is not the claim anyone needed.
In practice this means hashing each artifact at the moment it is produced rather than in a batch at the end: sha256sum <file> as soon as a scan output exists, recording the digest next to the file name and the capture time, and the same for each screenshot as it is taken. What accumulates is an evidence manifest, a short table of identifier, file name, digest and description, which is what the appendix of a professional report carries and what makes every claim in the body traceable to something that can be re-verified.
Tools for generating professional reports
| Tool | Description |
|---|---|
| Markdown, in whichever editor you already use (Obsidian, VS Code, Typora) | Plain-text source that diffs cleanly, exports to PDF or HTML, and preserves commands and tool output verbatim |
| LaTeX / LibreOffice / Word | For deliverables that must match a client’s document template or a formal typesetting requirement |
| CherryTree | Hierarchical note-taking application for building the evidence tree as you work. A document is a single file in one of four formats: .ctb and .ctx are SQLite-backed, .ctd and .ctz are XML, and the x and z variants are password-protected. .ctd is the sensible default for coursework and for anything you want to version-control, because XML is diff-friendly and opens without a password. Nodes nest to any depth, each holding rich text, images and code blocks, and the whole tree exports to PDF or HTML in one action |
| Flameshot | Screenshot capture with built-in annotation, which matters because a screenshot carrying an arrow and a label needs less explanatory prose beside it |
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 (deployed in Part 0 below), CherryTree
Part 0: Deploy the target
This part covers downloading, importing and configuring Metasploitable 2 as a lab target machine.
Step 1: Download Metasploitable 2
- Official download: Metasploitable 2 (SourceForge)
- File comes as a VMware image (
.vmdk)
Step 2: Import into your virtualization environment
If using VirtualBox
- Create a new VM → choose Linux → Ubuntu (32-bit)
- When asked for a hard disk, select Use existing virtual hard disk and point to the downloaded
Metasploitable.vmdk - Set:
- RAM: at least 1 GB
- CPUs: 1-2
- Network: Internal Network or Host-only Adapter (never use Bridged mode if connected to a real corporate network)
If using VMware
- Open VMware Workstation/Player
- Create a new VM → select Use existing virtual disk
- Choose the
.vmdkfile - Adjust RAM and network settings as above
Step 3: Network configuration
Your attacker machine (Kali Linux, Parrot OS, or Ubuntu with nmap) and Metasploitable must be on the same internal network.
Example:
- Attacker VM:
192.168.56.101 - Metasploitable:
192.168.56.102
Verify connectivity:
ping 192.168.56.102Step 4: Boot and credentials
Boot Metasploitable 2. Default login:
Username: msfadmin
Password: msfadmin
No additional configuration is needed. Leave the machine running as a target for lab exercises.
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
- Make sure the Metasploitable 2 machine deployed in Part 0 is running and reachable
- Execute a controlled network scan:
sudo nmap -sS -A -T4 <target-ip> -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 |
Question
Which open port in your findings table represents the highest risk, and why? What additional information would you need to determine whether it is actually exploitable?
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
Question
What criteria did you use to decide which information belongs in each CherryTree node? Would someone who was not present during the scan be able to reconstruct the analysis from your notes alone?
- 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
Question
What were the most common clarity or objectivity problems you found in the draft? Why does objectivity matter more in a security report than in other forms of technical writing?
- 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 |
| Rules of Engagement (RoE) | Agreed-upon boundaries defining what can be tested, how, when, and what is excluded, protecting both tester and client |
| Hash | Function that generates a unique fingerprint of a file to verify its integrity |
| Nmap | Network scanning tool for host and service discovery |
| Active reconnaissance | Interacting directly with a target system, for example by scanning its ports, as opposed to reading public sources about it |
| CVSS | Common Vulnerability Scoring System. A published method for scoring a vulnerability’s severity from 0.0 to 10.0, banded as Low, Medium, High and Critical |
| Evidence manifest | A table listing each evidence artifact with its file name, SHA-256 digest and description, so that claims in the report can be re-verified |