DNS spoofing detection shows why DNS telemetry needs active control

At a glance

What this is: This blog post explains how DNS spoofing works and how Wazuh uses Zeek logs, custom decoders, and alerting rules to detect forged DNS responses and host-file tampering.

Why it matters: It matters because DNS manipulation can redirect users to malicious infrastructure, undermine authentication trust, and expose credentials even when upstream identity controls appear sound.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• Only 38% have automated certificate lifecycle management in place.

👉 Read Wazuh's analysis of DNS spoofing detection with Zeek and Wazuh

Context

DNS spoofing is a control failure at the resolution layer. When a client accepts forged or inconsistent name resolution, every downstream control that depends on trustworthy destination identity becomes less reliable, including certificate validation, application allowlists, and security monitoring.

The article uses Zeek and Wazuh to show how that failure can be detected through behaviour, not just signature matching. That is relevant to IAM and NHI practitioners because redirected traffic can be used to intercept secrets, steal session material, or place users and services onto attacker-controlled infrastructure.

For teams running identity-dependent applications, this is a familiar pattern rather than an edge case. DNS spoofing often succeeds because the environment trusts the resolver path more than the application session, which makes the starting position common rather than exceptional.

Key questions

Q: How should security teams prevent DNS spoofing in production environments?

A: Security teams should sign public zones with DNSSEC, validate delegation paths, and monitor resolver behaviour so forged answers cannot be trusted or cached silently. The goal is to make DNS responses verifiable before they influence routing or access decisions. DNS integrity should be treated as an upstream trust control, not an optional network feature.

Q: Why does DNS spoofing create identity risk even when login controls are strong?

A: DNS spoofing can send users to a convincing fake site before any MFA prompt, certificate check, or session control is reached. That means strong identity controls at the application layer do not prevent credential theft if the attacker can corrupt the destination the user reaches. The trust failure happens earlier in the journey.

Q: What do security teams get wrong about DNS spoofing detection?

A: They often watch only for obvious poisoning indicators and ignore endpoint-level overrides, inconsistent resolution, and resolver trust boundaries. In practice, the attacker only needs one weak link in the resolution path, so detection must cover DNS, endpoint integrity, and routing behaviour together.

Q: Who is accountable when DNS spoofing affects authentication traffic?

A: Network, endpoint, and identity teams all share responsibility, but the accountable owner should be defined before an incident occurs. If spoofing can redirect authentication or secrets traffic, the response process should classify it as a trust and access incident, not only a network event.

Technical breakdown

How DNS spoofing changes trust at the resolution layer

DNS spoofing works by forging or manipulating responses so a legitimate hostname resolves to an attacker-chosen IP address. That can happen through cache poisoning, man-in-the-middle interception, or local host-file tampering. The technical risk is not only false answers, but inconsistent answers that break the normal trust assumptions of client-side resolution. Low TTL values can amplify the problem by forcing frequent re-resolution, while forged authoritative flags can make malicious data look legitimate to naive monitoring.

Practical implication: monitor for response inconsistency, unusual TTL values, and resolver trust violations rather than relying on single-point DNS logs.

Why Zeek makes DNS spoofing easier to detect

Zeek is a network security monitoring tool that observes traffic and turns it into structured logs, including DNS request and response metadata. In this workflow, Zeek captures query timing, response codes, authoritative flags, and returned addresses, then forwards those logs for analysis. That matters because spoofing often becomes visible as a pattern across multiple events, not as one isolated packet. Behavioural detection is stronger when the monitoring stack can compare repeated resolutions for the same name and spot mismatched answers from untrusted sources.

Practical implication: retain DNS telemetry long enough to compare responses over time and baseline normal resolution patterns for critical domains.

How host-file tampering becomes a DNS bypass

Modifying /etc/hosts or the Windows hosts file bypasses normal DNS lookup entirely by overriding name resolution locally. That is not DNS spoofing in the strict protocol sense, but it produces the same outcome: the user reaches an attacker-controlled destination while believing the hostname is legitimate. Because this alteration happens on the endpoint, network-only monitoring can miss it unless file-integrity monitoring is enabled. This is why DNS security and endpoint integrity controls need to be treated as one detection surface.

Practical implication: pair DNS monitoring with file-integrity checks on local resolution files and alert on any unauthorised change.

Threat narrative

Attacker objective: The attacker wants to redirect legitimate traffic to malicious infrastructure in order to intercept credentials, manipulate trust, and enable follow-on compromise.

1. Entry occurs when the attacker can influence DNS traffic through cache poisoning, MITM placement, or local file tampering on the endpoint or resolver path.
2. Escalation follows when forged responses or host-file overrides redirect the client to attacker-controlled infrastructure while preserving the appearance of legitimate name resolution.
3. Impact occurs when users or services connect to malicious destinations, allowing credential theft, traffic interception, or follow-on persistence through trusted-looking redirections.

NHI Mgmt Group analysis

DNS spoofing is a trust-layer attack, not just a network anomaly. The key failure is that clients and security tools often assume the resolver path is honest unless evidence proves otherwise. Once that assumption breaks, certificate warnings and redirect patterns become late-stage indicators rather than preventive controls. Practitioners should treat resolution integrity as part of identity trust, not a separate network problem.

Resolution inconsistency is the named concept teams should watch: when the same hostname resolves to different IPs, low TTLs, or untrusted authoritative responses, the environment is signalling policy drift or active manipulation. That concept matters because it gives security teams a concrete way to detect attack behaviour before user impact. The control gap is usually insufficient correlation between DNS telemetry, endpoint integrity, and resolver trust boundaries. Teams should make that correlation a standard detection pattern.

Endpoint file-integrity monitoring belongs in DNS defence. DNS spoofing and local host-file tampering produce the same operational effect, so limiting detection to recursive resolver logs leaves a blind spot. This is a governance issue as much as a technical one because ownership is split across network, endpoint, and identity teams. Practitioners should define who owns local resolution integrity and how alerts are triaged across domains.

DNS manipulation is especially dangerous where secrets or sessions are in motion. The value of a spoofed redirect is highest when the target is authentication, software update, or collaboration traffic that carries tokens and credentials. That makes this a cross-domain issue for IAM and NHI programmes, because redirected traffic can expose service credentials just as easily as human login data. Teams should map high-value destinations and tighten monitoring around them.

Behavioural detection is the practical alternative to brittle signature thinking. The article shows that custom decoders and rules can surface suspicious patterns from Zeek data, which is the right model for spoofing and other trust-subversion attacks. That approach scales better than looking for one malicious payload because the attacker’s success depends on appearing normal at the protocol level. Practitioners should design detections around deviation from expected resolution behaviour.

What this signals

DNS spoofing becomes harder to dismiss as a niche network issue once teams connect it to credential interception, token theft, and trust subversion at the authentication layer. The practical shift is to treat DNS integrity as part of identity assurance, especially for applications that exchange secrets over routinely resolved hostnames.

Resolver trust gap: the real control problem is not whether DNS traffic exists, but whether the environment can prove the answer came from a trusted source and matches expected behaviour. That means security teams should align DNS detections with endpoint integrity and identity workflows, then use the MITRE ATT&CK Enterprise Matrix to map the resulting attack path.

As environments adopt more service-to-service authentication, the line between network abuse and identity abuse keeps narrowing. That makes correlated monitoring more valuable than isolated alerts, because a spoofed hostname can be the first step in a broader compromise chain that affects both human and machine identities.

For practitioners

• Baseline DNS resolution for critical domains Track normal resolver outputs, TTL ranges, and authoritative sources for business-critical hostnames so that mismatched or rapidly changing answers stand out immediately.
• Correlate DNS logs with endpoint integrity alerts Combine Zeek-derived DNS telemetry with file-integrity monitoring on /etc/hosts and similar local resolution files to catch both network and host-level spoofing paths.
• Alert on low TTL and untrusted authoritative responses Create rules that flag DNS responses with unusually short TTL values, especially when they come from resolvers outside the approved trust set or claim authoritative status unexpectedly.
• Treat redirected authentication traffic as an identity incident If DNS spoofing affects login, token exchange, or API endpoints, route the event through identity and access response procedures because the attacker may be targeting credentials rather than availability.

Key takeaways

• DNS spoofing succeeds by breaking trust in name resolution, which can redirect users and services before identity controls are engaged.
• Behavioural indicators such as low TTLs, inconsistent answers, and untrusted authoritative responses are more useful than a single signature.
• Teams need correlated DNS, endpoint integrity, and identity response workflows because local file tampering and resolver manipulation can produce the same attack outcome.

Key terms

• 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.
• Queue Poisoning: Queue poisoning is the abuse of a shared request pipeline so that attacker-controlled bytes are processed as part of another user’s or another request’s traffic. It is dangerous because the attacker does not need direct code execution to influence what the back-end sees next.
• File Integrity Monitoring: File integrity monitoring is the practice of tracking critical files for unexpected changes in content, permissions, ownership, or metadata. It helps teams spot tampering, drift, and persistence attempts that can undermine identity and security controls. In mature programmes, it is tied to approved baselines and actionable change workflows.
• Authoritative Answer Flag: The authoritative answer flag indicates whether a DNS response claims to come from the authoritative source for the queried domain. Security teams treat unexpected authoritative responses with caution, especially when they originate from untrusted infrastructure or appear inconsistent with normal resolver behaviour.

What's in the full article

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

• Custom Zeek decoder and rule examples for identifying forged DNS responses in Wazuh
• Step-by-step agent and dashboard configuration for monitoring DNS logs and /etc/hosts changes
• A lab-style attack simulation using Scapy and dig to validate the detection rules
• Rule logic for low TTL, untrusted authoritative answers, and local host-file tampering

👉 The full Wazuh post shows the decoder logic, simulation steps, and dashboard filters used to detect DNS spoofing.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need stronger control over trust boundaries. It helps identity and security teams connect machine identity risk to day-to-day governance decisions.