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.
Análisis de la red Monero
La red de Monero está creada con 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.
Dado que la red está formada por nodos del mismo nivel distribuidos, cualquier criptominero debe interactuar directa o indirectamente con uno de los aproximadamente 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).
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.
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 tal como se describe en la primera publicación del blog de esta seriey (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: una de ellas fue 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 indica que tiene varios proxies que se acumulan hasta una tasa de hash de 5,6 Mh/s, lo que equivale a miles de máquinas afectadas (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.
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 de 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 cargador de forma sigilosa utilizando 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 propio malware de criptominería contiene el archivo config.json, que contiene la configuración de minería de datos. En otras muestras, el script OracleLoader suelta el malware de criptominería y establece 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 minero 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.
Mediante el uso de la aplicación web de supervisión de trabajo XMRig para supervisar a los mineros 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).
Como podemos ver en el panel del conjunto de minería, la tasa de hash constante sugiere que las víctimas están en todo el mundo, de lo contrario, esperaríamos una tasa de hash alterna basada en las horas de actividad de la zona horaria. 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 a la minería de criptomonedas, la rentabilidad minera de una moneda no es aparentemente la consideración 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 posible valor a largo plazo lo que los atrae hacia una criptomoneda en vez de a otra.
La mayor campaña de Zephyr que hemos visto que 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 se encuentra en otra campaña observada que utiliza proxies combinados con malware de conexión directa que parece dirigirse a usuarios de habla rusa (Figura 7).
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).
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, el ejecutor Solara de Roblox y otros, podemos llegar a una suposición más sólida: el malware finge ser un motor de trampas que tentará a los jugadores a buscarlo. 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 ha estado 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).
El flujo de ataque es similar entre las muestras de malware de la campaña. Normalmente comienza con una descarga directa de crackingcity.com, que inicia una cadena de carga útil. A continuación, en la última fase, despliega el malware 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 proxy con el nombre custompool.xyz el 29 de abril de 2022, apenas tres días después de la primera detección en VirusTotal. La primera muestra, llamada VScan.exees 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.
Utilizando la contraseña un#912345678@rar, podemos extraer el cargador de segunda etapa que se conecta al otro dominio C2, crackingcity.com. En la fase final, el malware ejecuta dlIhost.exe (básicamente, un cliente XMRig modificado con configuración en el pool custompool.xyz integrada), que en este punto es la dirección IP directa (Figura 11).
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 dedicado requiere que el minero opere en modo daemon (donde la solicitud RPC se transmite a través de HTTP), que 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" — 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.
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).
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 la red Monero, pero también es un nodo de salida para 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 que las detecciones sean precisas.
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.
Algoritmos resistentes a ASIC, como RandomX, normalmente implementan 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 misma suposición. 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 modernas características de las CPU, el uso las configuraciones del control de redondeo como en la herramienta de detección del desarrollador de RandomX es un modo de hacerlo.
De hecho, combinándolo con otros indicadores, como las operaciones AES de hardware y la configuración de hugepage, mejorará 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 de token de acceso del subproceso, respectivamente.
Podemos extender estos métodos a otros sistemas operativos, también, 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 minero 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 que, el patrón /[48][1-9A-HJ-NP-Za-km-z]{94}/ podría ser suficiente para esta tarea y también puede integrarse 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.
Para mantenerse al día con esta serie y demás novedades en las investigaciones sobre seguridad, puede consultar nuestra página de investigación sobre seguridad y seguirnos en redes sociales.