Hey everyone! It’s been a while! I’ve taken a bit of a break from blogging – working on a web app I plan on turning into a startup, doing my normal day job, and taking an enterprise hacking course in between all of that.

Lately, I’ve been missing bug hunting. So, I decided to get back into it.

I started using the same old tools I’ve been using and kept running into limitations. So, I decided to make my own tools that better fit my workflow.

Lately, I’ve been playing around with AI (since I use it a lot at work), so it was super easy to make these tools on the fly. It only took me a couple of days to make them all.

And they’re all public. So feel free to use them and tweak them on your own time. You can find them on my Github :).

Alright, enough yapping. Let’s get into it!

The tool kit

As I was hunting, I would think “Ya know, this tool could be better if it could take file input” or “I like this tool but it does a little too much for my liking.”

That’s when I decided to make my own, simple set of tools that would do exactly what I wanted. As I mentioned earlier, I used Chat-GPT to write these tools on the fly while bug hunting. So development only took around 15 minutes for each script (including writing the readme for the repo 🙂 ).

Each tool follows my basic workflow for approaching bug bounty programs:

1. Acknowledge the scope and save it to files in my working directory
2. Expand the attack surface by finding ASNs and IPs
3. Expand the attack surface by finding subdomains
4. Filter domains
5. Review gathered hosts

I took a similar approach to Tomnomnom in developing the tools. Tomnomnom uses a Unix-like methodology when he builds his tools, meaning each tool does one thing and does it really well.

This makes them simple to use and more modular. Modular, in the sense that they can be chained together and mixed for a variety of purposes.

I loved using his tools because his tools were flexible enough to adapt to my testing and fit in any stage that I was in. So, without further-a-do, here’s my attempt at putting my own spin on Tom’s suite of tools using my typical recon methodology!

Step 1: Assessing the scope

The first thing I do when starting a new program is read the policy and scope. Boring and obvious I know but everyone has to start somewhere.

I have a simple tool that will help me quickly get started with the scope called domain-scope-parser. Simply feed the scope CSV file from the program page on HackerOne like so:

domain_scope_parser scope.csv

Andi it automatically creates a few files:

• domains.txt – in-scope root-level domains
• wildcards.txt – in-scope wild-card domains
• outscopedomains.txt – out-of-scope domains
• out_scope_wildcards.txt: out-of-scope wildcard domains

Separating the domains into files makes it easy for me to keep track of the scope. Most importantly, I can quickly feed in-scope domains into other tools and filter the results against the out-of-scope data to keep me honest.

Step 2: Gather ASNs

Autonomous System Numbers (ASNs) are useful for identifying IP blocks belonging to an organization. I think that these are sometimes overlooked and can be interesting to consider for scanning.

To gather ASNs, you can use asn_finder:

$ asn_finder example.com

Domain: example.com
IP Address: 54.70.183.123
ASN: AS14519
-----------------------------------

EZ peezee.

And here’s where the modularity comes into play. You can pipe in a list of subdomains (from a file or other tools) to be processed by asn_finder:

cat domains.txt wildcards.txt | asn_finder -q | anew asn.txt 

asn_finder has an optional -q parameter for quiet mode. This omits all of the extra noise and just outputs the ASNs line-by-line (for processing with other tools).

You might have also noticed I used another command, anew. anew outputs unique lines of data to a STDOUT and a text file (kind of like combining sort -u and tee).

Now, I can easily convert these ASNs to their associated IP blocks with asn_to_ip:

cat asn.txt | asn_to_ip | anew ip.txt

You might be wondering why I would bother going through the process of converting these ASNs into IPs. I mean, why not feed the ASNs directly into other tools for scanning?

Well…

1. ASNs can cover a lot of infrastructure that can take forever to scan
2. Some of these IPs can belong to third parties and may be out of scope

So, I like to pick and choose IP blocks or specific IPs that could be interesting and feed them to tools like masscan and Shodan.

Step 3: Gathering Subdomains

Now for the bread and butter of many bug hunter’s recon: finding subdomains.

Subdomains are great for expanding the attack surface of a program. If you’re lucky, you may stumble upon an asset that has been relatively untested, leading to some low-pickings.

One of my favorite tools to use for finding subdomains is Sublist3r. Sublist3r uses several passive sources and active techniques for gathering subdomains but it has one flaw: it doesn’t let you specify a list of domains.

I use text files a lot as a part of my workflow, so I created a tool to wrap around the functionality of Sublist3r : sublist3r_helper. All sublist3r_helper does is allow you to supply a file of domains separated by new lines like so:

sublister_helper wildcard.txt

sublister_helper will run Sublist3r for each domain in the file, then store the output in the format <domain>.sublist3r.out.

Usually, I like to keep all of the gathered subs in one file. So, I’ll run a command like:

cat *sublist3r.out | anew subs.txt

Now, I have a convenient place to store any new sub-domains I gather manually or using other tools. And I can feed these subs to other tools.

For example, sometimes, tools like Sublist3r or other sub-domain gathering tools may gather domains outside of scope. To make sure I’m only working with in-scope domains, I’ll use filter_domains:

filter_domains wildcard.txt subs.txt | anew in_scope_subs.txt

Now I won’t stray from the scope and I’ll have fewer subdomains to work with (saving me some time).

Not all of these subdomains will be resolvable. Some might be stale or deprecated. So, the next tool I use to make sure I’m only considering active domains is resolve_domains:

cat in_scope_subs.txt | resolve_domains | anew resolved_subs.txt

It’s worth noting, I could have used a similar tool like httpx to find web servers. I do end up using it later in my flow, but I like using resolve_domains before-hand because httpx might miss other servers running non-web services like FTP, DNS, mail, etc. These might be worth taking a look at.

For those who like simplicity, here’s a one-liner of the flow:

sublist3r_helper wildcard.txt && cat *sublist3r.out | anew subs.txt && filter_domains wildcard.txt subs.txt | resolve-domains | anew filtered_subs.txt

Step 4: Reiterating with other tools

Going through this flow once and getting started exploring interesting findings is fine but we may want to go back and expand the attack surface even further to find more bugs.

The beauty of this toolkit is that it is modular, meaning we can jump in at any stage in our process to add more discoveries or refine existing findings.

For example, I like to usetheharvester to find additional subdomains and other assets:

theharvester -b all -d example.com -f example.com

This will output a collection of emails, IPs, ASNs, and subdomains to a file in JSON and XML format. I then use theharvesterparser to get each individual asset type so I can sort them into the correct files.

For example, if I wanted to add to the list of subdomains I’ve gathered:

theharvesterparser -i example.com.json -t hosts --only-hostname | filter_domains wildcard.txt | resolve_domains | anew filtered_domains.txt

I can also create a new list of emails for password spraying:

theharvesterparser -i example.com.json -t emails | tee emails.txt

Automated tools can help you find a lot of information about a target very quickly. Just make sure to mind the scope and only focus on assets you think would have the most impact. Our time is valuable and we wouldn’t want to waste it!

Conclusion

I hope this glimpse into my recon workflow helps you augment your own bug hunting strategy. Feel free to use my tools! I made them with the purpose of putting some more helpful tools in other hunters’ toolkits.

I also encourage you to tweak them or use them to develop your own tools. I built each of these with a simple prompt to Chat-GPT (and some minor tweaking on my end). So, whenever there is a gap in your workflow or a limitation with a tool you’re using, try using AI to quickly build a tool that fits your specific use-case.

And don’t forget to share it to better the hacking community!

I wish you the best in your recon ventures! ‘Til next time!