exploring hidden paths with DIRB

A quick introduction to using DIRB to discover hidden directories and files on web servers.

I’m writing a web security–oriented post after a while now. This is something I’m quite passionate about and often dive into whenever I have some spare time.

If you’re someone who’s into pentesting or ethical hacking in general, one of the vital steps is reconnaissance and scanning. In terms of websites and web applications, this matters even more because web servers may have sensitive directories and files exposed, including configuration files, backups, and more. DIRB is one such tool that does magic.

What is DIRB?

A directory buster, or less commonly referred to as a URL brute-forcer, is simply a CLI tool that looks for existing (and/or hidden) web objects on a remote or local web server. The tool by itself is sufficient at a basic level, but when combined with the right set of flags and wordlists, it can do absolute magic.

The tool itself is not a vulnerability scanner. Instead, it’s a simple dictionary-based enumeration tool that sends HTTP GET requests for each word provided in the dictionary.

For a 5 year old, imagine DIRB as a big basket filled with many different chocolates, but you’re interested in a specific one. So, just like a 5 year old, you pick up each chocolate one by one and look at it carefully. If it’s not the chocolate you want, you put it back and try the next one. When you finally find the chocolate you were looking for, you feel happy.

The technicalities

So, DIRB uses libcurl (a C library used for HTTP/HTTPS requests) to send GET requests for each crafted URL. The crafted URL consists of two parts: the domain and a word from the chosen dictionary. Something like this:

https://example.server/{word}

For each iteration of a word from the chosen dictionary, DIRB sends a GET request, records the HTTP response code, and reports back any valid directories or files.

Assuming you have a dictionary with a bunch of common words, the URL sequence would look like the following, and so on, including subdirectories as well.

https://example.com/admin
https://example.com/mysql/backup.tar.gz
https://example.com/.env
...

The fun stuff

So how do you get your hands dirty? Well, it’s as simple as installing the utility on your “favourite” guest OS. DIRB is available as a binary for both Linux and Windows and comes pre-installed with security-focused distributions such as Parrot and Kali.

If you don’t have it installed, follow one of the commands below based on your distribution.

On Debian flavours

sudo apt install dirb

On RPM based flavours

sudo yum install dirb

Direct downloads

https://downloads.sourceforge.net/project/dirb/dirb/2.22/dirb222.tar.gz

Basic syntax

dirb <url> [wordlist] [options]

1. <url> - The target website
2. [wordlist] - Optional. The custom wordlist to use, if not specified it falls back to it’s default.
3. [option] - Additional flags to customize default scans.

All the tool requires is a URL to scan, and voila, you can watch the results unfold. If you have a website (not mine) to test on, you can simply fire up the command like the one below:

dirb https://example.server

Example output:

» dirb https://example.server

-----------------
DIRB v2.22    
By The Dark Raver
-----------------

START_TIME: Sun Dec 13 01:11:06 2025
URL_BASE: https://example.server
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt

-----------------

GENERATED WORDS: 4612                                                          

---- Scanning URL: https://example.server/ ----
+ https://example.server/admin/ (CODE:200|SIZE:5819)
...

If you want to use a custom wordlist because you’re absolutely sure about the web stack the website is using, you can simply modify the command like this:

dirb https://example.server /home/tin/laravel-wordlist.txt

Some useful flags

1. -o <output_file>: Save output to disk.
2. -S: Silent Mode. Don’t show tested words. (For dumb terminals)
3. -X <extensions> / -x <exts_file> : Append each word with this extensions.
4. -p <proxy[:port]> : Use this proxy.

All of those flags combined, the command would look something like

dirb https://example.server -o /home/tin/scan.txt -S -p 127.0.0.1:1080 -x .php,.sql

Other tools?

Well, I can go on and on about DIRB in particular, but comparatively, it’s a little on the older side and slow when compared to other tools written in the Go language. That said, if you’re just getting started, it’s quite easy to use and requires minimal configuration.

The overall success of this tool solely depends on the quality of the wordlist, your reconnaissance on the target, and a basic understanding of HTTP response codes.

Until then, I’ll see you in the next one!