Analyze output from vulnerability assessment tools

The previous objective decided how to scan. This one is about reading what came back — and the exam shows you actual tool output and asks what it means.

Two skills, in this order: know which tool produced this, then know what the finding is actually claiming.

Knowing the tool from its output

Reading Nmap output

PORT     STATE    SERVICE     VERSION
22/tcp   open     ssh         OpenSSH 7.4 (protocol 2.0)
80/tcp   open     http        Apache httpd 2.4.6 ((CentOS))
445/tcp  open     microsoft-ds Samba smbd 4.6.2
3389/tcp filtered ms-wbt-server
8080/tcp open     http-proxy

Three things to take from this:

• open vs filtered vs closed. Open means a service answered. Closed means the host answered but nothing is listening. Filtered means something — a firewall — dropped the probe, so the scanner cannot tell. That distinction is examinable.
• Versions are inferences unless the scan was credentialed. Apache httpd 2.4.6 came from a banner, and banners lie or go stale.
• The interesting finding here is 445/tcp open alongside 3389/tcp filtered — someone firewalled RDP and left SMB exposed. Inconsistent controls are the finding, not any single line.

Check yourself

An Nmap scan reports a port as 'filtered' rather than 'open' or 'closed'. What does that mean?

• A service is running but refused the connection
• A firewall or filter dropped the probe, so the port's state is unknown
• The port is definitely closed
• The scanner ran out of time

Reading a vulnerability scanner finding

A Nessus-style finding has parts, and the exam tests whether you know which part means what:

Plugin ID:  156032
Severity:   Critical (CVSS v3.1 Base 9.8)
Host:       10.14.2.31
Name:       Apache HTTP Server 2.4.x < 2.4.53 Multiple Vulnerabilities
Synopsis:   The remote web server is affected by multiple vulnerabilities.
Output:     Installed version : 2.4.6
            Fixed version     : 2.4.53
Exploit available: Yes

• Plugin ID identifies the check, not the vulnerability. Useful for suppressing or investigating a specific check.
• Severity and CVSS base score describe the vulnerability in the abstract, with no knowledge of your environment. That gap is Objective 2.3's entire subject.
• Output is the evidence for the claim. This is where you verify — "installed 2.4.6, fixed in 2.4.53" is a version comparison you can check yourself.
• Exploit available matters enormously for prioritisation and is often the difference between a critical you patch tonight and one you schedule.

False positives and false negatives

Validating a finding is the analyst skill this objective is really about. Manually check the version. Query the host directly. Reproduce the condition. Where it is safe and authorised, confirm exploitability. A finding you have verified survives the argument with the system owner; a finding you have not, does not.

Check yourself

A scanner flags a RHEL server as running a vulnerable Apache 2.4.6. The system owner insists it is fully patched. Who is likely right?

• The scanner — the version string is definitive
• The system owner — Red Hat backports fixes while keeping the version number
• Neither; the scan must be rerun
• The scanner, unless the server was rebooted recently

Cloud assessment output

Cloud findings look different because they are about configuration, not patches:

[HIGH]   S3 bucket 'prod-customer-exports' is publicly readable
[HIGH]   IAM policy 'deploy-role' grants Action: "*" on Resource: "*"
[MEDIUM] EBS volume vol-0a3f21 is unencrypted at rest
[MEDIUM] CloudTrail logging is not enabled in region eu-west-2

Note what is not here: no CVEs, no versions, no patches. Nothing is unpatched — everything is misconfigured. A wildcard IAM policy is not a vulnerability in software, it is a decision someone made. That is why cloud posture tools are a separate category, and why "apply the patch" is never the remediation.