Analyzing a Go-Based IoT Self-Propagating DDoS Botnet

The sample we analyzed is a self-propagating IoT DDoS botnet written in Go. Its capabilities fall into three main areas: propagation, remote control, and DDoS attacks.

The malware’s C2 client maintains a connection to a hard-coded controller and waits for attack commands. Separately, its worm/scanner module continuously searches the public internet for vulnerable IoT and router devices. The scanner begins operating when the malware launches and does not require a command from the C2 server.

The sample also contains approximately 30 DDoS methods. These include basic volumetric floods, packet rate attacks, game server attacks, HTTPS- and TLS-based attacks, and techniques designed to bypass or evade mitigation.

This combination allows the malware to recruit additional devices while providing operators with a flexible pool of attack capacity (Figure 1).

The propagation module uses blind random public-IPv4 scanning. 

main.StartScanner launches exactly 100 concurrent goroutines. Each worker repeatedly generates a random IP address, attempts exploitation, waits 100 milliseconds, and starts again. The scanner filters out RFC1918 private addresses and loopback addresses, but there is no evidence of CIDR- or ASN-based targeting.

This means the scanner is not working from a predefined list of networks. Instead, it continuously samples the public IPv4 address space looking for vulnerable devices.

The exploitation sequence targets exposed router configuration and diagnostic interfaces.

The process begins with main.confCheck, which sends a raw TCP request for /config.dat with a User-Agent: Hello World header. The malware uses the response to determine whether the target exposes an unauthenticated configuration backup. A 200 OK response with a Content-Disposition: attachment header indicates a successful check.

If the configuration is accessible, main.getCredLeak and main.getAdminCredLeak retrieve and process the response. The malware uses a hand-written LZSS decompressor, similar to the approach used by Mirai’s table.c, before parsing credentials from the resulting plaintext using fixed two-byte TLV tags.

Importantly, the malware does not appear to rely on dictionary or brute-force attacks to obtain credentials. It retrieves them directly from the exposed configuration data (Figure 2).

The analyzed sample was also observed being downloaded after exploitation of Langflow CVE-2026-33017.

A honeypot captured a request to the Langflow /api/v1/validate/code endpoint that executed a command to retrieve bins.sh from the attack infrastructure (Figure 5).

The analyzed binary connects to 5.175.140.250:9111 using plaintext TCP. No TLS, authentication handshake, encoding, or obfuscation was observed on the C2 connection. After connecting, the malware reads the socket one line at a time with bufio.Scanner.Scan(). Each line is split into whitespace-delimited fields with strings.Fields(), with the first field determining the command.

Matched commands launch the corresponding Botnet_Methods function in a new Go goroutine, passing parameters such as the target and attack duration.

The command set includes:

• _KILL: terminates and removes the malware

• STOP: stops an active attack and resets the attack state

• Persist: invokes the persistence routine

• dns,ovh, fort, game, gbps, and https: launches different attack methods    

• bypass, crash, freez, and priv7: launches additional attack methods     

• discord and fivem: targets Discord and FiveM infrastructure

• ppsraw,udppps, raw-udp, raw-tcp, and raw-ack: launches packet- or transport-level floods           

• tlsplus and tlsplusbypass: launches TLS-based attack variants

Additional methods are present in the binary even though they were not individually traced to a literal C2 command, including TCPFlood, UdpFlood, TLSFlood, PPSFlood, and Minecraft. 

There was no evidence of multiple fallback C2 hosts, C2 encryption, or an authentication handshake in the analyzed sample. However, the C2 address is not necessarily fixed across every build. Compile-time configuration can replace main.ServerIP, allowing the operator to build the malware with a different controller (Figure 7).

Persistence is triggered by the persist C2 command. The main.AutoStart routine determines the malware’s own executable path, copies the binary to a persistence location, and makes the copy executable. It then checks startup files — including cron, init scripts, or rc-style configuration — for an existing entry. If none is found, it appends an entry for itself.

The observed sample also uses the following cron entry:

* * * * * /tmp/sysd > /dev/null 2>&1

This gives the malware a mechanism to regain execution after system events such as a reboot.

The Botnet_Methods package contains approximately 30 attack methods. Because many of the functions are thin wrappers around goroutines containing the actual packet and socket logic, the transport type for some methods can be inferred from function names or visible resolver/dial calls rather than directly confirmed from the extracted attack body (Figure 8).

The clearest evidence of deliberate evasion is Priv7Flood. Rather than sending identical requests, this method constructs HTTP-like traffic that varies between connections. It first normalizes the target URL and resolves the destination, then creates a worker pool sized according to the available CPUs: 250 workers on systems with fewer than four CPUs and 1,000 workers otherwise.

Each worker allocates a 2,000-byte buffer and generates random data between 16 and 141 bytes. It also selects strings from several pools: six strings likely representing rotating User-Agent values, four additional strings, and three longer strings. These values are incorporated into a 191-byte Sprintf template.

The result is a different-looking HTTP-like request on each connection. This behavior appears designed to make static-signature DDoS detection more difficult. Instead of relying on a single predictable request pattern, the malware introduces enough variation to complicate defenses that depend primarily on fixed signatures.

The sample contains additional TLS-oriented methods, including TLSFlood, TLSPlusFlood, and TLSPlusBypassFlood. TLSPlusBypassFlood loads a list of proxies from a file and routes traffic through the proxy pool, providing additional source-IP diversity.

The technical implementation of this botnet is relatively straightforward in some areas. Its C2 protocol is unencrypted and unauthenticated, for example, and the sample does not demonstrate the characteristics of a hardened, APT-style implant.

Instead, its threat comes from the combination of simple automation and broad attack capability. The scanner operates independently of the C2 connection, allowing infected devices to continue to search for additional victims. Once devices are compromised, operators can choose from a large set of attack techniques, including volumetric and application-layer floods.

Some methods deliberately vary their traffic or use proxies to make static detection more difficult. This creates a distributed attack platform that can adapt its traffic to different targets and defensive controls.

This Go-based IoT botnet demonstrates how automated propagation can turn vulnerable internet-connected devices into distributed DDoS capacity. Its scanner continuously searches for vulnerable public-facing devices, while its C2 infrastructure gives operators control over a broad collection of attack techniques. The malware also includes persistence mechanisms and several methods intended to vary or disguise attack traffic.

The sample’s significance comes from how effectively relatively simple components work together: automated recruitment, persistent access, centralized control, and a flexible DDoS toolkit.

For defenders, that combination reinforces the importance of understanding attack infrastructure at both the malware and traffic levels. Reverse engineering can reveal how a campaign operates, threat intelligence can turn those findings into actionable indicators and behaviors, and distributed edge defenses can help stop malicious traffic before it reaches its intended target.