The Bug Hunter's Methodology - Application Analysis | Jason Haddix

[Music] My name is Jason Haddix. You may have heard of me through that awesome introduction by our streaming panel, so that's cool. I'm here today as your keynote, and today we're going to talk about application hacking and my methodology. I call it the Buck Hunters Methodology.

Uh, I dropped this talk about a month ago at another con, uh, NahamCon, and I've made some improvements, and there's some new tools that I have been using in my methodology, and uh, wanted to share it with all you. So cool.

So this talk is not your normal, like, "this is how you do XSS," because I feel like there's a lot of places where you can learn how to just do something like that. My interest is more about where do you look for those bugs, right? Because a lot of the targets that you see, you know, at something like these events, you're looking at hundreds of parameters and hundreds of endpoints, and the application is infinitely complex, right? So instead of teaching you a fuzz string that you can use to inject, I'd rather teach you about tools, techniques, and basically where I look for those things.

I'm going to blow through a lot of these slides because I'm notorious for going over time when I'm speaking. So this is me, my family, these are the games I played. I've done a lot of bug bounty stuff over the past few years.

So the Buck Hunters Methodology was originally one talk, and it had recon and application analysis kind of baked into it. I'm really known for my recon methodology. This one diverges from that, and we split those two topics. So this is all application analysis in this talk. We're gonna talk about, uh, you know, like how you get started. And I think an important part about bug bounty that goes underserved a little bit, which is the discussion about mental hurdles when you're approaching an enterprise-level application or a large application. We're going to go through what I do for pre-manual and on automation and my thoughts around there. We're going to go through content discovery and then into application analysis.

Getting started: This is my obligatory kind of like resources if you're just starting bug bounty. These are the print resources I really recommend. Uh, everyone knows that the Web Application Hackers Handbook is kind of the bible for web hackers, um, even though, you know, kind of its release date, you know, says many years ago, it still contains all of the information for someone to get the basis of all the vulnerabilities you'll see inside of AppSec. And then you have Real World Bug Hunting by Peter Yaworski. You have OWASP references. You have Bug Bounty Bootcamp by Vicki Lee and a whole bunch of other wonderful books, as well as a new one that I recommend, which is Hacking APIs by Corey Ball, which has really helped me like learn and understand edge-case API hacking. So if you're new and you want print resources, these are the ones I recommend.

Now, if you're new and you want to go the route of live hacking your way to experience, just kind of cutting your teeth through live, you know, live targets, there's a ton of really good resources, right? You have PentesterLab, which is one of my favorites. You have Web Security Academy, which is uh, probably one of the most well-known and attached to Burp Suite, and then Hack The Box, as well as if you're interested in standing up your own servers, which I think is a valuable exercise, you also have VulnHub, which has a whole bunch of crackmes and VMs that you can get into. And then you also have the OWASP Vulnerable Web Application Directory, which whenever a GitHub project comes out that's a vulnerable, like, you know, Damn Vulnerable Node application or Damn Vulnerable whatever, those apps, they get put in a directory uh, here, and you can uh, download and kind of track what's coming out and use those targets to to learn on you on your own.

So if you want to follow people who do the stuff that is mentioned in this talk, these are all people I recommend to follow. They're all wonderful people, and there's a list, a Twitter list that includes kind of the Twitter audio of bug bounty in the bottom left-hand corner, and you can follow these and kind of get updates on what they're talking about, their tools, tips, techniques, everything like that. All right.

So the first part of the talk is basically mental hurdles. So when I look at a site, and when I started in bug bounty and still to this day, I face a lot of these mental hurdles, and I feel like a lot of new testers do as well. And the first mental hurdle I like to talk about is client reputation. So this is tesla.com, and I have friends who work at Tesla. They're probably top five percent security engineers, some of the smartest hackers I've ever known, some of the smartest security engineers I've ever known. And so I make this false connection to this site when I look at it and I say, "Hey, I don't know if I could find something here, like Tesla is like a pretty hardened target. Uh, everyone in the world has probably, you know, been looking at them," which is one of the next kind of fallacies I make, and I know people that work there and they're super legit, and uh, and so I'm maybe I'm not even gonna get to the point of looking at this domain, tesla.com. So that's the first mental hurdle that you have to overcome when you're looking at doing some application hacking, usually in bug bounty or even in a pen test or something like that.

The next one is pre-testing. And so I have a screenshot here of GitHub's bug bounty, right? And GitHub's bug bounty is pretty legit because they have their specific kind of custom leaderboard, and the custom leaderboard, you know, shows you what all these other hackers are doing and what badges they've earned, and SQL injection has been found, cross-site scripting, IDOR, privacy violations, all kinds of stuff has been found already in the domain. And so you can fall in the trap of looking at, you know, a leaderboard or, you know, who is hacked on a site and really convince yourself that there's been a ton of pre-testing on this target and you're not going to find anything. So this is the second mental hurdle that you can face as a bug bounty hunter.

The third one is size. And so in here I put Salesforce, and if you've ever looked at the back end of Salesforce, it's it's crazy how many parameters flow across an app like that, like an enterprise-level SaaS app that hundreds of thousands of companies are using, that's made to track data, has a whole bunch of modules, it's a really complex app. And so you'll start looking at this in Burp or some other interception proxy, or you'll even just use the app, and you'll be like, "This is too much to deal with," and you'll get analysis paralysis, and you don't know where to start, or or you're just like, you know, you won't start at all. So this is kind of the third mental hurdle that you can face in bug bounty.

The last one is kind of related to the first one, but not really: any software that is purchasable, whether it's open or whether it's COTS or self-hosted or SaaS or if it's open-source software, you can look at that and think, especially in open-source software, "Hey, it's been open source for so many years, and I'm probably not going to find anything anyone else hasn't reported already through the open-source community or security researchers who have done security research on it," and that's that's another fallacy you can you can fall into. The last one is this kind of fallacy of only touching the surface of the application, and this is actually one I see a lot, and it's where testers—this iceberg represents an application—testers will go to a domain, and they've they've overcome all those other fallacies, they'll go to a domain, and then they won't actually create accounts, which is, you know, kind of silly, but they'll only test the surface level of the application, the publicly available non-authenticated areas of the application, and all of the juicy stuff for the apps are actually on the inside, the authenticated portion of the application. And so, you know, like your "My Profile" section, integration functions, paid account functions, um, you know, there's all kinds of APIs on the internal that maybe were added on on top of original development of the app. You have all your upload and upload and export functions inside of the authenticated portion of the app, um, you have all your admin tools usually behind authentication that you want to try to get at as a hacker without, you know, the right credentials. You've got mute, you've got user levels for IDORs, customer data, and persistent user input. So this is the last kind of fallacy that you can face.

So all these fallacies are stacked against you from the start when you start application analysis, and I'm here to tell you that at least the first four, they don't effing matter. Every application has bugs, every single one, and they are out there, no matter how much they've been looked at, no matter how many people have looked at, which people have looked at, if it's been open source, if it's been closed-sourced, there are bugs in every single application, and you really have to push through these four things and recognize them before you get started and then just hit it real hard. And so I'm going to talk about a little bit about how I approach targets and where I look for some of the stuff I like to look for. Okay.

So the next part is what do I do when I'm approaching a target with kind of my pre-manual testing phase and what automation I use when I'm testing a one website, like after I'm done with recon, I land on one site, what am I doing? So this is how I look at an application of several layers. You have at the base layer your open ports and services, which goes underserved sometimes, right? So anybody who actually spends the time to do a port scan, you know, sometimes we'll get lucky and find web servers on high ports, that are admin panels, installed software on the same server on high ports, you'll find remote administration services, etc., etc. So it really pays to look at this level of the server, which is related to the application. Then you have your web hosting software where you can find default admin panels, default creds, sometimes, you know, CVEs that are related to certain things with misconfiguration, and you can basically check there. Then you have your application framework, and then your custom code, and then application libraries and any integrations. And so this is kind of how I break up an application. You need to test every single stage. What I see a lot of people skip is actually the server level, and in most bug bounties, people will accept or customers will accept things in that first layer there, since it's associated to the domain you're probably assigned to hack. You may find open ports, and I can't tell you how many times I have found like random stuff on high ports. In fact, even during this event, there are multiple sites that people have neglected the port scan and then actually found stuff on high ports or low ports, who knows.

All right. So how do I basically understand the application and what technologies it uses? Uh, I use two uh, tools, uh, one is WhatRuns, and the other is Wappalyzer, and uh, they're both browser extensions, but they also have command-line functions, and they will just give me an overview of what technology the website is using, and this gives me a good basis for the rest of my research, and I just note it down somewhere. I am a big fan of mind maps, and so I just put all this data in a mind map, and I'm like, "Okay, cool, I have it for later. I know what server software, I know what tag managers, analytics, I know what JavaScript frameworks they're using," and that is my basis to start the rest of my research. So if you don't want to use the browser extension, you want to automate this, and some frameworks do this already, you can use WebAnalyze on the command line, and it will go ahead and give you a command-line output for this. I like to give both uh, manual, like in-browser tools, because that's how some people prefer to work, and then I like to give command-line tools because some people prefer to automate these certain steps and glue them into an automation framework.

So then what you move on to is trying to find existing vulnerabilities for some server software that may have been associated to your target. Now what you want to look for are known vulnerability CVEs, framework logins, default creds, and anything that's related really to non-custom code. And uh, so there's a lot of kind of conjecture around if this is valuable in bug bounty because it leads to dupes and stuff like that, and I have very specific opinions on that. Some people disagree with me; we'll talk about them at the end of this section.

So when you're looking for common CVEs and you want to use probably the most infamous tool that's out there right now, which is Nuclei, Nuclei has over a thousand CVEs in its CVE database, uh, over 100-plus informational detections, 500 admin panels checks, and 150 other random checks. There are also other tools in this area, uh, so my my other favorite is Jails by a guy named Jesse JJ. It also has a very comprehensive CVE library of checks. Um, you can use retire.js to look for libs and frameworks that are out of date, Sniper, Intrigue, Go, Fingerprint—these are all tools that over like all of them combined, you know, probably rival what you can get in like a Nessus or something like that. I think that like the open-source tooling for finding CVE-level bugs uh, is actually outpacing a ton of the tooling that's enterprise-level. So um, these are kind of your options and the ones that that I like.

Now, uh, Corbin, good friend of mine, um, posted this I want to say like a month or two ago, and he's like, "Hey, using Nuclei is a competitive disadvantage because it'll lead to heartbreak and it'll abduct your kids and all this stuff," and that's, you know, that is actually true, right? If you're just taking these default tools and running them at the scope that everybody else is looking for, probably not going to be very useful for you, these CVE tools. But my caveat here is that if you're doing really good recon and you have found a greenfield domain or subdomain that nobody else has found, I have had a lot of success with something like Nuclei. And so really you got to be able to gauge when you find something that other people haven't been able to found but been able to find before. Also, making your own templates for Nuclei is probably the easiest it's ever been in any tool. And so making your own templates in Nuclei, you are no longer running what everybody else is running, and you can have great success if you learn how to code your own templates.

Now I wrote a thread on this at that bitly link up there on how I do this. So I use TweetDeck that searches for different vulnerability classes and polls every five seconds. And so I have things like here, like local file include, path traversal, broken authentication, and this parses Twitter as kind of like my threat hunting feed but for bug bounty. And so this basically I pull every day, and if there's a new CVE or a one-day or maybe even a 30-day, but it isn't in the Nuclei libraries, I poured it into a check, and I have steadily built probably 120 checks that were not in the original Nuclei library that have found me multiple bounties across scope that has been heavily tested because it's not the same thing everybody else is checking. And I write my own templates for it, and this pulls every day. I have, you know, basically you could follow this model and uh, do the same. Vulnerabilities that are in the OWASP Top Ten, um, I'm sure you can think of all the different names vulnerabilities are called, but this is how I do it. And so I released a thread that talks about this and kind of the automation that uh, people like me use to find, you know, CVE-related bugs.

All right. So I talked about port scanning and uh, you know, this should be a short slide. Uh, you know, most people are used to using Nmap for stability, extensibility, but not necessarily for speed. And in bug bounty, when you're attacking a large scope, you may need to go fast, or you don't want to wait for, you know, an Nmap, and you can tune Nmap to go really fast, but these days there are even faster tools than what you can get with the highest tuning in Nmap. So I actually recommend if you want a simple port scanner, you can use Project Discovery's Nabu. And if you want the fastest port scanner that exists today, um, SecMonkey wrote a whole side-by-side bake-off of all of the port scanning tools that exist, and RustScan is by far the fastest, two to ten times as fast as Masscan, which a lot of people use in their frameworks. And so really uh, really really useful if you're scanning a ton of domains and you want to go fast. So these are the two I recommend in the port scanning kind of realm, and you can check out the research at that link right there that he did where he pitted all the the port scanners against each other.

All right. So you've looked at your technology, you have, you know, probably noted it down somewhere, you've done some port scanning, you've probably scanned for some CVEs, hopefully you've built some of your own templates. Now what do you move on to on this site? Well, we're going to do some content discovery. This by far leads to more bounties than anything else I have ever seen in the bug bounty space. Effective content discovery is really, really, really important. Finding all of the endpoints and parameters that you can possibly find really leads to winning.

So there are a ton of tools that people use for content discovery or web fuzzing or whatever you want to call it, right? Wfuzz, ffuf, gobuster, Turbo Intruder, dirsearch, dirb, like there's like 20 tools in this space. Which one do I like? I like a new one called Ferroxbuster. We will talk about Ferroxbuster in a second, but these tools are only as good as the lists you feed them to do the brute forcing or content discovery, whatever you want to call it. And so this is my mind map of how I break down the different tools or the different lists for these tools inside of the industry. So if I am looking at IIS or a Microsoft framework or Azure, I choose uh, out of the wordlist.assetnote.io word list, which is a project that AssetNote puts up that they build. They build these massive word lists mostly from BigQuery, I think, I use the HTTP Archive, and I short-name lists. If I am going at something that's PGP or CGI-based, I use the hpr-dive CGI and underscore PHP lists. If I am going against a general API, I use the API routes and Swagger word lists, and then I also use one from Daniel Measler, which is on a set list called API Endpoints. If I am up against a Java app, I use JSP, JSPA, do, action, and if I am just looking at a generic app and I am done with the technology-specific brute forcing, I use the word list there. So this is how I choose my word list for different content. There are other texts that you can go against, and so just go to the AssetNote website for their word lists and and you can filter by different word lists to find paths and endpoints that they've seen associated to that technology.

All right. So what else is important in the content discovery space? Well, you also want to pay special attention to the frameworks you're going up against in their config files. So things uh, things like endpoints and files that give database configuration strings, these things are never supposed to be exposed to the public, but invariably sometimes they are. Sometimes there is some type of access rule that allows them to be exposed to the internet. Sometimes the site that went live on the internet actually was never supposed to be on the internet and wasn't configured properly. And sometimes these files can lead to big bounties, and you get lucky. So applicationsettings.json and asp.net site should never be ever exposed to the internet, but this is actually a screenshot from a bug bounty that somebody else scored, I can't remember who this one was, but uh, existed on the internet. So it helps, like some of the content discovery files I talked about in the last slide, they have these paths in them, but when you land on an app, it behooves you to go do the research of, you know, where is the database referenced, you know, the username and password referenced in the connection string, where's the configuration file, write it down, and every time you're testing a new framework, add it to your own word list and keep on iterating on your word list, so they're not just the generic ones everybody uses as well. There's also this idea—if you can find the source code for the application that you're hacking, if it's open source or if it's something else—you can build a word list out of the source code. So this is a tool called SourceToURL by Daniel Measler, good friend of mine, and this will take an install directory for an application, take all of the routes and endpoints, parse it down to a list for you, and then you can dynamically look for it through one of those other tools. This is also very useful if you can find an installed version of the application, if it's a COTS piece of application or if it's an open-source project, even if you know it's a sold piece of software. Uh, hot tip for that, uh, Docker, Docker Hub is where you can find a lot of people who have just dumped stuff um, online and and you can find it in a Docker container and reverse out the endpoints, pass, and sometimes source code.

The other thing that you can do is if you want to get a very detailed content discovery list for these tools for a piece of SaaS software or installed software, you can ask to just get a demo. A lot of sites will allow you to demo the site, and you can start building your content discovery list off of that. Sometimes if you want to spend the money, you can spend the money to buy the application, install it yourself wherever, and pull down the paths. And this is this gets a little bit deeper, and so you can find a lot of success when you have access to that kind of access to the application. Um, so there's also this idea of building custom uh, custom word lists based on the words that are present in the site that might be used to build endpoints. So there's a tool called Scavenger by @ox_dexterous that can build custom word lists. I don't use this all the time; every once in a while I use it, but it's a Burp plug-in. You pass in, you know, the domains you want, you go to Scavenger, and you click Generate, and it'll generate you a custom word list for uh, for your site, which might have like keyword terms that are relevant to only them. So like Twitch might have like a keyword term of like streaming or streamer or something like that.

So some other tools in this are historical content discovery tools. So one is called Gao. Gao is a tool that will go to AlienVault Open Exchange and the Wayback Archive and pull all endpoints and URLs it sees for your site from that database basically. And so you can use that to find a historical representation of what used to exist, what kind of URLs and paths, uh, and then you can build word lists uh, with that, um, and you can, you know, try to find those endpoints. You may not have found those endpoints, you know, during your manual spidering or something like that. So this is a new tool called um, called WayMore. It's kind of an extension of Gao, but it will also—not only pull from the API sources, and I really like this tool—it will not only pull from the API sources, but it will also download every single one of those archive pages from the Wayback Machine and also parse them for parameters, endpoints, and links. So it gives you a little bit of a competitive advantage if you're using this because you get a little bit more, hence the name WayMore. Another thing in content discovery that you want to think about is recursion. And so a lot of the tools will have recursion levels that you can run, but just as

An example, and this is actually from one of my bug bounties, is uh, is if you're not running a recursive tool where if you go to someapp.com and go to /admin, you get a 401. And then you see somewhere linked in the Javascript, maybe some_app.com/admin/dashboard, and you also get a 401. If you don't recursively brute force past where that says that dashboard, you're not really doing yourself a service. Because eventually, sometime in the chain of authorization, in some of these sites, especially for dashboards, people are using, you can get eventually like some kind of authorization bypass because they haven't coded the authorization correctly for that endpoint specifically. And so this has happened to me many, many times. It's actually recursion in content discovery is actually one of my biggest things that I run and do and get paid for, honestly. All right, so what else? Uh, one of my tips for finding endpoints related to a specific domain is parsing the mobile app.

Many times the top-level domain for an application that you're testing for a bug bounty will also have a mobile app, and they're also serving the mobile API from the same domain. So technically it's in scope, even if they don't say mobile apps are in scope. I mean, it's kind of like a, you know, like scope is negotiable, right? So, um, so I use APK Leaks for Android, and this will pull down all the endpoints out of a compiled APK file. Uh, and then I, you know, feed those into Burp, and it's, you know, a pretty simple tool. You just feed it the APK; you can go to any of those like APK stores that are public and grab the APK, and then it gives you all of the routes for everything related to the mobile app. All right, so if you want to be on the kind of the cutting edge, and I haven't used this yet, but it was recommended to me by a friend of mine, Patrick, who's a pretty good bug bounty hunter, um, you want to keep on top of change detection for these sites that you're monitoring. If you're going to plan to hack on the same target for a long time, and so there are some ways that you can kind of keep up to date on what an app or a company is doing. One is the target's newsletter; so subscribe to their newsletter, and they will tell you when they're, you know, developing or launching a new feature. Sign up for their affiliate program; their affiliate program gives you insider access often to the application before features launch. Google their conference talks, and when they tell you they're going to do something or they're building a new feature, get ready for it. Get ready not only for the endpoint that they're going to drop or the domain they're going to drop, but also testing the type of technology they're talking about. And then you can monitor domains for code changes with some degree of certainty with tools like changedetection.io, and that's the one Patrick kind of let me know about. I haven't used it much yet, but I plan to integrate it into my methodology on the next round. All right, so that's content discovery. Now we're going to talk about application analysis.

So like I said, this is not a talk about like me giving you some fuzz strings or showing you like an XSS payload or something like that; it's about how I look at an application. So when I'm looking at an application, I ask myself six questions. I think there's six here; hopefully, there's six. The first question I ask is how does the application pass data? Is it REST? Is it resource parameter and value? Understanding how the application passes data, um, is super important. Is it a web service? Is it the front end just like, you know, a single-page application that's sending a lot of API calls? Really, you need to understand your application, how it passes data, to be successful at all in any hacking. The second question I ask myself is how or where does the app talk about users? Does it talk about them in cookies and API calls as part of a parameter? Is it a UID? Is it via their email? Is it via a username? Or is it via UUID or GUID? And so understanding this early on will give you a lot of access to understand how you can do bugs like IDOR or different authorization bugs. So this is really important to understand right up front. The third question I ask is does the site have multi-tenancy or user levels? And most sites these days, most SaaS apps do. And so understanding if the app is designed for multiple users, does it have multiple user levels? Are there admin users? Are there regular users? Just tenant users, people who you can invite just to view a program or an application, a piece of data? And is there unauthenticated functionality? And this will give you another basis to look for a lot of bugs like IDOR, where you log in as an account viewer only and you can escalate to look at, you know, account user or account admin or things like that. And so for a lot of these types of bugs, I use tools like Authorize for my IDOR testing, but these are the core questions I want to ask myself when starting. All right, here we go, big talk, lots of tech. Uh, does the site—the next question I have, number four—does the site have a unique threat model?

And this is a contextual question about the app. So when you're looking at an app like twitch.com, you may look for the normal vulnerabilities everybody else looks for—injection and IDOR and access issues and all this stuff—but Twitch has some extra kind of surface area of things they're looking to protect. Like for Twitch specifically, your primary stream key is really important to keep private. Uh, it's an extra piece of data, not just your username or your credit card, normal things that go into SaaS apps. It has a custom surface area where you really do not want to leak someone's primary stream key. Every application has some kind of custom data like this that you want to include in your threat model. So instead of just asking to get the normal stuff like, you know, credit card number or date of birth or address or something like that, you can also say, what is an interesting way I could get at the primary stream key for Twitch? The next question I ask myself: has there been past security research involved? And so many times this has led me to basically testing a bug that was already tested; the customer implemented a patch, and then I am able to bypass the patch. Um, and so this is an example of me just what I do when I land on something like Tesla, right? I just Google Tesla vulnerabilities, and there's three main places you can Google them, and they'll be write-ups. Like Detectify has a write-up here on how they did DOM XSS on Tesla forums. Sam has one here where he blind XSS'd his Tesla, which was amazing, um, still one of my favorite bugs probably of all time. Put the blind XSS payload in the car; broke down; when the car broke down, it called assistance for Tesla, and the blind XSS payload triggered on the customer service panel of Tesla, which is like amazing. Also, you can get previous bug history from HackerOne and Bugcrowd; they both have histories for their programs, and the client decides how much information they will release about each bug, whether they give you a full URL or just a description of the bug, but it's a good place to do recon on previous issues they've had. Not only previous issues they had if you want to regression test that specific issue, but also just generally what kind of issues has Tesla had in the past. So this is something I do, um, in the kind of waiting periods where some of my tools are running or when I have downtime or whatever stuff like that. The last one is I look specifically into how the application framework of the application handles certain classes of vulnerabilities because they all have documentation on how the protections work because people want to know that when you're a developer. So how does the application handle XSS? Well, here you can see I'm looking at Laravel XSS protection. There's several articles about how Laravel handles cross-site scripting, CSRF, code injection, things like SQL injection, template injection for other technologies and things like that. So I start Googling this, and if I know right away that, you know, a certain framework has a pretty strong XSS handler or function protection function, then, uh, I might not prioritize that bug class when I'm testing the application. I will attempt to look at other bug classes that might be inherent. All right, so that's that section. So now we're going to talk about spidering, which is pretty simple; everybody knows that when you drop on a single domain, you have to spider it to understand all of the links you can see and parameters you can see. It's the basis of where you find your parameters to fuzz, et cetera. You can use two common proxies: ZAP and Burp for this. It's pretty simple; in ZAP, you do attack and spider; in Burp, you do scan, crawl. I choose cross-strategy fastest and never stop crawl due to application errors. I don't know if that's quite responsible, but that's okay. Then if you don't want to use the interception proxies, which are GUI tools, you can use two command-line tools. So HAT Crawler and GoSpider are two of my favorites to do command-line crawling. They also parse output of robots.txt files, anything they can pull from Javascript, et cetera. So if you want to bake in a spider into your automated tooling, these are the two I choose.

So the next section is Javascript, and this is also really important. So now you've looked at all of the endpoints historically, you've spidered, you have a lot of information about the technology, you have a lot of places where you want to fuzz, you have IDOR targets and authorization targets, and you're starting to build, at least in my area, a mind map of the application and the things I want to look at. The next place is parsing Javascript for endpoints. It's a form of content discovery, but basically you want to take all the Javascript on any domain—usually the Javascript files that are custom and not part of some framework, but sometimes you want the framework ones too—and you want to parse them to put them into your sitemap and find the parameters for them and either pack them or whatever. So LinkFinder was kind of the OG tool that everybody used for this method to a lot of success, uh, over the past like probably six years, five years. And my one problem with LinkFinder was that it would not parse inline Javascript. It would parse Javascript files, but not Javascript inline in the page that you were looking at. And so this is a new tool that I used by XML Hacker, who also had a previous tool in this area, and it does this; it will parse out inline Javascript. It has an improved regex for parsing out endpoints from both files and inline Javascript, and it is now part of my automation when I, uh, start looking at an application. So, uh, it is kind of the new hotness when it comes to Javascript parsing. You can also do it in Burp if you're a GUI user, right? Like I said, I like to give two methods. So XML Hacker has a tool called GAP, which is a Burp extension. You load GAP into Burp, and then it'll parse both parameters and paths that sees from all inline Javascript and Javascript files and put them back into your site tree. So super useful if you're—if you live inside Burp—like that's your go-to thing. All right, so the other last part of Javascript parsing for content discovery is, uh, is you have min—you have like minified or obfuscated Javascript. And most of the time you try to reverse this manually. I am like not the best at this, admittedly. Sometimes you can get a little cleaner from something like loading a Javascript file like that into like beautifier.io, but there is some tooling being worked on by Matsu right now which will dynamically recreate, you know, some obfuscated or minified Javascript for you in a readable fashion so you can pull out the paths. And so this research is still being done; no tools released yet, but he did release a release of proof of concept to, uh, to do this a month ago. I don't know where it's at right now, but, um, you know, keep an eye out in the space. All right, for Javascript libs and dependencies, I still use retire.js; it has the biggest database to tell you if a Javascript library is outdated and it has a vulnerability associated to it. It's a really nice tool. Now we're going to move into parameter analysis.

All right, so this is one of my hunting superpowers, and I think that when I released this data a long time ago, it kind of went underplayed, which was sad, but I did a DEF CON talk about it. And basically, uh, parameter analysis to me is, you know, where all the fuzzing input goes and where a lot of vulnerability classes stem from is is sticking stuff into routes or parameters. Now understanding which routes and parameters based on statistical analysis are most often vulnerable to which vulnerabilities is my superpower, and I built lists for this in a tool called Hunt that I released at a DEF CON talk, and this still remains to this day one of the most successful methods I use to target the right parameters. So what that project did is it took all of the customers on that platform that I was working for, took all of the vulnerabilities, and mapped them to parameters. And then we statistically, you know, rose the cream of the crop for certain parameter names or route names, uh, to the top. So here you can see insecure direct object reference, and these are the type of parameters that are most vulnerable to that class of vulnerability: ID, user, account number, order.key, email. And so this is really one of the superpowers I use when looking at an app's functions, parameters, and things like that. So other people have extended this research to take URLs and vulnerabilities from places like XSS.com or HackerOne's public disclosures. They then ported these lists to tools like gf, which will parse URLs, uh, for those parameters and give you just a list of where it saw it, uh, where it saw those parameters inside of a long list of URLs that you maybe got from somewhere else. So you can find this on like gf patterns, and but there's a whole bunch of sources for these this parameter analysis type content discovery. Now these are the links of all the projects I could find; a lot of them are rep, you know, like clones of each other; like they have the same parameters that were originally released by me many years ago, but some have new ones, which are really good. And so, um, what I would say is, uh, I am actually taking all of these and going to combine them into one super project called SusParams. I meant to do it before DEF CON, but I have three kids, and that didn't quite work out as I had planned. So, um, these are the repos that you can kind of pull those parameters from and keep an eye out for when they exist and how to parse them if you want to do this in Burp. Hunt was the tool that Bugcrowd released to do this, and it had those parameter lists in it. It is no longer maintained by me; I think there was a port that exists, but I'm not exactly sure if that's maintained anymore. There is one tool that still does it, which is called Burp Bounty; it's a paid tool; I think it's like 75 or something like this, but on top of adding more kind of active scan checks to your Burp, uh, scanner, it also will alert you when it sees any of these common parameters that are vulnerable to certain vulnerabilities. All right, the last section is called heat mapping, and it's very short. It's how I approach, uh, any target, and, uh, basically the places I look first for, um, when my spidey sense tingles is so heat mapping, you know, is this idea of like, you know, where things are happening or where they may be bad, um, you can call it hacker intuition or whatever, but I've tried to codify it a little bit because combined with the parameter analysis and heat mapping, it really helps me focus on where I think I should hack. Okay, so this is my mind map for heat mapping, and this is the thing I keep up on my desktop to remind me where I want to look. You can tell I'm a mind map guy because I just stuffed a mind map on the screen. Okay, so the six areas I look at first in any application: upload functions, usually vulnerable to injection, cross-site scripting, XXE, SSRF. Sometimes you can basically trick an upload function to shell a server, sometimes depending on what you—you know—what the technology is and what the parser is, and it'll also give you information on where data is stored for the application. So I check upload functions first for any given application. Content types; I filter Burp by all of the returning content types for the application. I want to look for multipart forms; I have it outlined in red because I have never met a multipart form that was secure. Multipart multipart forms always have some sort of vulnerability to them, um, whether you're shelling it or you're doing injection or, you know, somewhere in there; I've just never met one that that is secure. I look for content type XML for things where I'm going to try XXE, and I look for content type JSON to find the—sometimes the endpoints that give metadata about certain pages or also if there's a web service there that I can attack. The next section is APIs, which admittedly I'm not the best API hacker in the world, but I'm looking for that return of JSON data, looking at their APIs, trying to find hidden methods, so brute-forcing methods, and then lack of authorization on admin methods or methods that maybe shouldn't be accessible to a normal user or a user level that is lower privilege. The next section I look at is the account section, which contains most of the stored data on the web application. So I look at the profile for stored XSS; I look at custom application fields for stored XSS and server-side template injection if they're using a template engine. I look for integrations that the site does with third parties so I can smuggle in payloads through third parties into the app that I want to look at. Then I look at errors—actually, it's probably the last one I look at; I probably look at URLs first—so anywhere that the application references a path or a URL is where you want to look for for SSRF, basically. And this is like probably the—the one I do just as much as upload functions: redirection bugs, SSRF bugs, sometimes authorization bugs based on those two things. You can just filter and Burp on anything that—any parameter that references the path or URL. And the last place I look, just to be complete, is application errors through my spidering and using of the site and fuzzing it collectively. I run Logger in the background, and then I look at anything that gave me an exotic error that's not a default application error, and I check and see what triggered that error, and either I was getting close—I feel like sometimes those cases I was getting close to a good injection at some point—or I sent it something it didn't like, and if I do that a lot, I might be able to crash the app for an application-level DOS. And that's it. So that's my heat mapping kind of document for sites. And then what do I do to like track all this stuff and take notes and just like keep my brain organized? I use Notion, and you can see here that I just break up like the stuff I use often: fuzz strings, parameters that are often vulnerable; I just keep these in my foreground all the time. Um, you can see that I have like a SQL injection section, XXE; I've got notes for everything; I've got my seed discovery for recon; my syntax for certain tools that I use all the time. So this is how I keep up to date and just make sure that my growing knowledge base stays in my brain because you don't ever want to start a new project and then not have all of the knowledge that you built on your previous project. So that's a lot of stuff, um, basically a dump of of how I look for application vulnerabilities and how I break down apps, um, so what's next for this? It's already an hour-long talk, so I have to do a new version where I go into each specific bug class and talk about tools and techniques for each specific bug class. That's the next version, in 2.0. So I'll focus on SSRF, XXE, SQL injection, IDOR, and API bugs that I found before. That's more similar to some talks you're going to see today; people are just going to break down how they found certain bugs. I'm going to drop a new recon version of my talk, uh, in the next month, version 5 of the recon, and re-up all of the best recon tools that I think that the industry is using, and then a workshop for this associated to another conference coming up. And that's it. Thank you. Any questions? That was a lot. Sorry. Thank you, HackerOne, for having me, and I will see you guys around the event.