Target Discovery and Enumeration
Last updated
Last updated
We'll start by looking at hacker tools and techniques for target discovery and enumeration. An attacker begins by researching an organization, like falsimentis.com. They gather information, find targets, and check for weaknesses or open services. Once they know the vulnerabilities, they exploit them to gain access and repeat the process to gather more data, find more targets, and exploit them further.
We'll look at how attackers find and list targets, such as organization subdomains (like qa.falsimentis.com), partner and subsidiary organizations, and non-production systems.
A simple way to find target systems is by using a search engine. For example, searching for site:kringlecon.com on Google shows multiple web servers like kringlecon.com and others. This can help attackers find new servers and see naming patterns.
The site: search modifier works with Google and other search engines like Bing, Baidu, and DuckDuckGo. Although results may overlap, different search engines might show results in different orders.
DNS info is useful for attackers to gather details about an organization, like IP addresses, host names, email addresses, and MX records.
The main tools for checking DNS servers are nslookup and Dig. Nslookup comes with Windows and some UNIX systems. Dig is more advanced and lets you control DNS query results better than nslookup. Both tools can be used by attackers.
Let's jump into a Lightning Labs event to reinforce this learning objective.
1) Start with a basic query. Run dig www.falsimentis.com and examine the results.
By default, the output of Dig is kind of noisy. We can make the output quieter by adding a query option.
2) Add the short query option. Run dig +short www.falsimentis.com.
By default, Dig will query for an A record. We can also specify other DNS record types.
3) Change the query to ask for the IPv6 AAAA record type. Run dig +short AAAA www.falsimentis.com
Many DNS record types work for a hostname, such as www.falsimentis.com. Other queries work using the domain name, such as falsimentis.com.
4) Use dig to query the Falsimentis Mail Exchange (MX) records to identify the mail servers using dig +short MX falsimentis.com
5) We can use Dig to interrogate the authoritative DNS servers for a domain using the Name Server (NS) record type.
Identify the name servers for the falsimentis.com domain. Run dig NS falsimentis.com.
6) Query the Mail Exchange (MX) record type for both www.falsimentis.com and falsimentis.com. Run dig MX www.falsimentis.com then run dig MX falsimentis.com.
Notice how there is no MX record response for www.falsimentis.com. Some DNS records apply to the subdomain, not a specific hostname.
7) The ANY record is a magic record type. Issuing an ANY record will reveal multiple records for a matching name. Try it out. Run dig ANY www.falsimentis.com.
A zone transfer (AXFR) is a DNS record type used to copy all DNS records from a primary server to a secondary server. If an attacker requests this transfer, they can get sensitive details about the network's internal and external names.
To check if a DNS server is vulnerable to a zone transfer, first find the server in charge of the domain using Dig (e.g., dig +short NS zonetransfer.me). Then, try to get the zone data by sending an AXFR request to that server (e.g., dig @nsztm1.digi.ninja AXFR zonetransfer.me).
In this example, we try a zone transfer for the holidayhackchallenge.com domain. The dig tool shows an error, meaning the transfer failed and the DNS server is set up correctly by the admin.
When running an Nmap script, use --script-args to provide arguments as a comma-separated list. For example, set the target domain with dns-brute.domainand define how many DNS queries to run at once with dns-brute.threads. You also need -sS and -p 53 for the scan.
When the scan finishes, Nmap finds several hostnames. These are important for the attacker, as they show what each target can do.
Modern web browsers are good at spotting untrusted TLS certificates but struggle with malicious ones from trusted authorities. To address this, browsers require trusted Certificate Authorities (CAs) to log all issued certificates. This logging allows others to review and detect any suspicious certificate activities.
Certificate transparency helps attackers see details about certificates used by an organization, like hostname information. This can reveal hidden systems that might be potential attack targets.
Subfinder from Project Discovery (https://projectdiscovery.io) quickly finds subdomains and hosts by checking many online sources and APIs. For example, using Subfinder with the domain counterhack.com shows many extra subdomains and hosts.
Subfinder automates the process of finding subdomains by collecting data from various online sites with just one command. It simplifies gathering and organizing information about a target into a list of subdomains, compared to doing it manually.
To defend against target discovery and enumeration attacks, limit the amount of information publicly available to an attacker, and apply similar offensive discovery techniques to understand your organization's exposure.
To protect against DNS attacks, limit zone transfers so only your secondary and tertiary DNS servers can access them. Configure these servers to deny all other transfer requests. Use split DNS to separate your public and internal DNS servers. Public info goes on external servers, and internal names are only accessible within your network. This setup prevents attackers from seeing internal names or using DNS attacks like cache poisoning.
DNS server logs are useful for threat hunting. Logs vary by DNS software; ISC's BIND DNS logging guide is here, and Windows Server DNS logging info is here. Be careful not to mistake normal DNS activity for an attack.
Launch the Falsimentis DNS server target by running gonameserver . Use Dig to interrogate the server at 172.30.0.254, identifying dierent servers. Use the Nmap dns-brute script to collect more information, customizing the host list to identify even more systems. Review the DNS server logging information after the attack in ~/labs/dnslog .
From the terminal, let's start the DNS server for the test by running gonameserver.
To find out who controls a domain's DNS, use a WHOIS query with tools like Dig or a WHOIS website. This will show you the domain's authoritative DNS server.
In this lab, we will check the DNS server for falsimentis.com at 172.30.0.254.
Now let's use dig to check www.falsimentis.com.
Let's break down the command:
@172.30.0.254: The @ sign means the query goes to the server at 172.30.0.254.
A: The DNS record to check is an A record, which gives an IPv4 address.
The website www.falsimentis.coM points to the IP address 45.76.171.86.
The number 86400 is the TTL (Time To Live), which tells how long (in seconds) the DNS answer should be stored by the resolver (the client performing the lookup). IN means it's an internet record.
Let's run the command again with +short to get a shorter DNS response.
Let's request a zone transfer to get all DNS records from a server. Use Dig with the AXFR type and the domain name.
The zone transfer request failed, which is normal since internet-facing DNS servers rarely allow them. But we can still check the DNS server directly for specific names and record types.
Unlike a simple A record lookup, which just provides the IP address of a specific host, an MX record lookup reveals additional hostnames related to the domain. These hostnames can provide insights into the structure of a domain's email infrastructure.
In this output we learn that Falsimentis uses Microsoft 365 for email – a valuable piece of reconnaissance information.
We learned that Dig lets us check the server directly. An attacker could use it to find names and discover other target hosts.
When Dig can't resolve a DNS record, it shows no output. Some names gave no info, but we found two new ones: login.falsimentis.com and support.falsimentis.com. The IP addresses are in different formats, which might mean the DNS server is misconfigured, exposing both public (23.21.211.161) and private IPs (172.17.0.211).
Manually guessing DNS names is inefficient. Attackers can instead use automated tools like Nmap's dns-brute module.
The Nmap dns-brute script uses a list of hostnames from a file (/usr/share/nmap/nselib/data/vhosts-default.lst) to automate DNS name guessing against a chosen name server.
Let's break down the command:
--dns-servers 172.30.0.254: Choose the DNS server for name resolution, like a local server, the target organization's DNS, or a public resolver (e.g., Google's 8.8.8.8).
--script dns-brute : Tell Nmap to run the dns-brute script
--script-args dns-brute.domain=falsimentis.com : Set falsimentis.com as the value for the dns-brute.domain parameter.
Nmap found 5 hosts with the dns-brute script. Most of these we had already discovered, but it also revealed the news.falsimentis.com server as a new target.
Nmap's default DNS brute-force list is short and finds only common names. We can improve it by using a longer list.
Let's check the first few lines of a longer list found in labs/dns.
Let's redo the dns-brute scan using the namelist.txt file and add the dns-brute.hostlist argument for the custom list.
The Nmap scan found a new host we hadn't seen before: downloads.falsimentis.com.
An attacker won't just use public name lists for DNS queries; they'll also use custom lists made from their own gathered information to find more hosts.
In our Network Analysis lab, we studied the Falsimentis host fm-tetris. Falsimentis often uses "fm" in their hostnames. An attacker might make a wordlist with common host names that use this pattern. Let's make a new list of host names from namelist.txt.
Let's break down the command:
awk: It is used to search for patterns and perform actions on files or input streams.
print "fm-"$1: The awk program will display "fm-" before the first column of each entry in the file, adding "fm-" to each name in the list.
{ ... }: The curly braces {} enclose the action to be performed on each line of the input.
Next, let's run the dns-brute scan again with the falsimentis-namelist.txt file.
By creating a custom wordlist with "fm-" in names helps us find more systems from the DNS server.
We'll wrap up this lab by checking what incident responders see after a DNS interrogation attack. The DNS server is set up with ISC's recommended logging settings, not the default ones.
These logs were generated by our attacks during the lab exercise. One point to notice is that the zone_transfers file is empty, indicating that there are no logs of successful zone transfers. Let's examine the contents of the client_security log file with cat.
The server logged a failed zone transfer attempt from the host 172.30.0.1 (the Slingshot Linux host). This failed attempt is useful for tracking the IP address and spotting other suspicious activity.
Next, let's examine the first few lines from the queries file.
This log shows all DNS queries sent to the server. A busy DNS server will generate lots of log data, so we must manage and save old logs carefully. However, it gives valuable information for security monitoring, including:
Source IP address of the resolving client
Host name attempted to resolve
Date and time for the DNS request
The record type (A, AXFR, MX, etc.)
DNS request ags: +E(0)K means the request is recursive (+), enhanced (E(0)), and asks for a DNS cookie (K).
It's best to use a SIEM platform for analyzing query logs, but we can also do some basic analysis with command line tools like cut and uniq to check event counts over time.
This command shows Event Per Minute (EPM) data. Initially, there are few attacker requests, but at 13:58, there are 256 requests in under a minute, suggesting a switch to an automated tool. Later, there are two big spikes with 4655 requests each.
DNS analysis helps spot signs of early attacks and is also useful for checking how attackers control systems after exploiting them.
Check the DNS log at ~/labs/dns/dns.log. It’s from a Zeek capture and formatted for our lab. Look at events per hour and minute to spot any timing patterns that might suggest a compromise.
Let's start by examining the first few lines of the dns.log file using the head utility.
The log begins on 2021-08-15 at 16:08:14. Let's use the tail command to check the end of the log.
The log spans about 24 hours based on the start and end times.
In this log file, the IP address is the DNS resolver client, and it is the same for all log entries. Now let's evaluate the events per hour by extracting only the hour portion of the time field.
The log shows DNS requests per hour, like 16:00 or 17:00, with counts ranging from 2847 to 5764. No clear pattern or attack indication is visible.
Now, let's use the same awk command but count events per minute instead of per hour.
At first, the data seems unclear, but if you examine it closely, you'll notice a pattern: there are many more DNS requests every five minutes.
While this isn't enough to characterize a specic attack, it may be something that would be valuable to investigate as an anomaly that is unlike normal network activity.
