DNS Security for Healthcare: Blocking the Quiet Exfiltration Path

DNS is allowed out of almost every network, inspected by almost nobody, and will happily carry data out one query at a time. Logging, blocking and detection that does not break clinical systems.

GuardsArm Team

Security Experts

January 1, 2026

DNS security

Almost every firewall permits DNS outbound. Almost no healthcare network inspects it. That combination makes DNS the most reliable covert channel an attacker has: it is allowed, it is expected, it is high volume, and the payload sits in a field nobody reads.

Always allowed

DNS egress is permitted by default on essentially every network

Bidirectional

Queries carry data out; TXT and CNAME answers carry commands back in

Pre-authentication

DNS resolves before most security controls engage, so it works from anywhere

How data leaves over DNS

Exfiltration encodes data into the subdomain of a name the attacker controls. A query for 4d5a90000300.exfil.attacker-domain.com leaks twelve hex characters; a thousand queries leak a file. The attacker's authoritative name server records every label it is asked about. Nothing has to be "returned" for the theft to succeed.

The same channel works inbound: a TXT record answer is a convenient place to hand instructions to an implant.

The resolver is doing its job correctly at every step. That is the problem.

What to look for

Detection is statistical, not signature-based. The signals that work:

Query volume to a single domain far above that domain's peer group
Long subdomain labels — legitimate names are short; encoded data is not
High entropy in the leftmost label — random-looking strings
Unusual record types — heavy TXT or NULL query volume from a workstation
A newly registered domain receiving steady traffic from one internal host
Query volume with no matching connection — resolution that never leads to a session

The baseline that makes this tractable

Most clinical endpoints talk to a small, stable set of domains. Establishing that baseline per device class turns DNS monitoring from "too noisy to use" into one of the highest-signal detections you have — particularly for medical devices, whose name resolution should be almost perfectly predictable.

Controls that hold

Control	Effect
Force all DNS through internal resolvers	Removes the easy bypass; makes logging possible at all
Block outbound port 53 except from those resolvers	Stops an endpoint talking to an external resolver directly
Block or control DNS-over-HTTPS	Otherwise your logging is bypassed over 443
Protective DNS / threat-feed filtering	Blocks known malicious and newly-registered domains
Sinkhole rather than drop	A sinkhole tells you which host asked; a drop tells you nothing
Log every query with the source host	The single most useful artefact in an incident

DNS-over-HTTPS deserves particular attention. Browsers and some operating systems will use DoH by default where available, which moves resolution to port 443 and out of your visibility entirely. Disable it by policy on managed endpoints and block the well-known DoH providers at the perimeter.

Resolver logging is the point

If you take one thing from this: log queries with the client IP, keep them, and make them searchable. During an incident, DNS logs answer the question that matters most — which internal hosts contacted the adversary's infrastructure, and when. Without them, scoping a compromise becomes guesswork.

Retention of 90 days is a reasonable floor. The interval between initial access and detection is routinely longer than that, which is the argument for more.

Log the response, not just the query

Query-only logging tells you a host asked about a domain. Logging the answer tells you which IP it then talked to, which is what lets you pivot to firewall and proxy data during an investigation. Storage is cheap next to a scoping exercise conducted blind.

What breaks, and how to avoid breaking it

Healthcare DNS changes have a reputation for outages, usually for three avoidable reasons.

Hard-coded resolvers on clinical devices. Some medical equipment has a resolver IP baked into a configuration file set at commissioning. Blocking port 53 outbound without finding these first takes the device offline. Inventory them before you enforce — passive DNS monitoring will show you which sources are bypassing the internal resolvers.

Split-horizon dependencies. Clinical systems frequently resolve internal names that do not exist publicly. Sending that traffic to an external protective DNS service returns NXDOMAIN and the application fails. Keep internal zones authoritative internally and forward only what genuinely needs to leave.

Over-aggressive category blocking. Blocking "newly registered domains" catches real attacks and also catches the legitimate vendor portal that launched last week. Run new block categories in monitor mode first and review what they would have stopped.

Change	Risk if rushed	Safe sequence
Force internal resolvers	Devices with hard-coded DNS drop off	Monitor, inventory, exempt, then enforce
Block outbound 53	Same, plus vendor tunnels	Allow-list known resolvers first
Block DoH	Browser features degrade	Policy-disable on managed endpoints, then block
Protective DNS filtering	False positives on new vendor domains	Monitor mode for two weeks

Where to start

Point every endpoint at internal resolvers, block port 53 outbound from everything else, and turn on query logging. That is a day of firewall work and it converts DNS from a blind spot into a detection surface.

Then baseline your medical device VLANs — see IoMT security. Devices that should only ever resolve two vendor hostnames are where anomalies stand out most clearly.

GuardsArm builds DNS monitoring and protective DNS deployments for healthcare networks. Book a scoping call.

Topics

Written by GuardsArm Team

Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.