Linux/Moose es una familia de malware que ataca principalmente a los routers basados en Linux, pero que también puede infectar otros tipos de dispositivos con sistemas Linux a los que obtenga acceso. Los dispositivos infectados se utilizan para robar tráfico de red no cifrado y ofrecer servicios de proxy al operador de la botnet. En la práctica, estas capacidades se utilizan para robar cookies HTTP en sitios de redes sociales populares y llevar a cabo acciones fraudulentas, tales como hacer clics no legítimos en “Seguir”, “Visto” y “Me gusta”.
En mayo de 2015, ESET publicó un whitepaper sobre esta familia de malware. Tras la publicación del artículo, los servidores de comando y control (C&C) de Linux/Moose cayeron y perdimos la pista del malware. Unos meses después, en septiembre de 2015, recibimos una nueva muestra de Linux/Moose, que, como era de esperar, había evolucionado desde nuestra publicación.
Durante el último año, ESET y la empresa de seguridad GoSecure sumaron esfuerzos para investigar más a fondo a Linux/Moose. GoSecure investigó el aspecto del fraude en redes sociales y arrojó algo de luz sobre un mercado hasta ahora desconocido, al que llamaron “The Ego Market”. Este mercado se describe en un nuevo whitepaper publicado por GoSecure.
En este artículo explicamos los cambios técnicos detectados entre las variantes de Moose que describimos inicialmente en el whitepaper y las nuevas variantes que aparecieron en septiembre de 2015.
Ocultamiento de las direcciones de C&C
Lo primero que notamos en la nueva muestra es que ya no había más direcciones IP del servidor de C&C en el archivo binario. Parece que, tras leer nuestro informe, los operadores decidieron dificultarnos un poco más las cosas. En esta nueva versión, la dirección IP del servidor de C&C figura como un argumento de línea de comandos cifrado, como se muestra en la siguiente imagen:
Esta nueva característica implica que ya no podemos seguir ejecutando la muestra nosotros mismos; ahora, nuestras máquinas de pruebas tienen que infectarse mediante un dispositivo incrustado que propague la amenaza activa en el mundo real para poder recuperar la dirección IP del servidor de C&C. El lector atento observará que la dirección IP mostrada está en el formato de enteros de 32 bits.
El propósito de cifrar la dirección IP es el siguiente: en caso de que se detecte el archivo binario solo, será inútil sin el valor que se pasa como argumento. Por otra parte, el valor por sí solo tampoco tiene sentido si el binario no cuenta con el valor correcto para descifrar el argumento. El valor está codificado con XOR con un valor estático, como se muestra en el siguiente fragmento de código:
Resultado del descompilador
Por lo que sabemos, este valor sigue siendo el mismo de los últimos meses. El siguiente es un fragmento de código en Python para descifrar el valor del entero de 32 bits correspondiente al servidor de C&C:
Descifrado de la dirección IP del servidor de C&C
Comunicación de red
Otra de las cosas que cambiaron es el protocolo de red: aunque la base se mantuvo, se agregaron nuevas capas. A continuación se ve una captura de paquetes de ambas muestras. Al parecer, el cambio principal es que, en lugar de usar el protocolo binario, se pasó al protocolo de caracteres ASCII imprimibles. En la Imagen 1, a la izquierda figura el antiguo protocolo de red y, a la derecha, el nuevo.
Imagen 1: Diferencias en los protocolos de red
En la muestra más antigua, el servidor de C&C enviaba la configuración al malware con varios campos: un campo de bits para determinar qué característica se iba a habilitar, varios campos de direcciones IP, un campo de listas blancas y un campo de listas de contraseñas. Aunque estos campos siguen presentes en la nueva versión, se entregan por separado, bajo tres claves distintas (ver Tabla 1).
Los operadores usan los campos de encabezado HTTP Cookie: y Set-Cookie: para enviar la configuración. Esta configuración está cifrada con un simple bucle XOR similar a la primera versión, pero también está codificada para poder imprimirse en los encabezados HTTP mediante la siguiente función:
Resultado del descompilador
La Tabla 1 (tabla de valores de clave) resume la configuración principal de la versión 2 de Moose:
| Clave | Valor |
|---|---|
| PHPSESSID | Configuración principal (exploración local/externa, robo de datos, finalización de procesos) |
| LP | Lista de contraseñas |
| WL | Listas blancas |
La clave PHPSESSID contiene el valor cifrado de los campos de bits que permiten activar o desactivar algunas funciones de Moose (exploración local/externa, robo de datos, finalización de procesos). La clave LP contiene la lista de contraseñas. Linux/Moose sigue tratando de propagarse adivinando las credenciales de Telnet mediante ataques de fuerza bruta. Hubo un gran cambio en esta lista, que pasó de tener alrededor de 300 inicios de sesión y contraseñas en 2015, a tener solo alrededor de 10 en 2016:
La clave WL contiene las listas blancas. Una vez más, la lista se redujo de 50 a 10 direcciones IP, que están en la sección de indicadores de sistemas comprometidos. Linux/Moose aún mantiene su capacidad de ejecutar un servicio proxy escuchando en el puerto TCP 20012. La variante anterior escuchaba en el puerto 10073. La función de proxy permite que las direcciones IP en la lista blanca interactúen con el malware.
Conclusión
Es claro que los autores de Linux/Moose trabajaron mucho para permanecer bajo el radar con su nueva versión, ya que ocultaron la ubicación del servidor de C&C de manera más efectiva y cambiaron el protocolo de red. De esta forma, Moose evita los indicadores de sistemas comprometidos (IoC) que se publicaron en el whitepaper de ESET en 2015. La estrategia de Moose de acortar la lista blanca y la lista de contraseñas muestra que ahora usa un enfoque más comedido. Sin embargo, hay algunos rastros dentro del binario que se usan para engañar a los investigadores, como el dominio falso www.challpok.cn, que se encuentra en la lista de cadenas de texto sin codificar, o incluso nombres de archivo que pueden corresponder a programas extractores de Bitcoins o a malware para ejecutar ataques de DDoS. La amenaza Linux/Moose sigue alojándose exclusivamente en memoria; por lo tanto, reiniciar el dispositivo incrustado finalizará su ejecución.
Source:https://www.welivesecurity.com/
Entusiasta de la seguridad cibernética. Especialista en seguridad de la información, actualmente trabajando como especialista en infraestructura de riesgos e investigador.
Experiencia en procesos de riesgo y control, soporte de auditoría de seguridad, diseño y soporte de COB (continuidad del negocio), gestión de grupos de trabajo y estándares de seguridad de la información.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/.
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad
