Recently, I was a guest (again) on @AnyPort_Pod. This time, we talked about bug bounties, I thought it was a great discussion! (You can check it out here). At the end, I was asked about what tools I use when pentesting / bug hunting. I think I kind of stumbled through the answer a little, because there were so many directions I could have gone with that question. I discussed a few favorites that had been on my mind recently, but I thought it might be useful to follow that up with something a little more comprehensive.
I’d actually never considered that anyone would even care about the particular tools I use, but after having a few conversions I think for some newer people in infosec, or those who don’t really specialize in web applications, it might be pretty useful to see an example of what a more experienced web pentester uses and why. Rather than just provide a list, I want to add some context and advice as well.
If you are someone who is experienced enough to compile a similar list (which would probably end up much different than mine), just know you aren’t really the intended audience. Hopefully this can help some newer folks get some idea about new things to try or ideas on how to expand their skillset. If you know of something you think I should really be using, I’d love to hear that too!
Like I talked about on the podcast, I really try to keep things self-contained within Burp via extensions. That being said, sometimes the best tool for a particular job is just a standalone tool. For now, lets start with Burpsuite extensions.
Note: If you use zap, (for a reason other than money), what are you doing? There was a time (a very long time ago) when maybe it was a legitimate choice between Burp and Zap… But to continue to say that in 2021 is just absolutely unfair to Portswigger who have continued to relentlessly improve Burpsuite for years. So yeah: You should be using Burpsuite Pro!
All of the featured extensions are available in the BApp store within Burpsuite’s Extender tab. Some extensions require Jython. You will need to download the Standalone Jython jar file and configure Burp to point to it in the Extender tab options to use these extensions.
Arguably the best logging extension. Similar to Logger++. One very important difference: It will display requests that do not have responses, which can be important when trying to exploit HTTP Request Smuggling.
Having a logging extension which will allow you to view past repeater requests, which are otherwise not retained, is critically important as it pertains to properly documenting your testing activities.
Note: Burpsuite has a built in logger now, it might be better, but I just haven’t had time to test it properly.
Http Request Smuggler (@albinowax)
This is simply the best tool available to detect “modern” request smuggling. Written by James Kettle, who is the one who discovered these new techniques and revived the bug class from the grave. This will not only handle the detection of request smuggling but will build starter PoC exploits which can be used to validate the vulnerability or as the basis of developing further exploits.
If you haven’t explored this vulnerability class yet, you might be a little late to the party but it’s certainly not over yet. A lot of the vendors of various network devices / applications that were vulnerable have patched, so in my experience it’s a little more rare to find today than in the past. Still absolutely worth diving into. Here are some links to get you started:
Param Miner (@albinowax)
This is the one I talked about the most on the podcast. It’s another tool by James Kettle (@albinowax), and if it wasn’t obvious already I am a really big fan of his work. Basically, it will brute force headers, cookies, and GET/POST parameters and watch for differences in the response. It’s a fairly simple concept, really. The reason I am so excited about this at the moment is the amount of bugs I’ve been finding in otherwise very hard targets which are based on header manipulation.
As web applications become more complex, and traditional web vulnerabilities like XSS and SQLi slowly become less and less common (very slowly, unfortunately) a new attack surface is quietly becoming larger and more interesting. All of the intermediate devices that sit between you and your target webapp without you ever noticing are introducing new opportunities to mess with things, and one of the most common ways to do that is via headers. I’m talking about WAFs, API gateways, load balancers, reverse proxies, and last but certainly not least, web caches. These all can silently read, write, and alter HTTP headers as they go, and interfering with that process can have surprising effects.
One of the biggest and most well-researched use cases is with web cache poisoning, where it can be used to find unkeyed inputs that affect the content of the response. To learn more about such techniques, start here:
Aside from cache poisoning, I have had a ton of luck recently abusing some of these intermediate devices to land myself in an internal-only or privileged context, and therefore gain unauthorized access to things. The most dramatic case of this landed me on an internal API which had unrestricted access to basically everything this organization had, some of which was very sensitive. I’ve gained access to hidden admin portals, entire hidden web apps, and bypassed IP-based firewalls.
Something as simple has noticing a weird header changes a response in a subtle way can be a thread you can pull that will expose some very interesting bugs!
This is a fascinating and unique extension that operates on the theory that, statistically speaking, certain parameter names are more likely to be vulnerable to specific types of attacks. The extension will watch traffic and let you know when it sees a parameter name that is historically associated with an attack type. Of course, it finds tons and tons of false positives. Where I find it useful is as a reminder to myself to check obvious places for obvious bugs. So often I am diving so deep into things I forget to check things right in front of my face. It’s basically an extension of your own spider-sense which should already be triggered when you see certain common patterns, parameters like “file”, or “path”, or “URL”, etc.
SAML Raider (Roland Bischofberger / Emanuel Duss)
I’ll be perfectly honest, SAML is a bit of a weak spot for me. I have just not taken the time to understand how it works to the same extent that I have with many other authentication-mechanisms. All the more reason to have a solid tool to help me when I do encounter it. SAML raider takes the guess work out of a lot of common SAML attack patterns. Things like just removing the signatures (yes, sometimes this works), automatically building an XXE payload, or just signing a SAML response for you when you manage to pilfer a private key, which is surprisingly annoying to do by hand.
WSDLer (Eric Gruber)
Will parse a WSDL and automatically generate sample requests which can be loaded into repeater.
Basically if you encounter an API that has a WSDL, you are going to want to use this. Converting a WSDL into usable, properly formatted endpoints (the only thing you really care about) is one of those annoying tasks you just want to be done for you.
I just wish the result of the parsing survived restarting Burp!
Content Type Converter (Eric Gruber)
Surprisingly useful conversion utility for converting between JSON and XML. JSON endpoints that also accept XML are great places to find hidden XXE vulnerabilities. This is one of those things that should really just be built into Burp, but isn’t. This extension perfectly fills the gap.
Ok, this is not an extension, and is just a standard Burp feature… but I wanted to talk about it specifically though because of how damn useful it is.
For those who may not know, Burp collaborator is basically a server with public-facing interfaces that listens to HTTP/HTTPS, DNS, and SMTP requests for you. You have a client, built into Burpsuite, capable of generating the URLs and polling the server (retrieving the results). It’s used to determine whether or not you’ve successfully coerced your target into making one of these type of requests.
Obviously, it’s a must-have for things like SSRF or XXE to see if you have external communication. But what about RCE? Can you think of a less-intrusive way to confirm code-execution than just triggering a nslookup for your collaborator server? Planting a webshell or setting up some kind of reverse shell is not always an option (for a variety of reasons), but you can easily use this to prove you have execution instead.
It might even be a way to exfiltrate information when you get code execution but the server has strict outbound firewall rules blocking your reverse shells.
If you hack for Synack, you probably already know that you can’t poll for hits while connected through launchpoint. Go get a cheap server from digital ocean or AWS or linode or whoever, and set up your own. I’m not going to lie, it’s a pretty intense process to set one up but totally worth it after that – you’ll be able to poll without disconnecting from LP. I’ve found a ton of bugs where I used my private collaborator server for some part of the process, and never seen any complains about it.
On the pentesting side, your customers will likely be a lot more comfortable with traffic headed to collaborator.yourcoolpentestcompany.com (even though the public servers are perfectly safe) than the public servers.
Error Message Checks (August Detlefsen)
Adds additional support for identifying verbose error messages in output. Prone to some false positives. This is really simple, but I feel like verbose errors is one of those weaknesses that tend to get minimized a lot. There have been plenty of cases with black-box type engagements / bug bounties where some little tidbit of data I found in an error message enabled an entire attack chain. This will just help you avoid missing them.
An amazing tool for potentially identifying non-known Java deserialization bugs. Will take a wordlist of classes and automatically build test payloads with them in an attempt to identify classes and libraries which are available on the remote Java classpath. I haven’t successfully used this yet, but I feel like it’s just a matter of time.
You should go ahead and check out the blog post from BishopFox Labs about it. While you’re at it, read the rest of their stuff because its all great.
Software Vulnerability Scanner (vankyver)
Another N-day extension checker, based on Vulners.com API. Not something to turn on all the time, but when scanning non-custom software, it may be able to identify known vulnerabilities.
GraphQL Raider (denniskniep)
Put simply: if you ever encounter GraphQL, this is a must have.
J2EEScan (@ilmila) This extension adds many Java framework based N-day detections to Burp scanner. This is highly recommended for any application based on a Java framework, as it covers many important known-vulnerabilities that should always be checked for. There’s a long list of them, and remembering to check for them all manually is pretty inefficient.
Active Scan++ (@albinowax)
Adds a variety of advanced attacks to the standard set deployed on any Burp scanner run. Highly recommended any time you are using Burp’s scanning features.
CMS Scanner (moradotai)
Additional coverage for several popular CMS’s. Drupal, Joomla, and WordPress. Any time you are dealing with known-frameworks like this, try and take advantage of what other people have built to try and save yourself some time and ensure you are getting a good coverage. Nothing is worse than missing well-known n-day vulnerabilities on known frameworks. Get the basics checked off so you can go find interesting new bugs!
Collaborator Everywhere (@albinowax)
This extension adds a variety of headers to EVERY request, trying to tease intermediate systems into hitting your collaborator server. This can be a tip off to very interesting vulnerabilities driven by malicious headers, in a similar manner to Param Miner. This big difference is this adds headers infused with your collaborator domain to every request automatically as you browse. As this automatically modifies every request, it comes with a caution: I’d definitely leave it off until you are ready to actively use it.
Will analyze the contents of data found in various parameters and try to identify them. Might be able to spot something like a hash that you might overlook as random data when causally inspecting it.
JSON Web Tokens (ozzi-)
Will analyze JWT’s, allow you to edit them, and test for many known JWT vulnerabilities. Not my favorite JWT tool (that’s jwt_tool, more on that later), but pretty good, and convenient as its available within Burp. I use it as a quick survey of the contents of a JWT.
Freddy, Deserialization Bug Finder (@nickstadb)
Will scan for a large range of known deserialization vulnerabilities with Java and .Net.
Java Deserialization Scanner (federicodotta)
Adds additionally Java deserialization discovery and exploitation capability.
I really do like to keep things self-contained, but its just really not possible. I think it’s some weird form of OCD that I can never satisfy. When I step outside of the tools available within Burpsuite or an extension, there’s usually a good reason for it.
I can’t say enough about this tool from Alvaro Muñoz (@Pwntester). NET serialization was just a really under-explored area for a long time before this tool and all the research @Pwntester and others did in the area.
Any time you are doing anything at all related to .NET serialization, this tool has you covered. I’m not going to get into the fine details of how to use it (spoiler alert: my next blog post will in a big way), but its really as simple as selecting the gadget, selecting a compatible format, and setting the desired command. There are pre-built plugins for doing things like forging a .NET viewstate, exploiting DotNetNuke deserialization vulnerabilities, and many other specialized-but-common payload generation tasks.
I’d recommend using the pre-compiled version, I’ve just had the most luck with it.
If you are still a little lost with the entire concept of deserialization attacks, don’t feel bad. It can be confusing at first. In that case, start here.
Ferox Buster (@epi052)
I have always been a big fan of using Burp Intruder for dirbusting type activities. There are still some scenarios where I think it’s the best (complicated insertions and / or payload manipulation). However, for run-of-the-mill dirbusting situations, I have transitioned into using this as my go-to. It’s written in Rust, and from what I understand this is one of the main reasons for speed boost.
Sometimes fast is too fast, and you can tip-over poorly resourced servers… but that’s ok, it includes an “auto tune” feature to dynamically adjust the speed if it starts to hurt the server’s performance. There are a lot of smart features in here: like having recursion, but being able to cancel unwanted branches live while running. You can stop scans and resume them later You can filter the results in a number of ways, such as HTTP response code, keyword, or even regex. dirbusting is one of the more resource intensive things you will do against a web application, so it makes sense to outsource this away from Burp – which despite my unconditional love for, is still written in Java. ☹
Lets talk about Nuclei for a minute. It’s an open source vulnerability scanner, with a really amazing rule template engine based in YAML formatting. When I first heard about it, I wasn’t really that impressed. Then I started to look at the template language and realized how powerful it really is. When I saw someone successfully building an HTTP smuggling template, I was blown away. Seriously, with the use of the “raw http” mode, you can do just about anything with this.
Impressive template engine, huge library of community built templates, built in out-of-band detections, and also its fast and scales up well. I really think this is a game changer in a lot of ways.
However, there seems to be a lot of people just loading up every Nuclei template known to man and blasting away at everything. Maybe don’t do that? There are lots of really great signatures, but its probably worth being a bit more targeted in your approach. For one thing, don’t expect to find a lot of bounties doing the exact same scan as everyone else. Second, some targets can’t handle multiple people bombarding them with scans like this. Some systems are fragile.
I think the real value from a bounty perspective is in writing your own templates. Every time you find a bug, make a nuclei template for it and find it again every time, forever.
From the pentesting standpoint, get a good list of templates together and use them to build a ‘baseline’. Use it to check all the routine checkbox type stuff so you can focus on the really interesting manual stuff.
I have had to do several engagements that revolved heavily around JWT’s, and during these jwt_tool became my best friend. Not only does it automate and assist with all of the classic JWT security checks, but makes tampering with a token when you have the key a breeze. It’s really a one-stop shop for everything JWT related.
I will say, I actually prefer some of the older versions (I use version 1.3) because I kind of enjoy the interactive, step-by-step process of tampering with a JWT. The newer versions are much better suited towards automation and working with scripts and other tools, though.
IIS shortname scanner (@irsdl)
I’m not going to talk a lot about this, simply because I wrote an entire blog post on it. So go check that out! In one sentence – it lets you enumerate partial filenames / directories on some IIS servers by abusing old windows 8.3 style filenames. The bottom line is, if you are testing a .NET app just check to see if its vulnerable, it only takes a few seconds.
Everyone knows about SQLMAP, but I wanted to bring it up in the context of someone who doesn’t use a lot of non-Burp tools. I wouldn’t even think of using something else.
I can’t think of a security tool that has more thoroughly solved for a single bug class better than SQLMAP and SQLi.
It does fail sometimes, and I have had to make custom python scripts on occasion to get blind SQLi working in a few weird edge cases where SQLMAP just wouldn’t work. That being said, for 80 percent of SQLi, SQLMAP will find it… and there is simply not a more efficient way to exfiltrate data than using SQLMAP, in particular when you are talking about blind injections.
Yeah, I know. Pimping my own tool. Sorry, but it just happens to be my favorite padding oracle attack tool. There’s definitely nothing built into Burp to do it!
Padding oracle attacks are somewhat obscure, despite the technique first being discovered in 2002. I believe most researchers are not looking for them. My first couple blog posts talk about the tool and some general tips for hunting them.
If you listened to the Any Port on the Net bug bounty episode I’m in, you hear me talk about a bug that I can’t really talk about. While, I still can’t… but I can say it was a padding oracle vulnerability that I found with this tool, and it netted me by far my largest bounty of all time.
It will admit, it can be intimidating at first but it’s kind of designed that way. I’m trying to front-load the configuration so that once you get set up on a particular padding oracle bug that actual decryption / encryption is as easy as possible.
I haven’t gotten much feedback on it yet, I simply don’t think its gotten much attention and I just don’t have enough followers. I am sure there are bugs and edge cases that will necessitate some updates. So please, if you do use it, give me some feedback, even if it’s negative!
I’m not going to explain the padding oracle concept in-depth, simply because it would be longer than the rest of this post. It is not an easy concept to convey quickly. Fortunately, there are some great resources for understanding which a linked to in my Padding Oracle Hunting article, and I will relink here again:
Excelling technical deep-dive – https://blog.skullsecurity.org/2013/padding-oracle-attacks-in-depth
Great animation which can help visual learners conceptualize the attack – https://dylanpindur.com/blog/padding-oracles-an-animated-primer/
Hopefully this is useful to someone. There are tons of amazing tools out there that I didn’t mention, I’m just trying to highlight a few that I have found particularly useful over the last few years.
I’d love to know what great web hacking tools I’m missing out on, too! Hit my up on twitter @paulmmueller and tell me some of your favorites. I might even add them here!