Targeted DNS Forgery

Targeted DNS forgery is an on-path attacker rewriting the answer to one name lookup and leaving everything else untouched. Where DNS spoofing is often blanket tampering, this is surgical: the attacker forges the answer for a single high-value domain — your bank, a login page, a software update server — and forwards the rest of your lookups correctly.

Every site loads normally. The one that matters points at a box on your own network.

That precision is the whole point. A check that only watches a couple of fixed canary domains will resolve them cleanly — because the attacker never touched them — and report all clear while the one domain they did rewrite quietly sends your traffic somewhere it should never go.

First the attacker gets on-path — usually by ARP spoofing so your traffic flows through their machine. Then, instead of mangling every lookup, they configure a rewrite rule for a single domain and pass everything else straight through.

# on-path, then forge the answer for ONE domain only
# (conceptual — a real tool here is bettercap's dns.spoof)
set dns.spoof.domains  login.yourbank.example
set dns.spoof.address  192.168.1.66   # attacker box on your LAN
dns.spoof on

The forged answer points at a private, LAN-local address the attacker controls. Your browser connects there, gets served a convincing clone, and everything else about the network looks completely normal.

WifiThreatWatch resolves each domain in a curated set of stable public names two ways and compares. One path is the system resolver — the exact path an on-path attacker rewrites. The other is DNS-over-HTTPS to a literal IP (1.1.1.1, 8.8.8.8), a TLS-authenticated channel a port-53 attacker on your LAN cannot forge or intercept.

# What the system resolver says (the path that gets rewritten)
Resolve-DnsName login.yourbank.example -Type A

# Second opinion over TLS-authenticated DoH (port-53 attacker can't forge this)
curl.exe -s "https://1.1.1.1/dns-query?name=login.yourbank.example&type=A" -H "accept: application/dns-json"

The decisive signal is a public domain that the system resolves to a private, RFC1918 address while DoH says it is public. There is no benign reason for that — it is a local redirect, full stop. We query multiple DoH IPs so an attacker cannot simply blackhole one, and the check is built to be quiet: CDN geo-variance is public-versus-public and never fires, and a recognised Pi-hole or AdGuard sinkhole is suppressed rather than flagged.

The one honest caveat: an on-path attacker can still block the DoH connection outright. They cannot forge it — TLS won’t let them — but they can drop it. That is why we lean on several endpoints; taking them all down at once is loud, and the silence is itself a signal.

A public name answered with a LAN address is proof the network is actively hostile, not merely misconfigured — the moment to stop trusting it for anything you log into.

When you connect through Active Defense, your DNS resolves inside the encrypted tunnel, past whatever was rewriting answers on the local segment. The forged answer never reaches you, because the query never traverses the attacker’s box in the clear.