CySA+ Vulnerability Assessment Tools: Reading Nmap, Nessus, Burp, Prowler and BAS Output

You analyze vulnerability assessment output by asking four questions of every result: what the tool could actually see, how it reached its conclusion, how complete its coverage was, and what would confirm or refute the finding. Tools differ in vantage point (network, authenticated host, application, cloud API, source code), in method (banner match, package check, payload test, configuration rule) and in what they report when they see nothing. A result is only as strong as the method behind it.

The habits that separate good analysis from bad

• An empty result is not a clean result until you have proved the checks ran: a failed login, a missing API key, missing read permissions or a filter that deselected checks all produce silence.
• Method beats severity when judging truth. A critical finding from a version banner is weaker evidence than a medium finding from an installed-package check.
• Validate with the least disruptive test that answers the question, from the place the risk lives (the right network segment, the right account).
• Read the output literally. Each tool has a fixed vocabulary (port states, check codes, confidence levels, statuses) and most mistakes come from reading one tool's word with another tool's meaning.

Choosing the scan method (credentialed or not, internal or external, agent or agentless) belongs to objective 2.1, and ranking findings with CVSS and business context to objective 2.3. This lesson is about reading what the tools return.

Masscan and Angry IP Scanner show where things are: live hosts and open ports across large ranges. They do not identify the software or version behind a port, and they do not test for vulnerabilities, so their output is the input to a deeper tool such as Nmap or a vulnerability scanner.

Masscan

Masscan is an internet-scale port scanner. It is stateless: it sends SYN probes at a configured rate (--rate, packets per second) and records replies without tracking each connection, which is why it can sweep a /16 for every port quickly. Its output is a list of lines such as Discovered open port 445/tcp on 10.40.12.7, open ports only.

• Next step: to learn the service and version, run an Nmap version scan (-sV) against just the hosts and ports Masscan found.
• Rate and completeness: at very high rates, switches, firewalls or the sender's own interface drop probes and replies, and Masscan reports no error. It does not retry by default, so absence from a fast run proves little. Completeness falls as the rate rises: when results vary between runs, the slower run with retries is the more trustworthy one.

Angry IP Scanner

Angry IP Scanner is a GUI scanner that first decides whether each address is alive using a chosen pinging method (ICMP echo, a UDP or TCP port probe, a combined UDP+TCP method, or ARP on the local segment), then runs fetchers on live hosts: hostname, open ports, MAC vendor, web server banner and so on. By default it does not scan the ports of hosts it marks dead.

That order explains a classic misread: a server behind a firewall that drops ICMP looks dead to an ICMP echo sweep, and none of its ports are shown, even though users reach it every day. When hosts known to be up appear dead, the liveness probe is the problem, not the scan's speed, so choose a pinging method that the network path actually lets through.

Nmap reports each port in one of a small set of states, and each state describes how the target answered a probe, not whether a service is safe. Reading those states correctly, and comparing them from different vantage points, tells you whether the network or the host is responsible for what you see.

Vantage points

The same port can report different states from different places, because each scan sees the host through whatever filters sit in its path. A difference between an outside and an inside result is attributable to the network between them; the inside result is the better view of what the host itself runs. Comparing scans from outside and inside separates "what the network blocks" from "what the host offers", which is exactly what a remediation owner needs to know.

UDP and open|filtered

UDP services often ignore an empty or malformed probe, so silence is ambiguous. Look at the other ports first: if closed UDP ports on the same host return ICMP port unreachable, that suggests no filter is dropping ICMP from that host, and silence on a port leans towards a listening service that ignored the probe (for example an SNMP agent that rejected the community string). A filter can still drop a single port, so treat this as a lean, not proof. Also expect ICMP rate limiting: many hosts (Linux by default allows about one port-unreachable reply per second) throttle these replies, which slows UDP scans and can leave genuinely closed ports reported as open|filtered. Nmap's documentation recommends version detection (-sV) to resolve open|filtered: its protocol-specific probes draw a reply from a real service.

Other Nmap output worth recognising

• -sV adds a VERSION column (product and version from probes and banners).
• -O reports an operating system guess with a confidence; treat it as a lead, not a fact.

Nmap Scripting Engine (NSE) scripts extend a port scan with protocol-level checks, and their output lists what a service offers or how it is configured. The analyst's job is to translate each line into the risk it creates.

smb2-security-mode

This script reports SMB message signing for each SMB2/3 dialect, for example 3:1:1: Message signing enabled but not required. Signing protects message integrity; if a server allows signing but does not require it, an attacker who captures NTLM authentication can relay it to that server (an NTLM relay), because unsigned sessions are accepted. Requiring signing is the fix. Note what the script does not cover: it negotiates only SMB2/3 dialects, so its output says nothing about whether SMBv1 is also enabled; that needs a separate check such as the smb-protocols script.

ssl-enum-ciphers

This script lists, for each TLS version, every cipher suite the server offers with a letter grade, plus warnings (for example SWEET32 for 64-bit block ciphers such as 3DES) and a least strength line. Read it by protocol version: if a weak suite appears only under TLS 1.0, disabling TLS 1.0 removes both the deprecated protocol and that weak suite, while clients continue on TLS 1.2 or 1.3. Match the fix to where the weakness lives: a problem tied to a protocol version is solved by disabling that version, not by tuning the suites inside it.

ssh2-enum-algos

This script lists the key exchange, host key, encryption and MAC algorithms an SSH server offers. Any offered algorithm can be negotiated by a client that prefers it, so weak entries are findings even beside strong ones.

The Metasploit Framework (MSF) validates a scanner finding by testing the specific flaw against the target, either safely with a module's check command or conclusively by running the exploit. Scanners infer vulnerability; Metasploit demonstrates it.

Check codes

Many exploit modules implement check, which probes for the flaw without delivering a payload and returns a check code:

"Detected" is the one most often misread: it neither confirms nor refutes the scanner, so another validation method is needed, such as a credentialed check of the installed version.

Check versus exploit, and where you run it from

When a risk owner argues a flaw is unreachable from some network, the question has two parts: can that network reach the service, and is the flaw exploitable there? Running check from that network answers both with low impact. Other methods each answer only part of the question or carry more risk: weigh every option by whether it tests reachability, the flaw itself, or both, from the network in dispute, and at what impact to production.

Imported scanner data is a lead, not a result

db_import loads scanner output (for example Nessus XML) into the Metasploit database, and commands such as hosts, services and vulns then list it. Those entries record what the scanner reported, so they carry the scanner's confidence, no more; importing is data handling, not testing.

Maltego and Recon-ng are open-source intelligence (OSINT) tools: they collect what the internet reveals about an organization's domains, hosts, people and identities, so analysts can find exposure the organization does not know about. They examine public data, not the systems themselves.

Reading the output

• The gap is the finding. Compare discovered assets with what the organization knows it owns. Discovered hosts that do not match the organization's registered address ranges or its asset inventory are candidates for unmanaged (shadow) internet-facing assets, which nobody is scanning or patching. Confirm the DNS data is current before reporting them.
• Check the data source before trusting silence. Many Recon-ng modules call commercial APIs and declare a required key, added with keys add. keys list shows which keys are set. A module whose key is missing cannot reach its source, so its silence is absence of evidence, the same rule as any check that never ran.

Web application scanners report flaws at the application layer, and their findings must be read with the scan mode and confidence that produced them. Burp Suite and ZAP are intercepting proxies with scanners that test parameters; Nikto is a web server scanner that checks for known files and server misconfiguration.

Passive versus active scanning

The ZAP baseline scan, popular in CI pipelines, spiders the site and runs only passive rules. Its report can therefore contain only passive-type findings, and it says nothing about injection flaws until an active (full) scan has run.

Burp Scanner confidence and Collaborator

• Burp rates every issue's confidence as Certain, Firm or Tentative, separately from severity. Tentative means the evidence is weak, for example one slow response to a time-delay SQL injection payload. Confirm it manually in Repeater by varying the payload in a controlled way and checking that the response changes in step with it; a confirmation needs new evidence, not the same evidence again.
• Burp Collaborator detects out-of-band interactions: Burp puts a unique Collaborator domain into a parameter, and if the server then contacts that domain, a supplied value caused a server-side request. An "External service interaction" issue on a URL parameter therefore points to server-side request forgery (SSRF), which may reach internal services or cloud metadata endpoints.

Nikto

Nikto lists findings as + lines: the Server banner and version, missing headers such as X-Frame-Options, default files (Apache's /icons/README), dangerous files (a reachable phpinfo() page, configuration backups) and risky HTTP methods. Weigh them by what they expose: a phpinfo page reveals the full PHP and server configuration, paths, modules and possibly secrets in environment variables.

• HTTP methods are read from the Allow header of an OPTIONS response, and servers often list methods they actually reject. An advertised method is a lead; within an approved test, confirm it with a harmless request that proves the behaviour. A server that accepts uploads could host a web shell.
• Catch-all servers cause mass false positives. Nikto tries to learn how a server answers for missing files, but a single-page application that returns HTTP 200 and the same page for every path defeats that detection, so many checks look successful and findings appear for software the site does not run. How the server answers a path that cannot exist tells you whether existence-based findings can be trusted; if they cannot, confirm each by its content.

You read vulnerability scanner results by checking two things: the detection method behind each result, which exposes false positives, and proof that the scanner's checks actually ran, which exposes coverage gaps. Nessus and OpenVAS (Greenbone) combine remote checks, which see only what the network exposes, with authenticated checks that read installed packages.

Banner checks and backporting

A remote check often compares the version a service advertises with the versions named in advisories. Enterprise Linux distributions such as Red Hat Enterprise Linux and Ubuntu backport security fixes into the version they ship, so the banner (for example Apache/2.4.6 (Red Hat Enterprise Linux)) stays the same after patching. A non-credentialed scan then flags every upstream vulnerability after that version. The fix is evidence from the package: a credentialed check compares the installed package release with the vendor's advisory.

OpenVAS Quality of Detection (QoD)

Every Greenbone result carries a QoD percentage describing how reliable the detection method is. It is not severity and not the likelihood of exploitation.

By default the report filter hides results below 70% QoD, so low-QoD banner results appear only when the analyst shows all results.

Proving local checks ran (Nessus)

• The Scan Information output states Credentialed checks : yes or no. "No" in a policy that included credentials means the login failed (wrong password or key, privilege-escalation settings, a locked account), so "no missing patches" is a coverage gap, not a clean bill of health. Network-level findings only show remote checks worked.
• OS Security Patch Assessment Available is the informational plugin that confirms Nessus authenticated and assessed installed packages; its near-twin OS Security Patch Assessment Failed means the opposite.
• Credentialed checks : yes proves only that a login succeeded. A plugin such as Target Credential Issues by Authentication Protocol - Insufficient Privilege means the account lacked rights for some local checks (on Windows, typically not a local administrator or no access to the registry and admin shares), so local findings may be incomplete even though the login worked.

Reading Nuclei template results

Nuclei results are read as "this template's matchers fired here": Nuclei is a template-based scanner, and each output line names the template, the protocol, the template's severity and where it matched, in the form [template-id] [protocol] [severity] matched-URL.

• Severity comes from the template, declared in its info block by the template author, not from the target.
• Info results are fingerprints, not flaws. A tech-detect:nginx line records the technology in use.
• Exposure templates find readable files that should not be public, such as /.git/config, which can leak repository locations and history.
• CVE templates usually send a request that exercises the flaw (for example a path traversal) and match the response, which is stronger evidence than a version banner.

Template selection decides what an empty report means

Nuclei chooses templates before it sends anything. Filters such as -severity critical,high, -tags or -t (a specific template) decide which checks run at all, so a filtered run that returns nothing says nothing about the deselected checks.

The same model is Nuclei's strength: when a new exposure is disclosed and a community template appears, targeted runs of a single template make Nuclei well suited to fast, low-noise sweeps across many hosts. Review a community template before running it, as you would any code.

Cloud infrastructure assessment tools split by when they look: Prowler and ScoutSuite assess a running cloud account through read-only API calls, while Trivy and Checkov scan code and artifacts before deployment. Picking or reading the wrong kind of tool for the stage is a common error.

Prowler

• MANUAL means the control cannot be judged from API data (for example keeping account contact details current) and needs a person to verify it. It is neither a failure nor a pass.
• A mutelist suppresses chosen findings. Muted rows keep their real status (still FAIL) with the muted field set to true, and in JSON-OCSF output the finding is marked suppressed. A falling failure count can therefore reflect muting rather than remediation, so audit each mutelist entry for a documented, justified exception.

ScoutSuite

• "Checked items 42, flagged items 3" means 3 of the 42 resources evaluated break the rule. ScoutSuite sees configuration, not traffic, and its level rates the rule, not an incident.
• It can judge only what its credentials can read; its documentation asks for broad read access (ReadOnlyAccess together with SecurityAudit on AWS). Permission errors in the run log mean some services were never evaluated, so look at the checked-items count, not just the flagged count, before calling a service clean.

Trivy

Trivy scans container images for vulnerable OS and language packages and, with its misconfiguration scanning (trivy config), checks Terraform and other IaC too. Read the Status and Fixed columns: fixed means a patched package exists, while will_not_fix or affected with no fixed version means none is available yet. Gate flags work together: --exit-code 1 fails the build when findings remain, --severity filters by severity, and --ignore-unfixed drops findings that have no fix. --format sets the report format (table, JSON, SARIF).

Checkov

A failed Checkov policy names the check ID, the resource and the file lines. To accept an intentional deviation for one resource only, add an inline comment inside the resource block, such as #checkov:skip=CKV_AWS_20:Public website assets, which keeps the reason next to the code. Skips set for the whole run, on the command line or in a config file, are broader: they apply to every matching resource or path, so they need stronger justification.

Breach and attack simulation (BAS) results are read technique by technique as a detection chain: did the technique execute, was it logged, and did the analytics alert? BAS tools run known MITRE ATT&CK techniques safely so defenders find where that chain breaks.

Locating the gap

Two habits matter. "No alert" alone does not say whether the problem is telemetry or a rule: search the SIEM for the raw events before naming the gap. And a failed step is not prevention until its output shows why it failed (an environment problem and a real block can look identical in a status column). A simulation does not compromise anything; it is evidence about your defenses, not an incident.