Skip to content

Latest commit

 

History

History
232 lines (178 loc) · 48.3 KB

recon-methodology.md

File metadata and controls

232 lines (178 loc) · 48.3 KB

My Full Bug Bounty Hunting Methodology - Recon

GOAL: Find Every Possible Target & Attack Vector

  • An Injection Attack Vector is the unique combination of the following four things in an HTTP Request:

    • HTTP Verb
    • Domain:Port
    • Endpoint
    • Injection Point

  • A Logic Attack Vector is one of the following four things:

    • Overly Complex Mechanism
    • Database Query Using ID From HTTP Request
    • Granular Access Controls
    • "Hacky" Implementations

Ebb & Flow - Your hunting should come "in" and "out" of this recon methodology like the ocean tides. Move down the list until you have 3-5 attack vectors on a target URL. Spend some time testing those attack vectors, but not too long. You can always return to them later. When you feel stuck, put a "pin" in those attack vectors and go back to an earlier part of the recon methodology. Try new tools/techniques, anything you can think of to expand your knowledge of their attack surface. Then choose 3-5 new attack vectors and try again. Repeat until you're a millionaire, or you need a break, whichever comes first.

Core Recon Workflow

Finding Apex Domains

SUMMARY: Some bug bounty programs have a "Wide Open Scope", meaning you are free to submit reports on any asset you find that belongs to the company. For programs like these, we don't have any domains to start with, so we need to discover Apex Domains as a starting point for our recon.

Example Programs:

Input: Company Name

  • Web Scraping - One of the easiest ways to discover Apex Domains a company owns is to use public resources on the internet. Tools like Shodan DNS Dumpster and Reverse WhoIs can be used find the majority of IP Addresses and Apex Domains owned by a company, but remember that all other researchers can easily access these as well. Be creative, think of all the places on the open internet a company may reveal a domain it owns. Finding an Apex Domain other researchers haven't can lead to a huge payout! The intel module in Amass can also be used to find the majority of Apex Domains known to belong to a company.
  • Google Dorking - Google Dorking is a fantastic way to get more targeted search results that may be missed by other researchers. Using tags like intitle:, intext, site:, and many more a bug bounty researcher can identify websites hosted on domains that may be missed by simply searching for the company itself. This blog does a great job of explaining how to leverage Google Dorking for a variety of bug bounty hunting workflows.
  • Cloud IP Ranges - I go into more detail about how to use this workflow (and my tool that automates it) later when looking for subdomains, but scanning Cloud IP Ranges can be a very valuable tool to find Apex Domains as well. Simply grab the certificate data and search for any domain that conains the name of the company (or another string that may tie the domain to the company).
  • Autonomous System Number (ASN) - If a company has any infrastrucutre in their physical location instead of the cloud, they will need external IP Addresses to allow users on the open internet to connect to those devices. To do this, the company registers a set of IP Addresses with an Internet Service Provider (ISP). That IP Address range is then given an ASN as an identifier and can be easily queried through public resources. For companies that host their own infrastructure, ASNs can be a phenomonal way to enumeration their external attack surface and find Apex Domains.
  • Acquisitions & Mergers - If a company allows you to test on any asset they own, it's a great idea to keep an eye out for any mergers or acquisitions the company makes. If the company purchases another company, the domains of the purchased company will immediately become in-scope for the program. For public companies, these activities will be highly publicized. You can sometimes track these events through tech news agencies and respond accordingly. Websites like Crunchbase also provide a wealth of valuable information on companies, especially start-ups that have not yet gone through IPO.
  • LinkedIn + GitHub - One of my favorite techniques for finding hidden Apex Domains is to use a combination of LinkedIn and GitHub. Obviously searching GitHub for the company name (or other identifiers) can be a great way to search, but I prefer to be a bit more targeted and sneaky. First, use LinkedIn to find developers and other engineers that work for the target company. Use those profiles (if possible) to find their personal GitHub account. You would be shocked at how often developers test code on their personal repos, even if it connects to live domains. Look for any domains contained in their code that may be associated with the target company. Again, you'll be shocked at how often this actually happens.
  • Marketing & Favicon - Tracking cookies and Favicons can also be used to identify apps that belong to the target company. Basically, if you find another application using tracking cookies with the same ID or using the same Favicon as applications known to belong to this company, it's very likely to be owned by the target company.

Output: List of Apex Domains

Finding Live Web Applications

SUMMARY: Each apex domain in scope will have several subdomains available that host their own web application or service. Your goal as a bug bounty hunter is to find as many of the available subdomains as possible. Once you have a list of subdomains from a wide range of techniques, you will need to consolidate them into a single list of unique subdomains. Keep in mind that these domains point to IP Addresses, and applications may act differently if you access them by their IP directly, so the next step is to resolve the Fully-Qualified Domain Names (FQDNs) to the IP Address(s) they point to and add those to the list of possible targets. Finally, applications may be running on those targets outside of the normal web server ports 80 and 443, so scanning for open ports can help find targets that other hunters miss. At this point, you will have a list of unique FQDNs and IP Addresses/Open Ports. Probe each target on the list with HTTP Requests to identify which of the targets is currently hosting a live web application.

Input: Apex Domain

  • Apex Domain -> List of Subdomains
    • Amass - Amass (by OWASP) is the backbone of my recon methodology at this stage. It does many of the steps below in one tool, as well as DNS and ASN discovery. Amass typically finds 80% of the total subdomains I discover, but keep in mind that everyone else can easily use Amass as well. When it comes to recon, the bugs are at the far ends of the bell curve.
    • Web Scraping - Your goal here is to discover as many subdomains as you can using public resources on the web. Resources can range from public search engines like Google to APIs that maintain certificate registration data. Always try to be creative and find new ways to scrape public web sources for sudomains. If you can come up with a technique that no one has thought of, you might find subdomains no one else has tested.
    • Brute Force - Brute forcing for subdomains is fairly simple and exactly what it sounds like. Simply take a wordlist of possible subdomains and attempt to resolve the full domain with each subdomain in the wordlist.
      • ShuffleDNS
      • CeWL + ShuffleDNS - CeWL crawls a website and builds a wordlist dynamically based on the most commonly used words in the target app. Using CeWL to build a word list, then passing that list to ShuffleDNS, can be a great way to find subdomains that follow a naming convention that might show up in the DOM.
    • Link Discovery - At this point, you will have a list of subdomains that could point to live web application. For the next stage of recon, you will use tools to crawl the subdomains that point to live web applications. To do that, you first need to consolidate your list of subdomains and identify which of the FQDNs points to a live web app. There's more information on how to do that in the list below, but remember that you need do this twice: Once before Link Discovery, and once at the end after all other tools have completed.
    • Cloud IP Ranges - I've built an automated tool called Clear-Sky to do this. Keep in mind that loading the certificate data can take over 24 hours, depending on your Internet speed.
  • List of Subdomains -> List of Live URLs
    • Resolve Subdomains to IPs - Now that you have a list of subdomains, you can resolve each of them to identify the IP Address of possible targets. Keep in mind that this is very prone to false positives, so you need to manually verify each of the IP Addresses before you start testing. If the target's infrastructure is on-premises, make sure the IP is included in the CIDR Ranges of the ASNs. If their infrastrucutre is in the cloud, it's very possible that their IPs are not static. Manually verify by accessing the IP address directly through the browser (Example: https://192.168.1.1). By accessing the application by the IP directly, you may be able to bypass security controls or cause it to act differently than it would if you had accessed it throught he domain. This also changes the Host Header, and may allow you to access a new application altogether.
    • Port Scanning - Once you've got a valid list of IP Addresses that are confirmed to belong to the target, you can run a port scan to see what other services might be available to an attacker. Ideally, you can find a web application running on a different port, such as 8080 or 8443.
      • DNMasscan - This tool resolves the IP Address and does port scanning. Just remember to verify the results before testing.
    • Consolidate - As I mentioned before, you'll need to write an algorithm that consolidates the subdomains into a list of unique subdomains. You should also verify that all the subdomains belong to the original Apex Domain. Many of these tools, especially the crawlers, will return domains that are not "in scope".
    • Test for Live Web App - Finally, you can test your list of unique subdomains/IP addresses/ports to find which of those are pointing to a live web application. The two tools I use to do this are httprobe and httpx.

Output: List of URLs Pointing to Live Web Applications

Choosing Target URLs

SUMMARY: Now that you have a list of URLs pointing to a live web application, you'll need to decide which of these targets is worth your time to manually test. There are several signs that a target application may be worth your time, but ultimately you are looking for a target that has the greatest likelihood of having a valid vulnerability. Outdated NPM Packages, expired certificates, or an old copyright might mean a web application hasn't been maintained by the company and could be vulnerable to newer attack techniques. Targets that are deep into recon and very difficult to find will be missed by other researchers. New features or domains also may not have been tested by other researchers. Over time, you will build up your own list of "signs" that tell you a target may be vulnerable. Choose two or three at first, then move on to the next step. If you get stuck, come back to this step and choose a few others, then try again.

Input: List of URLs Pointing to Live Web Applications

  • Wide-Band Scanning - Before you start looking into each application one by one, you can start to narrow your search down by using automated tools that scan each URL for thousands of known vulnerabilities and misconfigurations. Not only can this be a way to find bugs (although it's rare since everyone does this), but the results of these scans can help you identify an application that is not being well maintained. The more high impact findings you have on a target, the greater chance of finding other bugs when you being to do manual Injection/Logic testing.
    • Nuclei - Nuclei by Project Discovery is the backbone of my vulnerability scanning methodology. Not only do that have a TON of great templates already created, but you can create your own with a simple YAML file. I will go into more detail about building custom templates to find bugs other researchers are missing in the CVE Spraying section below.
    • Semgrep - Semgrep is a phenomonal open-source Static Code Analysis Tool (SAST) that uses Abstract Syntax Trees (ASTs) to evaluate application code and identify patterns that could be exploited by an attacker. For most bug bounty programs you won't have access to the application's server-side code, but you still have access to the client-side code. Run all client-side JavaScript through Semgrep to identify any possible DOM injections or other code patterns that might show the application would be a target worth your time. If you're lucky when evaluating a React app, the developers did not properly obfuscate the webpack, meaning you can download all of the raw React files and scan them for known vulnerabilities using Semgrep.
Youtube Thumbnail
- **Choosing an App Worth Your Time** - Now that you have a picture of what vulnerabilities and misconfigurations exist in each app's attack surface, you can start to dig into the app itself. There are an infinate number of things that you could be looking for, and there's really no way to standardize this part of the methodlogy. Ultimately, you need to decide on a few URLs pointing to an app that gives you the greatest chance of finding a bug. This is a skill you have to develop over time, there's no substitute for hard work and experience here. Once you start to find and submit valid bugs, you will be able to tie those bugs to what you saw in the app and that will become a "Pointer" for you in the future. When you see the same configuration, you will check for the same vulnerability. Over time you will build up a list of many Pointers and this step will become much easier. Remember, just like when you're working out to build muscle, if you're not pushing yourself you won't grow. The feeling of being frustrated means you are growing, just like the feeling of pain in your muscles means you're building muscle. Embrace the frustration, dive into it head first, and push through it. - Screenshots - This is one of the quickest and easiest ways to find target apps that might be vulnerable. Look for major variations, error messages, development environments, etc. - [Nuclei](https://github.com/projectdiscovery/nuclei-templates/blob/main/headless/screenshot.yaml) - Nuclei has a headless browser template that does very well at taking screenshots. - [EyeWitness](https://github.com/RedSiege/EyeWitness) - In addition to taking screenshots, EyeWitness also gathers information about the target application that can be useful. If you want something a bit more robust than the Nuclei template, this is my go-to tool. - Tech Stack - It's always a good idea to test against applications built using technology you are familiar with and enjoy testing. If I see a URL pointing to an app built in the [MERN stacks](https://www.mongodb.com/resources/languages/mern-stack) and hosted in AWS, I'm excited to jump in! On the other hand, if I see .NET apps hosted in Azure, I'll probably save that one for later. - [Wappalyzer](https://www.wappalyzer.com/) - [BuiltWith](https://builtwith.com/) - [NPM Packages](https://www.w3schools.com/nodejs/nodejs_npm.asp) - NPM Packages are public JavaScript libraries that are used to supplement custom application code. As always, you won't have access to the NPM packages the developers are using on the server-side, but you can easily enumerate all of the client-side NPM packages. More importantly, you can identify the version of these packages, as well as if that version has any known vulnerabilities. *Remember, just because an NPM package has a known vulnerability, **it does not mean that vulnerability exists in the target application**. That vulnerability will almost always be in a single [method](https://www.w3schools.com/js/js_object_methods.asp) in the package. If the developers do not use that method, they are not vulnerabile to that CVE.* However, even if it's not vulnerable, a target application with outdated NPM packages can be a great sign that an application isn't being well maintained and may have other vulnerabilities. - [https://github.com/RetireJS/retire.js](https://github.com/RetireJS/retire.js) - [Certificates](https://www.cisa.gov/news-events/news/understanding-website-certificates) - Any target application that has issues with their certificate could point to an application that's not being actively maintained. Or, even better, it's a test/development app that the company was *hoping* you wouldn't find. Just remember that appending the port to the end of the URL can lead to false positives. If you access https://floqast.app:443, you will still access the same application, but the certificate will not include the port and cause a false certificate mismatch finding. The browser corrects this issue for you, but scanning tools like Nuclei will not. - [Expired Certificate](https://sematext.com/glossary/ssl-certificate-expiration/) - This could show that the application is not being actively maintained. Check any dates you can find to confirm. - [Mismatched Certificate](https://www.globalsign.com/en/blog/what-is-common-name-mismatch-error) - This could show that the app has recently gone through a domain change. There could be a lot of other massive changes happening at the same time. This could be a great candidate for future bugs. - [Self-Signed Certificate](https://www.entrust.com/resources/learn/what-is-a-self-signed-certificate) - These are my favorite! You know something has gone wrong here, a self-signed cert should never be public. It's very likely this is a dev/test app that has not gone through any security testing. Go nuts!!

Output: List of URLs Hosting Web Applications Worth Your Time

Enumeration

SUMMARY: Now that you have a few target URLs worth your time, your goal is to find an Attack Vector. First, crawl and use brute force to identify all available endpoints. Test each of those endpoints for parameters, Headers, Cookies, and valid HTTP verbs. You should be able to identify four or five Attack Vectors that might be vulnerable to an injection attack. Do the same for data and code stored on the client-side, as well as any mechanisms, roles, or database queries that could possibly be vulnerable to an injection attack. Now you're ready to take those attack vectors and thoroughly test them using the Injection or Logic methodologies.

Input: URL Pointing to Live Web Application Worth Your Time (Target URL)

  • Injection Attack Vectors - If you are interested in testing for injection vulnerabilities, focus your efforts on enumerating the following four data points. Remember that all injection vulnerabilities happen because user-controlled input is not properly sanitized before it is processed by the application. It doesn't matter if the injection occurs in the client-side, server-side, or database. All injections are caused by user-controlled input in the HTTP request that, when processed by the application, causes the app to act in a way the developers did not intend. That behavior (and the impact of the vulnerability) changes dramatically based on where the injection occurs, but how we got there is always the same.
    • Endpoints - I prefer calling them endpoints, but they are also called routes or paths. Either way, this is the part of the URL that points to a unique piece of the application. For example, navigating to https://floqast.app/login loads a page with a form to log into the application. However, navigating to the https://floqast.app/login/soo endpoint loads an entirely different form that allows the user to log in through a Single Sign-On (SSO) implementation. Your goal here is to find all available endpoints to give yourself the greatest chance of finding a valid bug. If you can find endpoints that other hunters miss because you're being creative, you will be the first to test the mechanisms on that endpoint, greatly increasing your chances of finding a vuln.
      • Manual - The first step you should take is to manually click through the application to find all the endpoints the developers expect you to find through typical navigation. These will probably be tested the most by other researchers, so it's good to get a picture of the app before you start fuzzing for hidden endpoints.
      • Automated Crawl - Next, use an automated crawler to make sure you didn't miss anything when manually crawling the app. Automated crawlers will pull endpoints out of client-side JavaScript and other places a typical user may miss.
      • Fuzzing For Endpoints - Finally, you can use a brute-force technique to test the application for hidden endpoints. It's as simple as loading a wordlist of possible endpoints and looping through them, making an HTTP request for each word (Ex: https://floqast.app/word_from_wordlist).
    • Parameters - Now that you have as many endpoints as you can find, you'll want to test each of them to find all the possible ways user-controlled input can be submitted to the application. In most cases, the best targets for injection attacks are parameters. Parameters are added to an HTTP request, either at the end of the URL or the body of the request. Parameters are user-controlled input that you know is processed by the application in some way.
    • HTTP Verbs - For some reason, this is an area of enumeration I see many researches missing. Each endpoint you discover will have an HTTP verb associated with it. Most will be GET requests to READ data from the database, but some (like form submissions) will be sent via a POST, PUT, UPDATE, PATCH, etc. These requests will contain a body with additional parameters is a specific MIME type. You should test each endpoint for every possible HTTP verb. It is very common to find endpoints that take multiple HTTP Verbs and have completely different functionality. This is why the HTTP verb is part of determining whether an attack vector is unique.
    • Headers/Cookies - Finally, spend a bit of time fuzzing for hidden Headers and Cookies. In some cases, these can be used as attack vectors for injection attacks. Finding hidden headers or cookies may also give you access to functionality that isn't meant for typical users. Maybe it's legacy code that was never removed because the developers simply stopped the header/cookie from being sent? Or maybe it's a debug function that wasn't removed before it was pushed to prod? These things happen all the time and can easily be found by sending HTTP requests with additional headers/cookies and looking for a variation in the server's response.
  • Logic Attack Vectors - If you are interested in testing for logic vulnerabilities, you will need to deeply understand the application. Before you invest that time, though, make sure that the app is complex enough to justify the effort. Just like with injection vulnerabilities, you are trying to find an attack vector. Instead of user-controlled input in the HTTP request, logic attack vectors come from developers not following best practices and/or building overly complex systems. Developers are almost always under a lot of pressure to deliver new features quickly. When a vulnerability reaches production, it's not that the developer was lazy or didn't care. They simply opened a ticket that said they needed to build a feature that does XYZ, then they wrote the code that accomplished that goal as simply as possible and moved onto the next ticket. They were probably also building a service that was part of a long chain of different services sending data between each other, all built by different development teams. This complexity is where logic vulnerabilities can be found.
    • Dev Tools - Looking through the data in the Developer Tools of your browser can be a great way to quickly find out if the developers are using best practices.
      • Client-Side Data Storage - Developers have the option of storing data in the client's browser through mechanisms like localStorage and sessionStorage. While these can be a great option for improving an application's performance or building new functionality quickly in a Single-Page Application (SPA), there are significant security risks to using these storage options for sensitive data. If you find an application that has a large amount of data in either localStorage or sessionStorage, especially any sensitive data, that's a great sign that this application is worth your time.
      • Cookies & Cookie Flags - Next, you will want to look through the cookies stored in the browser after you have logged in. Keep in mind that applications without authentication are not good targets for logic testing because you will be kept away from most of the mechanisms you will need to test. Once you've logged in, look through the cookies and identify any that are used to establish a session. For each cookie that is used to establishe a session, check for the following:
        • Data Stored in Cookie - Some cookies contain data that can be read in plain text, often after a bit of decoding. Cookies that contain data are most commonly encoded using Base64. The most well-known example of this is a JSON Web Token (JWT).
        • Cookie Signed for Integrity - If you find a cookie that contains data, check to see if that cookie has been signed for integrity. If not, the data in the cookie is a great target for injection & logic attacks. If so, be sure to check that it's being validated at every endpoint, not just at one point in the application. Don't assume the developers are running every HTTP request through a single point to verify the signature, that's best practice but in reality there will always be edge cases.
        • Secure Cookie Flag - The secure cookie flag prevents the cookie from being sent through unencrypted HTTP traffic. Lack of a secure flag on a session token may make it easier to leak a victim's valid cookie.
        • httpOnly Cookie Flag - The httpOnly flag prevents client-side JavaScript from accessing the cookie. Session cookies without this flag can be easily stolen through client-side injection attacks like Cross-Site Scripting (XSS).
        • sameSite Cookie Flag - The sameSite cookie flag helps prevent Cross-Site Request Forgery (CSRF) attacks. This cookie can be set using three options: strict, lax, or none. If the target application's session token is set to none, than CSRF attacks may be possible.
      • Client-Side JavaScript - You can learn a lot about a target application and the developers that built it by how the client-side JavaScript is developed/maintained. This code can contain a wealth of information about the application, especially for Single Page Applications (SPAs).
        • Check for the following:
          • Webpack Serialized/Obfuscated?
          • Client-Side JavaScript Readable?
          • Custom Client-Side JavaScript Files?
          • Secrets/API Keys Stored in JavaScript?
          • Find API Endpoints in Client-Side JavaScript?
        • Secure State:
          • Webpack is serialized and obfuscated properly so you cannot download the raw React (or other framework) code
          • Client-side JavaScript is Minified so it cannot be easily read
          • No custom JavaScript files on the client-side, only updated NPM libraries that have been thoroughly tested
          • No API keys or other secrets are stored in plain test in the client-side JavaScript
          • All API endpoints identified in the client-side JavaScript are easily found through typical navigation
        • Insecure State:
          • Webpack is not serialized/obfuscated, can be downloaded using a tool like JS Miner
          • Client-side JavaScript is easily readable by a human without any additional steps
          • Custom JavaScript files are used, meaning they have not been thoroughly tested like an NPM package would be
          • API keys or other secrets are found stored in the client-side JavaScript, ven if they are not sensitive secrets or keys, this still shows a failure to follow best practices and could point to bigger issues
          • Hunters can identify hidden API endpoints in the client-side JavaScript code to expand their attack surface
      • State/Props - Finally, if the application is using React on the front-end, use a browser extension like React Developer Tools to view data stored in the framework's Virtual DOM. Developers often forget that these values can easily be read by the client and will store data that can help a bug bounty hunter learn more about how the server-side works, or possibly even exfiltrate sensitive data.
    • Mechanisms - A mechanism in a web application is a series of HTTP requests that performs various CRUD operations that accomplish a specific task. When looking for logic vulnerability attack vectors, look for mechanisms in the application that meet the following criteria:
      • Complex - The more HTTP Requests, parameters, etc. that are required to make up a larger mechanism, the greater chance that something can go wrong.
      • Sensitive - As a bug bounty researcher, it's not enough to simply find a vulnerability in a web application. You need to also demonstrate the impact of that vulnerability. To show impact, you almost always need to show how your finding can have a negative impact on the application's customer data. So, for each mechanism you identify as an attack vector, be sure you can clearly explain how you can weaponize that mechanism to negatively impact customer data.
      • Examples to Get You Started:
        • Password Reset Mechanism
        • SSO/OAuth Authentication Mechanism
        • File Upload Mechanism
        • Online Shopping Checkout/Payment Mechanism
    • Access Controls - In web applications, Access Controls are a set of rules dictate what mechanisms a client has access to. These rules are defined based on different criteria, such as a Role or whether a client has been added to a specific Group. You'll need to do this part of your enumeration in two steps. First, identify the Type of access controls that are being implemented (there could be many). Once you've identified the type, you can identify all the ways a client could potentially bypass these controls. Once again, complexity = vulnerabilities. The more complex the access contols are, the more difficult it is for developers to enforce them.
      • Role-Based Access Control (RBAC) - This is the most common type of Access Controls. Applications will often have roles like Admin, User, Super User, etc. that allow granular permissions for each of the roles. All user accounts with that role applied can leverage the mechanisms that role has access to. In this case, you will want to see if you can execute mechanisms outside of the role's scope, especially if the mechanism is only accessible by a role with greater priviledges (User -> Admin).
      • Discretionary Access Control (DAC) - With DAC, a user is given explicit permission to a set of mechnaisms, usually part of a larger section within the application. For example, FIGMA allows users to create Figma Boards that enable collaboration for designers and developers. Once a user has created a Figma Board, they can invite other users to the board. Those users can then invite other users (if the Admin allows). If a user that has not been given an invite to the board can access the data on that board, they will have bypassed the DAC implementation.
      • Granular Policy-Based Access Controls (PBAC) - PBAC allow the developers to assign very granular permissions to individual users. These permissions are typically related a specific CRUD operation. For example, a user may be able to CREATE and READ a Figma Board, but that user is not allowed to UPDATE (modify) or DELETE that board. These granular permissions would be assigned by the owner of that board and could be changed at any time. This type of access control can be incredibly difficult for developers to enforce and are great targets for bug bounty researchers.
    • Database Queries - Finally, look through the application to find database queries that you may be able to manipulate in a way that allows you to access data you should not have access to. Keep in mind you're not looking for the possibility of a database injection, so you don't care if the endpoint sanitizes malicious characters before making the query. Instead, you are looking for database queries that are not validating that the client should have access to the data before returning the data to the client. Your goal is to find database queries that use a single identifier (ObjectID, UserID, Email, Username, etc.) to pull a larger dataset from the database. If the single identifier is controlled by the user in the HTTP Request, this is a great opportunity to test for Insecure Direct Object References (IDORs).

Output: List of Attack Vectors Worth Your Time

Findind Bugs w/ Recon

SUMMARY: Once your recon is complete, you should have a huge amount of data about the target's attack surface. Instead of moving on to manual testing, some bug bounty hunters may prefer to use this data in combination with additional automation scripts to find bugs without any manual testing. Below are a few examples of how this can be accomplished.

Leaked Secrets (In-App)

Input: URL Pointing to Live Web Application Worth Your Time (Target URL)

  • There are several places in a web application where sensitive data can be leaked. For bug bounty researchers who prefer to focus on a Recon Heavy or Future Bugs methodology, finding and reporting these data leaks can be a fantastic way to generate passive income. Keep in mind that you either need to be very fast or very creative here to find vulnerabilities other researchers are missing. Everyone can download an open-source took and scan applications for leaked API keys (just an example). You either need to find and report them first, or find ones that others are missing. It's much easier to be creative than fast, in my opinion, but to each their own!
  • Data Leak Examples:
    • API Key stored in client-side JavaScript
    • Developers return full user object, including Password Hash and Salt, of all users within an instance of the application
    • JSON Web Token (JWT) leaks server-side "seed" used to generate randomness, allowing attackers to predict behavior that should be random
    • An array of all user messages in a chatbot, including private messages belonging to other users, are stored in State/Props of the React Virtual DOM
    • An application's webpack is not properly obfuscated, showing how to access hidden debug API endpoints
    • The current user's plain-text username and password are stored in localStorage for a better User Experience (app has an issue with logging users out, so the devs decide to store the username and password to send in a new API login request to make a better user experience)

Output: Data Valuable to an Attacker

Leaked Secrets (Web Scraping)

Input: Company Name

  • There's a famous joke in the engineering industry that senior engineers are just really good at "Googling". And while that's obviously not the case, there is some truth behind the joke. If you've never been a developer, I'll let you in on a little secret: developers don't memorize the code patterns they write. As engineers work to build an application, they are constantly looking through documentation and public resources to identify/troubleshoot code patterns. Inexperienced developers sometimes even post code snippets to ask for help or use public storage services to share code. This is one example of where you can find secrets that might have leaked. Below are a few examples of public resources where you may find leaked code or secrets:

Output: Data Valuable to an Attacker

Leaked Secrets (GitHub/GitLab)

Input: Company Name, Employee Names, Company GH Org

  • For anyone with development experience that wants to make money bug bounty hunting, this is the perfect place to start. Code repositories like GitHub/GitLab are used by developers to store their code and faciliate collaboration with other developers (among many other benefits). If you have the ability to read code and understand how it works, you don't need any additional offensive skills to find bugs with this technique. Your goal is to find sensitive data/files that are available on a public repository. There are several ways that this can happen, here are a few examples:
    • Public Repo on Company's Official Org Account - All software comapnies will use a code repository service in some capacity. In most cases, their repos (and even their org account) will be private. As a bug bounty hunter, your goal is to find a repository that should be private but was accidently set to be public. Keep in mind that this won't always be a vulnerability by itself, you still need to find a way to demonstrate that this code being public can be used by an attacker in some way. Usually, this will take the form of a leaked API key or some other secret in the file. However, if the knowledge of the code can be used to circumvent an existing security control, this can also be a great way to show impact.
    • Repo on Software Engineer's Personal Account - This is another one of my favorite ways to hunt for bugs. You would be shocked at how often developers use their personal accounts on code repository services to test/store code for their organization. Maybe they are new to development and are self-concious about their code, so they want to test on their own first? Maybe they are a contractor that doesn't have the skills to complete a job, so they secretly set up another repo to collaborate with a more skilled contractor and complete the job? These are just a few examples of the "why" behind these vulns, but the goal is the same. The easiest way to look through the private accounts of developers for a specific company is to search GitHub/GitLab for any accounts that declare that company as their place of work. Those are easy to find, though, and remember that bug bounty hunting is all about being creative and finding things other hunters aren't looking for. Be creative! LinkedIn can be a great place to find software engineers for a specific company, even if they don't list their employment on GitHub/GitLab.
    • String Search + Code Types - Another way to find leaked GH source code is to simply search for the name of the company (or an Apex Domain) in the code of all public repos. You will find a lot of false positives, but you may also find public repos that other researchers miss. To narrow your search down, look for files written in specific languages. For example, any repo that has starbucks.com and is written in bash or python (scripting language). The hope is that an engineer at Starbucks has written a priviledged script with hard-coded API keys and/or passwords. This style of hunting can be time consuming, but it's not uncommon to find a High/Critical bug hiding in the large number of results.
    • String Search + Wordlist - In addition to searching for specific languages to narrow your search, you can combine the simple string search in code patterns with another string from a wordlist. For example, any code patterns that contain starbucks.com and also have the string password. I have a tool available on my GitHub that automates this process and has a wordlist that I have found a lot of success with.

Output: Data Valuable to an Attacker

CVE Spraying

Input: List of URLs Pointing to Live Web Applications

  • A Common Vulnerability Enumeration (CVE), is a formally identified and registered vulnerability in a specific application or protocol. There are two specific hunting styles that I use CVE Spraying for: Recon Heavy and Future Bugs. Which ever hunting style you choose, the goal of this technique is to find known vulnerabilities or misconfigurations in a target's external attack surface.
    • Recon Heavy - Your goal here is to find CVEs in parts of the attack surface that other researchers aren't scanning. Continuously work to impove your team's ability to identify new attack vectors, then feed those back into wide-band scanning tools like Nuclei. CVE's in an external attack surface are one of the easiest way for bug bounty hunters to find vulnerabilities, but that means just about everyone is doing it. You need to find domains/applications/infrastructure/etc. that others are missing.
    • Future Bugs - Here, instead of looking for attack vectors others are missing, your goal is to test for new CVE's before any other researcher can. This means you will need to build your own tests for the vulnerability. You will need a lot of technical skills to accomplish this, but it can put you miles ahead of other researchers. The process goes like this:
      1. New CVE is announced that could effect a bug bounty program's external attack surface. Look for CVE's in NPM packages, cloud services, infrastructure, Content Management Systems (CMS) like Wordpress, etc.
      2. Build a way to identify the CVE as quick as possible. You can either do this by writing a custom script, or you can use a tool like Nuclei and simply build a custom Template. You have to be quick since companies like Project Discovery have teams of engineers to build these checks when new CVEs are released, but large companies also have a long to-do list they have to prioritize. A small team of researchers can easily beat larger companies to building these scan checks if they are highly technical.
    • Both At Once (GOLD STANDARD) - Focus on one of the two hunting styles at first, but once you get a good handle on one, you can incorporate the other. If you and your team can get to place where you are finding attack vectors others are missing and you are hunting for new CVE's before others are testing for them, you will be miles ahead of other bug bounty hunting teams!

Output: Valid CVE Found on Target's Attack Surface