When the scan is wrong: troubleshooting configuration

Objective 3.2 in this course covers result analysis — CompTIA describes it as validating findings, troubleshooting configurations and identifying false positives. Lesson 18 took validation; this takes the middle one.

Why this matters

A scan that produces nothing is the most dangerous output in this domain, because a broken scan and a clean estate look identical in a report.

Lesson 18 was about not trusting a finding. This is about not trusting an absence — which is harder, because nothing draws your attention to it. Nobody investigates a quiet result.

The lesson

Blocked by a firewall, or genuinely not there

The first question about any empty result is whether the traffic arrived.

Symptoms that mean "blocked" rather than "clean":

• Every host in a range reports identically. Real estates are messy; uniformity is a filtering artefact.
• Everything is filtered rather than closed, which lesson 10 distinguished: closed means something answered.
• The scan finished far too quickly for the number of targets.
• A host you can reach by hand does not appear in the results.

The check is to test your own path independently: from the scanner's position, by hand, reach something you know is there. If your manual probe works and the scanner's does not, the problem is the scanner's configuration, not the network.

And record where the scanner sat. "Scanned from the DMZ segment" changes the meaning of every result, and it is the difference between a perimeter finding and a coverage gap.

Credential failures that silently degrade to unauthenticated

The most expensive misconfiguration in this domain, because it produces a plausible, complete-looking, badly incomplete report.

Most scanners, when credentials fail, do not stop. They carry on unauthenticated. The result looks like a successful scan with fewer findings — and fewer findings reads as better, which is exactly backwards.

Never assume authentication worked. Confirm it:

• The scanner's own authentication status, which most report per host and almost nobody reads.
• Findings that can only come from a credentialed check, such as package inventory or local policy. Their complete absence across every host is the tell.
• The target's authentication logs, which is the independent confirmation — your scan account should be plainly visible logging in.
• A canary host. Leave something on one host that only a credentialed scan can see. If that finding is missing, authentication failed, whatever the scanner claims.

Common causes: expired passwords, an account locked by the scan's own repeated attempts, insufficient privilege for specific checks, protocol restrictions on the target, or a name that no longer resolves to the host you think.

Plugin and feed staleness

A scanner is only as current as its vulnerability feed, and this fails quietly because an out-of-date scanner reports confidently.

Check and record: the feed version and its date, when the scanner itself was last updated, and whether the feed covers the technologies in scope at all.

That last one is easy to miss. A scanner with excellent coverage of mainstream operating systems may have almost nothing for an industrial controller, a medical device, a network appliance or a niche application — and it will say nothing rather than "I have no checks for this". A clean result on a device class the scanner does not cover is the purest form of false assurance, and it belongs in the report as a coverage limitation rather than as a pass.

Put the feed version in the report. It is what lets someone reading it in six months know what the scan could have known.

Rate limits, timeouts and truncated results

Scans get cut short in ways that are not always announced.

• Timeouts per host, where a slow host is abandoned partway and its partial results are indistinguishable from complete ones.
• An overall scan timeout, leaving later targets unscanned. Compare the number of hosts reported on with the number targeted — they are often different and almost never checked.
• Target-side rate limiting that silently drops probes, so ports look filtered.
• Scanner resource exhaustion on large scans, which degrades results without failing outright.
• Interrupted scans whose partial data still exports happily.

The habit: read the scan's own metadata before its findings. Start time, end time, hosts targeted, hosts completed, errors. Most scanners record all of it and most reports ignore all of it.

Reading the scanner's own log before believing its output

This is the lesson in one line, and it is the same instinct as everywhere else in this course: ask the instrument what it did before believing what it says.

The log answers what the findings cannot: whether authentication succeeded, which checks were skipped and why, what errored, whether the scan completed, and how long each phase took. It is unglamorous and it is the difference between reporting a scan and reporting an assessment.

There is a general principle here worth carrying beyond scanning, because it appears in every domain of this course: a tool that produces no output is making two different claims at once — "I looked and there was nothing" and "I did not look" — and it usually does not distinguish them for you. Lesson 14 built that distinction into a script. Here you get it by reading the log.

So before any empty or surprising result goes in a report, answer three questions: did it run, did it reach the targets, and did it authenticate. If you cannot answer all three, what you have is not a result.

What to take into the exam

• An empty result means "nothing found" or "nothing looked at"; those are different claims and the scanner rarely separates them.
• Failed credentials usually degrade silently to an unauthenticated scan — fewer findings, which reads as better and is not. Confirm authentication independently.
• Uniform results across a range, everything filtered, or a scan that finished too fast all indicate blocking rather than cleanliness.
• Record and report the feed version and coverage; a clean result on a device class with no checks is false assurance.
• Compare hosts targeted with hosts completed, and read the scan's own log before its findings.