In one of our previous Threat Hunting Use Case blogs, Firewall Targeting DNS, we focused on using firewall data to observe outbound DNS traffic in an environment to identify threats and potential security hygiene issues. One specific objective involved identifying potential endpoints bypassing internal DNS forwarders, in order to address any gaps in security controls or configurations, with the goal of increasing overall visibility into domains queried by endpoints in the environment. With this improved visibility we can more efficiently hunt for malicious DNS activity using internal DNS server logging. As part of our Threat Hunting Use Case series, we’re sharing the use case below, developed and refined by our Research and Development teams, to help you get started threat hunting.
DNS is an essential part of network communication and is often referred to as the phonebook of the Internet. Most network software, including malware, rely on it to resolve domains to IP addresses before it can establish connections over protocols such as HTTP(S), SMTP, and many others. This means that DNS logging will contain a more complete record, not limited to HTTP(S) traffic, of domains access by endpoints in the environment, making it a valuable log source for defenders.
Additionally, network reliance on DNS means that it is available in virtually all enterprise environments. Even in some of the most restricted network segments where HTTP(S) traffic is denied, endpoints may still be able to resolve domains, providing a direct or indirect line to the internet. This availability makes DNS an attractive protocol for attackers to tunnel communications for command and control (C2), data infiltration, and data exfiltration—a technique known as DNS Tunneling. DNS logging is critical to identifying this type of malicious activity, once again proving its worth as an essential log source for all defenders and threat hunters.
Use Case: DNS Query
Objective: The goal of this hunt is to review DNS logs to baseline common domains queried by endpoints in the environment as well as identify potentially infected endpoints by looking for evidence of DNS tunneling, domain generation algorithm (DGA) domains, and traffic to risky top level domains (TLDs).
Log Source & Requirements: DNS query logging
Duration: 30 Days
|What to look for||Why?|
|Review hosts with a high volume of uncommon record types (TXT, NULL, CNAME, etc.).||C2 channels may utilize less common record types to support different commands or functions. For example, a C2 channel may utilize TXT and CNAME requests to retrieve additional information, malware, or commands to execute.|
|Explore uncommon TLDs (.xyz, .me, .biz) and TLDs for geographical regions in which your organization does not regularly operate.||The proliferation of TLDs has made it easier for attackers to continually add new domains to their infrastructure to evade threat intel lists, as well as register doppelganger domains for common websites. Requests for TLDs of geographical regions outside of your organization’s point of presence should be considered suspicious and reviewed, especially regions synonymous with cybercrime and anonymization.|
|Filter on DNS application logs listing the response code NXDOMAIN (domain does not exist) to review hosts seen with a high volume of DNS resolution failures.||There are many benign reasons for failed DNS queries; however, abnormal volume can be a strong indicator of possible threat activity. For example, malware utilizing DGAs will cycle through multiple generated domains until a valid reply is received. Since most of the domains requested will not exist, it will generate a high volume of NXDOMAIN responses. In addition, abnormal NXDOMAIN volume could highlight hosts requesting malicious domains that are no longer active.|
|Look for hosts with high DNS request volume for multiple sub domains of a single parent domain.||A common method of communicating data is by including it in the query string itself in place of the subdomian (commonly encoded using Base64). Identifying requests of multiple suspicious subdomains for a specific domain could help to highlight this method of communication.|
|Identify suspicious requests by reviewing queries of domains that are abnormally long, or domains with a high level of entropy.||Highlighting abnormally long queries with high entropy could help identify encoded data hidden in query strings as well as evidence of DGA domains.|
|Review process names for any unusually named processes or processes that are not regularly seen generating logon requests.||Attackers can simply register new domains to evade detection by threat intel lists. Identifying newly registered domains could help to easily identify suspicious activity.|
Make threat hunting a reality at your organization with ReliaQuest GreyMatter.
By aggregating and normalizing your data from disparate tools, such as SIEM, EDR, multi-cloud, and third-party applications, ReliaQuest GreyMatter allows your team to run focused hunt campaigns, both packaged and freeform that are strategic and iterative. Use ReliaQuest GreyMatter to analyze indicators of compromise retrospectively or perform behavior assessments to visualize abnormal from normal activity.
Ready to kick start your threat hunting program? Get the white paper: Threat Hunting 101.
Check out the other blogs in our Threat Hunting Use Case Series: