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.

La inyección de comandos a un nivel más alto y abstracto

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.

Identificador del actor impreso en stdout en la ejecución inicial

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

IdentificadorTipo de ataqueDescripción
udpInundación UDPEnvíe una gran cantidad de paquetes UDP al servidor de destino.
maleficioAtaque basado en UDP
synInundación SYNEnvíe una gran cantidad de paquetes TCP SYN al servidor de destino. Los paquetes SYN solicitan una conexión.
ackInundación ACKEnvíe una gran cantidad de paquetes TCP ACK al servidor de destino. Los paquetes ACK validan que se recibe un paquete.
udpplainInundación UDP con menos opciones, optimizado para mayor PPSInundación UDP con diferentes opciones establecidas.
tcpallInundación de TCP con todas las opciones configuradasPaquetes TCP con todas las opciones configuradas.
tcpfragAtaque de fragmentación de TCPInundación de TCP dirigida a los mecanismos de reensamblaje de TCP, que unen paquetes de datos fragmentados.
pisar muy fuerteInundación de stomp TCPAbusar 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.
NavidadAtaque de paquetes navideñosEnvíe paquetes con cada una de las opciones configuradas para cualquier protocolo que esté en uso.
vseAtaque de consulta del motor de origenAtaque 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.
greipAtaque de encapsulación de enrutamiento genérico sobre IPGRE es un protocolo con el propósito de simplificar las conexiones entre redes. Este ataque abusa de este protocolo.
saludoAtaque de encapsulación de enrutamiento genérico a través de EthernetIgual que GREIP, pero centrándose en la capa Ethernet.
udpbypassProbablemente inundación de UDP con mecanismos anti-defensaAun no implementado.
tcprawInundación de TCPEnvíe datos aleatorios a través de TCP al servidor de destino.
stdAtaque 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.

Intercambio inicial entre el C2 y el malware

Descripción general de los comandos C2

Formato C2Descripció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.

Cambiar el nombre del proceso con prctl

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 muestraArquitecturaSha256
FederalAgency.arm5Armv5a1ffd6f459720014d7e54c023183b32f55fdd3811301922d623c96b2b4dcd024
FederalAgency.arm6Armv6a401e7ff574bcc5c34c6842e57fe5e4e7a00f9c8c52658abf033f0534a31ba90
FederalAgency.arm7Armv7f63f6c6549f238cca61b179d9b85aebce08348ce23c3c9db218038cb4f2d13f4
FederalAgency.mipsMipscbe3ad269c4b89027f9f475ee2b3d9be04cd48711a5ab85c3609b6389079ecb1
FederalAgency.ppcPowerPc59be5962169607dc9a0f0cea3056dc097b5c981f4fd9bca6dfc4c805b43b56b2
FederalAgency.x86x864126ccad08f12e61c06869726e1867e8970d705cd9c649ff7326141530eb5ed4

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