DirB
Last updated
Last updated
Related Sites:
If a webpage or directory is not linked to from other pages, how does dirb know it’s there? In short, it guesses.
To use dirb, you provide a wordlist. This wordlist might contain common endpoints, such as “index.html”, “admin.jsp”, “login.php”, to name a few examples. It might also include common directories like /.git/, /cgi-bin/, and so on.
Dirb takes the provided URL (ex: http://site-being-tested.com), appends the endpoints one at a time, and then makes a request.
The HTTP response code tells dirb about the webpage’s existence (or not):
If the endpoint does not exist, the webserver should return a 404, in which case, dirb ignores it.
If it returns a HTTP 200, then the webpage exists and is viewable.
If it’s a HTTP 30X, the server returned a response, redirecting dirb to another location.
If it’s a HTTP 40X, the server has indicated that authentication is required, and that dirb is forbidden or unauthorized.
Dirb does not “spider” websites (follow links), nor does it download files or run typical vulnerability scans. It just tries out all the endpoints provided in the wordlist.
You can read dirb’s if you’d like.
We’ll cover specific use cases later in this article, but here is the basic dirb command format:
Ubuntu:
By default, dirb looks in /usr/share/dirb/wordlists/ for a wordlist named common.txt.
If you get this error: (!) FATAL: Error opening wordlist file: /usr/share/dirb/wordlists/common.txt then you have two options:
You can move a wordlist with the name common.txt into /usr/share/dirb/wordlists.
Or, you can supply the path to a wordlist after the URL, such as
dirb http://site-being-tested.com /path/to/wordlist
If a website is written in PHP, use a PHP-specific wordlist. Same goes for other languages. You can also use wordlists that target a specific website platform, like IIS.
Dirb is only as good as the wordlists you provide it. While common.txt is a good place to start (and will typically find you the endpoints for common CTF challenges within HackTheBox, etc), you will want to branch out and tailor your wordlists to your application.
My two top picks for wordlists are:
Each of these resources has a variety of lists for different uses. I suggest that you save local copies and add to them as you discover new web technologies and related endpoints.
You can use multiple wordlists, just comma-separate them! For example,
Each of these resources has a variety of lists for different uses. I suggest that you save local copies and add to them as you discover new web technologies and related endpoints.
You can use multiple wordlists, just comma-separate them! For example,
As dirb is running, you can use hotkeys to skip ahead, pause the scan, or show stats:
This can be used to exclude a directory, by pressing n after the directory scan has started. Dirb will jump to the next directory in the list.
If you want dirb to ask ahead of time, you can use the -R flag for interactive recursion, meaning that dirb will ask you before it begins each directory.
Here are some common dirb use cases:
If you provide a URL beginning with HTTP and no further port info, the port used by dirb will be “80”. Likewise, HTTPS will use 443 by default.
To provide a specific port, use the format http://url:port or https://url:port. For example:
If you have a website that requires basic authentication, use -u <username:password>. For example:
If you have a client certificate to provide, use the -E flag:
If those options don’t cover your needs, you can always add other custom headers with -H <header value here> after the URL and wordlist.
If you’re using dirb with a proxy, you can use -p <proxy[:port]>
If authentication is required, add -P <proxy_username:proxy_password> (uppercase P).
If a website returns a certain HTTP status code that you’d like to ignore, use -N <HTTP code>. For example, if a website returns a 301 instead of a 401/403 response, you can ignore that with
On the other hand, if you want to see NOT_FOUND pages, you can use the -v flag (warning, this will likely be very noisy).
If dirb finds a file from the wordlist, you can instruct it to automatically try variations with the -M flag. For example:
If http://site-being-tested.com/db was found, dirb would automatically try http://site-being-tested.com/db.tmp and http://site-being-tested.com/db.backup.
This may not be available on all versions of dirb.
If you have a wordlist that is only filenames without extensions, you can use -X <file extension> to have dirb append the file extension for you.
This might be useful in a scenario where there’s a catalog of information within a certain topic. For example, /dog.html, /cat.html, and so on.
Here’s an for MacOS.
This second option will come in useful, since it’s a good idea to tailor your wordlist based on the website’s .
You can provide a cookie instead, if you have logged into the website (and then used , , or similar to find the relevant authentication cookie).