Summary

Malware samples often bypass DNS entirely, communicating directly to IP addresses instead. Our analysis of 4 million dynamic analysis reports indicates 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. Measured as a fraction of all C2 connection attempts, D2IP traffic accounts for 23.17% of the total. A wide variety of threats — including ransomware droppers, peer-to-peer (P2P) botnets and supply chain risks — communicate directly with hard-coded IP addresses, bypassing DNS entirely and evading DNS-based defenses altogether. This article introduces zero trust IP (ZT-IP), which is a network-level enforcement approach that applies zero trust principles to IP-based traffic. The enforcement approach verifies whether outbound connection destinations were ever sanctioned by a DNS response. We validate this approach against real-world network traffic and samples, demonstrating how ZT-IP successfully surfaces threats including:

  • Phorpiex ransomware droppers connecting directly to C2 IP addresses
  • A persistent data exfiltration campaign using a custom obfuscated HTTP GET request
  • Mozi P2P botnet payloads delivered to internet-of-things (IoT) devices without DNS Palo Alto Networks customers are better protected from the threats discussed here through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. | Related Unit 42 Topics | | DNS security has become a cornerstone of enterprise threat defense. By monitoring and filtering DNS queries, security teams can block malware from reaching known-bad domains and use sinkholing to disrupt C2 communications before they establish a foothold. This approach is effective when malware plays by the rules of relying on DNS for domain resolution. However, many types of malware do not. For example, a backdoor malware sample made no DNS query at all before initiating a WebSocket connection directly to an IP address. Disassembly via Ghidra revealed why. The destination address wss://154.92.19[.]71:39989 was hard coded into the binary as a Unicode string. This is not an isolated edge case. Without the DNS resolution step in network communications, malware is invisible to DNS-based security controls, protective DNS sinkholing and DNS anomaly detection systems. The connection simply appears as raw IP traffic with no prior context. We analyzed over 4 million Advanced WildFire dynamic analysis reports for a 30-day period to quantify how prevalent this behavior truly is. We filtered out connections to common legitimate services, internal addresses and DNS resolvers. After doing that, we found that 20.11% of malware samples exhibited C2 activity. The contrast with benign samples is striking. Only 1% of benign samples establish connections to untrusted IP addresses after applying the same filtering criteria. Those that do average just 1.6 such connections per sample. This is a small fraction of the activity observed in malware. Among malware with C2 connections, TCP dominates (94.43% prevalence, averaging 4.17 unique C2 IP addresses per sample). UDP is present in 17.50% of cases but contacts far more IP addresses per sample (average 13.79%), consistent with scanning and P2P mesh behavior. Most critically for DNS-based defenses, 45.32% of malware samples with any C2 activity made at least one direct-to-IP (D2IP) address connection — a raw IP contact with no preceding DNS query. Even after excluding bulk port-scanning behavior, the figure remains 41.97%. Measured as a fraction of all C2 connection attempts, D2IP traffic accounts for 23.17% of the total. By searching for D2IP connections (ZT-IP analysis), we were able to uncover multiple threats. Among traffic flagged by ZT-IP, we observed the following suspicious HTTP GET request toward the destination IP address at 178.16.54[.]109 as shown below in Figure 1. A screenshot of an HTTP GET request. It includes a user-agent string indicating Mozilla/5.0 with Windows NT 10.0 and Chrome/128.0.0.0, followed by a host IP address. We found that these requests correlate with several malware samples (e.g., the binary retrieved from hxxp[:]//178.16.54[.]109/st.exe) associated with Phorpiex (aka Trik), a long-running malware family used primarily as a dropper and spam botnet. Figure 2 illustrates the many malicious samples hosted on 178.16.54[.]109 in a flow chart of this activity. A network diagram showing interactions between nodes. A central node connects with multiple "FILE" nodes and a flag icon. Arrows indicate paths labeled "download" and "path_of." Another section features nodes connected by "load" and "download" pathways, ending in "FILE" nodes. A key indicator of malicious D2IP activity was the absence of DNS queries preceding the connections to 178.16.54[.]109. Since the request bodies appear benign, they often bypass standard heuristic detectors. One of the most distinctive findings was a persistent campaign using a non-standard HTTP request we call the \GET protocol. This is an obfuscated request format designed to evade security detection while exfiltrating data. Unlike standard HTTP requests, these requests begin with \GET (backslash-GET) rather than standard GET followed by a backslash. The \GET is followed by a long encoded string ranging from 250–666 characters, as shown in Figure 3. Red text overlaid on a white background, resembling network request or data transmission code, displaying a long string of alphanumeric characters typical in digital communication or coding.
  • The first and last four characters: alphanumeric (0-9 and A-Z), evenly distributed
  • Middle characters: hex-like (0-9 and A-F), evenly distributed
  • The payload length ranges from 250–666 characters Disassembly of associated malware samples (e.g., cc43cdbe8eb9874f55fffbe23b560b673eb9f31fb9a953926bba29464fd2dd07) confirms there are no hex-format IP addresses hard coded in the binaries. Instead, multiple hard-coded strings follow the same encoding rule, consistent with the payload lengths observed. The C2 infrastructure is hosted on public cloud infrastructure in Brazil. Samples that point to it were found impacting high-value sectors including government, airlines and universities. Because the threat leverages shared cloud resources, simple IP-based blocking is ineffective. Furthermore, the malware employs a notable operational security measure. It rotates both its destination port and IP address on a regular schedule, which evades static IP-blocking defenses. We observed two separate attackers operating infrastructure at 87.120.107[.]33 and 194.76.227[.]94, respectively, deploying the same malware family of SectopRAT against educational institutions. Both actors leverage SectopRAT’s in-browser proxy capability to silently mirror all victim browser traffic to attacker-controlled servers in real time. The proxy operates via two endpoints. The first, /churl (shown in Figure 4), relays every URL the victim visits, including:
  • Authenticated session pages
  • Single sign-on (SSO) redirects
  • Learning management system content A screenshot of an HTTP GET request. It includes a URL with a masked query parameter and header information such as an IP address, user agent details featuring Windows NT 10.0, AppleWebKit, and Chrome. The second, /fsave (shown in Figure 5), exfiltrates form fields including usernames and plaintext passwords at the moment of submission. A redacted URL string with hidden sections, displaying parameters and partially visible encoded values. An identifier (pcid/clid) in every request allows each actor to track individual compromised devices across sessions. Both attackers’ campaigns communicate entirely over D2IP connections, bypassing DNS-based visibility layers entirely. IoT malware families often exploit network vulnerabilities to self-propagate, relying on D2IP communication that makes them invisible to DNS-based security layers. Mozi is a Mirai-derived P2P botnet known for targeting IoT devices with MIPS, ARM and x86 architectures. We observed its characteristic exploitation payload embedded directly in HTTP requests. Figure 6 shows an example of the exploitation payload for Mozi. A terminal window displaying a command sequence that includes wget, a URL, and references to Mozi malware. In ASCII text, this translates to the three commands shown in Figure 7. A screenshot of a terminal showing commands for downloading, setting permissions, and executing a payload file, specifically for D-LINK/MIPS devices. The Mozi campaign showed highly distributed patterns with thousands of source and destination IP addresses, consistent with the Mozi botnet’s P2P mesh structure. However, because this IoT malware propagates by making D2IP connections without DNS resolution, blocking this type of connection can effectively prevent it from spreading within sensitive environments. Similarly, we identified a Mirai variant that we named Boatnet, which was distributed from the IP address 2.26.98[.]67. Boatnet demonstrates thorough platform targeting, covering at least 14 different architectures. Beyond standard IoT architectures, Boatnet includes binaries for m68k (Motorola 68000). This processor family is common in legacy industrial control systems (ICS) and aging embedded hardware, which current malware typically overlooks. Unlike generic variants, Boatnet fragments its ARM coverage into three discrete sub-variants (ARM5, ARM6 and ARM7) to ensure optimal performance across different hardware generations. Binaries are hosted under a /hiddenbin/ directory, as noted in Figure 8, showing a deliberate attempt to mimic legitimate system paths and evade basic file-path detection. A screenshot of a command line interface displaying an HTTP GET request. It includes headers such as Range, Accept, Host, and Connection. We observed infected devices fetching payloads with a User-Agent string of Wget/1.13.4 (released in 2012). This serves as a significant fingerprint, suggesting the botnet is specifically harvesting older, unpatched hardware. Boatnet also demonstrates more operational maturity than “vanilla” Mirai through its use of HTTP Range headers. D2IP communication from malware won’t be detected by approaches that focus specifically on securing requests at the time a hostname is resolved. This is illustrated by threats like the Phorpiex ransomware dropper, the obfuscated \GET exfiltration campaign and the P2P Mozi botnet. ZT-IP closes this critical gap by applying strict zero trust principles to outbound D2IP connections, ensuring only DNS-sanctioned traffic is permitted. It is a necessary network-level enforcement mechanism to block what DNS-based detection cannot see. Palo Alto Networks customers are better protected from the threats discussed here through the following products and services: Advanced WildFiremachine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research.Advanced URL FilteringandAdvanced DNS Securityidentify known domains and URLs associated with this activity as malicious.Cortex XDRandXSIAMhelp to prevent the threats described in this article, by employing theMalware Prevention Engine. This approach combines several layers of protection, includingAdvanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. Malicious destination IP addresses
  • 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 Malware samples
  • 01a96eeafb72042b3f69afd21b4c9155dbfe7f97ab3dca392972ad531a075ac2
  • 9639f7ebc6a6d69d7bf5b8bc869e7783a1406088f192868624ad8919e9bfd1d4
  • bf24277400cc453d530e4277d3bd24e96c5e409adef6970518bdc59205aa0241
  • e310476c41ae4f6e3c4ed9bb88303ee6e5e1455bd7afe51cf48965ea7599e6e5
  • e3513922666c202c1ae5c06eea277ba10477868d6d89ce2819f4f8ff9070bc85
  • e5715e6611ef6bcb233f5d2098510dab3db408abbb728b00e1821bb255829373 Phorpiex (Malware Family)– MalpediaOld Wine in the New Bottle: Mirai Variant Targets Multiple IoT Devices– Palo Alto Networks Unit 42It Was Not Me! Malware-Initiated Vulnerability Scanning Is on the Rise– Palo Alto Networks Unit 42 ZT-IP, which we have also called No-DNS or D2IP detection, extends the zero trust security model to IP-based traffic. This ensures that network services only connect to IP addresses previously resolved and approved by a trusted DNS service. Outbound connections to an IP address without a prior, valid DNS query are flagged as suspicious and blocked. In Figure 9, ZT-IP secures the network and firewall level through a simple enforcement mechanism: A network diagram illustrating packet flow with DNS filtering. The sequence includes a DNS query to example.com, a DNS response, and verification of IP by the DNS resolver, which is allowed. Another packet with destination IP is not approved and blocked. The mechanism:
  • Tracking legitimate IP addresses: The system monitors all valid DNS responses to learn which IP addresses are approved for outbound connections
  • Building a trust list: These approved IP addresses are tracked in a secure list, along with a time limit for how long they remain valid
  • Enforcement: Whenever a device attempts an outbound connection to an IP address, the firewall checks this list
  • Blocking bypass attempts: The connection is only allowed if the destination IP address was recently approved by DNS. If an IP address is not on the list or its approved time limit has expired, the connection is immediately flagged as a potentialNo-DNS threat and blocked. Because some legitimate network protocols (such as DNS, Neighbor Discovery Protocol, VoIP, P2P and certain IoT services) connect directly to IP addresses by design, ZT-IP incorporates mechanisms to prevent false positives. It uses allowlists that exempt private intranet IP addresses, specific trusted network protocols and well-known benign public IP addresses from these strict DNS checks. ZT-IP delivers the following key advantages for network defense:
  • Stops patient zero attacks: It proactively blocks unknown C2 callbacks and malware attempting to phone home using hard-coded IP addresses
  • Secures shared infrastructure: It differentiates between legitimate traffic and malicious connections targeting the same shared cloud hosting environments, securely blocking the malicious traffic because it lacks the necessary DNS context
  • Network-level protection: By operating at the firewall level, ZT-IP secures environments like IoT and operational technology (OT) without requiring endpoint agents to be installed on every single device

By Shu Wang, Zhanhao Chen and Daiping Liu

Original Article