Mirai-derived botnets continue to dominate the IoT threat landscape, but the more important shift is how quickly new variants can now be developed and deployed. Golang, reusable open-source components, commodity infrastructure, and automation have significantly reduced the effort required to build functional DDoS malware, enabling threat actors to assemble and iterate botnets with increasing speed.
This blog examines two Golang-based malware samples we identified in the wild this spring, Apex2 and c2c/meow, that illustrate this trend from different angles. While Apex2 represents a more structured evolution of an existing botnet targeting both Windows and Linux machines, c2c demonstrates how relatively simple components can be combined into an operational campaign. In both cases, the emphasis is not on sophistication, but on speed, reuse and scalability.
For defenders, the implication is clear: detection and response approaches must keep pace with faster malware development and exploit weaponization cycles. Organisations should expect a steady stream of simple but effective botnets targeting exposed Linux and IoT systems, particularly where weak credentials, internet-facing services, and limited outbound visibility persist. Scalable analysis techniques, including automation, machine learning, and large language models, are becoming essential to triage large volumes of samples, identify deviations from known families, and rapidly translate analysis into actionable detections.
Background and Scope
As we discussed in a previous blog post about proactively finding new OT threats, similar techniques can be used in the IoT space to surface unusual samples.
This spring saw a new wave of IoT malware targeting exposed devices and repurposing them for DDoS activity. Our AI-assisted monitoring helps review honeypot activity and highlight samples that differ from the large volume of known Mirai-like variants we already track. In this blog post, we focus on two Golang families that illustrate the broader trend: attackers are building functional botnets faster, while defenders need scalable ways to find the unusual samples, understand what changed, and translate those findings into repeatable detection and response workflows.
Apex2, a Still-Evolving IoT Botnet
Among the samples we receive every day, our AI-assisted system flagged one that, at the time of detection, was sufficiently different from the families we already tracked. Once the sample was in our hands, identifying it as Apex2 was straightforward. Beyond the name, the structural similarities between Apex and this sample indicate that Apex2 is a direct evolution of its predecessor.
The infection chain began with multiple Telnet connections to our honeypots, followed by credential brute-force attempts and the execution of the following commands:
After execution, the sample initiates communication with the C2 to register itself, sending the host’s OS and architecture using a simple plain-text protocol.
Based on the samples we analyzed, Apex2 supports both Linux and Windows hosts. The Windows builds support 386 and amd64 architectures, while the Linux builds additionally support arm, arm64, mipsle, and ppc64.
The bot receives commands from the C2 server instructing it to start or stop specific flood attacks. Some commands use descriptive identifiers, while others are less intuitive. When a command is received, the bot prints status messages describing the action being performed and when it completes. These debug-style messages are useful during development, but they also make malware analysis easier.
The following commands can be sent by C2 to initiate or stop attacks:
- cf: HTTP(S) flood targeting Cloudflare-protected sites. The attack randomizes requests using a large hardcoded list of User-Agent strings, sets the “Connection: keep-alive” header, and uses long timeout values.
- udp and pps: Different kinds of UDP flood attacks.
- discord and game: UDP flood attacks to target Discord and game servers.
- tls, tlsplus and tlsplusbypass: TLS flood attacks using different configurations of large KeepAlive and Timeout values, Connection: keep-alive HTTP header and using proxy from local proxy/tlsplusbypass.txt list.
- stop: Asks the infected machine to stop a specific attack.
While Apex2 represents a more structured evolution of an existing botnet, not all samples we encounter follow the same development patterns.
c2c/meow, a Generic Golang Flooder
Our machine learning system alerted us to the presence of another Golang-based malware reaching one of our SSH honeypots. At the time, the sample had no malicious detections on VirusTotal, so we decided to investigate further.
Compared to Apex2, this malware is a simpler standalone botnet. Instead of advanced evasion or complex infrastructure, its operators combined a scanner, basic C2 logic, persistence, and configurable flood modules into a working campaign.
There are a few naming artifacts worth clarifying before looking at the sample behavior. Some researchers refer to this family as “c2c” because the path “qwiklabs/c2c” appears in the analyzed sample. This may be an attempt to blend in with legitimate-looking training or cloud-lab terminology, or it may simply be a leftover artifact from the development environment.
During propagation, the attacker used “meow” as the filename for samples downloaded onto vulnerable systems. These strings can be useful campaign markers, but they are less reliable as long-term family names because they often change between waves.
Overall, the campaign shows a practical but relatively simple design. The distribution infrastructure and infection workflow require coordination, but the malware itself lacks several features commonly associated with more mature botnets, such as command signing, dynamic C2 discovery, protocol obfuscation or built-in propagation logic.
The analyzed binary does not include a self-propagation module. Instead, our honeypot logs suggest a separate Golang-based SSH scanner being used to identify internet-exposed hosts with weak credentials. This split between scanning and payload execution keeps the malware itself simple while still allowing the campaign to operate at scale when enough vulnerable devices are available.
Once running, the sample connects to a hardcoded C2 server and exchanges JSON messages over plaintext TCP, allowing for passive observation. On connection, it authenticates with the hardcoded string “ChangeMe123!” and identifies the infected system’s hostname and user.
The sample also includes a straightforward privilege-escalation and persistence routine. It checks whether passwordless sudo is available by running sudo -n true and evaluating the return value. If successful, it relaunches itself with increased privileges, copies to /usr/local/bin/cpufreqd, and creates a fake systemd service named “CPU Frequency Daemon” in /etc/systemd/system/cpufreqd.service, with ExecStart pointing to the copied binary.
Although the malware is relatively simple, it supports multiple flooding attack methods. The flood attack methods are configurable, but relatively simple. Each attack can be assigned a duration in seconds, and ports can be fixed, selected from a range, or set to 0 to request randomization. These capabilities would only become meaningful if the botnet reached sufficient size.
The supported attack types include:
- icmp: Sends ICMP echo requests to the target IP address while randomizing the source IP address.
- dnsudp: Sends UDP traffic to a specified domain for a defined duration. The port can be fixed, randomized, or selected from a range.
- udp: Like dnsudp, but targets an IP address instead of a domain.
- http: Performs HTTP GET or POST requests against a specified URL, with optional body content and support for HTTP/1.1 or HTTP/2. It uses Go’s standard net/http library.
- directhttp: Sends HTTP requests directly over a socket instead of using an HTTP library. Unlike the http module, it does not set the Cache-Control: no-cache or Connection: keep-alive headers.
- fasthttp: Uses the high-performance fasthttp library to send HTTP GET or POST requests to the target, selecting a user agent at random from four available options.
- betterhttp: Provides another HTTP-based flood module with behavior similar to the http command.
- tcp: Sends TCP traffic to a specified IP address with configurable flag, TTL, and window values.
- tcphandshake: Performs TCP handshakes against the target without the additional configuration options available in the tcp command.
- dnstcp: Resolves the target domain, then sends TCP traffic to the target.
Overall, this malware family appears less mature than longer-running, more established botnet projects. The “c2c” and “meow” names should therefore be treated as campaign markers rather than definitive family names. The Qwiklabs/c2c string observed in the sample may reflect a development artifact, a copied path, or an attempt to use legitimate-looking cloud-lab terminology, but the available evidence is not sufficient to determine intent.
Mitigations
- Reduce exposure of internet-facing management services wherever possible, especially Telnet and SSH on IoT, embedded Linux, and edge devices. Where remote access is required, restrict it through VPNs, allowlists, jump hosts, or other controlled access paths rather than exposing services directly to the internet.
- Eliminate default, weak, and reused credentials. Enforce strong authentication for administrative access and rotate credentials on deployed devices.
- Monitor for brute-force activity and unusual login patterns against SSH and Telnet services, including repeated failed authentication attempts, successful logins from unexpected geographies or cloud-hosted infrastructure, and immediate follow-on download commands.
- Inspect outbound traffic from IoT and Linux assets for suspicious C2-like behavior, including plaintext TCP sessions to unusual ports, repeated beaconing to unfamiliar hosts, and unexpected JSON-based command exchanges.
- Segment IoT, OT-adjacent, and low-trust Linux systems from critical business systems and sensitive networks. Limit outbound connectivity to what is operationally necessary so compromised devices cannot freely reach attacker-controlled infrastructure.
- Use network, endpoint, and threat intelligence detections together. The indicators in this post can support short-term hunting, but defenders should also build behavior-based detections for downloader activity, suspicious service creation, flood traffic, and anomalous outbound connections.
One way to put these mitigations into practice is to use a specialized platform such as the Nozomi Networks platform, which provides visibility across OT, IoT, and IT environments, continuously monitors network and endpoint activity, and combines behavioral analytics with threat intelligence to help identify exposed assets, suspicious access attempts, anomalous communications, and potential compromise. See how these capabilities can support your security program by exploring the Nozomi Networks platform through an interactive demo.
Conclusion
Apex2 and c2c/meow show two sides of the same trend: IoT botnet development is becoming faster, more modular, and easier to operationalize. Apex2 reflects a more structured evolution of an existing botnet, while c2c/meow shows how simpler components can still be assembled into an effective campaign when exposed services and weak credentials are available.
The defender takeaway is that sophistication is not the only measure of risk. Even relatively simple malware can have a meaningful impact when deployed at scale. Organizations should therefore combine automated analysis, behavioral detection, credential hygiene, and exposure reduction to keep pace with the volume and speed of new Linux and IoT malware.
Indicators of compromise
Apex2
- 82.223.44.153
- 176.65.139.177
- 31.56.209.85
- hxxp://31.56.209.85/x86
- hxxp://31.56.209.85/mips
- hxxp://31.56.209.85/mipsle
- ae55505870f4e4783eddf4e043a3e0de236c8fd81b63ea65f7b133c4f0a0a452
- c65a68fa814525ef7ef8b7ff300c2e002ede6098f835ebd4db6672ba8939d757
- e50060dfc0a905f3f459f04396ce3a4dfb506c94c8ab2caa56f22e334e7caa3f
- 85fa54c230195e2e5492ec0d2c1503d2710ad383cae3236179b388bff8d02787
- 28184f309a2f0021ab1d56e6d71e1f21345efbeb5d515064a2080c494dcb505c
- 1ae9560a4a762f03ef8f650f85fdd15a1a3e6f5d5ce6112bd1837e3edfebf8a5
- 0c14ea75940a7cd55796468f402ad2f6157284ac1e078fee4cf1774e8ecaeec3
- 07223a7e19345719db2d81a0ca14e986421ffdda577c281ca4f69a99f78af44b
- 2dbfcce95e5a6f6ab7c5b885d8cfee1332b7b194c767b6f7ea6ac65d7bf9aa21
- 310f38b8666d3f68fdf2ba0840ec048828566f92616cd452f2d0da8a332eeca2
- 7aebb4fbdcc9eb6474323ad00aa2e75f21907126bf18972288b62082bd216c25
- e29e70e167ff009b8a33f50dcb6b1a4d3264c2d59e41dc30ad78016ffd68dea7
c2c
- ff2aeae29f6b08146ec13515635d21df3c84d6d4a01145790d006955cf067332
- fbbd29bd9f03cf95b832bf87f46b69096548cb9a6cbd1d01c530435bec49c7e3
- b3999579550107ab792edbf54958ce5b56fecdf7b1e934589d7571b0fb4fcc6d
- 55cfdee201055744c001626cb028c84c50e9021211d692cf6cbb38a899d895a8
- 5bf67d64e94a8ed6b81a0855fee52626eb0f4caf1772518fc2404883030451c2
- 86d162d2e4ae90daad260faa7df25be2e28bc70a97d0d0548d80a670177a2739
- 27a3a5a4c65732e788b025cc2566ebae655359408eda61ff1ce6f4d6a823441
- 35.227.3.70 (SSH bruteforce)
- 34.138.181.9 (SSH bruteforce)
- 51.83.6.7:20086 (C2)
- 51.75.118.169:20037 (C2)
- hxxp://35.237.91.38/meow
- hxxp://35.237.91.38/meowarm64
.webp)
