Streamline Burp Intruder attacks with Payload Processing Regex

September 19th, 2012

Well, after having this blog sit around for a while, I finally have a little time to make my initial post!  Isn’t that exciting?

Portswigger’s Burp Proxy is one of my absolute favorite pen testing tools. Brute forcing forms is one of my favorite pen test activities. I’m not quite sure why, maybe “brute force” conjures up the image of piling some TNT against a door and seeing things go BOOM! I’m sick enough to even enjoy brute forcing security questions for password recovery. In fact, I’ve compiled several nice wordlists for just that purpose that you may help yourself to, as well as some of my other favorite lists.

 So here’s the deal, most, if not all of us, are using one or a few large to huge password/word lists in these scenarios. Hello crack lib dictionary at 13+ megs!  So, why should we process each and every line in that file if we don’t have to?

Over the past year or so when talking to other pen testers, I share a little trick I keep in my back pocket for just this purpose, and the feedback is always “wow, really?!” so I thought it was time to share the information.  So here we go…

Scenario: You’ve done your recon on a login system and discovered it is brute-forcable. You’ve also unearthed the password requirements.

For the purposes of our demo, let’s say our app requires passwords to be 4-8 characters in length.  We’re going to use Burp Intruder to do our dirty work, so, get your request captured and sent to the Intruder module, mark your injection positions and all that jazz then flip over to the Payloads tab. You can use this trick on any payload type, but if you’re typing in a manual list (say just a few user IDs), there’s really no need, so I’m going to jump right to tweaking the password list. Under Payload Type, select Runtime File, and load in your favorite password list.  At this point, your config should look a little something like this:

Payload Selection

Now, here’s a quick result set from the default run (for brevity, I’m only fuzzing the password parameter):

First run - no filtering

You can see we have some short passwords, some long passwords, and some special character passwords. Let’s start filtering! Next, you want to Add a Payload Processing rule, in this case the “Skip if matches regex” option, and you want to add the following as a filter: ^.{1,3}$

First Regex Filter String

This filter will ignore any string with a length of 1, 2 or 3. Now, Add a second regex rule and add the following value: ^.{9,}$ This filter will ignore any string of 9 characters or more.  When done, your settings should look something like this:

Final filtering rule set

That’s it, we’re all set to kick it off!

Filtered queries sent to server

Voila, short and long passwords are filtered, and now the attack will finish much quicker!

But, can I make it even more efficient?

Why yes, yes you can. Lets say you’re performing recon on the authentication system, and you come along a message like this:

Wait, I can't use what?!

So, we are not allowed to use special characters, eh? Good news, we can tune up the filter set to ignore non-alpha-num characters. In this case, it’s nice and easy, we just use the NOTWORD filter anywhere on the string. So create a new “Skip if matches regex” rule, and add: .*[\W].* When complete, your config should look like this:

Length and Character filtering

 And that’s it, Burp will now only attack the application with strings that are 4-8 characters, with numbers and digits only.

Obviously, the regex filtering has many uses, such as filtering certain characters during fuzzing that are known to cause unwanted server behavior, but this is my favorite example. Enjoy!