Anatomía de los programas de criptominería: análisis de los criptomineros
Resumen ejecutivo
Esta es la segunda entrega de nuestra serie de blogs de tres partes llamada Anatomía de los programas de criptominería. En la primera parte, hablamos sobre las criptomonedas en general, sus diversos atributos y lo que hace que algunas de ellas sean más atractivas que otras para los atacantes.
En esta parte, analizaremos en profundidad varias muestras de criptominería para comprender sus mecanismos internos y cómo funcionan. Nos centraremos en los programas de criptominería de Monero y Zephyr, que son dos de las monedas que descubrimos que son adecuadas para actividades maliciosas. En esta entrada del blog, trataremos:
El uso de la red de blockchain para identificar la comunicación de minería sospechosa de un posible malware de criptominería.
Cuatro casos reales de muestra que utilizan diferentes topologías para mantenerse activos y persistentes durante un largo periodo.
Un caso intrigante de una campaña larga y persistente con miles de víctimas que genera 5,50 USD cada hora.
Atacantes que utilizan varias monedas en una sola campaña.
Detección a través de las actividades de la red y referencias cruzadas con la red de blockchain.
Detección a través del análisis de memoria de procesos junto con la huella dactilar del algoritmo de consenso.
También hemos incluido una lista de indicadores de riesgo (IOC) de los casos prácticos en esta entrada del blog para ayudar a los equipos de seguridad a proteger sus activos.
Concluiremos esta publicación examinando las técnicas de detección que se basan en los conceptos de algoritmos resistentes ASIC, así como para la detección de operaciones de criptominería. La detección se centra en los fundamentos de la minería y se puede aplicar a nivel de red o de sistema operativo. Para descubrir cómo pudimos detener las campañas maliciosas de criptominería, consulte la tercera parte de nuestra serie.
Análisis de la red Monero
La red Monero se ha creado utilizando el protocolo Levin para implementar la comunicación punto a punto (P2P) a través de los nodos de red. Utiliza el protocolo para distribuir operaciones de blockchain, como nuevas transacciones y nuevos bloques. También proporciona a la red la capacidad de autosostenerse de manera descentralizada a través de la publicación de nodos del mismo nivel y la capacidad de eliminar ataques mediante algoritmos de consenso.
Aunque hemos utilizado Monero como ejemplo, la detección de redes de un blockchain debería ser posible en la mayoría de las criptomonedas. Esto se debe a la naturaleza distribuida de las redes de blockchain, y puede encontrar más información en nuestro blog anterior.
Detección de redes
Como la red Monero es una red descentralizada P2P de colaboradores individuales, podemos conectarnos fácilmente a ella nosotros mismos. Mediante la asignación de la red Monero, podemos obtener IOC fiables (como direcciones IP de nodo) y detectar la posible actividad de los centros de nodos que están más conectados que otros.
Esta información se puede utilizar para detectar e investigar operaciones de minería y también nos permite evaluar la red en busca de vulnerabilidades y exposición a ataques de blockchain. La figura 1 es una representación visual de la red minera de Monero, en la que el mapa térmico muestra la densidad de nodos por área geográfica. Hemos marcado nodos que están abiertos públicamente al mundo con puntos rojos.
Fig. 1: A graphical mapping of the Monero network (as of March 2025)
Dado que la red está formada por nodos homólogos distribuidos, cualquier programa de criptominería debe interactuar directa o indirectamente con uno de los 30 000 servidores del mundo que se pueden encontrar en nuestro mapa. Como veremos, el mapa resultó ser muy valioso para buscar muestras de criptominería, así como para detectar conexiones de red directas a los blockchains. (Puede encontrar más información en nuestro repositorio de GitHub, incluido el código fuente para el rastreo de blockchain y la generación de mapas).
Referencias cruzadas de criptomineros con la red
Utilizando los diferentes indicadores obtenidos a través de la asignación de la red Monero, es posible identificar muestras que interactúen con la red de blockchain. Por ejemplo, con VirusTotal Livehunt, podemos identificar archivos que contienen direcciones de nodo conocidas, lo que nos ayudará a detectar campañas de criptominería activas (figura 2).
Fig. 2: An example of a VirusTotal Livehunt YARA rule
Al igual que cualquier otra cosa en materia de seguridad, no se trata de una técnica de caza única para todos. El uso exclusivo de este enfoque puede dar lugar a falsos positivos cuando el servidor no es un nodo de blockchain exclusivo. También puede llevar a una falta de visibilidad porque el mapa no descubre todos los nodos. Sin embargo, la combinación de esta técnica con otros indicadores aumentará la tasa de detección positiva real.
El mapa contiene nodos accesibles públicamente junto con nodos accesibles recientemente. Algunos de los nodos se utilizan para más de un nodo Monero; por ejemplo, sirven como espejo del repositorio PyPi de Python o cualquier otro servicio. La figura 3 es un ejemplo de un servidor que proporciona varios servicios, lo que puede provocar mucha distracción en el proceso de búsqueda. Eliminamos estos servidores del análisis para reducir los posibles falsos positivos.
Fig. 3: Example of a node in the Monero network that serves multiple services (VirusTotal)
La calificación de muestras irrelevantes es tan importante en la búsqueda de amenazas como la calificación de muestras relevantes. El análisis de red combinado con un enfoque de referencias cruzadas puede revelar programas de criptominería y campañas de minería completas orquestadas a través de botnets. Al incorporar técnicas adicionales de análisis estático, como la coincidencia de direcciones de cartera codificadas, podemos enfocarnos de manera eficiente en las muestras maliciosas más relevantes.
Análisis de muestras de criptominería
Debido a la naturaleza ruidosa de la criptominería, puede ser fácil detectar su funcionamiento incluso con un "a simple vista". Un profesional de TI alertado puede detectar las anomalías generadas por los programas de criptominería sin necesidad de herramientas antimalware sofisticadas. Incluso las personas sin conocimientos técnicos son conscientes del rendimiento básico de su máquina y, si se ralentiza, es probable que lo analice un profesional que encuentre fácilmente la causa raíz. Por este motivo, muchos programas de criptominería no se molestan en proteger el malware contra el análisis y la detección, sino que actúan mediante la estrategia de infección masiva no selectiva.
En los siguientes casos reales, cubriremos algunas de las muestras de criptominería que identificamos en su entorno natural y examinaremos algunos de los detalles más interesantes sobre su funcionamiento y comportamiento. Se utilizaron dos factores principales para encontrar estos casos reales: (1) una moneda relevante como se describe en la primera entrada de blog de esta serie y (2) la topología de minería que explotan.
Caso real n.º 1: una campaña persistente y masiva
Como parte de esta investigación, analizamos una variedad de muestras de criptominería, de las cuales una era una campaña de 6 años. Como es típico en campañas de larga duración, parece ser una operación organizada o un servicio de distribución de malware que despliega el malware de criptominería para un tercero.
El análisis de esa muestra muestra indica que tiene varios proxies que se acumulan a una tasa de hash de 5,6 Mh/s, lo que equivale a miles de máquinas en peligro (figura 4). Se trata de un ataque masivo y persistente y, dado que la tasa de hash permanece estable, el malware probablemente no sea detectado por la mayoría de sus víctimas y sigue funcionando sin obstáculos. Ese tipo de ataque es una campaña extremadamente lucrativa para un atacante.
Fig. 4: The campaign’s Nanopool dashboard reveals the total hashrate
La campaña ha estado activa al menos desde junio de 2018 y contiene indicadores (por ejemplo, el lenguaje utilizado en las muestras) que podrían apuntar a un esfuerzo de colaboración entre atacantes rusos y chinos. El análisis de los servidores de mando y control (C2) también apoyó esta teoría, pero en la fecha de publicación de este blog no se ha confirmado completamente.
En el momento de redactar esta publicación, el atacante había acumulado al menos 1702 XMR, valorados en aproximadamente 280 000 USD al tipo de cambio actual. Distribuida en seis años, esta cifra asciende a un promedio de casi 47 000 USD al año en una sola campaña.
La mayoría de los ejemplos vinculados a esta campaña utilizan un lenguaje de scripts correspondiente al sistema operativo de la víctima como cargador y descargador inicial. Se basa en gran medida en el enrutamiento y en conexiones de red engañosas, probablemente en un intento de desvincular el archivo malicioso del servidor C2.
Después de analizar las muestras de la campaña, identificamos que utiliza PowerShell para implementar un ejecutable llamado loader de forma sigilosa mediante el rootkit r77. Incluso sin analizar el complejo dropper, podemos ver que hay varias versiones de este malware de criptominería.
En algunas versiones, el programa de criptominería en sí contiene el archivo config.json, que alberga la configuración de minería. En otras muestras, el script OracleLoader elimina el programa de criptominería y ajusta la configuración. El malware también cuenta con un mecanismo de actualización que podría recuperar la botnet en caso de riesgo (tabla 1).
Característica |
Valor |
Nota |
|---|---|---|
Nombre del malware |
Oracle Loader |
|
Versión actual |
1.1.72.0 |
<5.133.65.53>/Oracle/ver$77_loader.exe.txt |
Componentes relacionados |
|
Tabla 1: Características de Oracle Loader
El malware también escucha en el puerto 999, exponiendo la función de API HTTP de XMRig. Esto permite al atacante acceder al programa de minería de la víctima y le ayuda a supervisar el proceso de minería. Si la máquina víctima está conectada directamente a Internet y no está detrás de un router de traducción de direcciones de red (NAT) o un firewall externo, teóricamente podríamos encontrar a las víctimas a través de servicios de supervisión de red como Shodan. La figura 5 muestra el resultado de una consulta Shodan utilizada para detectar posibles víctimas.
Fig. 5: Shodan results for potential victims (Source: http://shodan.io)
Al utilizar el supervisor de trabajadores XMRig para controlar los programas de minería de las víctimas, podemos revelar información sobre ellos, como el modelo de CPU y la tasa de hash. Esta interfaz solo nos permite consultar información, por lo que aunque podamos ver actividad, no podemos controlar el minero a través de ella ni apagarlo (Figura 6).
Fig. 6: Remote access to the victim machine using the worker monitor
Como vemos en el conjunto de paneles de minería, la tasa de hash constante sugiere que las víctimas están por todo el mundo; de lo contrario, esperaríamos una tasa de hash alterna basada en las horas activas de la zona horaria correspondiente. Otra explicación podría ser que el atacante se dirige a los servidores y no a los consumidores, como lo hacen otras campañas de malware de criptominería.
Caso real n.º 2: topología de pool público utilizada por un criptominero de Zephyr
Aunque hay algunos atacantes muy motivados y sofisticados con campañas a largo plazo que generan enormes beneficios, como el caso práctico n.º 1, no constituyen la mayoría de las amenazas. Los programas de criptominería que utilizan pools públicos son los más comunes. Estos programas de criptominería no contienen funciones sofisticadas como técnicas de ofuscación o antianálisis. Un modus operandi típico sería ponerse en contacto directamente con el pool con una dirección de cartera en texto sin formato. También suelen tener menor impacto y beneficio.
El mercado de las criptomonedas ofrece varias opciones entre las que los atacantes pueden elegir, con una rentabilidad de la minería y un valor de las monedas variables. A pesar del aspecto financiero inherente de la criptominería, la rentabilidad de la minería de una moneda parece que no es lo más importante para muchos atacantes. La moneda Zephyr, que es menos rentable que Monero, es muy común entre los atacantes. La volatilidad del mercado de criptomonedas es una consideración tanto para los atacantes como para los compradores legítimos de criptomonedas. Podría ser el valor potencial a largo plazo lo que los lleva a elegir una criptomoneda sobre otra.
La campaña más grande de Zephyr que hemos visto tiene más de 1400 víctimas activas con una tasa de hash total de 800 Kh/s y un beneficio total de 906,3 ZEPH, lo que actualmente equivale a 2528 USD.
Podemos determinar cuándo un atacante apunta a regiones geográficas específicas al inspeccionar la tasa de hash de la botnet a lo largo del tiempo. Un ejemplo de esto lo observamos en otra campaña que utiliza proxies combinados con malware de conexión directa que parece estar dirigido a usuarios de habla rusa (figura 7).
Fig. 7: Cryptominer hashrate graph over time (Source: https://zephyr.hashvault.pro/en/)
Los cambios periódicos pueden indicar que la mayoría de las víctimas son usuarios humanos y no servidores, ya que es más probable que los equipos personales se apaguen periódicamente. Si analizamos la frecuencia de la tasa de hash, podemos ver que el ciclo es de 24 horas de duración y, suponiendo que el punto bajo es la noche, es posible localizar la zona horaria en la que viven la mayoría de las víctimas (Figura 8).
Fig. 8: Time zone map identifies the location of the majority of the victims (Source: https://www.timeanddate.com/time/map/)
Los intervalos de tiempo por sí solos no son prueba suficiente de la ubicación de la víctima, pero nuestra teoría estaba respaldada por la función de búsqueda de geolocalización IP proporcionada por el grupo HashVault. Al combinar esto con el análisis de malware y los nombres de distribución de malware relacionados con los juegos, como Fortnite, Solara executor for Roblox y otros, podemos llegar a una suposición más sólida: el malware pretende ser un motor de trampa que tienta a los jugadores a encontrarlo. También sospechamos que se ha propagado a través de redes sociales y aplicaciones de mensajería, como Telegram y Discord.
Caso real n.º 3: criptominería mediante una topología de proxy de minería
Utilizamos el mapa de la red Monero para recopilar información sobre más de 25 000 nodos, pero solo el 10 % de ellos eran directamente accesibles. De manera inversa, también usamos este mapa para filtrar cualquier programa de criptominería conocido que no se estuviera comunicando con la red, lo que nos permitió encontrar una campaña que llevaba activa desde abril de 2022.
La figura 9 muestra los vectores de ataque del malware: utiliza un proxy de minería como XMRig-proxy y distribuye su criptominero a través de software pirateado, como Internet Download Manager (IDM).
Fig. 9: Visualization of cryptominer using a cracked program for initial access
El flujo de ataque es similar entre las muestras de malware de la campaña. Por lo general, comienza con una descarga oculta de crackingcity.com, que desencadena una cadena de carga útil. Después, en la última etapa, implementa el programa de criptominería dlIhost.exe que se conecta a un proxy alojado en custompool.xyz. El atacante utiliza variables de entorno para pasar cadenas como argumentos a su proceso secundario, principalmente archivos por lotes, como técnica de evasión. Funciona descifrando archivos incrustados y ejecutando scripts o archivos después de manipular la lista de exclusión del defensor.
El atacante registró el dominio de proxy con el nombre custompool.xyz el 29 de abril de 2022, tan solo tres días después de la primera detección en VirusTotal. La primera muestra, denominada VScan.exe, es un archivo autoextraído que utiliza dos archivos por lotes. El primero es main.bat, que utiliza una contraseña oculta en las variables de entorno para extraer el archivo por lotes de la segunda etapa, VS.bat. Podemos extraer la información oculta mediante un depurador de dos maneras: interrumpir cuando se accede a una variable de entorno denominada "l3" (Figura 10) o interrumpir en cada modificación de las variables de entorno.
Fig. 10: Dynamic analysis reveals the encrypted compression password
Mediante la contraseña un#912345678@rar, podemos extraer el loader de la segunda fase que se conecta al otro dominio de C2, crackingcity.com. En la fase final, el malware ejecuta dlIhost.exe (esencialmente un cliente XMRig modificado con configuración incrustada en el pool custompool.xyz), que en este momento es la IP directa (figura 11).
Fig. 11: Intercepting configuration data through static analysis
Ahora hay una pregunta sobre el tipo de servidor. ¿Es un pool privado? ¿Un proxy de minería? ¿O es algún tipo de nodo personalizado que consideramos lo mismo que un pool privado? Para responder a estas preguntas, necesitamos una forma de extraer algunos identificadores del servidor. La minería en solitario a través de un nodo específico requiere que el programa de minería funcione en modo daemon (donde la solicitud RPC se transmite a través de HTTP), lo cual no está presente en esta configuración, por lo que claramente no es el caso.
La estructura JSON se conserva a través de la serialización, lo que nos permite intentar obtener respuestas del servidor enviando los diversos métodos de Stratum que admite XMRig-proxy. Si las respuestas del servidor coinciden con el orden de las claves y los valores, esto podría ser un gran indicativo de que el servidor utiliza XMRig-proxy o está basado en él.
XMRig admite tres métodos de protocolo Stratum:
- Login: La primera solicitud iniciada por el trabajador de minería de datos, que normalmente contiene la cartera como inicio de sesión.
- Keepalived: Solo consiste en mantener la conexión activa.
- Submit: Consiste en enviar el resultado cuando se encuentre un recurso compartido válido.
Cuando se solicita un método no válido, el XMRig-proxy responderá con un error (Figura 12). Esto puede ser indicativo del tipo de servidor porque otros servicios, como los pools, simplemente ignoran la solicitud incorrecta en lugar responder con el error. La combinación de todo esto nos lleva a la conclusión de que estamos tratando con XMRig-proxy.
Fig. 12: XMRig-proxy response as baseline
Hemos dividido el método Submit en tres casos que deberían devolver errores explícitos desde un proxy XMRig (Tabla 2).
Un recurso compartido de baja dificultad se produce cuando el minero envía un hash con un valor inferior al destino esperado.
Un nonce no válido es el resultado de un nonce fuera de rango según el diseño de NiceHash.
Un hash de máxima dificultad es el hash especialmente diseñado que probablemente satisfaga el destino de cualquier trabajo. En este caso, omitimos la validación de dificultad del proxy XMRig y transmitimos directamente al pool, lo que devuelve el error del pool.
Solicitud |
XMRig-proxy |
MoneroOcean |
HashVault |
Nanopool |
SupportXMR |
C3Pool |
Login |
(actividad normal) |
✕ |
✕ |
✕ |
✕ |
✕ |
Keepalived |
(actividad normal) |
≈ |
✅ |
≈ |
✕ |
≈ |
Desconocido |
(actividad normal) |
✕ |
✕ |
✕ |
✕ |
✕ |
Submit: baja dificultad |
(actividad normal) |
✕ |
✕ |
✕ |
✕ |
✕ |
Submit: nonce no válido |
(actividad normal) |
NA: IP bloqueada |
✕ |
✕ |
✕ |
✕ |
Submit: máxima dificultad |
Repetir el mensaje de respuesta de pool |
NA: IP bloqueada |
✅ |
✕ |
✅ |
✅ |
Tabla 2: Comparación de las solicitudes de protocolo Stratum entre XMRig-proxy y varios pools públicos; ✅ indica igual que la actividad normal, ✕ indica datos diferentes y ≈ indica los mismos datos en orden diferente
No solo podemos distinguir XMRig-proxy de los pools más utilizados, sino que también podemos distinguir entre los pools en sí. Esta información puede ser útil cuando se nos dirige a un pool a través de otros componentes de red, como el proxy inverso. En este caso, cuando enviamos resultados de minería con la máxima dificultad, obtenemos el error del pool back-end en lugar del proxy. Utilizando esta información podemos identificar que el atacante utiliza Nanopool, pero como no tenemos la dirección de la cartera, no podemos obtener una evaluación del recuento de víctimas para esta campaña o su beneficio.
Caso real n.º 4: comunicación de blockchain oculta utilizando una topología de proxy Stratum
El proxy de protocolo Stratum funciona a nivel de red mediante el reenvío de solicitudes de protocolo Stratum directamente a otro servidor sin modificar las direcciones de cartera. Esto garantiza que el trabajo de cada minero se acredite a su cartera respectiva. La implementación de un proxy Stratum se puede lograr mediante un proxy de red de capa de transporte básico o un proxy de aplicación especializado que entienda y gestione el protocolo.
Encontramos una campaña activa que utiliza esta topología y se conecta a un pool público a través de un proxy Stratum. No pudimos identificar si se trata de un proxy inverso a nivel de red o si intercepta el propio protocolo Stratum de por sí y funciona como un proxy de aplicación. En cualquier caso, redirige los mensajes de Stratum para ocultar el pool o nodo back-end. El análisis de los pools públicos para la cartera proporcionada revela que se pone en contacto con el pool público MoneroOcean.
La campaña ha estado activa durante al menos cuatro meses y su ganancia total es de 1,158 XMR (aproximadamente 180 USD). Por sí sola, no es una campaña muy exitosa, pero el aparente esfuerzo del atacante apunta a posibles planes más grandes que incluyen el desarrollo de toda la campaña por sí mismos: la infraestructura, el malware de criptominería y los diferentes archivos maliciosos para colocarla. Los atacantes también distribuyen la campaña por sí mismos sin depender de terceros, al tiempo que implementan mecanismos anti ingeniería inversa, como el cifrado, la ocultación y la prevención del uso de herramientas de supervisión (Figura 13).
Fig. 13: Persistent cryptominer uses Stratum proxy to hide the back-end pool
Aunque la campaña puede parecer perezosa, podemos ver una ejecución cuidadosa del malware, especialmente en el proceso de ocultación. El malware intenta ocultar la carga mediante la descarga de un archivo durante el tiempo de ejecución y ejecutando procesos con nombres de archivos de sistema legítimos.
Detecciones
Hay varias vías diferentes que puede tomar cuando se trata de detecciones en general. Cada método puede que no funcione por sí solo, pero sí lo hará si se utiliza junto con otros mecanismos de detección. Los programas de criptominería no son una excepción; de hecho, pueden ser elementos de malware difíciles de detectar debido a sus características benignas. Utilizan lo único que no requiere un permiso especial en la mayoría de los sistemas operativos: computación (tiempo de CPU).
Conexiones a la red
Para detectar a estos mineros, podemos comparar la red de blockchain (como la red Monero que hemos explorado anteriormente) con los datos que obtenemos de una herramienta de visibilidad de red, como un firewall o una solución de segmentación. Dado que cada nodo o bloque tiene que interactuar con el blockchain de Monero, esto proporciona a los administradores de red una valiosa información sobre el tráfico que sale de su red. Cuando se combina con puertos de red, facilita la detección, ya que la mayoría de los programas de criptominería utilizan números de puerto distintivos, como 999, 3333 o 7777. Aunque Monero se utiliza en este caso real, la asignación de red de blockchain se puede utilizar en todas las redes basadas en pruebas de trabajo (PoW).
Sin embargo, es importante tener en cuenta que no todo el tráfico a los nodos de Monero es necesariamente criptominería, ya que esos nodos a veces proporcionan más de un servicio. Por ejemplo, la IP 157[.]90[.]212[.]53 se encuentra en nuestro mapa de red Monero, pero también es un nodo de salida de la red Tor. Podría haber muchas explicaciones sobre por qué un nodo de Monero proporciona otros servicios; puede estar comprometido o simplemente puede que sea multifunción a propósito. En cualquier caso, el uso de la conexión a la red sin información adicional puede ser un indicador débil de la conexión al blockchain y generar falsos positivos. Esta es otra razón por la que la información del número de puerto es crucial para una detección precisa.
Otra razón para los falsos positivos puede ser una baja tasa de actualización del mapa. Se puede asignar a un servidor legítimo una dirección IP utilizada anteriormente por un nodo de Monero y provocar un falso positivo si el mapa no está actualizado.
Esta detección no puede sostenerse por sí sola, pero podría utilizarse como un activador para una lógica de detección o una investigación más exhaustiva. Cualquier operación de criptominería debe incluir comunicación con un servidor Stratum para una asignación de trabajo de minería de datos. Normalmente, funciona con pools de minería conocidos públicamente, pero en algunos casos, se puede ocultar mediante un proxy, que no aparecerá en el mapa de la red.
Detección de ejecución de algoritmo
Los programas de criptominería utilizan intensivamente los recursos informáticos de la víctima, por lo que supervisar el sistema para detectar picos de uso podría indicar una infección. Pero, al igual que con la referencia cruzada del mapa de red, no es una detección precisa por sí sola.
La combinación de varios IOC detectables aumentará la tasa de confianza de la detección; en otras palabras, reducirá los falsos positivos. Para que una operación minera tenga éxito, hay equivalentes esenciales. Los programas de criptominería deben minar la moneda elegida utilizando su algoritmo de consenso como prueba de trabajo. Cada algoritmo como este tiene una huella única en el sistema durante el tiempo de ejecución, y la extracción de esas características puede crear un método sólido para detectar programas de criptominería maliciosos.
Los algoritmos resistentes a ASIC, como RandomX, suelen implementar un conjunto complejo de operaciones que se pueden identificar de forma única. Por ejemplo, el desarrollador de RandomX creó una herramienta de detección basada en esta suposición exacta. Al iterar los subprocesos en ejecución en el sistema, podemos sondear el estado del subproceso, incluidos los valores de los registros de CPU. Dado que RandomX se implementa utilizando muchas de las funciones modernas de las CPU, usar las configuraciones de Control de redondeo, como en la herramienta de detección del desarrollador de RandomX, es una forma de hacerlo.
De hecho, al combinarlo con otros indicadores, como las operaciones AES de hardware y la configuración de hugepage, mejoraría la tasa de detección. En resumen, la detección se puede lograr buscando claves AES únicas en los registros SSE o consultando los privilegios del token de acceso del subproceso, respectivamente.
También podemos ampliar estos métodos a otros sistemas operativos porque la mayoría de los programas de criptominería pretenden ser independientes de la plataforma y deben comportarse de la misma manera incluso en diferentes sistemas operativos. No estar encasillado en un único sistema operativo permite que una campaña tenga un mayor éxito potencial, ya que los números de objetivos aumentan drásticamente de esta manera.
Localización de la cartera en la memoria del proceso
Cuando los programas de criptominería se comunican directamente con el pool de minería en lugar de a través de un proxy, la cartera del programa de minería debe residir en la memoria del proceso. Esto se debe a que el protocolo Stratum requiere que el minero autentique el servidor y le informe de qué cuenta debe recompensarse en los envíos de recursos compartidos válidos. Por lo general, usará una dirección de cartera y, para la minería de Monero, específicamente, el minero probablemente se base en el software XMRig. Utilizando estas suposiciones, podemos encontrar e interceptar la cartera cuando se envía al pool conectándola a las distintas API de socket o (teóricamente) podemos utilizar un "ataque" de máquina intermediaria (MITM) para interceptar el mensaje de autenticación enviado por el minero.
También podemos utilizar una simple búsqueda Regex en toda la memoria asignada del proceso para encontrar la dirección de cartera de 95 caracteres, ya que sigue un formato estricto. Comienza con 4 o 8 y consta de caracteres válidos de BASE58. Por lo tanto, el patrón /[48][1-9A-HJ-NP-Za-KM-z]{94}/ podría ser suficiente para esta tarea y también se puede integrar en una regla YARA. El análisis se puede realizar en cualquier momento después de la primera conexión del programa de criptominería al pool, ya que el minero debe mantener la dirección de la cartera disponible en caso de que necesite volver a conectarse.
Por último, podemos utilizar cualquiera de las técnicas mencionadas para encontrar otras cadenas relacionadas con el protocolo Stratum y analizar la cartera desde dentro. Estos indicadores podrían disminuir los falsos positivos, ya que la estructura JSON del protocolo es mucho más única. Por ejemplo, consulte la solicitud de "login" en la figura 14; podemos crear una firma más segura que contenga varias claves para una detección más precisa.
{
"id": 1,
"jsonrpc": "2.0",
"method": "login",
"params": {
"login": "<wallet address>",
"pass": "<Usually the worker name>",
"agent": "<Usually xmrig agent>",
"algo": [
"rx/0"
]
}
}
Fig. 14: Ejemplo de solicitud de login; la coincidencia con el patrón podría proporcionar una detección más precisa
Conclusiones
Los investigadores de Akamai seguirán exponiendo las campañas maliciosas y los atacantes que hay detrás de las mismas, así como identificando los IOC para ayudar a proteger tanto a nuestros clientes como al público en general.
En esta segunda parte de nuestra serie de tres blogs sobre criptominería, hemos demostrado una serie de técnicas para revelar más información sobre varias campañas, incluida la identificación de un pool de minería detrás de un proxy minero o la localización de la operación geográfica de la campaña mediante el análisis de la tasa de hash de la botnet de criptominería a lo largo del tiempo y mucho más.
Vimos programas de criptominería maliciosos que utilizaban Zephyr junto con la conocida Monero. Mediante el uso de las diferentes topologías de minería, los programas de criptominería pudieron ocultar información y minimizar el número de identificaciones e indicadores de riesgo.
Después de conocer la anatomía de los diferentes programas de criptominería y el proceso de minería, en general, se planteó una pregunta: ¿podemos detener la operación de minería de la botnet de criptominería? Si se detiene la operación de minería de forma eficaz, se cerrarían los programas de criptominería que infectan las máquinas de las víctimas y consumen sus recursos. Exploraremos esta pregunta en la última entrega de nuestra serie.
Si desea estar al tanto de esta serie y otras investigaciones punteras sobre seguridad, consulte nuestra página de investigación sobre seguridad y síganos en redes sociales .
Indicadores de riesgo
IoC |
Tipo |
Descripción |
|---|---|---|
f038c4273037 |
Hash |
Caso real n.º 1: Hash de un programa de criptominería activo |
47am2aMvQqCLnRBMqBz |
Cartera |
Caso real n.º 1: Dirección de la cartera de Monero |
4BEUrVUbd8h579R2b87uo |
Cartera |
Caso real n.º 1: Dirección de la cartera de Monero |
Conjunta 42XyygMzMRjd6A2MvPVXMGbZ6PzNe7Sivd8ek3ySHBmg18dDCWRhCZ6RFxVZFFUvoyCDnwA5Y2tSeSCaZAEq4n6q6DD8pQK |
Cartera |
Caso real n.º 1: Dirección de la cartera de Monero |
5.133.65.53 |
IP |
Caso real n.º 1: IP de proxy de minería |
5.133.65.54 |
IP |
Caso real n.º 1; IP de proxy de minería |
5.133.65.55 |
IP |
Caso real n.º 1: IP de proxy de minería |
5.133.65.56 |
IP |
Caso real n.º 1; IP de proxy de minería |
Conjunta 53ea10047275485734e75ca9d1205a51f372b564580e02a1e2062f3b5b3942ce |
Hash |
Caso real n.º 2: La campaña más grande de Zephyr que hemos visto |
Conjunta ZEPHYR3c6xGj8D5oP4tzKQbPn2dNdse6aPRWxNBiwBFrg7RFN4jf1cqgj5qdR9Wdru44g2FATJHHH38oFDTH6krgKntSzLc5Csy3t |
Cartera |
Caso real n.º 2: Cartera de Zephyr de una gran campaña que utiliza el pool de HashVault |
Conjunta 9a3b3a3003b283b5a43130093d5803be52f84c66dd2f4d4125039d396119d917 |
Hash |
Caso real n.º 2: Hash de muestra |
Conjunta ZEPHYR3CFYFAze5jkYEQMfKdkhvrgSiSchDxqC2ekV8TYaxLdCVffS2d2aeqivDgtRixDe73tj8SjeiUnvxgSrTp65UqiPTRKMo2Z |
Cartera |
Caso real n.º 2: Cartera de Zephyr |
https://pastebin.com/raw/4VeXYJAx |
URL |
Caso real n.º 2: Muestra con configuración controlable mediante el servicio Pastebin |
Conjunta ZEPHYR2PtmpFWSbkmyLfoy3wgnPSJdpSpjaH6vKaHh6KQB1FSRwxcgfRGx9qWYHQDNDQy5TFkYBRThm7jfCaQQPGNKe9pyvXG6Z3k |
Cartera |
Caso real n.º 2: Cartera de Zephyr, versión de configuración anterior |
Conjunta 49WbPNohkR8VySDznW2freM7d9uUNiZWajQTE4aeFBUT6gJqye3ZPWbbL9r92r4kzHM7pZaoULavWFK83cSMkEYYDJTV7bT |
Cartera |
Caso real n.º 2: Cartera de Monero de la misma muestra |
45.77.240.51 |
IP |
Caso real n.º 3: Proxy de minería |
Conjunta b64d80bf079266a1bfb0713f8c52db2e9b3a8060491f504e578a6bf05a9c6f46 |
Hash |
Caso real n.º 3: La muestra más antigua que pudimos encontrar de esa campaña |
Conjunta yn.mvip8.ru |
URL |
Caso real n.º 4: Proxy Stratum que oculta el pool público |
Conjunta 49J2yzHRcH8hAWSZajkjT2KztGjAMuTFKh5BxAUGdqomPkhvMmBNc9viDSVymu5V5SAqJrNHf4y9E6rLNArYWtuSJNtVEYv |
Cartera |
Caso real n.º 4: Cartera de Monero utilizada por la muestra |
