Gobuster: Directory, DNS and Vhost Brute-Forcing

Gobuster is a brute-forcing tool that finds things a website does not link to: hidden directories, forgotten files, live subdomains, and virtual hosts. It is one of the first tools a tester runs against a web target, because the fastest route to a breach is often a page the owner forgot was public.

We run it on most external and web engagements. Here is what it does, and, more usefully if you are the one being tested, what it means when it finds something.

The core idea

A website shows you what it links to. It does not show you what it forgot to remove. Gobuster takes a wordlist of common names, admin, backup, .git, config.php, staging, and requests each one, reporting which exist based on the server’s response. In minutes it maps the parts of your site no navigation menu points to.

That gap (between what a site links and what it serves) is where a large share of real findings live.

Gobuster is open source, written in Go, and actively maintained. As of September 2026 the latest release is v3.8.2 (September 2025), and the project’s README lists seven modes, covered below.

The modes that matter

Gobuster works in several modes, each answering a different question:

• dir: directory and file discovery. Requests paths from a wordlist against a target and reports what returns. This is where admin panels, backup files, exposed .git directories, and forgotten upload folders are found.
• dns: subdomain discovery. Brute-forces hostnames against a domain (dev., staging., vpn., mail.) to map subdomains that are not published anywhere. Each live subdomain is more attack surface.
• vhost: virtual host discovery. Finds sites served from the same IP under different Host headers, often an internal or staging application sharing infrastructure with the public site.
• fuzz: general-purpose fuzzing of any part of a request, for parameters and values.
• s3: Amazon S3 bucket enumeration, finding storage buckets that may be public.
• gcs: Google Cloud Storage bucket enumeration, the same idea on GCP.
• tftp: file enumeration against TFTP servers.

The two cloud storage modes are why the same tool shows up in cloud engagements, not only web tests: a public bucket named after the company is as much exposed attack surface as a forgotten directory.

A quick flag reference

The flags that turn up most often in real use map directly to the questions people search for:

Flag	Mode	What it does
-u	dir, vhost, fuzz	Target URL
-w	all	Wordlist file
-x	dir	File extensions to append (php, bak, zip)
-t	all	Number of concurrent threads
--delay	all	Wait between requests, to stay under rate limits
--domain (-do)	dns	Target domain (-d in older releases)
--append-domain	vhost	Add the base domain to each wordlist entry

Gobuster vs ffuf vs feroxbuster

Gobuster is not the only content-discovery tool, and testers pick by the job:

	Gobuster	ffuf	feroxbuster
Written in	Go	Go	Rust
Strength	Fast, simple, DNS and cloud modes	Flexible FUZZ placement anywhere in a request	Automatic recursion into found directories
Best for	Directory, subdomain and bucket sweeps	Parameter and header fuzzing	Deep recursive directory discovery

They overlap heavily. The choice rarely changes what gets found; it changes how quickly, which is why many testers keep more than one.

What its findings actually mean

When a report says “discovered via Gobuster,” the finding is one of a familiar set, and each maps to a concrete fix:

• An exposed .git directory: the entire source code of the application, often including credentials in commit history, downloadable by anyone. This is a critical finding and more common than it should be.
• Backup files: config.php.bak, database.sql, site.zip, source and data sitting in the web root.
• An admin panel or staging environment reachable from the internet, frequently with weaker authentication than production.
• Forgotten subdomains: an abandoned old. or test. host running unpatched software, providing an easier way in than the hardened main site.
• Directory listing enabled, exposing files never meant to be browsed.

The theme is consistent: none of these are exotic vulnerabilities. They are things that exist, are reachable, and were never meant to be public. Attackers find them with exactly this tool, which is why testers do too.

Why subdomain discovery matters more than it looks

Your security effort concentrates on the main application. But an attacker targets the weakest reachable asset, and that is rarely the main site. It is the forgotten staging. box, the marketing microsite on an unpatched CMS, the old vpn. endpoint. Subdomain enumeration is how that weakest asset is found, and why external network penetration testing always begins with mapping the full footprint rather than only the assets you volunteered. Keeping that footprint mapped over time is the job of external attack surface management.

How defenders detect and reduce it

Gobuster is loud. A single source requesting thousands of non-existent paths in seconds is an obvious signature:

• A spike in 404s from one source in a short window, the clearest indicator, visible in any web-server log or WAF.
• Rate-based WAF rules and simple rate limiting slow it dramatically and flag the source.

But detection is the second line. The real fix is reducing what there is to find:

1. Remove what should not be public: backup files, .git directories, and staging environments do not belong on internet-facing servers.
2. Disable directory listing.
3. Authenticate or firewall non-production subdomains so staging. and dev. are not reachable from the open internet.
4. Maintain an accurate asset inventory: you cannot protect the subdomain you forgot exists.

How we use it in an engagement

Gobuster belongs to the reconnaissance and discovery phase, the mapping that happens before any exploitation. In a web application penetration test it finds the hidden application surface; in an external network test its DNS mode maps the full footprint of internet-facing assets. It finds nothing by itself. It tells the tester where to look, and where to look is usually the whole game.

We run discovery only against the hosts and domains in the signed scope, at a request rate agreed up front so production traffic is not disrupted. Our external tests always include discovery of assets outside the list you hand us, so a forgotten staging host or public bucket is part of the result, and anything critical is raised with your contact during the test rather than held for the report, which then explains why it was reachable and how to remove it. The published starting prices for both tests are on the web application testing price page and the external testing price page.

Frequently asked questions

What is Gobuster used for? Finding content a website does not link to: hidden directories and files (dir), live subdomains (dns), virtual hosts (vhost), and public cloud storage buckets (s3, gcs). Testers use it to map attack surface; defenders should run it against their own estate to find the same things first.

Is Gobuster legal to use? Only against systems you own or have written authorization to test. Scanning someone else’s site without permission can breach computer misuse laws and the host’s terms. Every scan in a penetration test sits inside a signed scope and rules of engagement.

How do I tell it is being run against me? A spike in 404 responses from one source in a short window, visible in any web-server log or WAF. That signature is the clearest sign of directory brute-forcing.

The short version

Gobuster discovers the directories, files, and subdomains your site does not advertise, which is precisely where forgotten and exposed things live. Its findings are rarely subtle: exposed source code, backup files, unauthenticated admin panels, abandoned subdomains. The defense is not detecting the scan but removing what the scan finds, and keeping an inventory accurate enough that nothing is forgotten in the first place.

Curious what a brute-force of your external footprint would turn up? That discovery is the opening move of every external penetration test we run. Scope one here.