Introduction
DNS tunneling is one of the most elusive and dangerous tactics cybercriminals use to bypass security protocols. By exploiting the Domain Name System (DNS), attackers create hidden channels of communication, allowing them to exfiltrate data or communicate with malicious servers unnoticed. For organizations, DNS tunneling presents a major challenge because traditional security tools like firewalls and intrusion detection systems (IDS) often miss this type of attack.
In this comprehensive guide, we’ll delve into what DNS tunneling is, why it’s a critical threat, and how to detect and investigate these attacks using Splunk and network traffic analysis. By understanding the nuances of DNS tunneling and leveraging the right detection tools, you can outsmart even the most sophisticated attackers.
What is DNS Tunneling?
At its core, DNS tunneling is a method that attackers use to sneak data through DNS queries and responses, exploiting a fundamental internet protocol. DNS was designed to translate domain names like “example.com” into IP addresses, but attackers have found ways to abuse this legitimate function. They encode their malicious data within DNS traffic, effectively creating a tunnel that bypasses firewalls and IDS systems.
Once this tunnel is established, attackers can perform data exfiltration, communicate with Command and Control (C2) servers, and move laterally within a compromised network – all while flying under the radar. Since DNS traffic is typically trusted and often overlooked, this method can go undetected for extended periods, posing a serious risk to organizations.
Why DNS Tunneling is a Major Threat
The threat posed by DNS tunneling is multifaceted. Here’s why it’s such a significant concern for security teams:
- Hard to Detect: DNS traffic is usually considered legitimate, which means many security tools don’t inspect it closely. This gives attackers the perfect cover to hide their activities.
- Firewall Evasion: Since DNS traffic is rarely blocked, attackers can use it to bypass traditional security measures like firewalls, creating a covert channel to communicate with external servers.
- Persistent Access: DNS tunneling allows attackers to establish long-term communication with compromised systems, enabling them to maintain persistence in the network and carry out extended attacks over time.
- Data Exfiltration: Once inside, attackers can steal sensitive data by embedding it in DNS queries, making it incredibly difficult to trace without specialized monitoring tools.
Given these risks, it’s crucial for organizations to implement robust detection mechanisms and actively monitor their DNS traffic for signs of tunneling.
How to Detect DNS Tunneling Using Network Traffic Analysis with Splunk SIEM
Detecting DNS tunneling requires a deep dive into network traffic to identify suspicious patterns. By using Splunk, an industry-leading SIEM platform, you can monitor DNS traffic in real-time and set up alerts for abnormal activity. Below are key indicators and use cases for detecting DNS tunneling attacks.
Unusual domain names: It is vital to watch out for some key indicators, such as suspicious-looking or overly lengthy domain names often used by attackers to transmit data via DNS tunneling.
High entropy: Moreover, DNS tunneling traffic typically has a higher entropy level due to the encryption or encoding of the data being sent. Therefore, analyzing the entropy of DNS queries is necessary to identify potential tunneling activity.
Repeated or excessive DNS requests: It is also imperative to keep an eye out for repeated or excessive DNS requests, which are often indicative of DNS tunneling. Attackers tend to use specific domain names excessively, which is a red flag for tunneling activity.
Use Case 1: Unusual domain names
Attackers using DNS tunneling often create strange, overly long, or nonsensical domain names to encode data within their DNS requests. These domain names stand out compared to legitimate traffic and are a key indicator of tunneling.
sourcetype=stream:dns
| eval domain_length=len(query)
| stats count by query, domain_length
| where domain_length > <threshold_length>
| eval suspicious_domain=if(domain_length > <threshold_length>, "True", "False")
| table query, domain_length, suspicious_domain
Rule Name: Detect_Unusual_Domain_Names
Replace <threshold_length> with a specific length that you consider unusual for domain names. For example, you might choose 50.
Investigating Unusual domain names
When an alert for unusual domain names is triggered, follow these investigative steps:
Gather alert context: The first step when the “Detect_Unusual_Domain_Names” correlation rule triggers an alert is to gather alert context. This involves taking note of the domain name, domain length, and the source IP address from the alert details. The analyst should then determine the time frame of the event(s) and the associated user account or device.
Check internal logs: Next, the analyst should check internal logs, which involves reviewing proxy, web, and firewall logs to identify any related activity or additional requests to the suspicious domain. The analyst should look for patterns or correlations with other security events to gain a better understanding of the situation.
Analyze the domain’s reputation: The analyst should then analyze the domain’s reputation using threat intelligence platforms like VirusTotal, IBM X-Force, or AlienVault OTX. This step involves gathering information about the suspicious domain and checking if it’s associated with any known malware, phishing, or command and control (C&C) servers.
Examine DNS traffic: To further investigate, the analyst should examine DNS traffic from the source IP address to identify if the suspicious domain is part of a larger pattern of unusual DNS requests or if it’s an isolated event.
Review endpoint data: The analyst should also review endpoint data, including EDR and antivirus logs, for the affected user or device to look for signs of malware, unauthorized access, or other security incidents.
Investigate user behavior: Finally, the analyst should investigate user behavior by reviewing the user’s activity around the time of the event, including emails, logins, file access, and application usage. The analyst should determine if the activity aligns with their typical behavior or job responsibilities.
Validate Findings: Validate the findings by reaching out to the user. If they confirm the activity was not authorized, escalate the issue for further investigation.
Use Case 2: High entropy
Another telltale sign of DNS tunneling is high entropy – or randomness – in DNS queries. When attackers encode data, the resulting queries often appear disorganized or highly variable, which contrasts with typical DNS traffic patterns.
sourcetype=stream:dns
| eval domain_labels=split(query, ".")
| mvexpand domain_labels
| eval shannon_entropy=round((-1 * sum([(countby(domain_labels, _raw)/len(_raw)) * log2(countby(domain_labels, _raw)/len(_raw))])), 2)
| eval high_entropy=if(shannon_entropy > <entropy_threshold>, "True", "False")
| stats count by query, domain_labels, shannon_entropy, high_entropy
Rule Name: Detect_High_Entropy
Replace <entropy_threshold> with a specific threshold that you consider to be high entropy. For example, you might choose 3.5.
This rule calculates the entropy for each label in the domain name instead of the entire domain name. The domain_labels field holds the individual labels of the domain name after splitting it by the “.” delimiter. The rule then calculates the entropy for each label and flags those with an entropy score above the specified threshold.
Investigating High Entropy in DNS
When high entropy DNS requests trigger an alert, proceed as follows:
- Gather Context: Examine the domain, source IP, and entropy levels. Note the timeframe of the suspicious activity.
- Check Logs: Review logs from internal systems such as proxy and firewall logs for patterns that could correlate with the flagged DNS activity.
- Reputation Analysis: Investigate the domain’s reputation to determine if it has been linked to malicious activity or C2 servers.
- Investigate DNS Traffic: Assess whether the high entropy requests are part of a broader attack or isolated incidents.
- Endpoint Data Review: Examine endpoint security logs for signs of malware or unauthorized access that could explain the irregular DNS activity.
Investigate user behavior: Investigating user behavior by reviewing the user’s activity around the time of the event, including emails, logins, file access, and application usage, can determine if the activity aligns with their typical behavior or job responsibilities.
Network traffic analysis: Network traffic analysis is also crucial in identifying signs of data exfiltration, C&C communication, or other indicators of compromise (IoCs).
Validate findings: Lastly, it is vital to validate findings by reaching out to the affected user or their manager to confirm if the observed activity is expected or authorized. If the user confirms they did not initiate the activity, the incident must be escalated for further investigation and mitigation.
Use Case 3: Repeated or excessive DNS requests
Attackers often send repeated DNS requests to the same domain to maintain communication with their C2 servers. Excessive requests to a single domain or a series of similar queries can signal DNS tunneling activity.
sourcetype=stream:dns
| stats count by query, src_ip
| where count > <threshold_requests>
| eval excessive_requests=if(count > <threshold_requests>, "True", "False")
| table query, src_ip, count, excessive_requests
Rule Name: Detect_Excessive_DNS_Requests
Replace <threshold_requests> with a specific threshold for the number of requests that you consider excessive. For example, you might choose 100.
Investigating Repeated or excessive DNS requests
To investigate repeated DNS requests:
Gather alert context: Note the domain name, source IP address, request count, and the time frame of the event(s) from the alert details. Determine the associated user account or device.Analyze DNS Traffic: Identify patterns in DNS traffic from the flagged IP address. Are multiple requests targeting the same suspicious domain?
Log Review: Correlate DNS traffic with other system logs to spot any connections between these requests and suspicious activities.
Threat Intelligence: Use threat intelligence tools to assess the reputation of the domains in question.
Review endpoint data: Examine endpoint security solutions logs for the affected user or device. Look for signs of malware, unauthorized access, or other security incidents that could be generating the excessive DNS requests.
User Activity Analysis: Review the user’s activity around the time of the alert, including logins, emails, and file access, to detect potential anomalies.
Network Analysis: Analyze the broader network traffic to identify any signs of data exfiltration or C2 communication.
Validate findings: Reach out to the affected user or their manager to confirm if the observed activity is expected or authorized. If the user confirms they did not initiate the activity, escalate the incident for further investigation and mitigation.
If you happen to come across some suspicious activity, don’t worry – we got your back. Just take a deep breath and follow your organization’s incident response plan to contain the threat, get rid of the root cause, and bring back the affected systems. And while you’re at it, make sure to update your security controls and monitoring rules to keep those pesky threats at bay in the future. You got this!
Conclusion
DNS tunneling remains one of the stealthiest methods attackers use to evade detection and carry out data exfiltration or C2 communications. But with the right tools and proactive monitoring, organizations can detect and neutralize these attacks before they cause significant damage.
By leveraging Splunk and network traffic analysis, you can protect your organizations data from stealthy attacks such as DNS Tunneling.
