Introduction
If you haven’t seen the previous two parts in this series, please check out Information Gathering Part I: theHarvester, and Information Gathering Part II: Recon-ng, go check those out before reading this post, as in this post we’ll be picking up right where we left off in Part II.
In the last post we focused on using Recon-ng to obtain information on users, user accounts, and social media accounts linked to those user accounts. We also obtained information such as users’ first, last, and in some instances middle name, and whether or not those users had been victims in any previous large-scale data beaches or leaks. We determined that it wasn’t too difficult to quickly harvest all of this information and store it in a local database within Recon-ng.
In this article we’ll be focusing more on the systems than on people. We’ll be looking for things like IP addresses and address ranges, sub-domains, servers, etc. Information gathered via these means is typically used to set up the parameters for an IP or service scan.
Scanning Domains to find Hosts
We have already populated our domains table with the known domain, pixar.com, however, we aren’t sure what hosts exist on this domain, if any. There are several modules that we can use in an attempt to find hosts on these domains and populate our hosts table. The first two of which are Bing and Google.
use recon/domains-hosts/bing_domain_web use recon/domains-hosts/google_site_web
I’ve shown how to load and run modules in the previous article, so I’ll skip the step by step here. Both of these modules simply pulls entries from the domains table in order to run and don’t require any other parameters, so after you load each one, you should only need to execute it with run.
Let’s check the output from both of those commands.
I tried Bing first and was able to find a total of 10 hosts.
Google was then able to find 9 hosts, with two of them having not been found by Bing. This is why it’s always a good idea to use multiple tools whenever you have the chance.
Let’s take a look at all of the information gathered as it’s stored in our hosts table via the show hosts command.
Excellent. There are are quite a few hosts here, and many that we weren’t able to find with theHarvester. We see that 10 show up as being found with the bing_domain_web module and 2 with the google_site_web module.
Now let’s try running a module that’s locked behind an API key. The free modules work very well, but typically the modules that require an API key are much better, as we saw with FullContact. We’re going to use a Shodan module to search for hosts.
recon/domains-hosts/shodan_hostname
This requires no special parameters, so it can just be executed with run right away.
Almost instantly Shodan returned 25 new hostnames that weren’t before discovered. It also was able to resolve those hostnames to IP addresses and store those in the database as well.
Let’s check out the show hosts command again.
The hosts found by the Shodan module are much more interesting. Obviously without the Shodan API and the FullContact API, we would be missing out on a lot.
I won’t draw out the length of this posts unnecessarily with screen shots and step by step since you know how to use modules at this point, but we can resolve the IP addresses of the existing hosts that Google and Bing found using the module recon/hosts-hosts/resolve.
There are several modules in the Recon-ng application that provide even more functionality than what we’ve seen in these series. I recommend that you load up each module and type show info to see what each module does. By now you should get the gist of how the framework works, and how data is gathered.
Generating an HTML Report
When you’re finished with your information gathering you may want to generate a nice report. By default, Recon-ng keeps all of the database files in the directory ~/.recon-ng. That raw data, and even screen captures of show command output aren’t really too presentable though. Luckily Recon-ng provides a nice HTML reporting engine that will generate a report based on all of the data gathered in our current workspace.
For the purposes of this tutorial I’m going to fill in dummy data for the creator, customer, and filename. There is another option that must be set called SANITIZE, which sanitizes any potential sensitive material from the report. This defaults to YES, but I’m going to change it to NO.
use reporting/html set CREATOR h4x.life set CUSTOMER Pixar set FILENAME /root/pixar.html set SANITIZE False run
This will provide you with a nice report with collapsable sections that can either be presented on the web or printed.
It’s a single, simple HTML file that relies on no other external files and contains all of the counts and data from your information gathering in an easy to read format.
Conclusion
I encourage you to go through the rest of the modules that come with Recon-ng, see what each one does, and build a workflow for your gathering. Start with a domain, then collect users, then collect information about those users. Start with the domain again, and try to collect information about hosts and IPs as we’ve done here, and then take it a step further and try to discover IP blocks, locations, and more. Recon-ng is really a very powerful tool and once you have a workflow down, you can collect valuable information extremely quickly.