Dirbuster is a multithreaded Java application that tries to find hidden files and directories on a target web application by brute forcing their names. Dirbuster comes with 9 lists of common file and directory names that were crawled from the internet, but you can choose to use your own. Pure brute forcing is also available, but due to the time constraints, the filelist option is by far the most commonly used
As an aside, you might have probably noticed that lately I’ve been writing less writeups and have been focusing more on tools and system administration fundamentals. I thought that in the long run, this approach would yield better and faster results, both in CTF challenges and in real-life hacking (bug bounties, I’m looking at you). While I haven’t used Dirbuster so much, I was inspired to write a post for it after reading this blog post on how it helped in acquiring a nice bounty
With that said, let’s take a look at Dirbuster’s interface:
This tool is not complicated to use, nor does it have tons of other functionality besides discovering hidden resources. However, from my (limited) experience with it, the default settings might not work in the majority of cases (causing crashes and so on). A bit of fine tuning is required to get the most of your dirbusting experience, and is this that I will be covering here.
Dirbuster configuration
The first thing you will do when starting Dirbuster is to select a wordlist to use. The lists that come with Dirbuster are located in /usr/share/dirbuster/wordlists/ on a Kali machine.
Work method – leave the Auto Switch selected for fastest results. Dirbuster will try a HEAD request first, saving more bandwidth and latency than it would with a straight on GET request.
Number of threads – the default is 10, but in my own testing, I found this excessive, so I am now starting with 3-5 threads. Since the Go Faster option allows you to jump over 100 threads, you might think the faster the better, but I noticed that Dirbuster has a really thin line between slow but working and fast but crashed. Maybe it’s the local vulnerable installations I tested against, but it seems logical to treat a live target with more caution than a lab..you don’t want to DOS your target in your search for goodies.
In your choice of wordlist, take a second to review the target and see if it uses case sensitive resources (for instance, try seeing if admin returns the same as Admin, use lowecase lists if target is a IIS web server etc.). This will help you decide what list is most appropriate for the job, and save you precious time.
Under the starting options, you will tweak things as needed, because there is no one-size-fits-all approach to these checkboxes. The standard start point considers directories as ending with a / slash, and files ending with the specified extension. It’s best not to run with all the options checked at the same time, as this will take significant time and it may potentially crash the target. I separate the Brute Force Directories and Brute Force Files + Use Blank Extension. As always, the target dictates the weapon, so time constraints and the sensitivity of the target should also be taken into consideration for the Be Recursive option, which I toggle as necessary.
The URL fuzz option allows you to enter the words in the lists directly in the URL, in a template like manner. An example offered by Dirbuster is test.html?url={dir}.asp, where the content in curly brackets will be substituted for the words in list.
Dirbuster Options
In the Options tab, you can further tweak your Dirbuster installation.
Follow redirects – I check this, but it does come with an overhead increase, you might want to leave it unchecked and manually navigate to interesting places that were found
Parse HTML is on by default, and it lets Dirbuster read the HTML and look there for other files and folders that it won’t have to guess
In the Advanced options, there a few more tabs you can configure. The Dirbuster Options tab allows you to set some default values so you don’t have to change them each time you start the application.
In the HTML Parsing tab you can configure which HTML elements to extract links from, along with file extensions that should not be processed.
The Authentication tabs covers authentication options for Basic, Digest and NTLM authentication. In the HTTP Options tab you might want to spend a few moments to change the blatantly conspicuous user agent. Also, note the Run through a proxy option, which is available if you want to..well, run Dirbuster through a proxy. It’s also possible to add custom headers, maybe you want to add a cookie to use Dirbuster as an authenticated user. That might be risky if your user privileges allow you to perform certain actions on the target, so you might want to restrict other options in this case (maybe you don’t want to follow all the links in case one of them does something you really wouldn’t want to, and so on).
Finally, there’s the Scan options tab. I chose to decrease the default Connection Timeout value from 30 to 10 seconds and to limit the number of requests per second. You can also see the failcase string that Dirbuster uses to determine if a resource is actually there or not.
After running a scan, you can see the results found, including the HTTP response code and the size. I ran a test scan against Mutillidae with threads blazing for the demo:
You can also see the results in a tree view, for better readability:
This concludes the post on Dirbuster. Despite being unmaintained (not sure if that’s a word), it’s still the go-to application for files and folders discovery. Use it early in the recon process (after you took a look at the target to know which settings to apply) for best results!
1 2 3 4 5 6 7 8 9 | |