DNS Security on Windows: Hijacked Resolvers, DoH Blind Spots, and Exfiltration Over Port 53

Every other security control on a Windows box assumes one thing works honestly: name resolution. When you type update.microsoft.com, when your EDR phones home, when a certificate is checked against a revocation server - all of it starts with a DNS lookup you never see and rarely question. That blind trust is exactly why DNS is one of the most abused layers in a Windows intrusion. Rewrite where a machine resolves names and you can phish it invisibly, hide command-and-control traffic from every tool watching for it, and carry data out over a port no firewall dares to close. None of it requires malware on disk. It requires a settings change - and nobody looking.

A senior engineer treats resolver configuration as security state, not networking trivia. Here are the three DNS attacks that matter on Windows, what each one looks like in the actual registry and adapter settings, and how to keep the fix from quietly reverting.

1. Resolver hijacking: the invisible redirect

The most direct DNS attack is also the oldest: change which server a machine asks. Point a host at a resolver you control and you decide what every hostname means to that machine - send it to a phishing clone of its own SSO page, blackhole its telemetry, or man-in-the-middle an update channel. Because the redirect happens below the application, the browser bar still reads the right domain and nothing looks wrong.

On Windows the resolver can be set in several places, and an attacker only needs one. Check the per-adapter servers first - a static entry where DHCP is expected is a classic tell:

Get-DnsClientServerAddress -AddressFamily IPv4 |
  Select-Object InterfaceAlias, ServerAddresses

A healthy DHCP client usually inherits its resolver from the network; a hard-coded public or unfamiliar IP that you did not set deserves an explanation. Two lower-level redirects are quieter still and belong in any audit:

• The hosts file. A single line in %SystemRoot%\System32\drivers\etc\hosts overrides DNS entirely for a name. Malware routinely adds entries here to pin a security vendor's update domain to 127.0.0.1 - silently disabling updates without touching the product. Anything in that file beyond the commented defaults and loopback is worth reading line by line.
• The NRPT. The Name Resolution Policy Table (HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig) can force specific namespaces to specific servers. It is legitimate for split-horizon VPN DNS, which is exactly what makes a malicious rule blend in. Enumerate it and confirm every rule is one you deployed:

Get-DnsClientNrptPolicy | Format-List Namespace, NameServers
Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" |
  Where-Object { $_ -and $_ -notmatch '^\s*#' }

The danger of DNS hijacking is not that it breaks something. It is that everything keeps working - just pointed somewhere you did not choose.

2. Rogue DNS-over-HTTPS: the resolver your firewall can't see

DNS-over-HTTPS (DoH) is a genuine privacy win - it encrypts lookups so they cannot be read or tampered with on the wire. But that same property is a defender's blind spot. Traditional network security assumes DNS is plaintext on port 53, so it can be logged, filtered, and sinkholed. Move resolution to DoH on port 443 and it becomes indistinguishable from ordinary HTTPS: your DNS firewall, your protective-DNS filtering, and your query logs all go dark at once.

The attack is to enable DoH pointed at an attacker-friendly resolver, or to let an application (a browser is the usual culprit) run its own DoH that bypasses the OS resolver entirely. Either way the enterprise's DNS controls are silently routed around. Windows 11 exposes DoH as first-class client state, so you can audit what the OS itself is doing:

Get-DnsClientDohServerAddress
Get-DnsClientDohServerAddress | Select-Object ServerAddress, DohTemplate, AutoUpgrade

The posture question is not "is DoH on or off" - it is "is encrypted resolution going somewhere I sanctioned." A DoH template pointing at a resolver that is not your approved provider means your query visibility has a hole in it. The defensible position is a deliberate one: either DoH is disabled so all resolution stays inspectable, or it is enabled and pinned to a resolver you trust and monitor - never left to whatever a browser or a script decides on its own. Browser-level DoH deserves the same scrutiny; a managed estate should set it by policy rather than leaving each app to auto-upgrade.

3. DNS tunneling: exfiltration over the port nobody closes

Port 53 is the firewall rule everyone leaves open, because without it nothing resolves. Attackers know this, so they turn DNS itself into a transport. In a tunnel, stolen data is encoded into the labels of query names - <base32-chunk-of-your-data>.exfil.attacker.com - and the answers carry instructions back. It is slow and loud if you are listening, but most estates are not listening to DNS at all, so it sails straight through egress controls that would block any direct connection.

You do not spot tunneling by reading one setting; you spot it by knowing what normal looks like and watching for the shape of abuse. The tells are statistical: a single host emitting an abnormal volume of unique subdomains under one parent domain, queries with very long or high-entropy labels, a flood of TXT or NULL record lookups, and traffic to a domain nobody else in the org ever asks for. On a Windows host you can start from the resolver cache and the client's own event log:

Get-DnsClientCache | Group-Object -Property Data |
  Sort-Object Count -Descending | Select-Object -First 20
# DNS-Client operational log (enable it, then review):
#   Applications and Services Logs > Microsoft > Windows > DNS-Client > Operational
Get-WinEvent -LogName "Microsoft-Windows-DNS-Client/Operational" -MaxEvents 200 -EA SilentlyContinue |
  Where-Object { $_.Message -match '\.' }

The durable defense is architectural: force all DNS through a resolver you control and log, block outbound port 53 to everything else so a rogue client cannot bypass it, and enable DNS-Client operational logging so the queries are recorded somewhere you can actually hunt through them. Tunneling depends on egress no one inspects; the moment DNS is centralized and logged, a host suddenly asking a stranger domain thousands of questions stops being invisible.

Make the DNS baseline continuous, not a one-time sweep

The through-line of all three attacks is the same: a resolver, a policy, or a hosts line gets changed, nothing breaks, and it goes unnoticed for weeks. That is a job for continuous verification, not a heroic afternoon. WinSentinel's DNS Security audit reads exactly these facts on the machine in front of you - the configured resolvers per adapter, unexpected hosts entries, NRPT rules, and DoH configuration - and folds them into your overall posture score:

winsentinel audit
winsentinel score

Re-run it after any network change and the score moves the instant a resolver drifts - the audit is a fact you can check every day, not a memory of the Tuesday you locked DNS down. It runs entirely on the local machine, free and unlimited.

When one machine becomes a fleet

Manually re-checking resolver settings, hosts files, and DoH policy across 50 or 100 endpoints is precisely where good intentions die - and DNS is the textbook case of a setting that silently comes back after a VPN client update or a reimage. That continuous, centralized assurance is what WinSentinel Pro is for: lightweight agents report each machine's DNS posture to a central node, so a host that picks up an unsanctioned resolver or a rogue DoH template surfaces as a drift alert instead of an incident. The depth of each machine's DNS audit is identical to the free single-machine scan; Pro adds the fleet-wide history, rollups, and alerting you need to trust dozens of machines resolving names honestly at once.

The takeaway

DNS is the assumption every other control quietly depends on, which is exactly why attackers go there: hijack the resolver to redirect invisibly, stand up rogue DoH to blind your query logs, or tunnel data out over the one port nobody closes. Each attack is a configuration change, not a payload - so each one is something you can audit. Read your resolvers, your hosts file, your NRPT and DoH settings; force resolution through a server you control and log; then make the check continuous - free on the machine in front of you, fleet-wide with Pro when one machine becomes many. Name resolution should be a fact you verify, not a trust you inherit.