How does an unauthenticated network vulnerability scan decide a host is vulnerable, and how does a credentialed scan decide differently?
answer
- outside view versus inside view
- only what a service chooses to reveal
- banners, version strings, protocol responses
- installed package versions read after login
basics
~20 sAn unauthenticated scan infers from what services expose on the network: banners, version strings, protocol behaviour. A credentialed scan logs in and reads installed package versions and configuration, so it decides from the host's own record instead of a guess.
solid answer
~50 sAn unauthenticated (remote) scan only sees what a listening service reveals: it matches a banner or version string, a fingerprint of protocol responses, or occasionally the outcome of actually triggering the flaw, against the range of versions a check says is affected. That is an *outside-in inference* — accurate when the service tells the whole truth, wrong when the banner is hidden, rewritten or blind to patches. A credentialed scan logs in, typically over SSH or a remote-administration protocol, with an account the owner provides and runs *local checks*: it reads the installed package inventory, patch level, file versions and configuration and compares them with the fixed version the vendor's advisory names. It also finds what no port exposes, such as a vulnerable library or a weak local setting. Expect more findings in total, and far fewer of them to be false positives.
go deeper
Recall the one-line contrast: an unauthenticated scan infers from what services reveal over the network, a credentialed scan logs in and reads what is installed.
Explain the mechanics: banner and fingerprint matching against an affected-version range, versus installed versions compared with the fixed version an advisory names, and why each produces different false positives.
Show where each view fails in production: hidden or rewritten banners, fixes that leave the version string unchanged, local-only flaws, and exposure that only the network path reveals.
Frame the trade-off: credentials buy accuracy and depth at the cost of a privileged account on every host, while remote checks give the attacker's view at the cost of inference.
## Two ways to answer "is this host vulnerable?" A host vulnerability scanner never *knows* a host is vulnerable in the way the host's owner does. It collects **evidence** and applies a **check** — a small rule that says "if you observe X, report flaw Y". What evidence it can collect depends on one decision made before the scan starts: does the scanner have an account on the host or not? - An **unauthenticated scan** (also called a remote or uncredentialed scan) talks to the host only as any network client would. - A **credentialed scan** (also called an authenticated scan) is given a login and inspects the host from the inside, in addition to the remote view. Both run the same kind of engine. The difference is entirely in the evidence. ## How an unauthenticated scan decides From the network, the scanner can only learn what a listening service chooses to reveal. Its checks therefore decide from: - **Banners and version strings** — the greeting a service sends, a `Server:` header, a protocol handshake that names a product version. The check compares the advertised version with the affected range. - **Protocol fingerprints** — how the service answers specific, well-formed requests. Two versions that behave differently can be told apart even when no version is printed. - **Active probes** — sending what the flaw needs and observing the result. This is the only remote method that *proves* the flaw rather than inferring it, and it is often disabled because it can disturb the target. The weakness is structural: the evidence is *what the service says about itself*. A banner can be suppressed, rewritten by a proxy, or unchanged after a patch that fixed the code without changing the advertised version. The scanner then guesses, and the guess is only as good as the banner. ## How a credentialed scan decides Given an account, the scanner runs **local checks**. The sequence is roughly: 1. Log in with the provided account. 2. Enumerate the installed software: the package inventory, installed updates, versions of individual files and libraries. 3. Compare each installed version with the **fixed version** named in the relevant vendor advisory. 4. Read configuration — settings, permissions, enabled services — that no network client could see. The verdict now rests on the host's own record of what is installed, not on what a port advertises. How deep the scanner can look depends on the account's privileges: a low-privilege account can usually read installed versions, while some configuration needs an administrative one. ## Side by side | | Unauthenticated scan | Credentialed scan | |---|---|---| | Vantage point | A network client | A logged-in user on the host | | Main evidence | Banners, version strings, responses | Installed packages, patch level, configuration | | Sees local-only flaws | No | Yes | | Sees network exposure | Yes, from its own path | Only as configured on the host | | Typical false positives | Many, from version inference | Few | | Typical findings count | Lower | Higher | ## Why the two disagree on the same host Run both against one server and the reports rarely match. The usual reasons: - **The banner is hidden or generic** — the remote scan cannot match a version and reports nothing, while the local check reads the installed package and reports the flaw. - **The fix was applied without changing the advertised version** — the remote scan reports a flaw that is gone; the local check sees the patched package and stays quiet. - **The flaw is local-only** — a vulnerable library used by a batch job, a privilege-escalation bug, a weak file permission. No port exposes it, so only the credentialed scan finds it. - **The exposure only exists on the network path** — what a client actually reaches, what a service presents to a connecting client. The remote view shows that directly; the inside view has to infer it from configuration. This is why mature programmes run both: credentials for accuracy and depth, the remote view for the attacker's perspective. ## What to take away An unauthenticated scan answers "what does this host *look* like from here?"; a credentialed scan answers "what is *installed* on this host?". The first is an inference from self-reported evidence and produces most of the false positives people complain about; the second reads the source of truth but needs an account on every host. Neither is a penetration test: both report known flaws matched by checks, not what an attacker could chain together.
- Does a credentialed scan make the remote checks redundant?No. The inside view tells you what is installed and whether it is patched, but not what a client on a given network path can actually reach, or what a service presents to a connecting client. Programmes usually run both, and when they disagree about an installed version, the credentialed evidence is normally the one to trust.
- Is a credentialed scan more dangerous to the host than an unauthenticated one?Not inherently. Local checks are mostly reads: package lists, file versions, configuration. Risk to the host comes from which checks are enabled — an unauthenticated scan with intrusive probes can crash a fragile service, while a credentialed scan of safe checks only reads data. The cost of credentials lies elsewhere: a privileged account the programme must protect.
Judging whether a car is affected by a recall from the model-year badge on its boot is an unauthenticated scan; opening the service record in the glovebox to see which parts were replaced is a credentialed one. The badge can be missing, swapped, or simply not mention that the faulty part was already changed.
saying these in an interview costs you the question
- An unauthenticated scan reads the installed patch level over the network.
- A credentialed scan is always intrusive because it logs in.
- If the remote scan reports nothing, the host has no known vulnerabilities.
- Credentialed findings are less trustworthy because the scan reports more of them.
- A service banner proves which code version is actually running.