Business Solutions
Partners
Antivirus
Para todos los dispositivos
Viajes
Nuestra historia
Zona de prensa
Quiénes Somos
Área Partners
Contacto
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.
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.
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.
| 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 | |
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.
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
