Integrating Wfuzz with Burp Suite

From PortSwigger and Wfuzz

Words can’t express how much I appreciate Burp Suite, but sometimes you need Burp Suite-like functionality using other tools. For example, you may need to use Burp Intruder but

A) You only have Burp Suite Community Edition,

B) You’re taking an exam that doesn’t allow Burp Intruder, or

C) You prefer/need a command line option to Burp Intruder.

You’re in luck because you can pair another essential tool with Burp Suite via a proxy connection for Intruder-like functionality: Wfuzz — xmendez/wfuzz: Web application fuzzer (github.com).

Wfuzz is an effective and dynamic tool by itself, going well beyond what this blog post entails. For this example, we’re using wfuzz for a password dictionary attack against a web application. This approach will be similar to using Hydra, but honestly Hydra’s syntax often confuses me and wfuzz has many advanced options.

Setup and Enumeration

If you don’t have wfuzz, install it using pip.

pip3 install wfuzz

Let’s see our target web application.

It’s a Jenkins login page, so we’ll try to login and intercept the HTTP request in Burp Proxy. This will give us the information we need for setting up wfuzz.

Notice this is a HTTP POST request with the username and password specified in the data field.

Basic wfuzz Commands

Before we start proxying wfuzz through Burp Suite, let’s run a basic wfuzz command with two short username and password lists (jenkins-users.txt and jenkins-password.txt).

wfuzz -z file,jenkins-users.txt -z file,jenkins-passwords.txt -d "j_username=FUZZ&j_password=FUZ2Z&from=&Submit=Sign+in" http://10.129.45.237:8080/j_spring_security_check

• The wfuzz command includes two -z flags which specify the file payloads for the users and passwords lists.
• Since this is a POST request, the -d flag specifies the data field content. Notice the substrings FUZZ and FUZ2Z correspond respectively to the first and second file payloads.
• The full URL string is specified at the end of the wfuzz command.

You probably noticed the output is not helpful. All HTTP requests received a 302 Found status response code, meaning our requests were redirected to a different web page.

At this point, we don’t know if any of these username/password combinations is correct since the request with legitimate credentials could also be redirected — possibly to a different page.

Handling Redirects

Let’s send another wfuzz command include the verbose flag, -v. This will output the redirection location specified in the HTTP response.

wfuzz -v -z file,jenkins-users.txt -z file,jenkins-passwords.txt -d "j_username=FUZZ&j_password=FUZ2Z&from=&Submit=Sign+in" http://10.129.45.237:8080/j_spring_security_check

It’s not pretty, but now we have the Redirect column, specifying the redirection URL. One request did not redirect to the page loginError (the last item above). This seems very promising and is probably the correct credentials.

Another approach is to specify the -L option, which follows redirections.

wfuzz -L -z file,jenkins-users.txt -z file,jenkins-passwords.txt -d "j_username=FUZZ&j_password=FUZ2Z&from=&Submit=Sign+in" http://10.129.45.237:8080/j_spring_security_check

You’ll notice that the Response, Lines, Word, and Chars columns are different for one response (the one for the credentials root:password). Again, this points to the correct credentials. Sometime little differences for certain responses can provide useful hints when fuzzing.

Combining wfuzz with Burp Suite

Now, let’s get to pairing wfuzz with Burp Suite. As you can see, wfuzz is extremely useful by itself, but you may want to integrate wfuzz with Burp Suite.

• Sometimes you want to use Burp Suite’s GUI for reviewing HTTP requests and responses, or
• You use Burp Suite as your main repository for web app enumeration.

First, we’ll setup a new proxy listener in Burp Suite (in this example, over port 8081). Later, it will be clear why this can be helpful for filtering.

Now, we’ll execute a new wfuzz command specifying the proxy by including:

-p localhost:8081:HTTP

wfuzz -z file,jenkins-users.txt -z file,jenkins-passwords.txt -p localhost:8081:HTTP -d "j_username=FUZZ&j_password=FUZ2Z&from=&Submit=Sign+in" http://10.129.45.237:8080/j_spring_security_check

The command output will look our first one, but we can see the requests in Burp Proxy’s HTTP history.

Congratulations! We can now log our wfuzz attempts in Burp Suite!

Note the last column in the screenshot above, listener port. Since wfuzz is using a different proxy port (port 8081) than the web browser (port 8080), we can filter Burp Proxy HTTP history by listener port (see red box below), allowing us to view only wfuzz traffic.

We can also do a negative search filter for the string “loginError” since we see that in the HTTP responses for incorrect credentials (see red boxes below). This is a similar approach to how Hydra works, with the benefit of filtering and analyzing traffic within Burp Suite.

Now, we find the one request with correct credentials.

Leveraging User-Agent Headers

You may have noticed that, by default, wfuzz includes a very conspicuous User-Agent header, wfuzz/3.1.0.

This may be useful for filtering Burp Suite, since all requests from wfuzz will have this User-Agent header.

There is another option for distinguishing wfuzz requests that don’t obviously come from this tool: Use a legitimate User-Agent that doesn’t match your web browser.

WhatIsMyBrowser.com has a useful list of User-Agents, grouped by operating system, platform, etc.: Browse our database of 198.6 million User Agents — WhatIsMyBrowser.com.

From WhatIsMyBrowser.com

As of this writing, manually browsing these User-Agent lists is free. WhatIsMyBrowser.com offers a paid database download with more content.

We can now run wfuzz again, specifying the exact User-Agent string using the -H option for HTTP headers. In this example, I used the User-Agent for the most recent version of Microsoft Edge. I’m testing on Kali Linux, so won’t unintentionally use this User-Agent for something else.

wfuzz -z file,jenkins-users.txt -z file,jenkins-passwords.txt -p localhost:8081:HTTP -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36 Edg/103.0.1264.37" -d "j_username=FUZZ&j_password=FUZ2Z&from=&Submit=Sign+in" http://10.129.45.237:8080/j_spring_security_check

We can then filter in Burp Proxy HTTP history (or in Burp Logger) for this specific User-Agent string.

If you can’t or don’t want to use Burp Intruder, you could assign a different User-Agent for every distinct attack/fuzzing attempt. This would allow you to filter for a specific attempt — granted you will need to keep notes mapping User-Agents to fuzzing attempts.

Conclusion

We’ve covered

• Basics of using wfuzz for password dictionary attacks against web apps,
• Integrating wfuzz with Burp Suite via proxy settings,
• Leveraging User-Agent strings for tracking and filtering wfuzz attempts

I hope you found this useful! Please feel free to like and/or comment below.