Nearly half of malware command-and-control never asks DNS a question — Unit 42 measured it across four million analysis reports, which puts a number on the blind spot in every protective-DNS and DNS-firewall deployment

Protective DNS is one of the few controls a national or sector-level defender can deploy centrally and cheaply, which is why several European public-sector networks run one and why DNS response-policy zones, sinkholing and DNS firewalling sit at the front of many egress-control designs. Unit 42 published a measurement this week that bounds what that class of control can and cannot see, and the number is large enough to change how a SOC reads a clean DNS log.

Across more than four million dynamic-analysis reports, Unit 42 reports that "almost half (45.32%) of malware samples with any command-and-control (C2) activity made at least one direct-to-IP (D2IP) address connection," and that "measured as a fraction of all C2 connection attempts, D2IP traffic accounts for 23.17% of the total" (Palo Alto Networks Unit 42, 2026-08-04). The malware in question does not evade DNS monitoring by encrypting its queries or by using an unusual resolver — it simply never resolves a name, because the address is compiled in. Unit 42 attributes the behaviour across a wide span of threat classes including ransomware droppers, peer-to-peer botnets and supply-chain implants, so this is not one family's quirk.

The comparison figure is what makes it a usable detection rather than an interesting statistic: applying the same filtering, "only 1% of benign samples establish connections to untrusted IP addresses," and those that do average fewer than two such connections apiece. A behaviour present in nearly half of C2-active malware and in one percent of benign software is a discriminator, not noise. Unit 42's own proposal is a firewall-level enforcement model that verifies an outbound connection was sanctioned by a preceding DNS response, but the transferable version needs no product: correlate egress flow records against the same host's DNS telemetry and surface sessions to external addresses that no resolution preceded.

Triage: the hunt is an outbound TCP or UDP session from an internal host to an external, non-allowlisted address with no A or AAAA resolution for that address in the same host's DNS telemetry within a preceding window. The benign population that shares this shape is real and needs excluding first: time synchronisation, hard-coded public resolvers, some update and telemetry agents, content-delivery and cloud back-ends reached by IP after an earlier resolution, and peer-to-peer or real-time media protocols that negotiate addresses out of band. After those exclusions the discriminators are destination reputation, port, persistence of the beacon, and — most usefully — whether the initiating process normally resolves names at all: a browser or mail client that suddenly contacts a bare address is anomalous in a way that an NTP daemon is not.