Technical Analysis: C0XMO – The Modular Evolution of the Gafgyt Botnet

A sophisticated new variant of the Gafgyt malware family, tracked by researchers as C0XMO, has emerged, signaling a strategic shift in how IoT botnets are engineered. Unlike its predecessors, C0XMO adopts a highly modular architecture that decouples the scanning and propagation phases. By utilizing multi-architecture payloads, the operators have significantly increased their ability to compromise a diverse range of heterogeneous Linux-based IoT devices.

The initial infection vector identified in recent campaigns exploits CVE-2021-27137, a critical stack buffer overflow vulnerability within the UPnP SSDP parser of vulnerable DD-WRT firmware. The exploit is triggered by sending specially crafted M-SEARCH UDP packets containing oversized ST:uuid: values, allowing for remote code execution.

While telemetry indicates a specific target within a Japanese technology firm, the broader infection chain appears to originate from a German-based IP address. The malware stages its primary payload within the /tmp/.cache directory and serves a comprehensive suite of binaries compiled for a wide array of instruction sets, including ARM, MIPS, PowerPC, SuperH, MC68000, Intel 80386, and AMD64.

While C0XMO retains the “classic” Gafgyt toolkit—such as SSH/Telnet brute-forcing, diverse DDoS primitives, and aggressive competitor-killing routines—its architectural separation is its defining feature.

Modular Architecture: The Scanner vs. The Bot

C0XMO splits its operational logic into two distinct components: a lightweight bot binary and a high-level Python-based scanner. The primary bot binary is streamlined to focus strictly on persistence, process management, and Command and Control (C2) communication. Conversely, the independent Python scanner handles the “heavy lifting” of reconnaissance and lateral movement.

This modularity provides a significant operational advantage: the attacker can update the Python scanning logic to incorporate new exploits without needing to re-infect the entire botnet, while the architecture-specific binaries remain small and efficient on the compromised hosts. The scanner is currently hosted at 217[.]160[.]125[.]125:15527 and relies on Python libraries such as requests, paramiko, and beautifulsoup4 to automate HTTP interactions and credential-based access.

According to FortiGuard Labs, this separation allows for a much more scalable and adaptable infection engine than previous Gafgyt iterations.

Persistence and Defensive Evasion

Once a device is compromised, C0XMO establishes persistence through a disciplined four-stage sequence:

1. Self-Copying: The binary moves to hidden directories such as /tmp/.sys, /var/tmp/.sys, /dev/shm/.sys, or $HOME/.sys.
2. Hardening: The malware modifies file permissions to ensure it remains executable.
3. Scheduled Execution: A cron job is created to trigger the binary every 15 minutes.
4. Environment Modification: Files like ~/.bashrc or ~/.profile are modified to ensure the malware executes upon user login.

Furthermore, C0XMO implements a “competitor-removal” routine. It enumerates the /proc filesystem to identify and terminate processes associated with rival botnets, network services, or red-team utility tools. To avoid accidental self-termination during these cleanup operations, the malware verifies its own PID and executable filename before proceeding with the kill command.

C2 Communication and DDoS Capabilities

Communication with the C2 server utilizes a custom handshake protocol involving fixed magic strings and a shared secret. Once authenticated, the bot identifies itself as “BOT” and enters a command loop. The command handler supports heartbeat checks (ping/PONG), scanner orchestration (scan/stopscan), and a massive array of DDoS directives.

Analysis of the x86_64 sample reveals support for 19 distinct DDoS methods. These range from standard volumetric attacks (UDP/TCP floods, SYN floods) and amplification attacks (NTP, Memcached) to sophisticated application-layer attacks (HTTPStorm, HTTP GET) and protocol-specific abuses (Valve Source Engine, Discord voice floods). This diversity suggests the operator intends to monetize the botnet across a wide variety of attack-as-a-service models.

Scanner Functionality and Exploit Vectors

The Python scanner is highly organized into functional groups, including worker threads, blacklists, and exploit modules (Telnet, SSH, HTTP, and ADB). The worker modules manage the lifecycle of a target: fetching potential IPs, checking against blacklist.txt and failed.txt, fingerprinting services, and deploying the appropriate payload.

The scanner’s exploitation repertoire is extensive, targeting several critical vulnerabilities:

• UPnP SOAP Injection: CVE-2021-27137
• GLPI htmLawed RCE: CVE-2022-35914
• AVTECH Vulnerabilities: Including CVE-2025-34054
• Other Vectors: NVMS-9000 flaws, Zyxel SysTools RCE, and various DVR/Router command injection paths.

In addition to software exploits, the scanner actively hunts for exposed Android Debug Bridge (ADB) instances and utilizes credential stuffing to gain access to devices via weak Telnet/SSH passwords.

Defensive Recommendations

To mitigate the risk of C0XMO infection, organizations should prioritize the following actions:

• Patching: Immediately update DD-WRT firmware and any vendor-specific firmware associated with the listed CVEs.
• Service Minimization: Disable unnecessary services, specifically UPnP and Telnet, on all IoT devices.
• Credential Hygiene: Enforce strong, unique passwords and implement multi-factor authentication where supported.
• Network Monitoring: Monitor egress traffic for patterns indicative of automated scanning or connections to known C2 hosts (e.g., 85[.]215[.]131[.]70 and 217[.]160[.]125[.]125).

Indicators of Compromise (IOCs)

Network Hosts

• 217[.]160[.]125[.]125:15527
• 176[.]100[.]37[.]91
• 85[.]215[.]131[.]70

File Hashes (SHA-256)

444a9d34a9f59dc7975dfabefb47d789813a4497bbac9127c4806dd816e85211
9394666007fac4014a4641fdae150c1b969ed2bc4299876318a336fd386abf59
450ea44da0c9d96a2e8f4d6bad34f1c35cd35743295b8cd2defa9f7a9884685d
d452f22dacab9785539484245c13e9cce58df23fc82eeef205684fcd196da20b
20042f1efb59c99e3addf822a3e9e5a496f0b701362df038a50a32a9f504a136
7413cbb6eab4d6b10346f71be5dd76d7cf2f4817f7776367b162f83755aefa1f
b6f835ced11059d341222eba11fff3a4672f4de47a3a4d791fad86059a2b06d4
b61a5508847a2167b737d31193dc393e92c5be2aa5141bbe4b7ea6f440fd4799
dff0edae6e8854ddd3e617054ee0bd74c696c91411f704dff60aabaec839bec9
ea44138b9701fce1b2fe13de8f9e00681c007c9adc625edc9f507f177704c2e8
3ddb67ab079509dd1e7ac77fc4cfed25a271526668c68f8a2221e96a4cc21812
f02b1d8010dac35b007796def0cbd5d0c9414df790e2b55b105c95df2f2ffa91
8fc2d35b66c692d37a85ae9d30dc5c7f06f0b3eaf01112a5a6398a1a0feb3aee
eead44c0af7ddb12cece1a6125cf213bab3c22511cd59aff9d63dcfddb7d4386
41e8e327abbf2ba721be677ad8a416a7295708257b39688a0af03275fb199cec

Note: IP addresses are intentionally defanged (e.g., [.]) to prevent accidental resolution.