Reconnaissance 101
Last updated
Last updated
Utilizing the hacker methodology in an engagement can help make any red team member successful. If you haven't heard of the hacker methodology before, it is broken down into 6 phases:
Recon
Scanning and enumeration
Exploitation
Privilege escalation
Persistence
Covering your tracks
Some offensive teams add or take away from this list to customize it for the way they do business, so if you see a slightly different methodology out in the wild, know this is the reason why. In this lesson, we will be discussing the first phase within the hacker methodology.
You may ask yourself, "What is considered recon, or what is the difference between the recon phase and the scanning/enumeration phase?" Recon can be thought of as the passive phase of the hacker methodology. In this phase, none of the victim's assets are touched except for maybe their webpage if they have one. Utilizing open-source information, an attacker will attempt to locate, gather, identify, and record information about their target. The recon phase can be accomplished using search engines, social media, job listing sites, public registry databases, and a few handy tools.
First, let's talk about using social media as a source of open-source information. Utilizing social media for OSINT operations is often referred to as SOCINT and social media sites are one of the most significant risks to an organization and its secrets. These sites open up numerous opportunities for information gathering due to the vast amount of useful information located in one place. From disgruntled workers leaking information to individuals bragging out of pride about the projects they are working on, if an attacker spends enough time on social media, they can build a vast picture of an organization. The phrase loose lips sink ships may seem outdated today, but it still rings true today in the infosec sphere.
Another risk social media could present to an organization is the potential for various vectors of exploitation. For example, attackers could build trust and relationships on social media platforms with employees of a target organization to perform corporate espionage or phishing attacks. The more a user trusts someone, the more they will let their guard down. Once this trust has been established, an attacker could convince a target to open a weaponized document or malicious link to gain a foothold. Additionally, through discussions with their target, an attacker could cultivate sensitive data from a victim over time, which could be detrimental to an organization. This data could include information about the target's network, projects they are working on, username schemas (this can be used for brute force attacks ), and potential targets for phishing campaigns.
Another excellent source for information about an organization are public registry databases. Domain name registration databases can give an attacker a plethora of information, giving attackers some insight into your organization. Performing a search for a specific domain using one of these databases is commonly known as a whois lookup.
If the registrant does not use a privacy service when registering their domain, the registrant's contact information can provide an attacker with potential targets for a phishing campaign. These targets could include the registrant, the site's admin, tech support, and the billing department. If an attacker successfully phishes any of these targets, it could spell disaster for an organization. In addition to the registrant's contact information, some whois databases can also provide a domain's IP information. Suppose the victim is hosting their assets on a local server rather than the cloud. In that case, the IP information provided by a whois database could give attackers a starting point for scanning and enumeration if they already didn't have one. Now that we have discussed the potential risks of social media and whois let's discuss something more hands-on.
Search engines spider through web pages and archive information that organizations may not want users to see. For example, an organization may decide to store sensitive information on the same server as their web application. If a target stores sensitive information on the same server as their web application, this could result in its discovery by a search engine spider. Once the data has been discovered and archived, anyone utilizing that search engine can find the data.
One of the best search engines for discovering spidered and archived data is Google. Searching Google for targeted data can be accomplished using a series of special filters. Using Google in this way is known as Google Dorks, Google Dorking, or Google Hacking. Simple syntax for Google Dorking would be something like site:website "searchString". For example, if you wanted to search for the admin page of example.com, the syntax would be site:example.com "admin". See image 2.1 for an example of this basic search.
That is just an example of a basic targeted term search. Let's discuss more advanced search filters to perform Google Dorking. Say you wanted to find a specific file type on a webpage. If you use the search filter filetype: combined with a file extension Google will return a list of pages containing that file type. For example, say we wanted to search for PDFs on examples.com. The syntax for this search would be site:examples.com filetype:pdf. As you can see in image 2.2, our search has returned 72 possible PDF files located on examples.com. Using only this one filter can make things a bit difficult, especially if a website has a large number of files related to your filetype filter. What can an attacker do to refine their search?
Attackers can use multiple filters when performing Google Dorking to refine their searches. For example, if an attacker wanted to search for an env file containing passwords, they could use the search site:example.com allintext:password filetype:log. This search will look for occurrences of the word "password" in any log filetypes on example.com.
What other pieces of information can Google Dorking reveal about an organization's online assets? If an attacker wanted to find sensitive directories, they could use a search such as intitle:"index of" "/home/ROOT_PATH/". To identify server information, an attacker could use a search such as site:example.com intitle:"Lists Web Service" or site:example.com intitle:"Directory Listing, Index of /*/". An attacker can also use Google Dorking to find login portals with a search such as site: example.com intitle:"web client: login" or site:example.com inurl:weblogin.cgi?=1. These are just a few examples, and if you want to see more, check out the Google Hacking Database on ExploitDB at https://www.exploit-db.com/google-hacking-database. Additionally, Some examples of more filters are below.
allintext: Searches for occurrences of all the keywords given (allintext:"keyword")
intext: Searches for the occurrences of keywords all at once or one at a time (intext:"keyword")
inurl: Searches for a URL matching one of the keywords (inurl:"keyword")
allinurl: Searches for a URL matching all the keywords in the query (allinurl:"keyword")
intitle: Searches for occurrences of keywords in title all or one (intitle:"keyword")
allintitle: Searches for occurrences of keywords all at a time (allintitle:"keyword")
before/after: Used to search within a particular date range (filetype:pdf & (before:2000-01-01 after:2001-01-01))
The last topic we will discuss in this module is a fantastic all-in-one tool used by many attackers to help perform recon call "theHarvester". This tool is available on Kali by default; however, if you are not using Kali it can be downloaded from https://github.com/laramies/theHarvester. This tool combines many of the techniques discussed in the previous lessons. It is also helpful for any blue team member who wants to know what an attacker can see about their organization.
One of the top benefits of using this tool is the ability to quickly query a target using a wide swath of data sources. These sources include baidu, bing, bingapi, dogpile, google, googleCSE, googleplus, google-profiles, linkedin, pgp, twitter, vhost, virustotal, threatcrowd, crtsh, netcraft, and yahoo. These sources can be queried individually or all at once to help speed up the recon phase.
The syntax for theHarvester is pretty simple "theHarvester -d targetDomain options". For example, if we wanted to perform recon on example.com using bing the syntax would be "theharvester -d microsoft.com -b bing". Additionally, to speed up your search the -l option can limit the number of results. Some search engines such as Google can slow down your harvester searches due to their search engine database sizes. Image 2.3 demonstrates a search performed for yahoo.com and limiting the search results to 100. The search engine used for this query was Google.
As you can see from this search theHarvester returned two email addresses and 12 IPs/URLs. Had we expanded the search limit to something like 1000 we would have received even more data. Additionally, using different data sources for your search will provide different results. For example, in image 2.4 we performed the query "theHarvester -d funimation -l 100 -b linkedin" and were returned with a list of potential targets for a phishing campaign. As you can see theHarvester is a simple tool, but it could help you build a bigger image of a target organization and help you plan a better engagement by providing you with valuable data quickly.
What if you want to collect information about all of the potential subdomains related to a domain? That's where DNS Zone Transfer can come in handy. A DNS Zone transfer is the act of requesting information from an improperly configured nameserver to acquire valuable information. Typically large organizations will have a primary nameserver and a secondary nameserver for backup. If the primary nameserver were to fail, the secondary would serve DNS requests in its place. If the nameservers are correctly configured, they will only serve requests of Zone transfer from other nameservers. These Zone Transfers are typically performed between nameservers, so they stay in sync. If an attacker can execute a Zone Transfer against an organization's nameserver, the hostnames will be revealed for all of their IP ranges.
Why is this dangerous? The information gained by performing a Zone Transfer gives an attacker a better picture of a victim organization's network. For example, a Zone Transfer could reveal assets an organization doesn't want the general public to know about, such as subdomains with unpatched servers. This bigger picture of an organization's network gives attackers the ability to plan better.
For this lesson, we combined the identification and exploitation sections. We did this because the identification and exploitation of a DNS Zone use the same steps. We will cover how to exploit a DNS Zone Transfer vulnerability using Dig and NSLookup. Both tools are available natively on Linux, but the only one available natively on Windows is NSLookup. For this lesson, we will use Linux to demonstrate their usage.
The first of the two tools we will cover is NSLookup, which uses the syntax "nslookup -option target". If you wanted to specify a nameserver, you would need to add it to the end of your command. This syntax for this would be "nslookup -option target nameserver". See image 3.1 for an example of us performing a basic query.
As you can see from this image, we received only one record from the query we performed. We obtain this single result because we did not specify a query type. By default, nslookup will retrieve a domain's "A record" if no query type is specified. To specify a query type, you need to add the "-query=" option to the command. Below is a list of query types you can select.
NS: To query a given nameserver for a domains NS record
PTR: To query for a reverse lookup (PTR record) of an IP address
ANY: To query for ANY available records
AXFR: To query a given nameserver for the whole zone file of a domain
MX: To query for a mail server (MX record) of a domain
If an attacker wants to check for and exploit a DNS Zone Transfer vulnerability, the syntax "nslookup -query=AXFR target.com nameserver" can be used. Using this command results in us receiving the entire Zone file; if we were attackers, this information could help us build a better picture of the victim organization and reveal potential actor vectors. For example, image 3.2 shows admin.cydefe.com as one of the entries. This subdomain may contain a web application that, if exploited could result in a devastating compromise. See image 3.2 for the results of our command.
If you wish to use Dig instead of NSLookup, the syntax is very similar, so there isn't much of a learning curve. The syntax for Dig is "dig target type," and you can specify a nameserver to query with this tool as well. The syntax for including a specific nameserver would be "dig @nameserver target type." For example, "dig @8.8.8.8 cydefe.com MX" would be the command to specify the server of 8.8.8.8 and perform a mail exchange query against the target cydefe.com. See image 3.3 for an example of us performing a basic query.
In image 3.3, you can see we received some information regarding the IP of www.cydefe.com and information about the nameservers. If we want to perform a Zone Transfer with Dig, the syntax would be "dig @nameserver target AXFR." See image 2.2 for an example of this command. For this lab, we used the command "dig @172.17.0.2 cydefe.com AXFR" the nameserver of 172.17.0.2 is used because that is the IP of our VM. Please note that your nameserver IP will be different when running the VM.
Using Dig to perform a Zone Transfer gives the same results as using NSLookup. Images 3.3 and 3.4 demonstrate you can use either tool to get the same results. The main difference between the two is the formatting of their output. When picking which of these two tools to use, it comes down to preference and availability. Now that you know how to perform a Zone Transfer get out there and HACK THE PLANET!
To prevent a Zone Transfer to untrusted machines, you will want to set up your DNS servers ACL. Typically the ACL will be located in your server's configuration file. The ACL will look like something below and note that you will want to put your nameservers IPs in the ACL, not the example below IPs.
After you set your ACL, you will need to edit your Zone configuration file. Edit this file and add the line "allow-transfer { trusted-servers; };" to define what ACLs you will be using. See below for a simple example of how this file would look.
Once these edits have been made, restart your server for the changes to take effect.
Congratulations, you now know some basics about performing recon. Now that you have some basic knowledge about your target, it's now time to move onto the hacker methodology's scanning and enumeration phase. Get out there and HACK THE PLANET!
