Ingeniería Inversa y observación de una botnet de IoT

Los dispositivos de IoT están en todas partes a nuestro alrededor y algunos de ellos no están actualizados con el estándar de seguridad actual. Una sola bombilla expuesta a Internet puede ofrecer a un atacante una variedad de posibilidades para atacar empresas u hogares. Las posibilidades son infinitas.

Si pensamos en un enrutador o seguimos el ejemplo con la bombilla, tal dispositivo secuestrado puede usarse para diversas actividades maliciosas. Por ejemplo, construir una botnet y monetizarla ofreciendo DDoS como servicio o usando el dispositivo IoT como puerta de entrada a una red corporativa. También ha habido casos en los que se utilizó ransomware en dispositivos IoT. Y cuando hablamos de IoT en el contexto de abuso por parte de actores malintencionados, el término no se limita de ninguna manera al hardware de consumo, como las bombillas antes mencionadas. Esto incluye sistemas HVAC controlados de forma remota y también cosas como sistemas de control de acceso para edificios. Descubrirá que este último puede funcionar en más de un sentido.

En este artículo, nos centraremos en la ingeniería inversa de una muestra común de malware de IoT y nos conectaremos al servidor C2 para observar los comandos enviados por el actor a los dispositivos infectados.

Infección

En nuestro caso, observamos que el servidor C2 es el responsable de una infección inicial. Mediante la investigación, encontramos evidencia de que el servidor con la dirección IP 103.145.12.11 busca dispositivos que son vulnerables a CVE-2019-7256. El CVE describe una vulnerabilidad de ejecución remota de código en sistemas de control de acceso de la serie Linear eMerge E3. Este es un sistema de control de acceso que se encuentra comúnmente en edificios de oficinas y administración. Es posible que haya utilizado uno de estos sistemas al pasar su tarjeta de acceso por la mañana o una tarjeta de visitante. Al abusar de la vulnerabilidad de seguridad CVE-2019-7256, el atacante puede inyectar comandos de shell maliciosos para descargar su malware y ejecutarlo en el dispositivo.

El exploit descarga una muestra del servidor C2. Posteriormente, la bandera ejecutable se establece para esta muestra y se ejecuta. Finalmente, la muestra se elimina del dispositivo infectado.Pudimos recuperar más muestras de la dirección IP anterior. Este artículo se centrará en la variante dirigida a la arquitectura x86. Los hash correspondientes para estas muestras se pueden encontrar al final de este artículo.

Ingeniería inversa del malware

A continuación, vamos a sumergirnos en el malware y aplicarle ingeniería inversa. La mayoría del malware de IoT que se encuentra en la naturaleza se puede clasificar como una variante de Mirai. Al revisar el código, identificamos múltiples funciones, que también se utilizan en el código original de Mirai. Sin embargo, el autor modificó el código y creó algunas rutinas originales.

Al comienzo de la ejecución, el atacante imprime su mango. Esto es muy común para el malware de IoT y también puede ser un buen factor para una clasificación adicional, así como para asignar variantes a autores específicos.

Esta variante tiene una lista de credenciales de Telnet predeterminadas comunes codificadas de forma rígida. Durante la ejecución, genera direcciones IP aleatorias e intenta conectarse al puerto telnet.

No investigamos esta función por completo. Sin embargo, creemos que una vez que un puerto telnet es forzado con éxito, enviará la dirección IP de la víctima, así como las credenciales utilizadas a su servidor C2. El servidor C2 o la muestra en sí podrían desencadenar la acción maliciosa, lo que conducirá a la toma de control del dispositivo.

Descripción general de las capacidades de DDoS

Conocemos la mayoría de las variantes de ataque implementadas. Identificamos dos ataques DDoS basados ​​en UDP, en los que no profundizamos y aún no pudimos identificar. La muestra también tiene un método de ataque con el identificador “udpbypass”, que aún no está implementado. Esto es muy interesante, porque indica que esta variante aún es un trabajo en progreso. 

Una tabla a continuación muestra todos los tipos de ataques DDoS que encontramos.

Descripción general de los métodos de ataque DDoS

Identificador	Tipo de ataque	Descripción
udp	Inundación UDP	Envíe una gran cantidad de paquetes UDP al servidor de destino.
maleficio	Ataque basado en UDP	–
syn	Inundación SYN	Envíe una gran cantidad de paquetes TCP SYN al servidor de destino. Los paquetes SYN solicitan una conexión.
ack	Inundación ACK	Envíe una gran cantidad de paquetes TCP ACK al servidor de destino. Los paquetes ACK validan que se recibe un paquete.
udpplain	Inundación UDP con menos opciones, optimizado para mayor PPS	Inundación UDP con diferentes opciones establecidas.
tcpall	Inundación de TCP con todas las opciones configuradas	Paquetes TCP con todas las opciones configuradas.
tcpfrag	Ataque de fragmentación de TCP	Inundación de TCP dirigida a los mecanismos de reensamblaje de TCP, que unen paquetes de datos fragmentados.
pisar muy fuerte	Inundación de stomp TCP	Abusar del protocolo STOMP. Después de la conexión inicial a través de TCP, se envían paquetes STOMP basura. Estos se procesan y pueden provocar un bloqueo del servidor.
Navidad	Ataque de paquetes navideños	Envíe paquetes con cada una de las opciones configuradas para cualquier protocolo que esté en uso.
vse	Ataque de consulta del motor de origen	Ataque basado en UDP. Abusa de las solicitudes de TSOURCE ENGINE QUERY enviadas a los servidores del juego. Attack está diseñado específicamente para atacar servidores de juegos.
greip	Ataque de encapsulación de enrutamiento genérico sobre IP	GRE es un protocolo con el propósito de simplificar las conexiones entre redes. Este ataque abusa de este protocolo.
saludo	Ataque de encapsulación de enrutamiento genérico a través de Ethernet	Igual que GREIP, pero centrándose en la capa Ethernet.
udpbypass	Probablemente inundación de UDP con mecanismos anti-defensa	Aun no implementado.
tcpraw	Inundación de TCP	Envíe datos aleatorios a través de TCP al servidor de destino.
std	Ataque basado en UDP

Protocolo C2

El protocolo C2 es bastante simple e indica que el autor planea mantener las funcionalidades limitadas a los ataques DDoS. Tras la infección, envía un mensaje de baliza inicial al servidor C2, que debe enviarse al servidor C2 solo una vez. Posteriormente, mantiene una conexión TCP con el servidor y espera más comandos. Con todo, el atacante implementó 2 comandos C2 diferentes.

Descripción general de los comandos C2

Formato C2	Descripción
[IP], [PUERTO], [MÉTODO DE ATAQUE DDOS], [DURACIÓN]	Inicie el ataque DDoS en el host remoto con la dirección IP entregada
! [IP]	Mata el proceso bifurcado con está atacando actualmente la dirección IP entregada

Una vez que el bot recibe un comando C2, se crea un nuevo proceso hijo. El proceso hijo utiliza un pequeño truco para cambiar su nombre de proceso. Primero, toma la dirección IP de destino y la agrega a un signo de exclamación. A continuación, llama a prctl con la opción 15 para cambiar su propio nombre de proceso. El nombre del proceso hijo ahora contiene una subcadena de la dirección IP atacada.

El segundo comando C2 se puede utilizar para eliminar un ataque DDoS en curso. Una vez que se recibe un comando kill, escanea el archivo de estado en el directorio proc en busca de la dirección IP atacada. Si se encuentra, el proceso se mata.

Recopilación de comandos C2

Finalmente podemos volver a implementar el protocolo C2 y empezar a comunicarnos con el servidor C2. El servidor C2 creerá que una máquina infectada válida envió la baliza inicial y comenzará a enviar comandos C2 para ejecutar.

El bloque anterior muestra una parte de los comandos C2 que recibimos durante un período de 2 días. Como se vio anteriormente, el tipo de ataque hexadecimal se emitió con mucha frecuencia.

Ultimas palabras

La variante que acabamos de hacer ingeniería inversa y rastreamos es uno de los muchos casos comunes que generalmente se encuentran en el panorama de amenazas de IoT. Cuando se trata de malware de IoT, encontrará muchos casos similares como este.

Por lo tanto, es muy importante que los investigadores comprendan casos como este de la misma manera, ya que es importante distinguir entre un troyano bancario más sofisticado como Emotet y un malware escrito por algún hacker, que está escribiendo malware solo por la emoción. Comprender diferencias como esta nos ayuda a buscar malware de IoT más avanzado, como el malware Mozi, que apareció alrededor de septiembre de 2019. El malware de IoT puede avanzar y seguirá adelante y estaremos atentos.

Indicadores de compromiso (IOC)

Nombre de la muestra	Arquitectura	Sha256
FederalAgency.arm5	Armv5	a1ffd6f459720014d7e54c023183b32f55fdd3811301922d623c96b2b4dcd024
FederalAgency.arm6	Armv6	a401e7ff574bcc5c34c6842e57fe5e4e7a00f9c8c52658abf033f0534a31ba90
FederalAgency.arm7	Armv7	f63f6c6549f238cca61b179d9b85aebce08348ce23c3c9db218038cb4f2d13f4
FederalAgency.mips	Mips	cbe3ad269c4b89027f9f475ee2b3d9be04cd48711a5ab85c3609b6389079ecb1
FederalAgency.ppc	PowerPc	59be5962169607dc9a0f0cea3056dc097b5c981f4fd9bca6dfc4c805b43b56b2
FederalAgency.x86	x86	4126ccad08f12e61c06869726e1867e8970d705cd9c649ff7326141530eb5ed4

Enlace: https://www.gdatasoftware.com/blog/2020/08/36243-reverse-engineering-and-observing-an-iot-botnet Blog de G DATA