Directory and web content enumeration

Objective 2.2 in this course covers enumeration techniques — CompTIA describes it as performing DNS enumeration, service discovery and directory enumeration. This is the third of the three, and it is the applied lab for the objective.

Why this matters

A web server publishes what it is asked for, not what it advertises. Links tell you the intended surface; enumeration tells you the actual one — and the gap between them is where the findings are.

This is also the single most common source of a serious finding in a real engagement. Not a clever exploit: an administrative interface nobody linked, a backup file left in the web root, a .git directory that hands over the source.

The lesson

Wordlists, and why the list decides the result

Directory enumeration is a guessing game, so the wordlist is the technique. Everything else is plumbing.

• A generic list finds generic things: /admin, /backup, /test. Worth running, quickly exhausted.
• A technology-specific list matters once you know the stack — the framework determines what paths exist, and the OSINT from lesson 7 told you the stack.
• A list built from the target is the one that finds what generic lists miss. Product names, internal project names, office locations, the vocabulary from their job adverts and their own page text.
• Extensions matter as much as names. The same name with .bak, .old, .zip, .txt or a swap-file suffix is a different request, and those are where source and configuration leak.

The discipline: record which list you used. "No admin interface found" means nothing without it, and a later tester with a better list will contradict you.

Status codes, redirects and soft 404s

The naive rule — 200 means it exists, 404 means it does not — fails immediately in the real world.

• A soft 404 returns 200 with a "not found" page. Everything looks like a hit. Calibrate by requesting a path that certainly does not exist and learning what the server does; then filter by response size and content, not status.
• 301 and 302 are informative. A redirect to a login page proves the path exists and is protected — which is a finding about structure even where you cannot reach it.
• 401 and 403 are hits, not misses. They confirm the resource is there. A 403 on a directory often means listing is off but files inside are reachable.
• 405 Method Not Allowed says the path exists and wants a different verb.
• 500 frequently means you found something that takes input and mishandled it — worth revisiting in Domain 4.

Filter on behaviour, not on status alone: baseline the server, then look for responses that differ from the baseline.

Finding the admin interface nobody linked to

Unlinked administrative interfaces are the classic finding, and they usually turn up through a combination rather than one technique:

• Enumeration against the main host.
• Virtual host discovery: the same address serving different content by Host header, so an admin panel can live on a name with no public DNS.
• The certificate names from lesson 7, which frequently name internal-sounding hosts.
• Non-standard ports, since management interfaces often sit on a high port that a default web scan never touches.

When you find one, the finding is the exposure, and it stands on its own. You do not need to break in to report that an administrative interface is reachable from the internet — and attempting credentials on it is a separate act needing its own place in the scope. Lesson 25's rules about lockout apply.

Backup files, version control directories and editor droppings

The highest-value targets, because they hand over information rather than requiring an exploit:

• Backups in the web root — .bak, .old, .zip, ~ suffixes, or a dated copy. Frequently the application's source.
• Version control directories left deployed. A .git directory in the web root can allow reconstruction of the entire repository, including the history, which is where credentials live long after they were removed from current files.
• Editor and OS droppings — swap files, .DS_Store, which lists directory contents.
• Configuration and environment files, which exist to hold credentials.
• Build artefacts and source maps, which give a readable view of client-side code.

Treat anything retrieved as client data under lesson 4's rules: minimum necessary, redacted in the report, deleted on schedule. A configuration file's database password is proof of impact — and quoting it in full creates a new exposure, so the report shows that credentials were retrievable and not what they were.

Load: enumeration that becomes a denial of service

Enumeration is thousands of requests at speed. That has consequences lesson 8 already introduced, and here they are concrete:

• Application servers and databases behind the web tier take the load too. A path that triggers a heavy query multiplies your request rate into their backend.
• Log volume, which fills disks and can take down their logging platform.
• Rate limiting and automated blocking, which may block the source address — and if you are testing through a shared egress, you can block legitimate users with you.
• Session and connection exhaustion, where each request creates state that is not cleaned up fast enough.

Mitigations: concurrency you chose deliberately, a rate you can justify, stopping when response times climb — a server slowing under enumeration is a warning, and continuing through it is how you cause the outage. And, as ever, this runs against the lab from lesson 2 or an in-scope target inside the window.

What to take into the exam

• The wordlist is the technique; record which one you used.
• Baseline the server and filter on behaviour — soft 404s defeat status-code logic.
• 401, 403, 405 and redirects are hits: they confirm the resource exists.
• Version control directories and backups in the web root are among the highest value findings and need no exploit.
• Enumeration load reaches the backend; slowing response times mean stop.