Skip to content

Direct-to-IP malware communications

Summary

Malware can bypass DNS-focused controls by connecting directly to hard-coded or dynamically obtained IP addresses. Unit 42 calls this direct-to-IP (D2IP) behavior and measured it across more than four million dynamic-analysis reports: among malware samples with command-and-control activity, 45.32% made at least one D2IP connection. D2IP represented 23.17% of all observed C2 connection attempts; after excluding bulk port scanning, 41.97% of C2-active malware samples still used it.

This is a detection and enforcement pattern, not a malware family or actor attribution. Unit 42's August 2026 research applies it to ransomware delivery, browser-session theft, data exfiltration, and IoT botnet propagation.

Tags

Why this matters

  • Protective DNS, sinkholing, newly registered domain detection, and domain reputation do not see a hostname when malware connects to a raw IP address.
  • In Unit 42's filtered dataset, only 1% of benign samples contacted untrusted IP addresses, while 20.11% of malware samples exhibited C2 activity. D2IP is not proof of compromise, but unexplained raw-IP egress has useful discriminating value when combined with process, destination, port, and protocol context.
  • Direct-IP traffic is common across very different operations: hard-coded WebSocket C2, HTTP payload delivery, browser proxying, cloud-hosted exfiltration, peer-to-peer botnets, and exploit propagation.
  • DNS-only egress policy leaves an important blind spot on developer endpoints, servers, IoT, and operational-technology networks where endpoint telemetry may also be weak.

Observed cases

Phorpiex ransomware delivery

Unit 42 linked direct HTTP requests to 178.16.54[.]109 with Phorpiex, also known as Trik. Observed paths included sequential numeric resources, /sex/k/n.txt, /new.php, and /st.exe. The infrastructure staged multiple malicious components, including ransomware payloads, without a preceding DNS lookup.

Backslash-GET exfiltration

A persistent campaign used a malformed-looking request method written as \GET, followed by a 250–666-character encoded value. The first and last four characters were alphanumeric and the middle was hex-like. Unit 42 associated the traffic with sample SHA-256 cc43cdbe8eb9874f55fffbe23b560b673eb9f31fb9a953926bba29464fd2dd07 and reported impact in government, airline, and university environments.

The destination used public-cloud infrastructure in Brazil and rotated both IP address and port. This makes a static denylist insufficient: hunt for the request shape, direct-IP process ancestry, destination churn, and exfiltration-sized payloads together.

SectopRAT browser proxying

Unit 42 observed separate operators at 87.120.107[.]33 and 194.76.227[.]94 using SectopRAT against educational institutions. Its browser proxy relayed visited URLs, authenticated pages, SSO redirects, and learning-management content through /churl; /fsave captured submitted form data including usernames and plaintext passwords. Requests carried pcid or clid victim identifiers and used D2IP throughout.

Mozi and Boatnet IoT propagation

Mozi's peer-to-peer propagation generated distributed direct-IP exploitation and payload-fetch traffic. Unit 42 also named a Mirai variant Boatnet, served from 2.26.98[.]67 under /hiddenbin/. Reported builds covered at least 14 architectures, including m68k and separate ARM5, ARM6, and ARM7 variants. A Wget/1.13.4 user agent provides a useful but non-exclusive pivot toward older embedded devices; HTTP Range requests were another observed trait.

Hunting pivots

Network

  • Outbound TCP, UDP, HTTP(S), or WebSocket sessions to public IP addresses with no recent DNS resolution by the source host.
  • Raw-IP URLs in command lines, scripts, configuration, memory strings, proxy logs, and packet metadata.
  • Literal-IP TLS SNI or certificate mismatches, unusual destination ports, and repeated IP/port rotation.
  • HTTP requests beginning with \GET and a 250–666-character structured value.
  • SectopRAT-style /churl and /fsave requests carrying pcid or clid parameters.
  • IoT fetches from /hiddenbin/, especially with Wget/1.13.4, unusual Range headers, or immediate execution attempts.

Endpoint and workload context

  • Browser, document, package-install, web-server, or service processes initiating unexplained raw-IP egress.
  • Child processes that retrieve or execute content immediately after a D2IP session.
  • Embedded or OT devices making new internet connections outside their established controller, update, NTP, DNS, or vendor-service allowlists.
  • Multiple internal sources contacting the same raw IP, or one source contacting many raw IPs without corresponding DNS activity.

Reported destination indicators

Unit 42 listed the following malicious destinations. Treat them as time-bounded pivots and verify current ownership before blocking or attributing activity:

  • 2.26.98[.]67
  • 62.60.179[.]230
  • 87.120.107[.]33
  • 91.92.243[.]29
  • 103.245.236[.]146
  • 178.16.54[.]31
  • 178.16.54[.]109
  • 194.76.227[.]94
  • 206.189.229[.]43

Defender actions

  1. Measure before enforcing. Inventory legitimate D2IP use by resolvers, NTP, VoIP, peer-to-peer applications, content delivery, monitoring, embedded systems, and private-address services.
  2. Correlate DNS and flow telemetry. Record recent DNS answers per source and flag outbound public-IP connections that lack a matching approved resolution. Preserve NAT and proxy identity so source attribution survives aggregation.
  3. Use scoped allowlists. Permit required protocols and destinations narrowly by device group, workload identity, process, and port rather than globally allowing raw-IP egress.
  4. Prioritize high-risk segments. Apply tighter controls first to build runners, servers, kiosks, IoT, OT, and user segments that should rarely contact arbitrary public IPs.
  5. Do not rely on static IP blocking alone. Shared cloud infrastructure, reassignment, and destination rotation require behavior, process ancestry, and protocol-shape detection.
  6. Investigate as possible C2 or exfiltration. For unexplained D2IP, preserve process, socket, DNS-cache, proxy, packet, and endpoint evidence; scope peer hosts; isolate when malicious execution or credential capture is corroborated.

Limitations

  • Unit 42's percentages come from its Advanced WildFire dynamic-analysis telemetry and filtering choices; they are not a universal internet prevalence estimate.
  • A missing observed DNS request can result from telemetry gaps, caching, encrypted DNS, another resolver path, or a legitimate protocol. D2IP should be risk-scored, not treated as a stand-alone compromise verdict.
  • Several reported IPs sit on infrastructure that can be reassigned or shared. Historical connection evidence is stronger than a present-day ownership check, and an IP match alone does not establish actor identity.

Sources