DNS tunneling detection shows why DNS visibility still matters

At a glance

What this is: This is a Wazuh walkthrough for detecting DNS tunneling by combining packet capture, log ingestion, and rule logic to spot covert DNS activity.

Why it matters: It matters because DNS is often permitted by default, so security teams need behavioural detection that can expose covert channels used for exfiltration or command-and-control.

👉 Read Wazuh's guide to detecting DNS tunneling with Wazuh

Context

DNS tunneling is a covert channel that abuses permitted DNS traffic to move data and commands past controls that inspect ports but not content. In practice, that means a network can appear normal while endpoints quietly exchange encoded payloads with attacker-controlled infrastructure.

For identity and access teams, the relevance is indirect but real: covert DNS activity often follows compromise of credentials, endpoints, or workloads, then supports persistence and exfiltration. That makes DNS telemetry part of broader detection engineering, not just a network hygiene issue.

Key questions

Q: How should security teams detect DNS tunneling in enterprise networks?

A: Use behavioural correlation rather than single indicators. High-entropy query strings, unusually deep subdomains, and TXT or NULL records become far more meaningful when they occur together from the same host. Forward endpoint or resolver logs into a central detection platform so analysts can compare patterns over time and investigate the systems that deviate from normal DNS behaviour.

Q: Why does DNS tunneling remain effective even when firewalls are in place?

A: Firewalls usually allow DNS because name resolution is required for business operations. Attackers exploit that trust by hiding commands or data inside permitted traffic, so the network sees approved protocol usage rather than obvious exfiltration. The problem is not DNS itself, but the lack of content-aware inspection and behavioural baselining around it.

Q: What signals indicate DNS traffic is being used as a covert channel?

A: Look for long pseudo-random labels, repeated queries to the same suspicious domain, deep subdomain nesting, and unusual record types such as TXT or NULL. A single signal may be benign, but a combination of them usually means encoded data or command traffic is being moved through a trusted protocol.

Q: Who is responsible when DNS tunneling is missed in an environment?

A: Responsibility is shared across network security, SOC, and endpoint teams, because the failure is usually one of visibility and correlation rather than a single missing control. In practice, leaders should assign ownership for DNS telemetry, detection engineering, and incident triage so tunnelled activity is not treated as a niche network issue.

Technical breakdown

How DNS tunneling encodes data inside ordinary queries

DNS tunneling works by hiding payloads inside subdomains, query names, and sometimes record data so that the traffic looks like routine name resolution. Attackers often use long, random-looking labels because base32 or base64 fragments survive DNS character constraints and can be reassembled server-side. The tunnel endpoint then acts like a covert relay, receiving queries, decoding the content, and sending instructions or exfiltrated data back through responses. Because resolvers and firewalls usually trust DNS by default, the channel can persist unless defenders inspect patterns rather than just destination and port.

Practical implication: inspect DNS content and structure, not just volume or destination.

Why entropy, label depth, and record type matter together

No single DNS indicator proves malicious intent. High-entropy strings can appear in legitimate services, and deep subdomains can exist in modern SaaS naming schemes. The detection value comes from correlation: long alphanumeric labels, unusual depth, uncommon record types such as TXT or NULL, and repeated queries to the same suspicious domain. When these features align, they are more consistent with encoding and transport than with normal name lookup. This is the same reason good detections should combine multiple weak signals into a stronger behavioural rule.

Practical implication: build composite detections that require two or more indicators before alerting.

How log-based DNS monitoring fits into SIEM and XDR workflows

The Wazuh approach shown here captures DNS traffic with tcpdump, writes it to a local log, and forwards that log into a SIEM and XDR workflow for parsing and alerting. That architecture is useful where full packet inspection is unavailable, because the detection engine can still extract fields like query name, source, destination, and record type. It is not a replacement for network sensors, but it gives teams a practical control when they need low-friction visibility on Linux endpoints and can operationalise rules centrally.

Practical implication: treat endpoint DNS logging as an enrichment source for central detection and triage.

Threat narrative

Attacker objective: The attacker aims to maintain hidden communication with the victim system while moving data or commands without triggering standard network controls.

1. Entry begins when an endpoint or workload is already compromised and starts using allowed DNS traffic as a covert channel.
2. Escalation occurs as the tunnel carries encoded commands or exfiltrated data through high-frequency queries, deep subdomains, and nonstandard record types.
3. Impact is covert command-and-control, data theft, or staging that continues while perimeter controls see only permitted DNS activity.

NHI Mgmt Group analysis

DNS tunneling is a visibility problem before it is a malware problem. Perimeter controls that allow DNS by default often miss the behavioural change that matters, which is encoded traffic moving inside a trusted protocol. That makes DNS telemetry a governance issue for network security teams, not just an incident-response curiosity. The practical conclusion is that DNS needs content-aware detection, not only transport allow-listing.

Composite detection is the right model for covert-channel hunting. High entropy, long labels, deep subdomains, and TXT or NULL records are each imperfect signals on their own. Combined, they create a much stronger indicator of transport abuse. This aligns with framework-driven detection engineering in MITRE ATT&CK and with control expectations under NIST CSF for continuous monitoring. Practitioners should tune for correlated behaviour, not single-rule triggers.

DNS tunneling often rides on earlier control failure elsewhere. A tunnel is rarely the first weakness. It usually appears after endpoint compromise, stolen credentials, or an exposed workload has already created a foothold. The named concept here is trusted-protocol concealment: abuse of an approved protocol to hide adversary communications inside normal traffic. Teams should treat that as a signal to improve detection coverage across endpoint, network, and identity layers.

SIEM correlation only works if the underlying telemetry is usable. The post shows a simple but operationally relevant pattern: capture with tcpdump, forward to a log pipeline, and write rules that extract fields consistently. That is a reminder that observability design matters as much as rule content. If DNS logs are not structured, retained, and searchable, the detection logic loses most of its value. Practitioners should make DNS observability part of their baseline monitoring design.

Network exfiltration controls still need identity context. DNS tunneling usually follows compromise of a host, account, or workload identity, then turns that access into a covert channel. That intersection matters for IAM and PAM teams because standing privilege, unmanaged service accounts, and exposed endpoints create the conditions for tunnelled abuse. The conclusion is simple: reduce the number of identities that can open the door, then detect the traffic that tries to leave through it.

What this signals

Trusted-protocol concealment is the broader lesson here: once adversaries can hide inside allowed traffic, traditional perimeter thinking breaks down. Teams should plan for detection that correlates protocol behaviour, endpoint context, and identity posture rather than relying on port-based trust.

DNS telemetry becomes more valuable when it is treated as an identity-adjacent control surface. A compromised workload identity can generate covert traffic long before a human sees a symptom, so IAM and PAM teams should coordinate with SOC and network engineering on shared detection criteria.

If your programme already tracks workload and service-account exposure, connect that work to DNS anomaly review. The goal is not to chase every odd query, but to reduce the set of identities that can create a persistent covert channel and to shorten the time to detect when they do.

For practitioners

• Implement composite DNS detection rules Correlate entropy, subdomain depth, and record type so alerts fire only when at least two tunneling indicators appear together.
• Forward endpoint DNS logs into central detection Use endpoint collection and SIEM parsing to extract query name, source, destination, and DNS type from monitored traffic.
• Baseline normal DNS behaviour by host Measure query frequency, common domains, and record-type distribution per system so anomalies stand out quickly during triage.
• Harden the systems that can generate covert traffic Reduce standing privilege on endpoints and workloads so a compromised identity cannot sustain hidden DNS communications for long.
• Rotate and compress DNS logs on a fixed schedule Use logrotate to retain recent evidence, limit disk growth, and preserve readable history for investigation and tuning.

Key takeaways

• DNS tunneling succeeds because defenders often trust the protocol more than the traffic pattern.
• Correlating entropy, depth, and record type gives stronger detection than any single indicator on its own.
• Visibility into DNS should be treated as part of identity-adjacent monitoring, not only network operations.

Key terms

• DNS Tunneling: DNS tunneling is the use of DNS queries and responses to carry hidden data for command-and-control or exfiltration. Because DNS is commonly trusted and lightly inspected, attackers can hide malicious communication inside traffic that looks routine at first glance.
• High Entropy Query: A high entropy query contains a string that looks random rather than human-readable. In DNS monitoring, that often suggests encoded payloads such as base32 or base64 fragments, especially when the pattern appears in long labels or repeats from a single host.
• Deep Subdomain Structure: Deep subdomain structure means a DNS name contains multiple nested labels before the registered domain. Attackers use this structure to split and move encoded data within DNS size limits, so repeated depth combined with other anomalies is a useful tunneling indicator.
• Covert Channel: A covert channel is any communication path that hides its true purpose from normal security controls. In DNS tunneling, the protocol remains legitimate, but the content being exchanged is not, which makes behavioural inspection essential for detection.

What's in the full article

Wazuh's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step tcpdump monitoring setup on Ubuntu so the DNS traffic capture can be reproduced exactly.
• Full decoder and rule definitions for extracting DNS fields from /var/log/dns_monitoring.log.
• Systemd and logrotate configuration details for keeping the monitoring service running and the log file manageable.
• Example dig test commands that trigger each rule so teams can validate their own detections.

👉 See Wazuh's full walkthrough for the decoder rules, test commands, and log rotation setup.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It gives security practitioners a common baseline for connecting identity control to broader detection and resilience work.