Information Gathering Part II: recon-ng

Introduction to Recon-ng

In the last part in this series, theHarvester, we looked at a simple tool that would allow us, with a single command, to gather information on a target domain given only the name of the domain itself. We found that this could provide us with some good information as a start, but the tool isn’t very large or powerful by itself. That’s where Recon-ng steps in.

Recon-ng is an entire framework more than it is a command line application. Recon-ng supports many plugins and APIs, and is able to use them to gather large amounts of data on a target, and store that data in a local database. Separate “Workspaces” can be defined for each target, so that we don’t have to worry about mixing information gathered from one target to the next. As you’ll see, Recon-ng is a slightly complicated but very powerful tool for information gathering.

Expanding Recon-ng with API Keys

Recon-ng can harness the power of third party APIs like Twitter, LinkedIn, Shodan, and FullContact. Obtaining an API key for each of the third party utilities that Recon-ng supports is beyond the scope of this article, but typically you would sign up for a developer account through those services to obtain API keys. Some of the services provide free API keys, and some services charge for them. At minimum I would recommend getting keys for Shodan and FullContact, which are free for a limited number of searches per month.

Once you’ve obtained API keys for specific services, you can install them from within the Recon-ng console. We’ll do that later in the article. It should be noted that API keys for these services are unique to you, and are tied to your account on their respective sites. As such, you’ll want to keep these keys secret, and treat them like you would a password.

Setting Up Recon-ng API Keys

Unlike theHarvester, Recon-ng requires a bit of setup. For the most part this will consist of importing your API keys. Let’s launch the Recon-ng console by simply typing recon-ng, and see what keys we currently have installed.

When you first launch Recon-ng, you’ll get a bunch of red text. This text is error messages, most of which state that you don’t have certain API keys installed. You can safely ignore this text, as during this tutorial we won’t be installing an API key for every service that Recon-ng supports. Optionally, you don’t really have to install any, although you’ll get much better results with API keys installed, and a few of our examples will use functions that you won’t be allowed to use if you don’t have API keys installed.

Ignoring the error text, you’ll want to enter the command show keys into the recon-ng prompt.

The output should show you for which modules you have API keys installed. By default, you should have no keys. At this point I’d recommend that you sign up for a developer account at Shodan, and also sign up for a free trial account over at FullContact. Once you have API keys for those sites, you can import them with the following syntax.

keys add fullcontact_api api_key_goes_here

keys add shodan-api api_key_goes_here

As you can see in my output from above, I’ve got Shodan and FullContact keys installed, as well as Twitter API keys.

If you mistype a key, or want to delete a key, you can remove keys as well. For example, I’ll remove the key for fullcontact_api.

keys delete fullcontact_api

Be aware, however, that this results in some odd behavior, as “fullcontact_api” will no longer be shown on the output if you type show keys. This doesn’t remove the module though, and you can add another fullcontact_api key the same way that you had done originally.

Also note that Recon-ng must be exit and re-run for imported keys to take effect. You can exit by typing exit.

Creating and Switching Between Workspaces

Now that our API keys are installed, let’s re-launch the recon-ng console by typing recon-ng.

The first thing you’ll see when you launch Recon-ng is the prompt. Like I said, Recon-ng is a framework, not necessarily just a command line application that throws output at us. Notice the [default] prompt. This means that we are in the default workspace. Typically you’ll want to create workspaces for every target that you are gathering information on separately.

In keeping with our previous example from Part I, we’ll create a new workspace for Pixar.

workspaces add pixar

The pixar workspace will be created and we will be placed into that workspace. You’ll get the similar error text for lack of API keys – just ignore that. We can list the currently configured workspaces by typing the following:

workspaces list

This shows us that we have a workspace called pixar and a workspace called default. We can easily switch back and forth between workspaces by typing the following syntax:

workspaces select default

workspaces select pixar

This will switch us in to the default workspace, and then switch us back into the pixar workspace. You’ll notice that very time we enter a workspace we’re reminded about those API keys again. This can be annoying. You can clear the screen by typing clear.

If we want to delete a workspace, that’s easy too. I’m sure by now you’ve guessed how.

workspaces delete pixar

Be careful with this command though – as you aren’t prompted for a confirmation when deleting a workspace.

Adding Information to a Workspace

If you haven’t already, ensure that you’ve created a workspace called pixar and that you’ve switched into it. Now we’re going to add a domain to the pixar workspace. Syntax is again very simple.

add domains pixar.com

Notice that we aren’t using the www. at the beginning of the domain. That’s because www. is a reference to the public web server at pixar.com, and we don’t want to limit ourselves to just output from information regarding the web server. In fact, if we added the www., we may not get any information back at all.

If your target person or organization has more than one domain, you can continue to add multiple domains in this way.  For this example, we’re going to stick with the one domain. Use the command show domains to see what domains exist in your current workspace.

Here we can see that we have one domain, pixar.com, and that we defined it explicitly. If another module would have populated a domain for us via its information gathering engine, the name of the module that added the domain would be listed in that column.

Now that we’ve got information added into our workspace, let’s scan based on that information and see what we can find.

Using Modules to Search for Contacts

Recon-ng has many modules preinstalled that you can use to gather information. If you’d like to see a list of them, simply use the following command:

use recon/

Notice the format of each module’s name. All modules are located within recon, so the first part makes sense. The second part of the module, for example, is something like domains-contacts. This lets us know that the module that we’re using will search based on information in our domains table (which we’ve previously entered) and attempt to find contacts. Obviously if we have no known domains entered, all of the modules within domains-* would be worthless to us. For now, all we have is a domain, so we’ll be looking to those modules to help us gather more data.

Specifically, we’ll be looking at pgp_serach to find contacts. This a module that doesn’t require an API key. Let’s attempt to re-create what we performed earlier with theHarvester and see if we can get more information from Recon-ng. Let’s enter the context of our first module.

use recon/domains-contacts/pgp_search

As you can see, our prompt changes to indicate that we are now inside of the pgp_search module. We don’t know much about what this module requires to successfully run, so let’s type show info to get a better idea of what the module does.

Here we can see the name of the module, path, author information, a description as to what the module does, and most importantly the options. This shows us what is required to run the module successfully. If we don’t have all of the options defined, the module will fail to run and give us an error message. Since the requirement for the module is a domain, we know that we’ve got a valid domain in our list via the show domains command, so we should be set to go. We also see that this module will update the contacts table with email results, so we’ll have to be sure to check that after we run this module.

To run the module, simply type run.

It looks like the module was able to find quite a few email addresses. It auto populates the data from its findings in the contacts table for us. Unlike theHarvester, it was able to find some additional information beyond just email addresses. Let’s see everything the module was able to find with the show contacts command.

This time, not only were we able to find email addresses, but we were also able to find first, last, and sometimes middle names. Notice that under the module column, all of these entries list pgp_search as the module and not user_defined, as our user-defined domain was before in the show domains table.

If you wanted to manually add a person to this table because you know what their information is, or you got it from another tool like theHarvester, you could optionally manually add entries.

If you aren’t able to find any contacts with this module, try using the module recon/domains-contacts/whois_pocs.

Using Modules to Search for Contact Vulnerabilities

Now that we’ve got a list of contacts, let’s attempt a search to see if any of them have been compromised in known public hacks in the past. Hacks like this would include major public breaches like the ones seen at Target, Home Depot, LinkedIn, Kickstarter, Yahoo, and many more in the past.

For this we’ll be using a new module.

use recon/contacts-credentials/hibp_breach

You can use show info to see more info about the module, but the only requirement to run it is that we have contacts within the contacts table, so let’s go ahead and run it.

As we can see, the tool uses the haveibeenpwned.com API (doesn’t require an API key) to determine if any of the email addresses in your contacts table have been compromised in the past. As you can see, not only does Recon-ng tell us who has been compromised, they also tell us during which breach or breaches they were compromised. This means that if a breach contains password hashes, or even plain text passwords, and you are able to download dumps from that breach, which often make their way on to Torrent sites, you may have some vital information here.

Searching for Contact Information with FullContact

This article is already getting lengthy, but there’s one more module I want to explore, and that’s the FullContact module. Remember, FullContact requires an API key, which you must sign up for on their website and manually import into Recon-ng as explained at the beginning of this article.

Let’s load up the FullContact module, and run it against our contacts table.

use recon/contacts-profiles/fullcontact

run

Simple enough, and now let’s see the output…

If you are running this yourself and are able to scroll back up through the output, you’ll find a trove of information on each user. If you aren’t, just look at the tail end of this output. FullContact provides us city/state location information, job title, and links to social media accounts like Facebook, Flickr, Github, Gravatar, Keybase, Klout, LinkedIn, Vimeo, Instagram, GitHub, Foursquare and Twitter. It even provides us with a confidence level score that show how confident the site is that the information being shown is information about the person we’re searching.

In just this one search, the tool was able to find 69 total profiles, and 11 new contacts. Saving the best for last, what happens when we view the profile information that this module found with the show profiles command?

Not only has Recon-ng conveniently saved every link associated to every social media account and for every user, it has also been able to farm usernames from each of these links.

This tool by itself should make some people think about how much information they freely throw out on social media. Who knows – some of these social media accounts could be completely locked down, but all of them may not be. Information gleaned from the data you freely provide to social media can easily be used in social engineering attacks, spear phishing attacks, and as we learned a couple days ago, in targeted password attacks. Some of it could even be used for more serious physical crimes, like blackmail, kidnapping, or extortion.

Conclusion

I hope you found this article both educational and eye-opening. Some take-aways from this: be careful what you put on social media, lock your social media accounts down, don’t use the same password for all of your accounts, change passwords regularly, and be sure to change your passwords after being notified that a breach occurred on any of the services you use.

Honestly, Recon-ng is one of my favorite tools, and I will most likely do a follow-up article that hinges more on the side of IP and host discovery with Recon-ng rather than contact discovery.

If you enjoyed this tutorial and would like to see more, please feel free to share this article on social media, comment below letting me know what else you’d like to see, and follow me on Twitter @JROlmstead.