Bloqueo accidental de una botnet
Resumen ejecutivo
Los equipos de Akamai han continuado sus investigaciones sobre KmsdBot, una botnet de criptominería, y han comprobado que los autores la bloquearon accidentalmente.
En nuestro entorno controlado, pudimos enviar comandos al bot para probar su funcionalidad y sus firmas de ataque.
Como parte de este análisis, un error de sintaxis provocó que el bot dejara de enviar comandos, acabando eficazmente con la botnet.
Dado que esta botnet en particular no busca persistencia en un sistema, solo puede continuar su misión si vuelve a infectar el sistema.
Introducción
A principios de este mes, el equipo de seguridad de Akamai publicó una entrada en su blog, sobre KmsdBot, una botnet de criptominería que infectó a sus víctimas a través de SSH y credenciales débiles. Analizamos esta botnet e informamos de ello inmediatamente después de que infectara uno de nuestros señuelos.
Sin embargo, después de esa publicación, seguimos supervisando la botnet, y tenemos algunas novedades que compartir en esta entrada del blog, como el hecho de que la hemos podido dejar inservible. En esta publicación, describiremos los pasos que hemos dado para inspeccionar KmsdBot, lo que nos ha llevado a ejecutar nuestros comandos y, en última instancia, a su desaparición.
Obteniendo el mando y control del mando y control
El elemento más letal de cualquier entidad maliciosa es la capacidad de obtener mando y control (C2). Dado que KmsdBot tenía funcionalidad C2, queríamos probar varios escenarios relacionados. Parte de esa prueba fue la modificación de una muestra reciente de KmsdBot para que se comunicara con una dirección IP en el espacio de direcciones RFC 1918.
Esto nos permitió tener un entorno controlado en el que probar y, como resultado, pudimos enviar al bot nuestros propios comandos para probar su funcionalidad y firmas de ataque. Curiosamente, después de un único comando con formato incorrecto, el bot dejó de enviar comandos. Naturalmente, iniciamos una investigación. No todos los días nos encontramos una botnet en cuya destrucción los propios atacantes colaboran.
Cómo lo detectamos
Fig. 1: Desmontaje de la función sys.main.connect()
Puede ver que el segmento de cadena se almacena en la ubicación de memoria 0x00632f19. Podemos saltar a esa dirección en el código binario y modificar su contenido para que apunte a una dirección de red en el espacio RFC 1918, es decir, en algún lugar de 192.168.0.0/24, que controlamos.
De esta forma, podemos actuar como el C2 y enviar comandos de ataque de muestra para dirigir el tráfico de ataque a un objetivo donde podemos registrar el tráfico de red.
Fig. 2: Escritura de la dirección en hexadecimal .861.291 al revés por la extremidad de endianness
Por lo tanto, nuestro nuevo C2 es 192.168.0.31 en el puerto 57388 (Figura 2). Sabemos que el C2 se comunica en texto no cifrado, por lo que el envío de comandos de malware se puede realizar mediante netcat. A continuación, configuramos dos máquinas virtuales: una en la que detonar el malware y la otra para utilizarla como nuestro C2.
Durante las pruebas, detectamos que la botnet dejó de enviar comandos de ataque tras observar que llegó un único comando con formato incorrecto. El comando:
!bigdata www.bitcoin.com443 / 30 3 3 100
Un atento observador notará la falta de espacio entre el sitio web de destino y el puerto. El bot no tiene integrada la comprobación de errores en su código para verificar que los comandos tienen el formato correcto.
Debido a esto, un comando con formato incorrecto provocaba que el binario Go se bloqueara con un seguimiento de pila que indicaba un error de índice fuera de rango. Esto se debe a que se proporcionó un número incorrecto de argumentos. Probamos esta teoría con nuestra configuración de C2 y bots (Figura 3).
Fig. 3: Emulación del C2 y reproducción del comando mal formado que se envió
Fig. 4: El bot se bloqueó porque se proporcionó un número incorrecto de argumentos
Este comando mal formado probablemente bloqueó todo el código de la botnet que se ejecutaba en los equipos infectados y se comunicaba con C2, básicamente, acabó con la botnet. Dado que el bot no tiene ninguna funcionalidad para la persistencia en un equipo infectado, la única forma de recuperarse es reinfectar y reconstruir la botnet desde cero.
Conclusión
No es frecuente que veamos esta situación en el ámbito de la seguridad. En nuestro mundo plagado por amenazas de día cero y burnout, ver que se puede mitigar una amenaza simplemente mediante una especie de error ortotipográfico en el código es algo sorprendente. Esta botnet ha estado persiguiendo a algunas grandes marcas de lujo y empresas de juegos, y sin embargo, un comando fallido ha sido su fin. Este es un claro ejemplo de la naturaleza voluble de la tecnología y de cómo incluso el atacante puede verse atacado por ella.
El objetivo del equipo de investigación sobre seguridad de Akamai es rastrear, detectar, documentar y publicar nuevos descubrimientos para proteger la seguridad y la estabilidad de Akamai, a sus clientes y a Internet en su conjunto. Seguiremos vigilando estos ataques y actualizaremos este blog en consecuencia. Para estar al tanto de las novedades en investigación sobre seguridad en tiempo real, síganos en Twitter.
