TL;DR: DNS attacks exploit a protocol that most networks still trust by default, and CyberFOX cites CISA guidance that DNS plays a role in roughly 91% of malware attacks. The security issue is not that DNS is broken, but that visibility, filtering, and anomaly detection remain too weak for the amount of malicious traffic moving through it.
At a glance
What this is: DNS attacks abuse a trusted resolution layer to redirect traffic, hide command and control, exfiltrate data and disrupt services.
Why it matters: Security and identity teams need DNS visibility because trusted network plumbing can become a covert path for credential theft, malware delivery and lateral activity.
Context
DNS is the naming system that turns human-readable domains into IP addresses, and that utility has made it a trusted layer in most environments. The security gap is that a protocol designed for reachability is still treated as low-risk inspection-wise, even though attackers routinely abuse that trust to move victims toward malicious destinations or to hide traffic inside normal lookups.
For IAM, PAM and broader security teams, the identity angle is indirect but real: DNS abuse often supports credential theft, malware callbacks and access to services that should never have been reachable. The article is focused on network-layer abuse, but the underlying governance issue is the same one that appears across identity programmes when default trust outlives the controls built to verify it.
Key questions
Q: What breaks when DNS is not governed as part of the trust stack?
A: When DNS is weakly governed, users and applications can be sent to the wrong destination before TLS, SSO, or DMARC can help. That creates a control failure at the first trust decision, which means downstream protections may be perfectly configured and still miss the attack path entirely.
Q: Why do DNS attacks often lead to credential theft or malware delivery?
A: Because attackers abuse the trust built into name resolution. If a user is redirected to a convincing fake site or a malware domain, the DNS layer has already enabled the first step of compromise, which makes credential capture, payload delivery, and command-and-control much easier to execute.
Q: What are the signs that DNS tunnelling is bypassing normal controls?
A: Look for unusually long queries, high-frequency lookups, repeated requests to obscure domains and traffic patterns that do not match normal application behaviour. Those signals matter because tunnelling hides data and command traffic inside a protocol that many teams still treat as routine background noise.
Q: How should security teams balance DNS filtering with PAM and password management?
A: Use DNS filtering to block malicious destinations early, then reduce blast radius if credentials are captured by tightening privileged access and improving password hygiene. The three controls solve different parts of the same problem: reachability, privilege and credential value.
Technical breakdown
Why DNS abuse works at the protocol layer
DNS was built for fast, distributed name resolution, not for adversarial inspection. Queries are high-volume, frequently benign, and often allowed to pass with minimal scrutiny because blocking them would break basic connectivity. That makes DNS attractive for attackers seeking redirection, covert channels or command-and-control. The protocol itself is not the flaw. The flaw is the assumption that a universal control plane can be trusted simply because it is foundational and operationally necessary.
Practical implication: treat DNS as a monitored control surface, not as background traffic that can be ignored.
How spoofing and tunnelling turn trust into exposure
DNS spoofing works by poisoning resolver or cache responses so a legitimate name resolves to a malicious IP address. DNS tunnelling takes a different path by encoding data inside queries and responses, which lets malware communicate or exfiltrate data through channels that resemble ordinary lookup activity. Both techniques exploit the same governance gap: defenders often optimise for availability and miss the need to inspect content, structure and behaviour of DNS exchanges.
Practical implication: combine domain reputation checks with query-pattern analytics, not just allow-and-forward resolution.
Why DNS filtering changes the control point
DNS filtering moves the decision earlier in the path by evaluating the requested domain before the endpoint connects to a destination. That can block phishing sites, malware infrastructure and command-and-control destinations before a session forms. For defenders, the architectural value is not just blocking bad domains but shrinking the attack surface created by default trust in name resolution. It also gives teams a place to apply policy consistently across roaming users, remote devices and branch networks.
Practical implication: enforce policy at lookup time so malicious destinations never receive traffic in the first place.
Threat narrative
Attacker objective: The attacker wants to redirect victims, steal credentials or keep malware communicating with external infrastructure without triggering obvious blocking.
- Entry begins when a user or host resolves a domain that an attacker has poisoned, registered deceptively or hidden inside DNS traffic.
- Credential access or payload delivery follows when the victim is redirected to a fake site or malware is delivered after the malicious lookup.
- Escalation occurs as DNS tunnelling or command-and-control lookups let the attacker maintain communication, move data or direct additional malicious activity.
- Impact lands in credential theft, data exfiltration, service disruption or malware-enabled compromise across the affected environment.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
DNS trust is a policy problem, not a protocol problem. The article correctly frames DNS as a trusted layer that defenders still under-monitor. That matters because trust at the transport and naming layers often outlasts the controls designed to supervise them, especially in distributed environments with remote users and mixed devices. Practitioners should treat DNS as a governed control point rather than a passive utility.
DNS filtering is a preventive control, but it only works when paired with visibility. Blocking malicious destinations at lookup time can prevent a session from ever forming, which is materially different from reacting after payload execution. But filtering alone does not solve tunnelling, resolver poisoning or low-and-slow abuse unless organisations also inspect patterns, anomalies and resolution behaviour. The operational lesson is to combine block decisions with telemetry.
Default trust creates a detection gap that attackers can exploit at scale. DNS traffic is high-volume and often allowed through without content-aware scrutiny, which makes it attractive for redirection, malware callbacks and exfiltration. The named concept here is DNS trust gap: the distance between how much a protocol is relied on and how little it is actually governed. Security teams should close that gap before it becomes an access path.
For identity programmes, DNS abuse is an upstream access risk. Credential theft and phishing via DNS redirection do not start in IAM, but they frequently end there, because compromised identities unlock downstream systems and business processes. That means identity governance cannot stop at authentication controls alone. Practitioners should align DNS inspection with PAM, MFA and credential hygiene so one weak lookup does not become an enterprise compromise.
Layered control remains the right model, but it must be sequenced correctly. The article's three-pronged framing around DNS filtering, PAM and password management reflects a real control pattern: prevent malicious reachability, reduce privilege blast radius and limit credential value if capture occurs. The practitioner conclusion is straightforward. If DNS is unfiltered, identity controls are absorbing risk that should have been stopped earlier.
What this signals
DNS trust gap: when a foundational protocol is still treated as low-risk, attackers can use it for redirection, covert communication and malware delivery. Security teams should move DNS into the same governed inspection model they already apply to other control surfaces, because default trust is the condition attackers are exploiting.
For practitioners, the main shift is to treat filtering as a preventive control and anomaly detection as the backstop. That combination matters because blocking known bad domains will not catch every tunnelling pattern, poisoned cache or lookalike destination.
Identity programmes should account for the fact that DNS abuse often precedes credential theft rather than replacing it. If DNS is not filtered, downstream IAM and PAM controls inherit avoidable exposure that should have been stopped earlier.
For practitioners
- Implement DNS-layer filtering for all user populations Block known malicious domains before connection establishment, including phishing, malware distribution and command-and-control destinations across office, remote and branch users.
- Add anomaly detection for DNS tunnelling patterns Flag unusual query lengths, high-frequency lookups and obscure domains that suggest covert data transfer or persistent malware communication.
- Align DNS controls with PAM and password hygiene Reduce the value of credential theft by pairing DNS filtering with privileged access management and strong password governance, especially for environments with many endpoints.
- Review resolver and cache trust assumptions Audit where recursive resolvers, caches and forwarders accept responses without strong validation, and remove unnecessary trust paths that could be poisoned or abused.
Key takeaways
- DNS attacks succeed because many networks still treat name resolution as trusted background traffic rather than an inspected control surface.
- The article’s central issue is weak visibility into high-volume DNS activity, which attackers use for redirection, tunnelling, malware callbacks and disruption.
- DNS filtering, anomaly detection and tighter identity controls reduce risk by stopping malicious destinations early and shrinking the value of stolen credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001; TA0006; TA0011; TA0040 — Initial Access; Credential Access; Command and Control; Impact | DNS spoofing, tunnelling and DDoS map directly to attacker tactics in this article. |
| Recommendation — Map DNS abuse patterns to ATT&CK tactics and add detections for poisoning, covert channels and disruptive traffic. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and services are monitored to detect cybersecurity events | The article's core gap is insufficient monitoring of DNS traffic and anomalies. |
| Recommendation — Extend monitoring to DNS resolution behaviour and alert on suspicious lookup patterns. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | DNS filtering and anomaly detection are network defense controls central to this article. |
| Recommendation — Apply network monitoring and defense controls to inspect DNS traffic and block malicious domains. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | DNS filtering acts as an early boundary control that stops malicious destinations before connection. |
| Recommendation — Use boundary protection controls to block unsafe DNS resolutions before sessions form. | ||
Key terms
- DNS Filtering: DNS filtering is a control that blocks, allows, redirects, or reroutes traffic based on domain resolution requests. It reduces exposure to phishing, malware, and unwanted destinations by applying policy at the point where devices attempt to resolve names into reachable internet endpoints.
- DNS Spoofing: DNS spoofing is the manipulation of name resolution so a victim is sent to a fake destination instead of the intended service. In identity security, it matters because users may trust the right brand while unknowingly sending credentials or tokens to an attacker-controlled endpoint.
- 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.
- Command-and-control: Command-and-control is the communication channel an attacker uses to issue instructions to malware and receive results back from a compromised host. For XWorm, the channel is encrypted and used for session management, payload delivery, surveillance, and modular expansion of capabilities after compromise.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners who want to connect access governance, credential risk, and security control design across programmes.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org