Authenticated and unauthenticated scanning

Objective 3.1 in this course covers vulnerability scans — authenticated, unauthenticated, SAST and DAST. This lesson takes the first two, and it is the applied lab for the objective.

Why this matters

The authenticated/unauthenticated distinction is examined directly, and it is one of the few places where the right answer is unambiguous once you understand what each one can see.

It also matters commercially. Clients often buy unauthenticated scanning because it needs no setup, then read the results as an assessment of their patching. They are not that, and explaining why is a conversation worth being able to have.

The lesson

What credentials change about the results

Unauthenticated scanning sees a host from outside: open ports, service banners, responses to probes. It infers, and lesson 15 listed the ways inference fails.

Authenticated scanning logs in and reads — the package inventory, patch state, registry and configuration, installed software, local policy. It stops guessing.

The practical differences:

• Accuracy. Reading an installed version defeats the backported-patch problem that breaks banner-based findings.
• Depth. Local issues — weak permissions, insecure service configurations, unpatched software that listens on nothing — are invisible from outside and are most of what a host actually has wrong with it.
• Volume. Authenticated scans typically produce far more findings, which is the correct result and is frequently mistaken for the scan being broken.
• Load. Reading an inventory is gentler than probing, so authenticated scans are often less disruptive than unauthenticated ones.

The examinable summary: unauthenticated shows what an outsider sees; authenticated shows what is actually there. Both are useful, and they answer different questions.

Least-privilege scan accounts, and protecting them

A scan account is a credential with reach across the estate, which makes it a target in its own right. If you are asking a client to create one, ask properly:

• The least privilege that does the job. Read access to the things the scan reads. Administrative rights are often requested by default and are often more than the checks require.
• Dedicated to scanning, never a shared administrator account, so its activity is distinguishable in logs and it can be disabled independently.
• Time-boxed to the engagement, and disabled afterwards. Include that in the cleanup list, which lesson 39 covers.
• Handled under lesson 4's rules: you are holding a client credential, so it is encrypted, not shared, and destroyed on the agreed schedule.

There is a finding hiding here too. If the client hands over a domain administrator account without question, or emails it in plaintext, that is worth reporting — you have just tested their credential-handling process and it failed.

The gap between an external and an internal view

Run both and the difference is itself the finding.

A service reachable from outside that the internal view shows as misconfigured is a different risk from the same service reachable only internally. The comparison answers questions a single scan cannot:

• What does the perimeter actually filter? Compare what answers externally against what is listening internally.
• Is segmentation real? Scan from inside one segment towards another and compare with the claim in their documentation. This is the evidence for or against a segmentation statement, and lesson 22 attacks it directly.
• What would an attacker gain by getting a foothold? The internal view is the post-compromise view, and describing it is what makes a phishing risk concrete for a client.

Where you scanned from is therefore part of the result, and belongs recorded alongside it.

Agent-based scanning as a third option

Agents run on the host and report in, which changes the trade-offs again:

• No scan window problem. A laptop that is never on when you scan still reports when it is on — which addresses lesson 15's switched-off asset.
• No credential distributed to a scanner, since the agent runs locally.
• Continuous rather than periodic, so the data is fresher.

Against that: agents must be deployed and maintained, they only cover hosts that have them (coverage again), they cannot see the network view at all, and they add software to every host — which is itself attack surface.

For an engagement, the useful framing is that agent data is an input you may be given, with its own coverage gaps, and not a substitute for looking.

Comparing both scans of the same host in your lab

The applied lab for objective 3.1, run against the lab from lesson 2 where you know the truth.

Take a host you built, deliberately leave something wrong on it — an outdated package, a weak file permission, a service with a poor configuration — and then:

1. Scan it unauthenticated and write down what was found.
2. Scan it authenticated and write down what was found.
3. Diff the two, and account for every difference.

What to look for, because these are the lesson:

• Issues that appear only with credentials — usually most of them.
• Issues reported unauthenticated that authentication disproves, which is the backported-patch false positive appearing in front of you.
• Anything the authenticated scan missed that you know is there, which is the feed's coverage limit made visible.

Then write two sentences describing the host's security posture, one from each scan, and notice how different they are. That contrast is what you are being paid to explain to a client.

What to take into the exam

• Unauthenticated shows what an outsider sees; authenticated shows what is actually on the host.
• Authenticated results defeat backported-patch false positives and find local issues that are invisible externally.
• More findings from an authenticated scan is the correct result, not a fault.
• Scan accounts get least privilege, dedication, time-boxing, and credential handling — and careless issuance of one is itself a finding.
• Where you scanned from is part of the result; comparing inside and outside is the evidence for a segmentation claim.