Nikto and web scanning

Objective 3.3 in this course covers discovery tools — CompTIA names Nessus, Nikto and OpenVAS. Lesson 20 took the two general-purpose scanners; Nikto is the web-specific one, and this lesson closes Domain 3 as its capstone.

Why this matters

Nikto is named by CompTIA, so it is examinable by name. It is also the clearest example in the course of a tool whose value depends entirely on understanding what it is: a fast, loud, signature-driven check of a web server that produces a starting list and nothing more.

The lesson

What a web server scanner checks for

Nikto tests a web server against a database of known-interesting requests. Broadly:

• Dangerous or unexpected files and paths — default pages, sample scripts, administrative endpoints, backup files. The same territory as lesson 11, driven by a curated list rather than a wordlist.
• Outdated server and component versions, by banner, with all of lesson 18's caveats about what a banner proves.
• Server configuration issues — permitted HTTP methods, directory listing, missing security headers, weak TLS configuration.
• Known issues in recognised software, matched by signature.

What it does not do: understand your application. It has no idea what the application is for, so every logic flaw, every authorisation problem, every broken workflow from lesson 15 is invisible to it. It checks the server, and a clean Nikto run says nothing about the application on top.

Noise, and why Nikto is not a stealth tool

Nikto makes thousands of requests, many of them for paths that do not exist, with a recognisable signature and a self-identifying user agent by default.

That is a design choice, not a flaw — it is built for speed and completeness in an authorised assessment, where hiding is not the objective (lesson 1: a penetration test is overt unless scoped otherwise).

The consequences to plan for:

• It will be logged, loudly, and will generate alerts. Tell the client, and make sure it is in the activity log from lesson 8 so their analysts can reconcile it.
• It may get you blocked by a web application firewall or automated defence — and once blocked, every subsequent result is meaningless. A run that starts finding things and then finds nothing at all has probably been blocked partway, which is lesson 19's truncation problem.
• The load is real, per lesson 11.

If an engagement genuinely needs quiet testing, Nikto is the wrong tool and the scope should say which is right.

Tuning to the checks that matter for the target

Running everything against everything wastes the window and multiplies the noise.

Tune on what Domain 2 already told you:

• Tune by check category. If the target is a static site behind a CDN, the server-side scripting checks are wasted requests.
• Target the right host. Virtual hosts matter — the same address serving different sites by Host header, which lesson 11 raised. Scanning the default virtual host tells you nothing about the application you were hired to test.
• Use the right port and protocol, including the management interfaces on high ports that a default web scan never touches.
• Mind the timing, for the same reasons as everywhere else in this domain.

And record the invocation, because lesson 20's rule holds: a finding is reproducible only if the command that produced it is written down.

Combining with the directory enumeration you already ran

Nikto and lesson 11's enumeration overlap and are not substitutes, and knowing the difference is the practical point of this lesson.

• Nikto brings a curated database of known interesting paths — things that have historically been worth finding, across many products. It knows things you would never think to guess.
• Directory enumeration brings your wordlist, including the target-specific vocabulary from lesson 7 that no general database can contain.

So run both, and merge the results into one picture of the site's real surface. Then feed that into Domain 4: the paths that take input are where lessons 30 to 32 start, and the administrative interfaces are where lesson 25's rules about lockout apply.

The merged list, with what each path returned, is a far better artefact than either tool's output — and it is the thing that makes the web findings in the report coherent rather than a pile of scanner exports.

Confirming each hit by hand before it becomes a finding

Domain 3's closing rule, and the capstone for the domain: every Nikto hit is a lead.

Nikto's false-positive rate is high by design — it errs towards reporting, and soft 404s (lesson 11) make it worse, since a server returning 200 for everything makes every check look like a hit.

So for each result that might become a finding:

1. Request it yourself and look at what actually comes back.
2. Check it is not a soft 404, by comparing against a path that certainly does not exist.
3. Establish impact for this client, not the generic description. A found backup file matters because of what is in it.
4. Capture the evidence — request and response — per lesson 6.
5. Discard what does not survive, and keep no record of it in the report.

That is the whole of Domain 3 in one procedure, and it is why this course keeps saying it: the scanner narrows where to look, and the tester decides what is true. A report that skips step 1 is a scanner export with a cover page, and lesson 18 explains what it costs when the client finds the first wrong one.

What to take into the exam

• Nikto checks the web server against a signature database; it cannot see application logic.
• It is deliberately loud and self-identifying — not a stealth tool, and being blocked partway silently invalidates the rest of the run.
• Tune by category, host, virtual host and port; scanning the default virtual host can miss the application entirely.
• Nikto's curated database and your own wordlist find different things; merge both into one picture of the surface.
• Every hit is confirmed by hand, checked against a soft 404, and given impact for this client before it becomes a finding.