Nmap to Pentest Report - How to Turn Scan Results Into Professional Findings

Nmap gives you data. Clients need findings. The gap between a terminal full of scan output and a professional pentest report with CVSS scores, business impact analysis, and remediation steps is where most pentesters spend their time. This guide shows you exactly how to bridge that gap - how to take common Nmap results and turn each one into a properly written finding with the structure and detail that clients expect.

The Gap Between Nmap Output and Client Deliverables

Nmap output tells you what is running on a target: open ports, service versions, operating system guesses, and script results. That is reconnaissance data. It is not a finding. A finding requires context that Nmap does not provide: why this matters to the business, how an attacker would exploit it, what the risk level is according to a standardized scoring framework, and what specific steps the client should take to remediate.

Consider a simple Nmap result showing port 23 (Telnet) open on a server. That raw output is one line of text. The corresponding finding in your report needs a descriptive title, a technical explanation of why Telnet is insecure (cleartext transmission of credentials), a CVSS score with a justified vector string, evidence (the Nmap output itself), business impact (credential theft, compliance violations), and specific remediation (disable Telnet, enable SSH, configure firewall rules). One line of Nmap output becomes half a page of professional content.

Multiply that across twenty or thirty findings from a network pentest, and you understand why report writing takes longer than the testing itself. Here are the five most common Nmap-sourced findings and how to write each one properly.

Finding 1 - Unnecessary Network Services Exposed

Example Nmap output:

PORT     STATE SERVICE     VERSION
21/tcp   open  ftp         vsftpd 3.0.3
23/tcp   open  telnet      Linux telnetd
445/tcp  open  netbios-ssn Samba smbd 4.7.6
3389/tcp open  ms-wbt-server Microsoft Terminal Services
8080/tcp open  http        Apache httpd 2.4.49
443/tcp  open  ssl/http    Apache httpd 2.4.49

This is a web server with ports 443 and 8080 serving its intended purpose. But FTP, Telnet, SMB, and RDP are also exposed. Each unnecessary service expands the attack surface.

Finding title: Unnecessary Network Services Exposed

Description: The target host exposes multiple network services that are not required for its primary function as a web server. The following unnecessary services were identified: FTP (port 21), Telnet (port 23), SMB (port 445), and RDP (port 3389). Each exposed service represents an additional attack vector. Telnet transmits credentials in cleartext. FTP and SMB have well-documented exploitation paths. RDP has been the target of multiple critical vulnerabilities including BlueKeep (CVE-2019-0708).

CVSS vector: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N = 5.3 (Medium). Attack Vector is Network because these services are accessible remotely. Attack Complexity is Low because the services are directly reachable. Privileges Required is None and User Interaction is None because no authentication or user action is needed to connect to these services. Confidentiality Impact is Low because the exposed services leak information about the system configuration but do not directly expose sensitive data without further exploitation.

Remediation: Disable all network services that are not required for the server's intended function. Configure host-based firewall rules (iptables or Windows Firewall) to block inbound connections to non-essential ports. Implement network-level firewall rules to restrict access to management services (RDP, SSH) to authorized administrator IP ranges only. Conduct a periodic review of running services on all servers to prevent service sprawl.

Finding 2 - Outdated Apache HTTP Server With Known Path Traversal

Example Nmap output:

PORT    STATE SERVICE VERSION
443/tcp open  ssl/http Apache httpd 2.4.49 ((Unix))
| http-server-header: Apache/2.4.49 (Unix)
|_http-title: Site doesn't have a title

Apache 2.4.49 is vulnerable to CVE-2021-41773, a path traversal and remote code execution vulnerability. This is not a theoretical risk - public exploits are widely available and actively used in the wild.

Finding title: Outdated Apache HTTP Server With Known Path Traversal (CVE-2021-41773)

Description: The target host runs Apache HTTP Server version 2.4.49, which is affected by CVE-2021-41773. This vulnerability allows an attacker to perform path traversal attacks to access files outside the document root. When combined with CGI configurations, it enables remote code execution. The vulnerability exists due to a flaw in the path normalization logic introduced in version 2.4.49. An attacker can use URL-encoded path traversal sequences to bypass access controls and read arbitrary files on the server, or execute commands if mod_cgi is enabled.

CVSS vector: Per NVD, CVE-2021-41773 is scored as 7.5 (High) for path traversal and up to 9.8 if RCE is achievable via CGI. Reference the NVD entry directly for the authoritative score and vector.

Remediation: Update Apache HTTP Server to the latest stable release immediately. Version 2.4.49 should not be running in any environment. If an immediate update is not possible, apply the vendor patch or mitigate by ensuring the "Require all denied" directive is applied to directories outside the document root. Verify that mod_cgi is disabled if not required. Implement a vulnerability management process to track and apply critical patches within a defined SLA.

Finding 3 - Weak TLS Configuration

Example Nmap output:

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLSv1.1:
|     ciphers:
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|_  least strength: C

The server supports TLS 1.0 and TLS 1.1, both of which are deprecated. It also offers 3DES cipher suites, which are considered weak. While TLS 1.2 is available with strong ciphers, the presence of older protocols enables downgrade attacks.

Finding title: Weak TLS Configuration - Deprecated Protocols and Cipher Suites

Description: The TLS configuration on the target host supports deprecated protocol versions and weak cipher suites. TLS 1.0 and TLS 1.1 are enabled, both of which were formally deprecated by RFC 8996 in March 2021. These protocol versions are vulnerable to known attacks including BEAST and POODLE. The 3DES cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA) is also supported, which is vulnerable to the Sweet32 attack (CVE-2016-2183). An attacker in a man-in-the-middle position could force a protocol downgrade and exploit these weaknesses to decrypt traffic.

CVSS vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N = 5.9 (Medium). Attack Vector is Network. Attack Complexity is High because exploitation requires a man-in-the-middle position. Confidentiality Impact is High because successful exploitation could expose encrypted traffic contents.

Remediation: Disable TLS 1.0 and TLS 1.1 on the server. Only enable TLS 1.2 and TLS 1.3. Remove all CBC-mode cipher suites and 3DES ciphers. Configure the server to prefer ECDHE key exchange with AES-GCM ciphers. A recommended cipher configuration for Apache: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256". Test the configuration using tools like SSL Labs or testssl.sh after making changes.

Finding 4 - Default Credentials on Management Interface

Example Nmap output:

PORT     STATE SERVICE VERSION
8080/tcp open  http    Apache Tomcat 9.0.41
| http-default-accounts:
|   [Apache Tomcat Manager Application]:
|     tomcat:tomcat - Valid credentials
|_    admin:admin - Valid credentials

Nmap's http-default-accounts script found valid default credentials on the Tomcat Manager application. This is a critical finding - the Tomcat Manager allows deployment of arbitrary WAR files, which means an attacker can achieve remote code execution on the server using default credentials that are publicly documented.

Finding title: Default Credentials on Apache Tomcat Manager Interface

Description: The Apache Tomcat Manager application on port 8080 is accessible with default credentials (tomcat:tomcat and admin:admin). The Tomcat Manager interface allows authorized users to deploy, undeploy, and manage web applications on the server. An attacker using these default credentials can deploy a malicious WAR file containing a web shell or reverse shell, achieving full remote code execution on the underlying server with the privileges of the Tomcat service account. Default credentials for Apache Tomcat are publicly documented and included in automated exploitation frameworks.

CVSS vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 (Critical). Attack Vector is Network because the management interface is remotely accessible. Attack Complexity is Low because default credentials are publicly known. Privileges Required is None because the attacker uses default credentials to authenticate. Confidentiality, Integrity, and Availability impact are all High because remote code execution provides full control over the server.

Remediation: Change all default credentials on the Tomcat Manager interface immediately. Remove the default tomcat and admin accounts from tomcat-users.xml. Create new accounts with strong, unique passwords. Restrict access to the Manager application by IP address using the RemoteAddrValve configuration. Implement account lockout to prevent brute-force attacks. Consider disabling the Manager application entirely if it is not required in production.

Finding 5 - DNS Zone Transfer Enabled

Example Nmap output:

PORT   STATE SERVICE
53/tcp open  domain
| dns-zone-transfer:
|   example.com:
|     example.com.        SOA   ns1.example.com. admin.example.com.
|     example.com.        NS    ns1.example.com.
|     example.com.        NS    ns2.example.com.
|     example.com.        A     192.168.1.10
|     dev.example.com.    A     192.168.1.20
|     staging.example.com. A    192.168.1.21
|     db.example.com.     A     192.168.1.30
|     vpn.example.com.    A     10.0.0.1
|     admin.example.com.  A     192.168.1.40
|_    mail.example.com.   A     192.168.1.50

The DNS server allows zone transfers to any requesting host. This exposes the complete DNS zone, revealing internal hostnames, IP addresses, network structure, and potentially sensitive subdomains (dev, staging, db, vpn, admin). This information significantly aids an attacker in mapping the target environment and identifying high-value targets.

Finding title: DNS Zone Transfer Enabled (AXFR)

Description: The DNS server at the target host allows unrestricted zone transfers (AXFR). Any host on the network can request a complete copy of the DNS zone, which reveals the full inventory of hostnames and their associated IP addresses. The zone transfer revealed internal subdomains including development, staging, database, VPN, and administrative interfaces. This information disclosure allows an attacker to enumerate the organization's internal infrastructure without active scanning, identify high-value targets such as database servers and admin panels, and plan targeted attacks against specific services.

CVSS vector: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N = 5.3 (Medium). Attack Vector is Network. Attack Complexity is Low because zone transfers are a standard DNS query. Privileges Required and User Interaction are None. Confidentiality Impact is Low because the information disclosed (hostnames and IPs) is organizational metadata rather than sensitive data, but it enables further attacks.

Remediation: Restrict DNS zone transfers to authorized secondary DNS servers only. On BIND, configure the allow-transfer directive to list only the IP addresses of legitimate secondary name servers. On Windows DNS, configure zone transfer settings to "Only to servers listed on the Name Servers tab" or specify authorized servers explicitly. Verify the configuration by attempting a zone transfer from an unauthorized IP address after making changes.

Structuring Nmap Findings in Your Report

Once you have written individual findings from your Nmap results, you need to organize them into a coherent report. Here is how to structure them effectively.

Group by severity, not by scan order. Critical findings come first. The default credentials finding (9.8) should appear before the DNS zone transfer finding (5.3). Your client's remediation team will prioritize from the top of the report down, so put the most urgent items first. Use a good pentest report template that enforces this structure.

Include raw Nmap output as evidence. Every finding should include the exact Nmap output that supports it. Place the raw output in a clearly labeled "Evidence" section within the finding. This serves two purposes: it proves the finding exists, and it gives the remediation team the exact technical details they need to reproduce and verify the fix. Do not paraphrase Nmap output - include the actual text.

Write remediation that developers can act on. "Fix the vulnerability" is not remediation. "Update Apache to the latest stable version" is better but still incomplete. Good remediation includes the specific action (update Apache), the target state (latest stable version, currently 2.4.59), the immediate mitigation if a full fix takes time (apply the "Require all denied" directive), and the verification step (run the Nmap scan again to confirm the version has changed). Developers should be able to read your remediation and know exactly what to do without additional research.

Provide CVSS vectors, not just scores. A score of 7.5 means nothing without the vector that produced it. The vector string shows your reasoning - it explains why you chose Network over Adjacent for Attack Vector, why Complexity is Low instead of High. This transparency builds trust with technical reviewers and prevents arguments about severity ratings. For a complete guide on building accurate vectors, see our article on how to calculate CVSS scores.

Consolidate related findings where appropriate. If Nmap shows ten servers running TLS 1.0, you do not need ten separate findings. Write one finding for "Weak TLS Configuration" and list all affected hosts in the "Affected Systems" field. This keeps the report concise and avoids inflating the finding count. However, do not combine findings that require different remediation steps - default credentials on Tomcat and default credentials on a network switch are separate findings because the fix is different for each.

Automating the Nmap-to-Report Process

Writing each finding manually works when you have five findings. It does not scale when you have thirty. A network pentest against a mid-size organization can produce dozens of Nmap-sourced findings across hundreds of hosts. Converting all of that raw output into professional findings by hand is where pentesters lose entire days.

An AI pentest report generator automates the entire process described in this article. You paste your Nmap output - the complete scan results, not individual findings - and the AI pipeline parses the output, identifies findings, scores each one with a proper CVSS 3.1 vector, generates professional descriptions and remediation, and composes the complete report. The five findings we wrote manually above take about an hour to write by hand. An AI generator produces equivalent output in minutes.

The key advantage is consistency. When you write findings manually at 11 PM after a long engagement day, quality drops. Finding number twenty-five gets less attention than finding number one. An AI pipeline gives every finding the same level of detail regardless of when it appears in the report. The CVSS scoring is systematic - each metric is evaluated independently against the finding details, producing a vector string rather than an estimated number.

You still review and edit the output. The AI gets you from raw Nmap output to a professional draft in minutes. You spend your time reviewing and adjusting rather than writing from scratch. That is the difference between a tool that replaces your judgment and a tool that eliminates the tedious formatting and content generation work. Check our pricing page to see plans that fit your engagement volume.