Several months ago we shared our experiences as a small business DoD contractor using a free DNS filtering tool from the NSA. In that post we mentioned another free tool to help with investigating suspicious DNS queries: Windows Sysinternals’ Sysmon. In this post, we will explore DNS querying in depth, and we will examine how Sysmon can be leveraged to track down suspicious or unwanted activity within your environment. Aside from DNS query analysis being a key consideration for those implementing the NIST 800-171 standard, and/or on track to receive a Cybersecurity Maturity Model Certification (CMMC), it’s also a cybersecurity best practice, and can help secure your small business. First let’s start with a discussion of DNS, then we’ll turn our attention to thwarting DNS attacks using filtering and Sysmon.
Overview of the DNS Protocol
The Domain Name System (DNS) protocol is one of the most overlooked protocols adversaries can leverage to infiltrate your network. Before we dig into how the DNS protocol is compromised, it’s essential to understand a few fundamentals of what DNS is. DNS is essentially the phonebook or contact list of the Internet. The DNS protocol translates a Domain Name that people can easily remember (e.g., Totem.Tech) into IP addresses such as an IPv4 address, like 151.101.2.133, or a more complex IPv6 address, like 600:1f18:1f:db01:11af:58af:ae11:f645. In other words, when a user types in the name of a website into the browser address bar, a translation must occur that associates the domain that the user types in and the IP address to which the domain is linked. DNS “resolver” then attempts to fetch the IP address in the local cache (on the endpoint) for a record for the requested Domain Name. If the IP address isn’t found in the local cache, the resolver then queries a local (in the organization) DNS server for a record. If an IP Address still can’t be found, it goes through a recursive DNS query in which it queries different nameservers (external to the organization) to get the IP address of the domain. During this translation process, a small amount of data can be transferred, possibly to external destinations. Adversaries can exploit this information transfer to initiate a DNS tunneling attack, which we describe in the next section, along with a couple of other different suspicious DNS uses.
DNS tunneling as a cyber attack technique
DNS tunneling can consist of data exfiltration, command & control communication (C2) as part of lateral movement, malware infestation, and credential theft through DNS cache poisoning. DNS provides a relatively unabated channel for adversaries to establish a virtual tunnel, as the protocol itself is required to flow directly through a perimeter firewall. DNS is quite simple and robust, but it was primarily designed for usability and not security. Monitoring DNS traffic can expose suspicious activity in near real-time, helping to avoid breaches. Still, due to the sheer number of DNS interactions, most security software won’t be equipped to analyze the data packets that are exchanged, and it’s nearly impossible to apply detection logic to identify every incident. Therefore, you’ll need to depend on the correlation of various anomalies to point to where a DNS tunnel attack may have occurred. The following are a couple of “eyebrow raising” attributes of DNS queries that can indicate your organization should conduct a more thorough analysis:
- Obscure domain name requests: Non-dictionary words or random characters in a domain name (e.g., abejubh.com or 12.345.67.iuasd.com) can be potential rogue servers attempting command & control methods and should be immediately blacklisted. In a nutshell, it’s worth investigating if the domain name doesn’t roll off the tongue or is isn’t super memorable (like totem.tech!).
- Newly registered domains: Many attackers quickly setup and teardown temporary domains or websites from which they launch attacks or host malware. Newly registered domains (under a month old) in DNS queries can indicate a malware infestation or C2 link has been established in the organization.
- Geographic location of a DNS server: Geographic considerations are another factor that could be used. For example, large amounts of DNS traffic to parts of the world where you don‘t conduct business can indicate dubious activity. Therefore, it’s an excellent practice to flag top-level domains where known bad actors tend to reside (e.g., .cn (China) and .ru (Russia)).
- Abnormal volume of DNS: An atypical amount of DNS queries, especially during off hours, could indicate a DNS tunnel within your network. This is because a DNS tunnel can only carry small amounts of data at a time through the query. Therefore, it would require several queries to run commands or to exfiltrate data, thereby leading to a spike in the number of queries at any given point.
How DNS filtering can help thwart attacks
One way to protect your environment from the attacks described above is by enabling DNS filtering on an Intrusion Detection System (IDS). Using DNS filtering can flag suspicious DNS transactions based on policy, and block known malicious domains or IP addresses. In addition, IDS DNS filters can be set up to check websites for malicious code. For example, JavaScript is a primary vehicle of attack for these malicious websites. Based on an organization’s IDS policy, once malicious code is detected, these sites can be blocked outright or flagged as an event for a technician to examine later.
Below is an example of a DNS query attempt flagged by the Suricata IDS built into AlienVault sensors. In this example, the domain was identified by the IDS DNS filter as a Potentially Unwanted Program (PuP). The Restoro domain is host to a “system optimizer.” The site itself uses pop-ups to lure users into paying for a service that “cleans” a system registry. Microsoft published an article stating they do support nor recommend the use of registry cleaners. While Restoro is more of a questionable quick-fix product than a legitimate threat, it is still a site you probably don’t want your users visiting. Similar products have been compromised in the past and used to distribute malware.
Analysis of a suspicious DNS query using Sysmon
While the IDS alert raw data (not shown in the above image) indicates when the query occurred and what machine executed the query, we’d still like to know exactly what process on the machine kicked off the query, so that we can answer some questions: Is there malware on the machine that is communicating to this site? Is there any evidence of a C2 attempt?
Luckily for us there is additional information in the alert we can use to dig deeper, if we have the right tools in place. For instance, the alert has a timestamp. From the timestamp, we can perform further forensic analysis by examining various logs on the asset that triggered the alert. This is where Sysmon comes into play. Sysmon is a Microsoft Windows Sysinternals tool installed as a service to log various events and information to the Windows event logs. Handily, a DNS query event ID was incorporated in 2019. This allows administrators to quickly track down offending applications that may be connecting to unwanted sites or exhibiting other undesirable behavior.
By default, DNS query logging in Symon is not enabled. However, pseudonymous computer security expert SwiftOnSecurity produced a streamlined Sysmon configuration to enable Event ID 22: DNSEvent (DNS query), as well as clear up a lot of the noise created by enabling the baseline Sysmon service.
One of the features of Sysmon is that its logs can be accessed from a familiar location: Windows Event Viewer. In the Event Viewer (which is accessible by right-clicking on the Windows Start menu), Sysmon logs are viewable under Applications and Services → Microsoft → Windows→ Sysmon. Here, we can search and filter like any other Windows event log.
With Sysmon configured to collect Event 22 logs, we can dig into the Event Viewer logs on the machine in question and investigate further into the DNS query alert identified by the AlienVault DNS filter. The screen capture below shows the event log that indicates the name of the process (listed as “Image:” in the screenshot) performing the DNS query. Identifying the process allows us to focus on offending applications that may be attempting to connect to unwanted sites or performing other undesirable behavior.
In this case, a user was browsing with Chrome to a website that triggered a DNS query indicated in the “QueryName:” field. It appears there were no other connection attempts going to this website and Sysmon identified the executable as the browser, so there probably isn’t much of a threat. However, if the “Image” field indicated a rogue Windows executable — .exe file — with a random name or an app that should not be communicating through a DNS query, especially if that .exe triggered multiple DNS query events, we would definitely want to investigate further. In this instance, we may just want to warn users that some sites may trigger queries to unwanted domains (e.g. Restoro) and possibly blacklist the website that generated the DNS query.
Configuring Sysmon to log DNS Queries for analysis
Installing and configuring Sysmon for DNS query analysis is relatively easy and free. Sysmon can be resource intensive however, so we wouldn’t recommend installing or configuring it on machines with less than 4 GB of RAM and/or 500 GB of hard drive space. This section will briefly outline the steps to get Sysmon to collect the Event ID 22: DNS Query logs.
1. Download Sysmon from Microsoft (https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon) and extract the .zip file.
2. Download the Sysmon configuration from SwiftonSecurity (https://github.com/SwiftOnSecurity/sysmon-config) to the same directory you downloaded and extracted Sysmon.
3. Install Sysmon with the SwiftonSecurity configuration through the command prompt.
- For a 32-bit system, open an admin-enabled command prompt and navigate to the directory that you downloaded Sysmon to and type the following command:
sysmon.exe -accepteula -i sysmonconfig-export.xml
- For a 64-bit system, open an admin-enabled command prompt and navigate to the directory that you downloaded Sysmon to and type the following command:
sysmon64.exe -accepteula -i sysmonconfig-export.xml
4. Enable audit process tracking in the Local Security Policy.
- Open Local Group Policy Editor and expand the Computer Configuration → Windows Setting → Security Settings → Local Policies → Audit Policy → Audit Process Tracking.
- Configure the properties for both ‘success’ and ‘failure’.
5. Ensure the Symon64 service is running (or Sysmon for 32-bit systems).
- Click the Windows Start menu and type services.msc and hit Enter. Scroll down to the “Sysmon” service and ensure it shows as “Automatic” and “Running”.
Wrapping Up
That’s the basic run-through of how you can perform DNS query analysis to detect potential attacks using Sysmon. Detecting DNS query anomalies is one of many ways to thwart DNS query attacks. If you’d like to know more about how logging DNS query events and analysis can help protect your organization, or how it relates to CMMC compliance, grab a seat in one of our Workshops! Or, drop us a line, and I’m sure one of us will talk your ear off about how to better monitor and protect your organization! We’re geeky like that!
Always keep an eye on your six!
— Matt
