If you've done any sort of recon, you're probably familiar with tools like Subfinder, Sublist3r, Amass, etc. I talked a bit about a couple of the methods these tools use to retrieve the data you want in my first blog post on attack surface (which usually boils down to querying a bunch of different APIs and/or some brute forcing.)
The Anatomy of a Subdomain
At their core, subdomains are meant to be "friendly" names for services that explain a bit about what is going on with the application or service that it's pointing to. For example, if you click on a link to
support.apple.com, you know you're probably going to find answers to questions you have about your Apple products.
In modern development though, there are almost always multiple different versions of any particular service floating around. The one you're meant to see is the production environment, but there are a bunch of other environments used by developers, quality assurance testers, etc. Often times enumerating subdomains you may stumble across staging, development, or QA versions of a site, which you can usually spot by the naming convention the company applies to them.
A good real-life example can be seen with the two Uber subdomains
bonjour-staging.uber.com. You'll notice in the pictures below that while they obviously are meant to serve the same purpose, the designs and data are a bit different. (A longer explanation of different environments can be found here.)
Where Ripgen Comes In
Ripgen is designed to take a list of known-good subdomains and generate different permutations. It does this by breaking apart subdomain names into individual words, and then generating thousands upon thousands of different possible domains for you using those words and some other common subdomains prefixes and suffixes.
If we go back to Uber, we can run some tests to see just how much this technique can help us by measuring how many additional subdomains it finds. We start off by running Subfinder to see how many subdomains it can find on its own, and see that it comes up with 369 unique, resolvable, non-wildcard subdomains.
➜ subfinder -d uber.com -r 22.214.171.124,126.96.36.199,188.8.131.52,184.108.40.206 -nW -o uber-subfinder.txt ➜ cat uber-subfinder.txt | wc -l 369
We then feed these results through Ripgen, where it generates 843,071 new subdomains to try. When we resolve all of those subdomains using dnsx, we find that we now have 411 total resolvable subdomains, meaning that Ripgen helped us find 42 new subdomains, over a 10% increase!
➜ cat uber-subfinder.txt | ripgen > uber-ripgen.txt ➜ wc -l uber-ripgen.txt 843071 ➜ cat uber-ripgen | dnsx -t 1000 -silent -o ripgen-results.txt ➜ cat uber-subfinder.txt ripgen-results.txt | sort -u | wc -l 411
Permutations are really good way to discover new subdomains that other tools miss, but you have to be careful of how much data you feed tools like Ripgen, since their output seems to grow almost exponentially. If you have a list of more than 1.000 subdomains, be prepared for this process to take a loooooong time.
Links in this Article
- Ripgen, it's wonderful author @d0nutptr, and his recon platform (coming soon)
- Earlier work on which Ripgen is based
- Project Discovery tools that I love and use a bunch
- Difference Between Development, Staging, and Production
- Other great subdomain enumeration tools