Content Discovery — Finding What the Server Hides
In 2017, a security researcher noticed that the Nissan Canada Finance website had a directory accessible at /backup/. Inside that directory sat a plaintext file containing the personal information of over 1.1 million customers: names, addresses, vehicle details, and loan information. The file was not linked from anywhere on the website. There was no button to click, no breadcrumb trail to follow. It was simply sitting there, accessible to anyone who knew — or guessed — the path.
No hacking was required. Just an HTTP GET request.
This is directory enumeration: the systematic practice of probing a web server for paths that are not advertised on the public site but that the server will happily serve to any client that asks for them.
Why web servers expose hidden files
Web servers are fundamentally simple: they map URL paths to files on disk. If a file exists inside the web root and the server receives a request for the corresponding path, the server sends the file. The server does not know which files are "supposed" to be there and which files were placed there by mistake. It does not distinguish between files linked from the navigation menu and files that a developer dropped there for "temporary" storage two years ago and forgot about.
This creates a class of vulnerabilities that are surprisingly common in production systems:
- A developer generates a database backup to investigate a production issue and copies it to
/backup/db.sqlfor "easy access," intending to delete it later. - A deployment script leaves a
.envfile containing database credentials in the web root. - A
.gitdirectory is included in the deployed codebase, exposing the entire source history. - An old admin panel at
/admin_old/is no longer linked from anywhere but was never actually removed from the server. - A PHP configuration file at
/phpinfo.phpwas used during setup and never deleted.
None of these files are accessible through normal site navigation. All of them are accessible to any HTTP client that knows the path.
How attackers find the paths
Attackers use tools like gobuster and ffuf to automate the discovery process. These tools work by sending one HTTP GET request per path from a large wordlist and recording which responses are not 404 Not Found. A typical wordlist has tens of thousands of entries — common directory names, file names, and combinations of the two with various extensions.
The tool sends requests at rates of thousands per second. Against a typical wordlist of 20,000 paths, a scan completes in seconds on a fast connection. The attacker reviews the results — any 200 OK, 301 Redirect, or 403 Forbidden is a finding worth investigating.
What you will find in this lab
The interactive panel on the right shows a simulated directory scanner targeting http://target.example.com/. When you start the scan, it probes 150 paths from a wordlist. Most return 404 and disappear from the view. A small number return non-404 responses — those are the findings that matter.
Among the discovered paths is a database backup file. Your goals in this lab are:
- Start the scan and watch it run.
- Identify the database backup file in the results.
- Submit its full path.
- Open the file to find the embedded CTF flag.
By the end of this lab, you will understand exactly how attackers discover sensitive files that developers assume are hidden, and you will know the specific remediation steps that prevent this class of exposure.