Table of Contents
In my role as Cyber Threat Intelligence Researcher at Lumu, I sometimes find stories that both show the scope of what we do, as cybersecurity analysts, and remind me of the importance of Lumu and network visibility in defending our customers. I would like to tell you of one such event — a DNS tunneling attack.
This true story is the perfect example of the importance of DNS tunneling detection in your cybersecurity arsenal. I always have my eye on intelligence, analytics, and anomalies across our customers and, in doing that, I recently uncovered a tunneling incident which had spread across key authentication and management systems of a multinational insurance company, based in North America.
It was a very serious case: these systems controlled authentication and key management traffic for the entire company. The insurance firm operates almost 50 such servers across its branches, and DNS tunneling activity was detected on all of them.
The most alarming factor was that the attacker had already established active channels for data exchange and was in constant communication with the compromised servers. I had discovered a hidden network of DNS tunneling.
The Start of This DNS Tunneling Story
When this customer decided to partner with Lumu they had recently come out of a ransomware incident and decided they needed more visibility on their network.
In fact, the incident the insurance company had had before we arrived probably contributed to this attack. The domain that I found on the Lumu platform when it first alerted us to potential DNS tunneling had been linked to the incident and that’s why it caught my attention.
DNS tunneling is a cyber attack method that uses subdomains and DNS records (such as MX and TXT) to send and receive information. This allows them to avoid traditional security measures, such as firewalls, antivirus protection, Endpoint Detection and Response (EDRs), and email security, and more complex intrusion detection and intrusion prevention systems. This makes DNS tunneling detection unlikely when only using traditional security tools.
In the previous incident, the SecOps team had quickly implemented domain filtering rules to block access to the known malicious domains — but that highlights one of the strengths of a DNS tunneling attack: attackers can rapidly rotate domains or leverage a pool of new, seemingly benign ones, evading simple filtering measures designed to stop them. Many firewalls do not have the ability to operate at the higher levels of the OSI (open systems interconnection model) and cannot control DNS traffic.
The organization’s firewall could not block the attack and the technology that the insurance organization had was not able to detect DNS tunneling. They were using a well-known endpoint protection suite which was only seeing connections without context. The repeated access to their network by the threat actor appeared to their SecOps team simply as random, non-malicious contacts.
How Did Lumu Mitigate the Risks from DNS Tunneling?
We had a session with the customer and explained that we had found DNS tunneling across all their key authentication and management systems. They asked us for help to mitigate the risk, so we conducted a forensic investigation to detect the origin.
One challenge that faced us was that, even if just one of the domain controllers in the network was infected, they were all linked. This one talks to that one, and that one talks to this one, and so on, so this makes for a very difficult chain to unravel.
We helped the customer set up a DNS Sinkhole across their environment to immediately isolate and disrupt communication channels used by the threat actor while we continued our investigation.
What do I mean by a DNS Sinkhole? Instead of allowing malicious or unwanted traffic to reach its intended destinations, we redirected and controlled all requests to those domains, effectively cutting off any further attacker communication attempts and ensuring the compromised systems remained secure during analysis.
At that point, our goal is not to stop the internal malware from communicating entirely — we need the activity to continue so that we can trace the origin of the communication and gather critical intelligence to effectively neutralize the attack.
What Kind of DNS Tunneling Attack Was This?
From our investigation we were able to draw some conclusions, which I can share with you now.
When it comes to DNS Tunneling, the objective can be two things: exfiltrating data or command and control.
The DNS tunnel might not be made to filter out large amounts of data; however, we recorded the total data exfiltrated from one device at 37 megabytes of sensitive data.
The attackers exfiltrated detailed network topology data and user access credentials, leading us to conclude that their focus was on reconnaissance and facilitating lateral movement within the network. The incoming data suggested they were gathering system information, accessing internal directories, and probing for potential vulnerabilities. Based on our analysis, this incident ended up being command and control rather than data exfiltration.
Who Was the Attacker?
We were able to build some intelligence on the attacker, which can also be helpful in understanding their motivations and tactics.
To find the origin of a DNS tunneling attack, we have to follow a string of clues. The attacker used the tactic of forming a chain of domain records. One NS (Name Server) register links to another NS, that, in turn, points to multiple intermediary servers, creating a cascade effect that complicates the tracing process.
We detected at least 52 nodes in different countries with different infrastructure — but even that is not the end. All of this is designed to prevent us from seeing where the origin of the attack is. Despite this, we conducted a detailed threat hunting exercise and uncovered that the attack originated in Russia.
Where did I uncover evidence for this? I traced the attack by analyzing the DNS traffic patterns and the specific server responses, noting their behavior and routing paths. The infrastructure’s configuration, timing of requests, and unique server headers pointed to regional practices and techniques associated with Russian cyber operations. Cross-referencing this with threat intelligence databases and known attack patterns solidified Russia as the origin.
What Was the Attacker’s Final Goal?
We identified that in total, 58 megabytes of critical internal information were accessed by the attacker. Thankfully, Lumu was able to quickly detect and disrupt the DNS tunneling activity, preventing a more severe incident.
In this case, the primary objective of the attacker was to establish a foothold within the network for potential command and control (C2) operations. By maintaining covert communication channels, they tested their access, manipulated internal pathways, and positioned themselves for greater control or influence. If their objective had solely been immediate damage, they could have escalated their activity and deployed more disruptive measures within a short timeframe.
Since this attack originated from a Russian-based threat actor, there was clearly a strategic intent to establish persistent control within the targeted environment, consistent with known Russian cyber tactics. Rather than focusing solely on data exfiltration or overtly destructive attacks, their approach often involves creating reliable access points for extended operations, leveraging command and control to further infiltrate or manipulate the network.
Is this DNS Tunneling Attack Over?
If the organization that was targeted was a single small team, with only one endpoint linked to the DNS tunneling event, you can easily isolate it and start forensic work. Here, however, there are many systems connected to the servers and the source of the attack is much more difficult to locate.
In this case, working with a large entity such as a multinational company takes time and decisions are not made quickly, but fortunately, the evidence gathered by Lumu was instrumental in enabling the organization’s C-level executives to act decisively. The source was immediately isolated and thoroughly investigated to determine the initial vector and take corrective measures based on what was found in these systems. At this point, we can confidently say that the DNS tunneling attack is over.
Why Is DNS Tunneling Hard To Find and How Did Lumu Catch It?
The traditional security stack is not capable of detecting malicious behavior on DNS packages, because they are, in quotation marks, “legitimate traffic”. The attackers simply communicate with the victim’s network and return the communication, as apparently normal behavior between the external infrastructure and the user. It is very difficult to identify and expose.
Detecting when an organization is being breached by DNS tunneling requires the ability to identify anomalies and suspicious behavior. Indicators of Compromise, such as domains or linked IP addresses used in DNS tunneling, are difficult to detect because they are often custom-generated for a specific attack. Attackers typically use these indicators exclusively for one target, and the associated IP addresses are ephemeral, often reassigned shortly after the attack. This makes detecting DNS tunneling nearly impossible without advanced anomaly and behavior analysis.
In the case of this insurance company, how did Lumu alert us to the DNS tunneling attack and what would you look for in your Lumu interface?
Lumu uses advanced machine learning to understand when network traffic is ‘normal’ — when there are exceptions and when Lumu finds a high possibility of an event such as DNS tunneling it alerts the SecOps team so that they can take action. While monitoring the customer’s Lumu environment, we noticed anomalous activity and alerted both the DGA and Tunneling anomalies sections of their Analytics section in the portal.
If you would like to see more about how Lumu can improve DNS tunneling detection and visibility on your network, open a Lumu Free account today.
