Active Reconnaissance: Overview, Methodology and Tools
The cybersecurity kill chain by Lockheed Martin walks us through the seven sequential steps an attacker will commonly follow during an attack. Previously, we took a look at how the entire process starts by using Opensource Intelligence (or OSINT) to do passive recon on a target. We went over popular OSINT tools like Maltego and The Harvestor that facilitate the information gathering process.
In this blog, we’re going to look at the active recon tools and techniques that we can use to find holes or vulnerabilities in our target. We’ll also see how taking the proper steps in this stage can minimize our exposure and reduce our risks of tripping security devices.
What Happens During Active Recon?
During the active recon phase, we interact directly with the target to gather information that can be utilized for later stages of the attack. Specifically, we’re looking to find a vulnerability or weakness that can be weaponized in the next step of the kill.
But even within this phase, there are incremental steps and processes we take that go from low to high risk for exposure. Because we are making direct contact with the target, we want to minimize the noise and be strategic about how we use the tools at our disposal.
That means we start with low-risk items and then use that information in a careful way with high-risk items. Low-risk reconnaissance generally deals with fairly benign scans or queries and usually does not trip any IDS or firewall alerts. Medium risk recon consists of items that security devices are actively looking for but, if done correctly, can be accomplished with no risk of getting. The high-risk recon is classified as one that will definitely trip a security device that is configured correctly.
However, as we’ll see later – the idea would be to minimize the time spent in this area by using the information we’ve obtained in previous steps. Let’s start by looking at some low-risk active recon techniques like DNS and SMTP enumeration.
With DNS enumeration, our goal is to obtain the IP addresses of servers we can target. A corporation’s DNS server can, at minimum, give us specific public-facing server IP information to focus on. And a misconfigured DNS server can provide us with the internal IP scheme of the company or allow zone transfer, which is essentially a DB dump of all IP resolution information.
Tools like DNSrecon or DNSenum are included in Kali and can help do a lot of the manual work by automatically attempting zone transfers or querying for common subdomains like “ftp” or “internal” which could lead us to new places to explore. DNS queries are very low risk, but attempting a zone transfer can cause some red flags, so use caution. In my example, I’ve used DNSenum on a domain and found other interesting subdomains, like this FTP server which is probably used by the web admin for file transfers to the website.
Now, if we decide to target that FTP server for our attack, we’ll have much more success if we can find valid accounts that may be used to log in successfully, and that’s where we can move to SMTP enumeration to find valid accounts.
The SMTP protocol supports very interesting commands that we can use to find out more information about the email accounts of a particular domain. By using simple netcat query to the MX server’s IP address that we found in the previous step, we can use the ‘VRFY’ command to check if a given user exists on the domain. The mail server will gladly tell us whether that is a valid user because it’s a common exchange in the SMTP protocol itself. The goal here would be to check against common usernames like ‘root’ or ‘admin’ and find a valid username we can use for later attacks. Kali also includes the ‘swaks’ toolset that includes everything you need to not only enumerate an SMTP server but test using a variety of different options.
Our enumeration phase has yielded some interesting information that we can use to narrow our scope for the next higher-risk phases. Now that we have identified servers and usernames to work from, we may choose to use Nmap for port scans or service enumeration. Port scanning, even behind a proxy, can be considered high risk because even the most basic modern firewalls and IPS devices have port scanning detection. However, there are a few things we can do to protect ourselves from detection. Most notable are things like using decoys or spoofed IPs and slowing down our scan time.
The Nmap -D option allows us to use decoys as a way of spoofing the source IP of the scans. This way, the target sees a different source IP trying to initiate different connection attempts. To use the decoy option, simply provide a ‘-D’ option to the Nmap command, followed by the different public IPs you would like to use as the spoofed source. You could also leave it to Nmap to decide what IP’s to use by typing in “RND” following the -D option. If we look at a wireshark capture of the subsequent scans, we’ll see that the source IP has been changed, which reduces the hits from a single source IP
It’s worth noting that using the decoy is not 100% foolproof. There are port scan detectors that can effectively see the original source of the IP, so always use with caution. Also, there are some ISPs that filter out spoofed packets, but it seems to be rare. When the decoy option is used in combination with a slow scan, it can prove to be quite effective at lowering your risk of detection by security devices.
OS Fingerprinting/ Banner Grabbing / Service Enum
Nmap is an extremely powerful tool, and there are tons of great resources on YouTube to walk you through all of its capabilities but always use with caution. For example, it’s common to use OS fingerprinting and service enumeration operation during a scan. However, decoys will only work with the port scanning and OS detection phases. That means that banner grabbing and service enumeration can leave you exposed, putting you at a higher risk of detection. However, finding out precisely what application is running on a given port is crucial to a successful attack. Knowing that a port is open is usually not enough to succeed because we also need to know the application and version number running on the port. Based on this, we can move on to the next phase in the kill chain, which is ‘Weaponization,’ and find ways to exploit a given application.
While Nmap is not considered a full-fledged vuln scanner, it has a good amount of built-in scripts called ‘Nmap scripting engine (NSE).’ NSE is essentially a library of scripts that can be used to detect and validate vulnerabilities. We can call NSE from Nmap by using the – – script option, and from there, we can search the database by using “-script-help and put our search term inside quotes. For example, we can write “ftp-* and discovery” to find a list of ftp scripts under the ‘discovery’ category.
Once we have the script we want to use, we can simply reference it by using ‘Nmap – – script ‘ followed by the script name and then the target. This will run only that specific Nmap script against our target. That should be our goal after all; to be careful and precise about our scans so when we have to use risky techniques, we’re minimizing our interaction and hopefully lowering the risk of raising red flags.
Of course, there are several vulnerability scanners that we can use, and Nmap is probably the most basic and easy to use of the batch. Some common examples include Nessus, OpenVAS, Burp Suite, Nikto, and many more. Each scanner will have its own options and techniques to make as little noise as possible because, ultimately – running any type of vulnerability scanning is the easiest way to set off a firewall or IDS device.
Our ultimate goal for the reconnaissance phase is to find a weakness, any weakness. In the next step of the kill chain, we aim to find a way to search for ways to actively exploit that vulnerability.