Investigación del resurgimiento de la campaña de Mexals
Resumen ejecutivo
Comentarios editoriales y adicionales de Tricia Howard
Akamai Security Research ha estado realizando un seguimiento y analizando el resurgimiento de Mexals, una campaña de cryptojacking probablemente establecida en Rumanía.
La campaña ha estado activa al menos desde 2020, y anteriormente se trató en un informe de Bitdefender en julio de 2021.
La nueva ola de ataques y mejoras de malware parece haber comenzado en octubre de 2022. Ahora se llaman a sí mismos Diicot, que también es el nombre de la agencia rumana contra el terrorismo y la delincuencia organizada.
Los investigadores de seguridad de Akamai comenzaron a analizar la campaña tras la detección de DNS malicioso en un cliente de Akamai. Todos los clientes de Akamai afectados fueron notificados rápidamente y se tomaron las medidas adecuadas.
Los atacantes utilizan una larga cadena de cargas útiles antes de soltar un malware de criptominería de Monero.
Las nuevas capacidades incluyen el uso de un módulo de gusano de protocolo de comunicaciones seguras (SSH), un aumento de la generación de informes, una mejor ocultación de la carga útil y un nuevo módulo propagador de LAN.
Al analizar el depósito del minero, estimamos que los atacantes han extraído monedas XMR por un valor aproximado de 10 000 USD.
Ofrecemos estrategias de mitigación, herramientas de detección y un completo repositorio de indicadores de riesgo (IOC). También nos pusimos en contacto con víctimas con estas herramientas, antes de la publicación de este blog.
Introducción
Los investigadores de seguridad de Akamai han estado investigando una campaña activa de cryptojacking, que creemos que es un resurgimiento de la campaña de 2021 cubierta por Bitdefender. Aunque hubo varias correlaciones con el informe original, este malware ha subido de nivel desde entonces.
Uno de los cambios entre las dos campañas es su nombre: El grupo anteriormente conocido como Mexals (vea su página web en la Figura 1) ahora se llama Diicot, y una de sus herramientas lleva el mismo nombre. Diicot es también el nombre de la agencia rumana contra el terrorismo; para tratar de evitar la confusión, nos referiremos al grupo de amenazas como Mexals. Durante el análisis del modus operandi, la cadena de carga útil y los IOC, quedó claro que, a pesar del cambio de nombre, estas dos campañas estaban relacionadas.
Fig. 1: La página web predeterminada que se muestra en el dominio del atacante y que también aloja sus cargas
En esta campaña hemos visto una ocultación mejorada, nombres de archivo más discretos y proxies de depósitos de minería personalizados que no estaban presentes en la iteración anterior. La cadena de ataques comienza con la fuerza bruta de credenciales SSH. Luego viene una larga cadena de cargas ocultas, que finalmente suelta un malware de criptominería XMRig. Una de las cargas útiles soltadas es un módulo que se puede propagar como gusano que creemos que ha estado activo en este resurgimiento.
También creemos que sus servidores de ataque propios se alojan en un servidor privado virtual (VPS) con sede en los Países Bajos, y sus víctimas están esparcidas por todo el mundo. Estimamos que los atacantes han logrado extraer más de 10 000 USD en monedas XMR.
Algunos hackers tienen un kit de herramientas. Estas personas parecen tener una cadena
Encontramos ocho ejecutables en nuestro análisis de la cadena de infección de los atacantes. Estos ejecutables no parecen diferir mucho de lo visto por Bitdefender, excepto por los nombres de archivo, las rutas y algunas nuevas capacidades (Figura 2).
Nombre de carga útil |
Uso |
|---|---|
History |
Un script Bash. Comprueba si Update se está ejecutando. Lo ejecuta si no lo está. |
Update |
Un script Bash compilado. Notifica a los atacantes a través de un webhook de Discord y ejecuta un análisis de red en una red IP aleatoria de clase B para máquinas con SSH abierto. Suministra los resultados a aliases. |
Chrome/ps |
Un escáner de red. Acepta un rango de red de clase B (255.255.0.0) y un puerto. Explora el rango de red para equipos con ese puerto abierto y guarda los resultados en un archivo. |
Un módulo de gusano SSH escrito en Golang. Ejecuta payload. |
|
El módulo principal posterior a la vulneración. En función de los recursos disponibles para la víctima, instala una puerta trasera, un malware de criptominería o un gusano SSH LAN. |
|
.diicot |
Un script Bash compilado. Descarga Opera, un malware de criptominería. También instala otra puerta trasera en forma de un nuevo usuario y clave SSH. |
Opera |
Un malware de criptominería XMRig. |
Un script Bash compilado. Es el inicio del módulo propagador de LAN. Ejecuta un analizador de puertos SSH en el rango IP de la LAN interna y, a continuación, llama a la red para intentar vulnerar las máquinas con SSH. |
|
Network |
Otra variante de aliases con menos capacidades. Realiza un ataque de diccionario SSH en la LAN local, guarda la información de las máquinas pirateadas (y las credenciales de trabajo) en un archivo de texto. |
Fig. 2: Un resumen de las diferentes cargas útiles utilizadas por los atacantes
Generación binaria y ocultación
El cambio más significativo que hemos visto es la ocultación de la carga útil. Anteriormente, la mayoría de las cargas ejecutables eran, de hecho, scripts Bash que se compilaban con shc, pero ahora esos scripts Bash compilados también estaban empaquetados en UPX, y el encabezado UPX se había depurado para dificultar el análisis y la descompresión (Figura 3).
Fig. 3: Un ejecutable empaquetado que UPX no puede desempaquetar debido a un encabezado depurado
Afortunadamente, podíamos confiar en una herramienta creada por Larry Cashdollar, investigador de Akamai, como parte de una alerta del equipo de respuesta a incidentes e inteligencia en seguridad (SIRT) anterior. Esto nos permitió restaurar fácilmente el encabezado UPX, descomprimir los ejecutables ELF y extraer los scripts Bash que contenían.
Entonces, nos quedamos con un binario totalmente depurado y compilado estáticamente, sin forma de distinguir entre el código del malware y el código de glibc (Figura 4).
Fig. 4: El punto de entrada del binario depurado
Podemos confiar en el código fuente de glibc para entender cómo es el punto de entrada. La función principal real es la función cargada en rdi. Si lo analizamos, podemos encontrar una cadena de error bastante específica: E: neither argv[0] nor $_ works., que podemos buscar en la web. Esto nos lleva a shc. Por desgracia, no hay ningún descompilador fácilmente disponible. En lugar de realizar ingeniería inversa y crear un descifrado, lo que sería demasiado complicado, podemos depurar la carga útil y pausar la ejecución después de un segundo. El script de shell descifrado residirá en la memoria del malware, que luego podemos volcar y analizar.
Cadena de infección
Fig. 5: La cadena de carga útil completa
Cada carga útil se encadenará de forma relativamente sencilla, con varios métodos de configuración del siguiente eslabón. Por ejemplo, acabar con mineros de la competencia o procesos pesados de CPU, limpiar el historial de Bash o instalar persistencia y, a continuación, descargar y ejecutar la siguiente carga útil (Figura 5).
Análisis técnico de las cargas útiles principales
aliases
Se trata de un binario Golang, que no se ha depurado para que pudiéramos encontrar fácilmente toda la lógica del malware. El malware lee dos archivos, que se crearon en pasos anteriores: protocols (lista de palabras de contraseña de usuario difundida por Update) y bios.txt (lista de IP objetivo de máquinas con SSH abierto, creada por Chrome). A continuación, procede a realizar un ataque de diccionario en cada objetivo y, tras una autenticación correcta, ejecuta payload y otros comandos para perfilar el sistema vulnerado.
El último comando que se ejecutará es uname -s -v -n -r -my se analiza su salida. En concreto, busca nombres de sistemas operativos (SO) específicos dentro de esa salida que puedan indicar objetivos interesantes. Para la mayoría de los nombres de SO que busca, no hace nada, pero si el equipo de destino está ejecutando OpenWrt, ejecuta otro comando Bash en él para descargar y ejecutar otro script de shell desde 107.182.129.219, lo que difundiría alguna variante de Mirai. Creemos que el enfoque en OpenWrt se debe a que está instalado en dispositivos integrados y podría servir como vector de acceso inicial a las redes de la organización. Con esto, los atacantes demuestran que están interesados en algo más que otra campaña de criptominería y están buscando activamente nuevos pastos.
Una vez que el malware termina su intento de vulneración, informa a los atacantes a través de un webhook de Discord (una práctica de ataque que está ganando popularidad). Hay cuatro webhooks diferentes, con diferentes propósitos (Figura 6).
Fig. 6: Una interceptación de los webhooks Discord llamados por el malware
El primer webhook es de una función llamada toDiscord, y relega los resultados de los diversos comandos de creación de perfiles que se ejecutan en el equipo de destino. Los dos siguientes se llaman desde las funciones toAPIlogs y toDisc, y remiten la misma información: la IP de destino y el usuario y la contraseña que pueden autenticarse en ella.
Por último, si la víctima ejecuta OpenWrt, se llama a otra función toMirai, y envía la misma información a otro webhook. Aquí hay cierta redundancia, suponemos que para que los atacantes puedan rastrear diferentes métricas más fácilmente, o que puede servir como separación para diferentes partes de su campaña de ataque (Mirai como botnet/IAB frente al uso habitual de Mirai como malware de criptominería).
payload
Aunque es "solo" un script Bash compilado, payload es interesante porque está plagada de comentarios y mensajes de progreso, que nos pueden enseñar los procesos de pensamiento de los operadores de malware.
Los comentarios y los mensajes de progreso están en rumano, lo que refuerza la suposición de que los atacantes son rumanos (el dominio de mando y control/descarga del malware se traduce literalmente como "archivo de hacker").
El script también comprueba la presencia de otros programas de criptominería conocidos y acaba con sus procesos, entre ellos dhpcd y ksmdx. Esto demuestra que los atacantes son conscientes de su ecosistema y no solo están probando suerte en el mundo de la criptominería.
Después de acabar con la competencia y otros procesos pesados de CPU, la secuencia de comandos comprueba cuántos núcleos de CPU tiene la máquina; si tiene menos de cuatro, simplemente instala History y Update y un trabajo Cron para ellos. (Los dos ejecutables son responsables de descargar la carga útil de aliases y están programados para ejecutarse al reiniciar el equipo afectado). Si hay cuatro o más núcleos, el script también se descarga y se ejecuta .diicot, un script Bash compilado que descarga y ejecuta un malware de criptominería XMRig.
Por último, si hay ocho o más núcleos de CPU, el script descarga y ejecuta retea, el propagador de LAN.
retea
El módulo propagador LAN presenta una nueva capacidad en la cadena de los atacantes. Es otro script de shell compilado, que extrae todos los usuarios configurados en el sistema y crea un archivo llamado .usrs. El archivo se utiliza para un ataque de diccionario SSH y se rellena con los usuarios extraídos y una lista de contraseñas predeterminada codificada. A continuación, descarga y ejecuta un analizador de red en la red LAN, que detecta equipos con puertos SSH abiertos y escribe la salida en un archivo. A continuación, descarga y ejecuta Network, que es una versión inferior de aliases, con menos capacidades. En lugar de instalar una carga maliciosa o informar a un webhook de Discord, solo guarda la salida de los equipos vulnerados en un archivo, que los atacantes pueden seleccionar posteriormente.
Conozca a las víctimas
¿Lo son?
Dado que los atacantes tienen una carga útil que se puede propagar como gusano, resulta difícil distinguir qué IP de origen capturada en nuestros sensores de amenazas es la infraestructura de los atacantes y cuál es la víctima. En esta sección, trataremos de diseccionar la infraestructura del atacante y encontrar a las víctimas reales.
Extrajimos todas las IP atacantes que detectamos (50 direcciones IP únicas) y las asignamos a su ubicación geográfica en el mundo. Además de las IP atacantes, también encontramos pruebas de infección en algunos de los clientes de Akamai, por lo que también se incluyeron en nuestra lista de víctimas. La distribución geográfica de las víctimas/infraestructura se muestra en la Figura 7.
Fig. 7: Mapa del mundo con geolocalización de las IP de ataque
Aunque la mayoría de las ubicaciones muestran muy poca actividad, tenemos algunos puntos de acceso en Europa Occidental. El aumento de la actividad allí (figura 8) nos lleva a la hipótesis de que los puntos de acceso son en realidad equipos controlados por los atacantes, mientras que el resto son equipos víctima tomados por el módulo que se puede propagar como gusano. Parece que el módulo no está particularmente activo, ya que vemos muy pocos equipos activos al mismo tiempo. Esto tiene sentido, dado que aliases se ejecuta solo una vez por cada ejecución de trabajo Cron, en una clase B aleatoria. El Cron está programado para ejecutarse al reiniciar el equipo, lo que probablemente sucede con poca frecuencia, dada la naturaleza de los equipos víctima (por ejemplo, servidores Linux abiertos a Internet).
Fig. 8: Número de IP que atacan a nuestros sensores de amenazas simultáneamente a lo largo del tiempo
Si observamos las direcciones IP que más se registraron en nuestros señuelos, que suponemos que son una infraestructura de atacantes, podemos ver una distribución clara de los hosts (Figura 9). Las direcciones IP antiguas se alojaban con DigitalOcean. Parece que las direcciones más recientes (debido al reciente resurgimiento) se han alojado en Serverion, un VPS y proveedor de alojamiento web de los Países Bajos (su número de sistema autónomo (ASN) está registrado en su empresa matriz, Des Capital B.V., una agencia inmobiliaria, que nos confundió inicialmente).
Fecha del ataque |
Recuento de ataques |
IP del atacante |
Nombre de la organización de alojamiento |
|---|---|---|---|
01/02/2023 |
14 |
185.225.74.231 |
Des Capital B.V. |
01/10/2022 |
72 |
45.139.105.222 |
Des Capital B.V. |
01/10/2022 |
62 |
212.193.30.11 |
Des Capital B.V. |
01/03/2022 |
22 |
195.133.40.157 |
Des Capital B.V. |
01/12/2021 |
43 |
134.209.95.47 |
DigitalOcean, LLC (DO-13) |
01/12/2021 |
37 |
134.209.195.231 |
DigitalOcean, LLC (DO-13) |
01/12/2021 |
34 |
104.248.85.104 |
DigitalOcean, LLC (DO-13) |
01/12/2021 |
27 |
134.209.198.229 |
DigitalOcean, LLC (DO-13) |
01/12/2021 |
27 |
167.71.48.128 |
DigitalOcean, LLC (DO-13) |
01/12/2021 |
74 |
188.166.60.8 |
DigitalOcean, LLC |
Fig. 9: Principales IP de ataque, que suponemos son la infraestructura del atacante, no solo víctimas
Antes de la publicación de esta entrada de blog, nos pusimos en contacto con los clientes de Akamai afectados para informarles sobre los ataques, así como sobre los correos electrónicos atacados registrados para cada dirección IP de ataque.
Atrápame si puedes
Parece que los atacantes han cambiado su configuración de minería desde la campaña anterior. Anteriormente, indicaron a sus mineros que trabajaran con supportxmr.com directamente, pero los mineros que analizamos recientemente se comunican con direcciones IP que probablemente estén bajo el control de los atacantes. Temíamos que se tratara de depósitos privados, lo que significaría que no podríamos rastrear los pagos, pero nuestros temores eran infundados: supportxmr seguía realizando un seguimiento de los pagos de minería a la cartera, por lo que asumimos que sus servidores son simplemente proxies del depósito alojado por supportxmr. Esta podría ser una forma de evadir el bloqueo y la detección de DNS al no llegar directamente al depósito.
Conseguimos extraer dos direcciones de cartera diferentes de las cargas útiles de XMRig que hemos visto al investigar la campaña. Esas direcciones de cartera son diferentes de las que vio Bitdefender, pero según su historial de pagos, parecen haber estado activas también durante ese tiempo.
Podemos ver que los importes de pago variaban mucho antes de noviembre de 2021 (incluso alcanzando un XMR completo dos veces), pero después se volvieron mucho más frecuentes y constantes (figura 10). Esto podría deberse a un cambio en el esquema de pago o a la incorporación de más trabajadores mineros. El momento se corresponde con otros picos de actividad de malware detectados.
Fig. 10: Historial de pagos de minería a la cartera de los atacantes, tal como se ha extraído de supportxmr
En resumen, calculamos que los atacantes han logrado extraer XMR por un valor superior a 10 000 USD durante toda su campaña, con más del 75 % extraído desde su resurgimiento. La cantidad real extraída posiblemente sea superior a nuestra estimación, a juzgar por el recuento de trabajadores único del que informa supportxmr, solo hemos visto la mitad de las cargas y configuraciones de XMRig (figura 11).
Fig. 11: Mineros asociados con una de las carteras de los atacantes
Resumen
La cadena de carga útil empleada por los atacantes es sin duda impresionante, y habla de un atacante bastante sofisticado. Generalmente tampoco vemos una cadena tan larga de cargas útiles y creemos que hay algunas razones por las que los atacantes decidieron utilizar tantas.
Ocultación - cuantas más partes móviles haya en el sistema, más difícil será analizarlas y controlarlas. El hecho de que los binarios estén ocultos solo refuerza esta hipótesis.
Hay varias personas detrás del grupo de amenazas. Aunque no disponemos de información real sobre los atacantes que hay detrás de la campaña, hemos visto diferencias de código sorprendentes entre diferentes muestras de los mismos scripts, que solo podemos atribuir al hecho de que han sido desarrollados por diferentes personas.
La campaña de malware está diseñada para evolucionar con el tiempo. Vemos pruebas de ello en las nuevas capacidades y la ocultación adicional que se han añadido, así como en algunas de las redundancias en el código que se crearon como base para su uso futuro.
Mejoras y adiciones a su operación anterior
Empaquetado UPX y depurado del encabezado UPX.
La función de actualización automática se ha movido desde dentro de la carga útil a los scripts externos (History y Update).
Nombres de archivo más discretos (Chrome, Opera : imitando navegadores)
Informes de malware adicionales por Discord
Comportamiento específico de OpenWRT (y probablemente más próximamente)
Uso de proxies de pools de minería personalizados en lugar de pools públicos
Archivo del defensor
Proteger el perímetro y la red
El malware no tiene ninguna técnica novedosa o sofisticada para distribuirse por sí mismo. Simplemente utiliza un ataque de diccionario en SSH. Como tal, solo están en riesgo las máquinas que están abiertas a SSH desde Internet. Bloquear el SSH en el perímetro de la red, o trasladarlo detrás de una VPN, puede reducir en gran medida los riesgos que plantean estos ataques.
Además, el uso de credenciales no predeterminadas o contraseñas complicadas reduce en gran medida el riesgo de un ataque de diccionario como el empleado por este malware. También recomendamos utilizar claves SSH para la autenticación, ya que son aún más seguras que las contraseñas (son imposibles de adivinar y el "secreto" nunca se transmite a través de la conexión).
Por último, también tenemos que considerar el módulo propagador de LAN. Puesto que también utiliza SSH para el movimiento lateral, la segmentación de la red puede mitigar ese riesgo de forma segura. Si consideramos los servidores abiertos a Internet como la zona desmilitarizada (DMZ), lo lógico es evitar el tráfico SSH (y, por lo general, otro tráfico que se pueda utilizar para el movimiento lateral, como RDP, MS-RPC o WinRM) desde la DMZ al resto de la red. Si, por alguna razón, necesita que uno de esos servidores tenga acceso SSH a la red interna (porque sirve como jumpbox, por ejemplo), el método preferido debería ser trasladarlo fuera de la DMZ y bajo la VPN. No exponga los servidores a Internet y permita que los atacantes salten desde ellos internamente: reduzca el radio de explosión y las rutas de propagación.
Detección de infecciones
Hemos creado un Repositorio de GitHub para herramientas que pueden ayudarle a detectar infecciones de esta campaña maliciosa. Allí encontrará un script Bash, una lista completa de IOC y consultas osquery que pueden utilizar los clientes de Guardicore Segmentation de Akamai. También puede encontrar el script de detección y una lista parcial de IOC al final de esta publicación.
Además de estas herramientas, también nos gustaría recomendar una forma general de detectar programas de criptominería que podrían aplicarse en este caso: detectar el tráfico saliente a los pools de minería observando el puerto de destino. Los puertos predeterminados para los pools de minería a veces son bastante únicos, por lo que estar atentos a ellos puede resultar beneficioso. Por ejemplo:
El puerto TCP 4242 es el puerto predeterminado para esta implementación del pool
Los puertos TCP 3333, 5555, 7777 y 9000 son los puertos predeterminados en la implementación del pool nodejs
Por supuesto, los mineros también pueden comunicarse con su pool a través de HTTP y HTTPS, en cuyo caso la detección sería mucho más difícil. Sin embargo, vale la pena buscar estos puertos.
Script de detección
El script de detección busca varios IOC que pueden indicar la presencia pasada o actual de la campaña de ataque. Busca artefactos en Crontab, por sus rutas de archivos, así como procesos en ejecución, y también por la puerta trasera de la clave SSH maliciosa. Para ejecutarlo, simplemente descárguelo en el equipo que desee comprobar y ejecútelo. Escaneará el equipo e imprimiría su veredicto:
Figura 12: Ejecutando el script de detección para buscar artefactos Mexals.
Indicadores de compromiso
La siguiente es una lista parcial de IOC. La lista completa está disponible en nuestro Repositorio de GitHub.
Rutas
/var/tmp/.update-logs/
/var/tmp/Documents/
/var/tmp/.ladyg0g0/
/dev/shm/.x/
/dev/shm/.magic/
Nombres de archivo
protocols
bios.txt
Update
History
aliases
payload
retea
.usrs
IP
107.182.129.219
45.139.105.222
185.225.74.231
212.193.30.11
Dominios e indicadores de recursos uniformes (URI)
arhivehaceru[.]com
discord[.]com/api/webhooks/954295081765072926/Zu7Vu-LpfgRqSmCyFvz3BCkR1Lt7clYOJeayCFzZwtPmZlVn9og_6mPS_BJY-374m5Y3
discord[.]com/api/webhooks/1036206037373571082/9bs01KrT-TrcbSAPI_i-adV1Bhn56A4X4fxzCYEw3zMq95H1mFvlKWb6-KYzvEoVfTnS
discord[.]com/api/webhooks/1036205058456563722/1_saZM0fE7nLgYG668LmDfNmSvrWpD-6Z8nIXljm0qlm6YyMxAyYuZIu4LhN2gHsgSQy
discord[.]com/api/webhooks/965651135102865479/PFdU4u8yZrn0XhzIKShcaxL3_IaBjsstYmFEXlThF2_1XCnwXSAjKos3ptwKYpPyGqvI
discord[.]com/api/webhooks/848592916951203860/WeWBGYSVreTlE0aO_6alVN3Qrj6_aRxnaDpq4_6wD04V2aHlMFvgik2Z2h78Dstg9fZY
discord[.]com/api/webhooks/1036225255049531422/qyOrT3SxHaOC-9yS2NQiPxlSMYmRFFIpU-rMKzmcDv9pQyP4uaZEiZXDXioUtf0DJLUB
