DNS security gaps that let phishing, malware and C2 through

At a glance

What this is: This is a DNS security explainer showing that attackers exploit the resolution layer to redirect users, hide malware infrastructure and bypass later-stage controls.

Why it matters: It matters because IAM, NHI and endpoint teams increasingly rely on DNS controls to reduce phishing, credential theft and risky external connections before a session or workload reaches them.

Context

DNS is the naming layer that translates a domain into an IP address before a connection is established. That design was built for reach and speed, not for deciding whether a destination is trusted, which is why the resolution step is now a control point attackers actively abuse.

That gap matters well beyond web browsing. When users, devices, workloads or even AI tools make outbound requests, DNS becomes an early governance layer for protective DNS policy, especially where roaming endpoints and unsanctioned services can evade perimeter-only controls.

Key questions

Q: What are the best practices for using DNS filtering to reduce phishing and malware exposure?

A: Use DNS filtering as a policy layer, not a standalone control. Prioritise blocking malicious, phishing, and unwanted destinations, then supplement that with content category rules, custom allow and block lists, and encrypted DNS transport. Keep rule design simple enough for teams to manage centrally, and review exceptions regularly so the control remains effective as business needs evolve.

Q: Why is DNS a useful control point for malware and command-and-control traffic?

A: Because almost every internet connection starts with a lookup, DNS gives defenders a chance to stop the session before it begins. If the query is blocked or redirected to a sinkhole, the malware cannot easily reach its operator or download the next stage from the intended host.

Q: What are the signs that DNS tunnelling is being used for command and control?

A: Common signs include high volumes of structured subdomain queries, repeated lookups to a single parent domain, and process activity that aligns with unusual outbound resolution. The key is correlation: suspicious DNS alone may be noisy, but suspicious DNS tied to a newly dropped or masquerading binary is a much stronger indicator.

Q: What is the difference between DNS filtering and a traditional network firewall?

A: DNS filtering acts at the name resolution stage, before a device connects to the destination, while a firewall typically controls traffic after a connection path is already being established. DNS filtering is especially useful for distributed users because it follows the device wherever it goes. Firewalls still matter, but they do not replace early-stage destination screening.

Technical breakdown

How DNS hijacking turns trust into redirection

DNS hijacking changes where a query resolves so the user reaches an attacker-controlled destination instead of the intended service. In practice, that can happen through compromised resolvers, altered local settings, poisoned routing paths or malicious infrastructure that answers queries first. The key mechanism is not breaking encryption or authentication directly, but subverting the lookup that users assume is trustworthy. Once the response is altered, the browser, mail client or app follows the false destination as if it were legitimate. See the DNS Security Guide.

Practical implication: Map outbound name-resolution controls to the systems that can alter DNS responses, not just to web gateways.

Why DNS tunnelling and DGAs evade conventional visibility

DNS tunnelling hides data movement inside query and response patterns, while domain generation algorithms create disposable domains that malware uses to find command-and-control nodes. Both techniques exploit the fact that DNS traffic is routine, high-volume and often under-monitored. Security teams that focus only on blocking known bad websites can miss these patterns because the traffic looks like ordinary name resolution until the query cadence, entropy or destination patterns are analysed.

Practical implication: Inspect DNS logs for anomalous query volume, high-entropy domains and repeated failed lookups that suggest covert communication.

Why protective DNS works earlier than perimeter inspection

Protective DNS inserts policy at the point of resolution, before the connection opens. That means a malicious destination can be blocked before the browser loads the page, the payload downloads or the client contacts its C2 server. This is different from controls that inspect traffic after a session is already established. The architectural value is timing: the decision happens before trust is converted into transport. That makes DNS filtering especially relevant for roaming laptops, home-office endpoints and cloud-connected users.

Practical implication: Use DNS filtering as a pre-connection control and pair it with endpoint and firewall enforcement for layered coverage.

Threat narrative

Attacker objective: The attacker wants to redirect trust away from legitimate destinations and use DNS as the first step toward credential theft, malware delivery or covert command-and-control.

1. Entry begins when a user or device issues a DNS query for a lookalike, hijacked or malicious domain.
2. Escalation occurs when the altered resolution sends the client to phishing pages, malware infrastructure or a command-and-control host.
3. Impact follows when credentials are stolen, malware is delivered, or attacker-controlled communications are established over ordinary DNS-driven access paths.

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 security is becoming a governance layer, not just a network control. The article correctly frames DNS as a high-frequency decision point where trust is established before a session starts. That matters because the control problem is no longer only whether a destination is reachable, but whether the destination should ever be resolved. Practitioners should treat DNS policy as part of access governance across users, devices and workloads.

Protective DNS closes the gap that perimeter tools leave open. Firewalls and endpoint controls still matter, but they often engage after a destination has already been selected. A resolution-stage control changes the timing of defence, which is why it can reduce exposure to phishing, malware and covert communications more effectively than inspection alone. The operational implication is to measure control coverage by query volume and block events, not just by endpoint agent deployment.

DNS abuse now intersects with identity risk because attackers use resolution to reach credentials and unmanaged services. The article's mention of phishing, unsanctioned applications and AI tools is the real bridge point: name resolution increasingly decides whether a human or machine identity is sent toward a trusted service or a hostile one. That makes DNS part of the control surface for browser and computer-use agents and other systems that act through user sessions. Practitioners should align DNS policy with identity trust boundaries, not treat it as a standalone utility.

Query visibility is the differentiator that turns DNS filtering into an investigation control. Blocking alone is useful, but clear logging is what lets teams separate a one-off policy hit from repeated adversary behaviour. That is where the article's emphasis on threat intelligence and compliance reporting becomes important: the control must show what was requested, what was blocked and why. Practitioners should require DNS telemetry that supports both prevention and post-incident reconstruction.

What this signals

DNS policy is moving into the identity trust boundary. As more work happens through roaming laptops, managed browsers and AI-assisted tools, the question is not only whether a destination is malicious, but whether that destination should be reachable from a given identity context. That makes resolution policy part of access governance, not a separate networking concern.

Network-layer prevention now has to be measured by visibility as well as blocking. The control only becomes operationally useful when teams can prove what was requested, what was denied and why. Without that evidence, DNS filtering risks becoming a silent filter rather than a governance control that supports investigation, reporting and continuous tuning.

For practitioners

• Enforce resolution-stage blocking for known malicious domains Apply category-based and per-domain controls before the connection opens, so phishing pages, malware hosts and C2 domains never resolve for users or devices.
• Hunt for tunnelling and DGA patterns in DNS logs Review query volume, failed lookups and high-entropy domains for signs of covert data movement or malware staging, especially from roaming endpoints.
• Extend DNS policy to roaming devices Make sure laptops and mobile devices keep the same DNS protections when users work from home networks or public Wi-Fi rather than the office perimeter.
• Require investigative logging from DNS controls Keep clear query logs that show the requested domain, block decision and threat reason so investigations and compliance reviews can reconstruct user and device activity.

Key takeaways

• Attackers abuse DNS because resolution happens before most other security layers can judge whether a destination is safe.
• The article's central point is that protecting the name-resolution step can cut off phishing, malware delivery and C2 access earlier in the chain.
• Teams get the most value when DNS controls include policy, roaming-device coverage and query logging for investigation.

Related NHI Mgmt Group resources: DNS Security Guide · Network Ports and Protocols Security Guide · Browser and Computer-Use Agent Security Guide

Key terms

• Protective DNS: Protective DNS is the use of DNS policy and intelligence to prevent access to harmful or non-compliant destinations. It combines domain resolution with security controls such as threat blocking, category filtering, and reporting, giving organisations an early checkpoint that works across devices, locations, and work models.
• 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.
• Domain generation algorithm: A domain generation algorithm is code that creates many possible command-and-control domains, usually on a schedule or from seed values. It helps malware recover from server loss and frustrates blocklists because defenders must predict the next set of domains rather than block a fixed address.
• 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. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.