Bug Bounty Phase 2 - Recon

In this short blog we discuss Bug Bounty Recon to find assets which may be vulnerable to our exploits.

Bug Bounty Phase 2 - Recon
Photo by Matias Luge / Unsplash

Reconnaissance (Recon) is arguably the most important phase of Bug Bounty hunting. This is where you find assets to explore for vulnerabilities based on the bug programs scope. In general, this is the simple methodology to target

  1. Understand the programs scope
  2. Find domains and sub-domains
  3. Find Pages, Directories and Files

The Scope

Firstly, understanding the scope is a vital step to starting recon. As mentioned in previous blogs, ideally you want to target wildcard domains such as *.test.com and not small scope programs like dev.test.com.

To quicky recap, this is because the wildcard *.test.com could include dev.test.com, but also uat.test.com, prod.test.com and more. In general, the wider the scope, the more assets you will find to test and more potential issues are present.

Some programs may provide you autonomous system numbers (ASN). These are typically given to huge companies that own large IP Address spaces. In this instance, the world of discovery could be huge and full of bugs to find.

Asset Discovery

The below presents where to begin with asset discovery based on your given target.

ASN Discovery

Should you be starting with an ASN, you can use tools such as ASNMAP to find associated IP Addresses. From the projectdiscovery blog, here's an example:

$ ./asnmap -silent -a AS394161

As seen above, this tool produced a number of IP Addresses that you can then use to find any associated domains. For example, you may use these IP Addresses with:


Whois is used for querying internet resources for a variety thing things. In our case, we can use WHOIS to return databases of domain names relating to an IP Address. There are many Whois providers out there which can help us do this, but here are three examples:

Reverse DNS

In DNS, pointer records (PTR) are used for the exact purpose we want. To reverse DNS lookup and match domain names with IP addresses. dnsx can help with this.

echo AS17012 | dnsx -silent -resp-only -ptr


Sub-domain Discovery

Once you have gained a list of domains from the ASNs or if you are starting out with a wildcard domain, you will want to start running sub-domain discovery tools such as:

These tools query search engines like Google or Shodan, perform DNS zone transfers, review TLS information and conduct brute forcing to find sub-domains.

You may wish to use multiple tools in your methodology to ensure you cover the targets as best as you can. The important thing to remember here, is Wordlists make a difference. Try various Wordlists and not just the in-built ones. You should also consider rerunning the tool on any newly found subdomains.

Subdomain Wordlist Creation

We mentioned about creating your own wordlists and not simply using the in-built tool wordlists. This is because every target is different, generic wordlists are a good start but they attempt to enumerate thousands of unrelated subdomains which wastes time and causes pointless resource usage for the target servers.

This is where a tool such as Alterx comes in. Alterx can be configured with a pattern and when run against one or more target domains, it will generate a custom wordlist based on the pattern and also based on the words present within the already known domains (using -enrich). This can then be used with a tool like httprobe to verify if the domain permutations are valid gaining you potentially hundreds more targets for bug hunting.

The example below shows the generated permutations for our own blog:

Alterx showing subdomains
Alterx Example

Content Discovery

With a range of subdomains identified, you can begin content discovery. This is where you will try to find pages, directories and files which could lead to finding undocumented sensitive or vulnerable functionality. You will also find information about used technology stacks and other related information.

Pages, Directories and Files (Active Recon)

There are many tools you can use to find content. Active recon is likely to be the most effective way of finding content but to do so, you need to interact with the in-scope servers which may take large amounts of time. This is called active recon and here are some tool examples:

Again, the important thing to remember is Wordlists make a difference. Try various Wordlists and not just the in-built ones.

Passive Recon

Passive recon is conducted when what you do doesn't interact with the in-scope targets. Here are some examples:

  1. Using WayBackMachine and other databases with Gau. This can help find old, unused but still present parameters and pages.
  2. Using Shodan or Censys to find service information
  3. Google Dorks to find Passwords, API Keys, vulnerable pages and more
  4. wappalyzer or BuiltWith to find JS libraries, web servers, CDNs, etc

Service Discovery

To complete the picture of what a domain presents, you may review its port and service information. After many years, nmap still is one of the best tools to find this information. It can do port scanning and banner grabbing to see the types of running servers.

nmap -O -v test.test.org

Starting Nmap ( https://nmap.org )
Nmap scan report for test.test.org (
Not shown: 997 closed ports
22/tcp    open     ssh
443/tcp    open     https
8443/tcp   open ldp

Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6.39
OS details: Linux 2.6.39
Uptime guess: 1.674 days (since Fri Sep  9 12:03:04 2011)
Network Distance: 10 hops
TCP Sequence Prediction: Difficulty=205 (Good luck!)
IP ID Sequence Generation: All zeros

Read data files from: /usr/local/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 5.58 seconds
Raw packets sent: 1063 (47.432KB) | Rcvd: 1031 (41.664KB)

What you are more interested in here is forgotten or misconfigured services, as well as development environments. For example, you may find a production web service on port 443. But you may then find a development version on port 8443.

Development environments are less secure and could lead to critical bugs.

See the next part of our Bug Bounty Phase blogs:

Bug Bounty Phase 3 - Vulnerability Assessment
In this short blog, we discuss the tools and continuous learning required to keep finding vulnerabilities for your bug bounty journey.

See the previous part of our Bug Bounty Phase blogs:

Bug Bounty Phase 1 - Platforms
You may wonder where to begin when searching for bug bounty programs. This short blog aims to help you narrow down your search for the best platforms and programs to get you finding those elusive bugs.