Skip to content
All articles
September 24, 2026 12 min read

Open, Filtered, Plugin Output: Reading Nmap, Nessus, and Nikto Line by Line the Way CySA+ Expects

Chris Rees

Chris Rees

25+ years in IT · Pluralsight author, 4.6/5 across 2,000+ ratings

Open, Filtered, Plugin Output: Reading Nmap, Nessus, and Nikto Line by Line the Way CySA+ Expects
www.skillthropic.com

The report says Critical, 9.8, exploit available, and the host is a patient portal. A candidate who stops reading there escalates it. A candidate who keeps reading finds the version came from a banner on a CentOS box that patches by backport, so the scanner never saw whether the fix was present. Objective 2.2 is a reading test: output from Nmap, Nessus, Nikto and a web proxy, and one question about each. What did the tool actually observe? That, not the severity cell, decides what happens next.

The question behind every line

Every scanner finding rests on one of three kinds of evidence, and the weight the finding can carry depends entirely on which.

Evidence What the tool did What the finding is
Banner or version string read a service header, matched it against a version range a hypothesis: the version looks affected
Authenticated check logged in, read the package database, registry or config a strong claim: the installed version is known
Active check or exploit sent the malicious input, got the vulnerable response a fact: the flaw is reachable and works

The hypothesis and the fact arrive in the same report, colored the same red. Which scan to run, credentialed or not, agent or agentless, is objective 2.1's question, and it decides which evidence type you will get.

Nmap, line by line

Nmap is the output you are most likely to be shown. A service, OS and script scan against one host:

# nmap -sV -O --script ssl-cert,http-title 10.4.19.22
Not shown: 994 closed tcp ports (reset)
PORT     STATE    SERVICE    VERSION
22/tcp   open     ssh        OpenSSH 7.4 (protocol 2.0)
80/tcp   open     http       Apache httpd 2.4.6 ((CentOS))
|_http-title: Meridian Patient Portal
443/tcp  open     ssl/http   Apache httpd 2.4.6 ((CentOS))
| ssl-cert: Subject: commonName=portal.meridianhealth.example
|_Issuer: commonName=Meridian Internal CA
445/tcp  filtered microsoft-ds
3306/tcp closed   mysql
8080/tcp open     http-proxy Jetty 9.4.31.v20200723
Running: Linux 3.X|4.X
OS details: Linux 3.10 - 4.11

Not shown: 994 closed tcp ports (reset) is the most underrated line in the report: the host answered every one of those probes with a reset, so it is alive and nothing filters those ports. open means a service accepted the connection: genuine attack surface. closed means the host replied that nothing is listening, which proves reachability. filtered means nothing answered: a firewall dropped the probe and Nmap cannot say whether a service sits behind it. One filtered port on a responsive host, like 445 here, is a deliberate rule. A whole subnet coming back filtered means the scanner is on the wrong side of a firewall.

The VERSION column is what -sV inferred from response characteristics: wrong behind a proxy or load balancer, and silent about patch state on a distribution that backports fixes. OS details from -O is the same kind of guess, drawn from TCP/IP stack behavior, which is why it gives a range.

Lines beginning with | are NSE script output, indented under the port they belong to: here an internal CA on a portal the scan reached, and the application's name. This is where Nmap stops fingerprinting and starts collecting evidence. And the real finding is the line nobody rated: 8080 is running Jetty, which is not in the inventory.

Nessus and OpenVAS: the anatomy of a finding

Nessus and OpenVAS findings share a shape: a plugin ran, matched a condition, reported. Every field has a job.

An annotated Nessus finding: the plugin ID identifies the check that ran, the name states the version range the plugin assumes, severity and the CVSS vector give the vendor's opinion of the worst case, the host and port line is where the exposure question begins, the solution is what the vendor wants done and may be impossible on a backported package, and the plugin output is the only evidence, here an installed version read from a banner rather than the package database, which is what makes the finding a probable false positive SEVEN LINES, ONE OF THEM IS EVIDENCE A NESSUS FINDING Plugin ID: 156000 Name: Apache 2.4.x < 2.4.51 Path Traversal (CVE-2021-41773) Severity: Critical, CVSS v3.1: 9.8, AV:N/AC:L/PR:N/UI:N Host: 10.4.19.22:443, Exploit available: yes Solution: Upgrade to Apache 2.4.51 or later Plugin Output: Installed version: 2.4.6 (from banner) Fixed version: 2.4.51 the check that ran, not the flaw itself; the same ID reappears on every host the version range the plugin assumes; that assumption is the real condition the vendor's opinion of the worst case; the vector says network, no auth, no click where it was seen; the exposure question starts here, not in the score what the vendor wants done; may be impossible on a backported package THE EVIDENCE: a banner, not the package DB; a backport makes this a false positive compare with the vendor changelog, not with the upstream version number The severity column is where an inexperienced analyst stops. The plugin output is where a competent one starts.
Five of the seven lines are the vendor's opinion. Only the plugin output records what the scanner observed, and here it observed a banner.

The plugin ID names the check and is how you suppress or track it across hosts. The name encodes the assumption: any Apache below 2.4.51 is affected. Severity and the CVSS vector are the vendor's estimate of the worst case; the vector is worth reading because AV:N, PR:N and UI:N say reachable over the network, no credentials, no click. The solution is the vendor's fix. The plugin output is the evidence, and here it is a version string lifted from the Server header.

That is the false positive pattern the exam loves. CentOS and its relatives backport patches into the existing version number, so Apache 2.4.6 on a patched host can carry the fix upstream shipped in 2.4.51. The banner cannot tell you; only the package changelog can, and the plugin did not read it. A credentialed scan would have, which is why the same plugin reports Critical without credentials and nothing with them.

Nikto: trivia and emergencies in the same list

Nikto fires thousands of checks for known dangerous files, outdated versions and misconfigurations at a web server, and prints one line per hit.

# nikto -h https://portal.meridianhealth.example
+ Server: Apache/2.4.6 (CentOS)
+ The anti-clickjacking X-Frame-Options header is not present.
+ Uncommon header 'x-powered-by' found, with contents: PHP/5.4.16
+ /admin/: Directory indexing found.
+ /backup.sql: Database backup file found.
+ /icons/: Directory indexing found.

Nothing here is ranked. A missing security header sits one line above a database backup anyone on the internet can download. Reading Nikto is a sorting job: version disclosures and headers are hygiene, directory indexing is exposure, a readable backup or config file is an incident. Nikto does not crawl the application or test its logic; it checks a list, loudly, and its traffic is unmistakable in the target's logs.

Burp and ZAP: findings that come with a request and a response

Web application flaws live in logic and parameters, not package versions, so a finding from Burp Suite or OWASP ZAP carries the request that triggered it and the response that proved it.

Issue:        SQL injection
Severity:     High         Confidence: Firm
Path:         /api/appointments   Parameter: patientId
Request:      GET /api/appointments?patientId=10442' HTTP/1.1
Response:     HTTP/1.1 500 Internal Server Error
              "You have an error in your SQL syntax near '''"

Two fields Nessus lacks matter here. Confidence (Certain, Firm, Tentative in Burp; High, Medium, Low in ZAP) is the tool's own statement of how good its evidence is, separate from severity: a Tentative High is a lead, a Certain High is a result. And the request and response pair is the evidence itself, replayable by hand. An echoed database error is strong evidence; a timing difference of a few hundred milliseconds is weak. Authorization flaws, the parameter that lets one patient read another's record, do not appear at all, because no scanner reliably finds them: that is the manual-testing role of these tools.

The rest of the toolset, and what their output proves

Tool What its output looks like What it proves
Angry IP Scanner a table: address, ping, hostname, a few ports which hosts answered; a dead-looking row may only block ICMP
Masscan one line per open port, huge ranges a port is open; nothing about what is behind it
Maltego a graph of entities (domains, addresses, people, certificates) joined by transforms relationships an adversary could discover from public sources
Metasploit a session, or a module reporting the target is not vulnerable exploitability: a hypothesis becomes a fact
Atomic Red Team, Caldera per technique: executed, detected or missed a gap in your defenses, not a flaw in a host

Angry IP Scanner deserves one warning: by default it marks a host that does not answer ping as dead and skips its ports, so a server blocking ICMP shows as absent rather than filtered. Masscan feeds Nmap: sweep fast, then interrogate what answered. Maltego's output is a picture, and the exam asks about it for relationships and external attack surface, never host vulnerabilities.

True positive or false positive: follow the evidence

A true positive is a real flaw the tool reported; a false positive is a report with no flaw behind it. The exam tests both through output, and the decision is the evidence question.

A decision flow for validating a scanner finding: a Critical finding arrives; ask what the scanner actually observed; if it was only a banner or version string, check whether the vendor backported the fix, and if so it is a false positive to document and suppress, otherwise reproduce it with Metasploit or a manual request; if it was an authenticated package check, confirm the vulnerable configuration is present, in which case it is a true positive to fix and verify, otherwise note it as mitigated; if an active check or exploit succeeded it is a confirmed true positive to escalate and prioritize TRUE POSITIVE OR FALSE POSITIVE: FOLLOW THE EVIDENCE A finding arrives, rated Critical What did the scanner actually observe? Banner or version string only Server: Apache/2.4.6, OpenSSH 7.4 Authenticated package check package database, registry, config file Active check or exploit worked payload returned, session opened Fix backported by the vendor? read the package changelog Vulnerable setting present? many CVEs need a specific config TRUE POSITIVE, confirmed escalate; prioritize on exposure FALSE POSITIVE yes: document it REPRODUCE IT no: try to exploit TRUE POSITIVE yes: fix, verify MITIGATED no: note, monitor whatever the score said, this is the only path that proves it Severity is the vendor's guess about the worst case. Evidence is what the tool saw. Validate on the evidence.
Three kinds of evidence, three paths. Most Criticals from non-credentialed scans take the left one; only the right one turns a hypothesis into a fact.
Worked example: the Nessus finding above, on the Nmap host above. Evidence: banner only. The vendor's httpd changelog lists the CVE as fixed, so it is a false positive: document the reason, suppress the plugin for that host, re-scan with credentials. Then look at the Jetty on 8080, which no plugin rated because nobody knew it was there. Validate it with a manual request or a Metasploit module; if it responds, that is the true positive on this host, and the one that goes to prioritization.

Two related traps. A false negative never appears in the output, so the exam tests it through configuration: a non-credentialed scan that reports a host clean has not proved it clean. And Metasploit's role here is validation, not assessment: it converts a claim into a fact, under written authorization and a defined scope.

Four stems, decoded

  1. An Nmap scan of a subnet returns every port on every host as filtered. The scanner is on the wrong side of a firewall. Nothing about the hosts has been learned.
  2. Nessus reports a Critical path traversal on a CentOS web server; the plugin output shows the version came from the Server header. Probable false positive from a backported fix. Check the changelog, re-scan with credentials, then decide.
  3. A Nikto report lists a missing X-Frame-Options header first and a readable backup.sql fifth. The order means nothing. The backup file is a data exposure and is handled first.
  4. A Burp finding shows SQL injection with Confidence: Tentative and no error in the response. A lead, not a result. Replay the request before reporting it as a vulnerability.

Key takeaways

  • Ask what the tool saw. Banner, authenticated check, or successful exploit: the same red can rest on any of the three.
  • Nmap: closed proves the host is alive, filtered proves only that something is blocking you. Version and OS lines are inferences; NSE lines are evidence.
  • In a Nessus finding, plugin output is the only line that records an observation. A banner version on a backporting distribution is the classic false positive.
  • Nikto is unranked and Burp carries its evidence. Sort Nikto by consequence; read Burp's confidence field and replay the request.
  • Validate, then prioritize. Metasploit turns a claim into a fact under authorization; a silent non-credentialed scan is not a clean host.

Analyzing output from vulnerability assessment tools is objective 2.2 of CySA+ Domain 2, Vulnerability Management, 26% of the exam. It sits between choosing the scan in 2.1 and the CVSS, EPSS and KEV prioritization in 2.3, and an unvalidated finding poisons both. Work all 24 topics with our free CySA+ Domain 2 study guide.

#CySAplus #CS0004 #Nmap #Nessus #Nikto #BurpSuite #FalsePositives #VulnerabilityManagement #InfoSec #CyberSecurity

Share this article

Keep reading

CySA+ deep dives

The Analyst's Toolkit: Which Tool Answers Which Question, From Wireshark to YARA

CySA+ objective 1.3 lists eighteen tools and the exam never asks what any of them is. It asks which one you reach for. The toolkit sorted by the question each tool answers: packet capture versus flow analysis, Snort and Suricata rule anatomy, SIEM correlation, EDR against the wire, the file analysis chain from Strings to YARA, and the workflow that turns a suspicious attachment into a hunt.

Read CySA+ deep dives

Feeds, Confidence, and the Pyramid of Pain: Threat Intelligence and Threat Hunting the Way CySA+ Tests Them

A sharing group sends a report with no hash to block and no signature to deploy, only a description of how the adversary works. Turning that into detection is CySA+ objective 1.4. Threat actor types, where intelligence comes from and how much of it to believe, the intelligence cycle, STIX and TAXII, the Pyramid of Pain, and why a threat hunt starts from the opposite assumption to a monitoring rule.

Read CySA+ deep dives

CVSS, EPSS and KEV: Cutting 61,000 Findings Down to This Week's Work

Severity is not priority. What CVSS actually measures and the two metric groups almost nobody applies, how EPSS turns severity into probability, why the CISA KEV catalog ends most arguments, and a prioritization funnel that survives contact with a real vulnerability queue. CySA+ CS0-004 Domain 2.

Read

Enjoyed this? Get the AI security news that matters.

Join The AI Security Brief for the top AI security news, plus what's important to the C-suite. Free, straight to your inbox.

No spam. Unsubscribe anytime.

CySA+ Domain 2 · 26% of the exam

Turn 61,000 findings into a plan

Vulnerability Management is the second-largest domain on CySA+ CS0-004. Work all 26 topics across the four objectives, from asset inventory and scan selection through reading real Nmap, Nessus and Nikto output line by line, with 80 practice questions.

Get the CySA+ Domain 2 guide