“Almost half (45.32%) of malware samples with any command‑and‑control (C2) activity made at least one direct‑to‑IP (D2IP) address connection.” That single statistic, drawn from an analysis of more than 4 million Advanced WildFire dynamic analysis reports over a 30‑day period, frames a simple but consequential reality: a large portion of malicious code sidesteps DNS entirely and so avoids the very defenses built to watch DNS traffic.
Direct‑to‑IP traffic: how widespread and how measured
Palo Alto Networks’ Unit 42 filtered those 4 million dynamic reports to remove common legitimate services, internal addresses and DNS resolvers, then measured C2 behavior. Twenty‑point‑one‑one percent of malware samples showed C2 activity after filtering; among those, 45.32% made at least one D2IP connection. Measured another way, D2IP traffic comprises 23.17% of all C2 connection attempts. By contrast, only 1% of benign samples connected to untrusted IP addresses under the same criteria, and those averaged 1.6 such connections per sample.
The protocol mix matters. TCP dominates C2 connections — present in 94.43% of cases and averaging 4.17 unique C2 IP addresses per malicious sample. UDP appears in 17.50% of cases but touches many more IPs per sample (an average of 13.79), consistent with scanning and peer‑to‑peer mesh behavior.
Specific threats that hide behind raw IP traffic
Unit 42 used D2IP‑focused analysis (also called ZT‑IP or No‑DNS detection) to surface multiple campaigns. Examples documented in the data include:
- Phorpiex (Trik) — binaries retrieved from hxxp[:]//178.16.54[.]109/st.exe and related paths; staged payload downloads align with a dropper model that fetches configuration and then additional components. Crucially, connections to 178.16.54[.]109 often had no preceding DNS query, allowing otherwise benign‑looking HTTP request bodies to bypass heuristic detectors.
- An obfuscated exfiltration campaign using a non‑standard request called “\GET” (backslash‑GET). These requests begin with “\GET” followed by a 250–666 character encoded string; the first and last four characters are alphanumeric, the middle characters resemble hex. Disassembly of a linked sample confirmed multiple hard‑coded strings following this encoding rather than hex IP literals. The associated C2 infrastructure is hosted on public cloud infrastructure in Brazil and impacted sectors including government, airlines and universities; the actors rotate ports and IPs to evade static blocking.
- SectopRAT campaigns — two separate attackers operating at 87.120.107[.]33 and 194.76.227[.]94 deployed the same family against educational institutions and used an in‑browser proxy capability. The proxy relays URLs via a /churl endpoint (including authenticated pages and SSO redirects) and exfiltrates form fields via /fsave; a pcid/clid identifier tracks individual devices. Both campaigns communicated entirely over D2IP.
- IoT botnets — Mozi showed characteristic exploitation payloads embedded in HTTP requests and a highly distributed pattern with thousands of source and destination IPs consistent with a P2P mesh. A Mirai variant named Boatnet was distributed from 2.26.98[.]67, covered at least 14 architectures (including m68k), hosted binaries under /hiddenbin/, presented Wget/1.13.4 user agents, and used HTTP Range headers to target older, unpatched devices.
Built by Nubivance.
OSINTSights' secure edge-first architecture, AI content pipeline, and serverless ops are designed by Nubivance. We do this for clients too.
Talk to us →Why DNS‑focused defenses miss these threats
DNS‑based controls — filtering, sinkholing and anomaly detection — operate at the moment a hostname is resolved. When a binary contains a hard‑coded destination such as wss://154.92.19[.]71:39989 (observed in disassembly), there is no DNS event to trigger those controls. The connection appears as raw IP traffic and therefore slips past systems that rely solely on DNS context.
ZT‑IP: enforcing zero trust at the IP layer
Unit 42 proposes ZT‑IP (zero trust IP) as a network‑level enforcement that treats outbound IP connections as suspect unless DNS has recently sanctioned the destination. The mechanism tracks valid DNS responses to build a timed trust list of approved IPs, and the firewall checks that list before allowing outbound connections. If an IP is not on the list or the approval has expired, the connection is flagged and blocked. To avoid false positives, ZT‑IP incorporates allowlists for private intranet addresses, specific trusted protocols (DNS, Neighbor Discovery, VoIP, P2P where appropriate) and well‑known benign public IPs.
Unit 42 validated ZT‑IP against real‑world traffic and samples and found it surfaced multiple D2IP threats. The authors argue ZT‑IP stops “patient zero” callbacks, differentiates malicious traffic in shared cloud hosts, and offers network‑level protection for IoT and OT without requiring endpoint agents.
What this means for technologists, procurement leaders, and affected enterprises
- Technologists and security teams: add D2IP detection to your network controls, monitor for indicators flagged in these cases (absence of prior DNS, \GET payloads, pcid/clid identifiers, unusual User‑Agent strings such as Wget/1.13.4) and consider firewall‑level ZT‑IP enforcement alongside endpoint measures like Advanced WildFire, Cortex XDR and XSIAM.
- Procurement leaders: recognize that shared cloud hosting and rotating IP/port operational security by attackers reduce the efficacy of simple IP‑blocklists; evaluate solutions that maintain DNS‑sanctioned trust lists and time‑bound approvals.
- Affected enterprises (government, airlines, universities): watch for D2IP indicators in outbound traffic and, if compromised or urgent, contact Unit 42 Incident Response (numbers and regional contacts are provided in the report).
Unit 42’s data‑driven conclusion is direct: a large slice of modern malware deliberately avoids DNS, and roughly one in four C2 connections now uses raw IP. Closing that visibility gap requires extending zero trust to the IP layer — a network‑level check that treats outbound IPs as untrusted unless DNS explicitly says otherwise.
