Or: How a Routine Posture Check Revealed My AV Was Undermining My Stack

In cybersecurity, we talk a lot about detection rates, threat intelligence, and endpoint performance. But sometimes it’s the silent layers — like DNS handling — that reveal whether your defenses are truly holding.

Recently, during a routine verification of my own security posture, I discovered that a well-known antivirus product was actively circumventing encrypted DNS configurations, exposing DNS traffic over port 53 without disclosure or consent.

🧪 The Setup: Hardened Stack, Intact Expectations

Here’s what I had configured on my system:

– Firefox with DNS-over-HTTPS (DoH) enabled via Cloudflare
– System DNS set to Cloudflare IPv4/IPv6 (1.1.1.1 / 2606:4700:4700::1111)
– Windows Firewall rules explicitly blocking outbound DNS (port 53, TCP & UDP)
– VPN with DNS override enabled (ProtonVPN Secure Core, with optional NetShield)
– No router-level DNS fallback to the ISP

I wasn’t troubleshooting an issue — just doing a posture check to confirm that DNS traffic was fully encrypted, properly routed, and not vulnerable to MITM interception.

🔥 The Discovery: Plaintext DNS Leak via Port 53

Despite my configuration, Wireshark revealed that DNS queries were:

– Still going out over UDP port 53
– Visible in plaintext
– Originating from a service tied to the antivirus suite
– Completely bypassing DoH, system settings, firewall rules, and VPN protections

The protocol used was not listed anywhere in the antivirus software’s settings, nor was there any option to change it.

🛠️ The Technical Breakdown

To verify the DNS traffic at a system level, I ran:

netstat -ano | findstr ":53"

This confirmed a UDP connection to 1.1.1.1 on port 53, tied to a process belonging to the antivirus suite.

Then I opened Wireshark and used the following filter:

udp.port == 53

Result: continuous plaintext DNS traffic to 1.1.1.1, no encryption, no HTTPS handshake.

Firewall rules were already set:

New-NetFirewallRule -DisplayName "Block Outbound DNS UDP" -Direction Outbound -Protocol UDP -RemotePort 53 -Action Block
New-NetFirewallRule -DisplayName "Block Outbound DNS TCP" -Direction Outbound -Protocol TCP -RemotePort 53 -Action Block

And confirmed active with:

Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*DNS*" }

Despite this, DNS traffic was still leaving via port 53 — meaning the antivirus had likely installed a low-level network filter or kernel driver that bypasses user-defined firewall behavior.

🔐 Why This is a Problem

DNS traffic sent over port 53 is:

– Unencrypted (readable by anyone in the network path)
– Vulnerable to spoofing or redirection
– Routable by ISPs, middleboxes, or attackers
– A privacy risk when operating outside of your configured VPN and DNS provider

This behavior directly undermines any system configured with encrypted DNS or zero-trust assumptions.

🧠 Analyst Takeaways

– Validate DNS settings with actual network analysis, not just system settings
– Use tools like:
netstat
Wireshark
tcpdump
PowerShell firewall auditing
– Don’t assume DoH or VPN tunneling protects DNS — verify DNS egress routes
– Be wary of any product that prevents DNS configuration transparency or protocol selection

📦 Final Thought

This wasn’t a forensic hunt — it was a standard security posture verification. What I discovered was that a popular security product was actively breaking the security controls I’d configured, without notice or consent.

If your DNS traffic isn’t going where you think it is — it’s time to look closer.