Persiguiendo remolinos: nuevo InfoStealer basado en Rust empleado en campañas CAPTCHA

Preámbulo

Elastic Security Labs descubrió un nuevo ladrón de información basado en Rust distribuido a través de campañas CAPTCHA falsas. Este malware está alojado en múltiples propiedades sitio web controladas por adversarios. Esta campaña aprovecha páginas engañosas de verificación CAPTCHA que engañan a los usuarios para que ejecuten un script de PowerShell malicioso, que en última instancia implementa el ladrón de información, recolectando datos confidenciales como credenciales, información del navegador y detalles de la billetera de criptomonedas. A este malware lo llamamos EDDIESTEALER.

Esta adopción de Rust en el desarrollo de malware refleja una tendencia creciente entre los actores de amenazas que buscan aprovechar las características del lenguaje moderno para lograr mayor sigilo, estabilidad y resiliencia frente a los flujos de trabajo de análisis tradicionales y los motores de detección de amenazas. Un ladrón de información aparentemente simple escrito en Rust a menudo requiere esfuerzos de análisis más dedicados en comparación con su contraparte de C/C++, debido a factores como abstracciones de costo cero, el sistema de tipos de Rust, optimizaciones del compilador y dificultades inherentes en el análisis de binarios seguros para la memoria.

Conclusiones clave

• Campaña de CAPTCHA falsa carga EDDIESTEALER
• EDDIESTEALER es un ladrón de información de Rust recientemente descubierto que apunta a los hosts de Windows.
• EDDIESTEALER recibe una lista de tareas del servidor C2 que identifica los datos a los que apuntar.

Acceso inicial

Visión general

Los CAPTCHA falsos son construcciones maliciosas que replican la apariencia y la funcionalidad de los sistemas CAPTCHA legítimos, que se emplean para distinguir entre usuarios humanos y bots automatizados. A diferencia de sus contrapartes legítimas, los CAPTCHA falsos sirven como puertas de entrada para malware, aprovechando la ingeniería social para engañar a los usuarios. A menudo aparecen como mensajes como "Verifique que es un humano" o "No soy un robot" y se integran perfectamente en sitios web comprometidos o campañas de phishing. También nos encontramos con una campaña similar distribuyendo GHOSTPULSE a finales de 2024.

Según nuestro análisis de telemetría previo a la entrega de EDDIESTEALER, el vector inicial fue un sitio web comprometido que implementaba una carga útil de JavaScript basada en React ofuscada que muestra una pantalla de verificación falsa de "No soy un robot".

Imitando la interfaz de verificación reCAPTCHA de Google, el malware emplea el método document.execCommand("copy") para copiar un comando de PowerShell en el portapapeles del usuario, luego le indica al usuario que presione Windows + R (para abrir el cuadro de diálogo de ejecución de Windows), luego Ctrl + V para pegar el contenido del portapapeles y finalmente Enter para ejecutar el comando malicioso de PowerShell.

Este comando descarga silenciosamente una carga útil de segunda etapa (gverify.js) del dominio controlado por el atacante hxxps://llll.fit/version/ y la almacena en la carpeta Downloads del usuario.

Finalmente, el malware ejecuta gverify.js empleando cscript en una ventana oculta.

gverify.js es otra carga útil de JavaScript ofuscada que se puede desofuscar empleando herramientas de código abierto. Su funcionalidad es bastante simple: obtener un ejecutable (EDDIESTEALER) de hxxps://llll.fit/io y almacenar el archivo en la carpeta Downloads del usuario con un nombre de archivo pseudoaleatorio de 12 caracteres.

EDDIESTEALER

Visión general

EDDIESTEALER es un novedoso ladrón de información de productos básicos basado en Rust. La mayoría de las cadenas que delatan intenciones maliciosas están cifradas. El malware carece de protecciones robustas anti-sandbox/VM contra huellas dactilares de comportamiento. Sin embargo, variantes más nuevas sugieren que las comprobaciones anti-sandbox/VM podrían estar realizar en el lado del servidor. Con capacidades relativamente sencillas, recibe una lista de tareas del servidor C2 como parte de su configuración para apuntar a datos específicos y puede autoeliminarse luego de la ejecución si se especifica.

Símbolos despojados

Los ejemplos de EDDIESTEALER presentaban símbolos de función despojados, probablemente usando la opción de compilación predeterminada de Rust, lo que requería la restauración de símbolos antes del análisis estático. Usamos rustbinsign, que genera firmas para bibliotecas y paquetes estándar de Rust en función de versiones específicas de Rust, compilador y dependencia. Si bien rustbinsign solo detectó hashbrown y rustc-demangle, lo que sugiere que se estaban empleando pocas cajas externas, no pudo identificar cajas como tinyjson y tungstenite en variantes más nuevas. Esto ocurrió debido a la falta de artefactos de cadena claros. Todavía es posible identificar cajas manualmente encontrando cadenas únicas y buscando el repositorio en GitHub, luego descargar, compilar y crear firmas para ellas usando el modo download_sign . Es un poco complicado si no sabemos la versión exacta de la caja que se está empleando. Sin embargo, restaurar la biblioteca estándar y los símbolos de tiempo de ejecución es suficiente para avanzar en el proceso de análisis estático.

Ofuscación de cadenas

EDDIESTEALER cifra la mayoría de las cadenas mediante un cifrado XOR simple. El descifrado implica dos etapas: primero, se deriva la clave XOR llamando a una de varias funciones de derivación de clave; luego, el descifrado se realiza en línea dentro de la función que emplea la cadena.

El siguiente ejemplo ilustra esto, donde sub_140020fd0 es la función de derivación de clave y data_14005ada8 es la dirección del blob cifrado.

Cada rutina de descifrado emplea su propia función de derivación de clave distinta. Estas funciones aceptan consistentemente dos argumentos: una dirección dentro del binario y un valor constante de 4 bytes. Luego se realizan algunas operaciones básicas en estos argumentos para calcular la dirección donde reside la clave XOR.

Binary Ninja tiene una función útil llamada User-Informed Data Flow (UIDF), que podemos usar para establecer las variables en valores conocidos para activar un análisis de propagación constante y simplificar las expresiones. De lo contrario, un emulador de CPU como Unicorn combinado con una herramienta de análisis binario programable también puede ser útil para el análisis por lotes.

Existe un patrón general para la inicialización perezosa y segura para subprocesos de recursos compartidos, como cadenas cifradas para nombres de módulos, dominio C2 y puerto, el identificador único de la muestra, que se descifran solo una vez pero se hace referencia a ellas muchas veces durante el tiempo de ejecución. Cada función getter específica verifica un indicador de estado para su recurso; si no se inicializa, llama a una función de sincronización compartida de bajo nivel. Esta rutina de sincronización emplea operaciones atómicas y primitivas de espera del sistema operativo (WaitOnAddress/WakeByAddressAll) para garantizar que solo un hilo ejecute la lógica de inicialización real, que se invoca indirectamente a través de un puntero de función en la tabla virtual de un objeto dyn Trait .

Ofuscación de API

EDDIESTEALER emplea un mecanismo de búsqueda WinAPI personalizado para la mayoría de las llamadas API. Comienza descifrando los nombres del módulo y la función de destino. Antes de intentar la resolución, verifica una tabla hash mantenida localmente para ver si el nombre y la dirección de la función ya se resolvieron. Si no se encuentra, carga dinámicamente el módulo requerido usando un contenedor LoadLibrary personalizado, en el espacio de direcciones del proceso e invoca una implementación conocida de GetProcAddress para recuperar la dirección de la función exportada. Luego, el nombre y la dirección de la API se insertan en la tabla hash, optimizando las búsquedas futuras.

Creación de mutex

EDDIESTEALER comienza creando un mutex para garantizar que solo se ejecute una instancia del malware en un momento dado. El nombre del mutex es una cadena UUID descifrada 431e2e0e-c87b-45ac-9fdb-26b7e24f0d39 (única por muestra), a la que se hace referencia más adelante una vez más durante su contacto inicial con el servidor C2.

Detección de sandbox

EDDIESTEALER realiza una comprobación rápida para evaluar si la cantidad total de memoria física es superior a ~4.0 GB como mecanismo de detección de sandbox débil. Si la comprobación falla, se elimina automáticamente del disco.

Autoeliminación

Basado en una técnica de autoeliminación similar observada en LATRODECTUS, EDDIESTEALER es capaz de eliminar a sí mismo mediante el cambio de nombre de los flujos de datos alternativos de NTFS, para evitar los bloqueos de archivos.

El malware emplea GetModuleFileName para obtener la ruta completa de su ejecutable y CreateFileW (envuelto en jy::ds::OpenHandle) para abrir un controlador a su archivo ejecutable con los derechos de acceso adecuados. Luego, se pasa una estructura FILE_RENAME_INFO con un nuevo nombre de flujo a SetFileInformationByHandle para cambiar el nombre del flujo predeterminado $DATA a :metadata. El controlador de archivo se cierra y se vuelve a abrir, esta vez empleando SetFileInformationByHandle en el controlador con el indicador FILE_DISPOSITION_INFO.DeleteFile establecido en TRUE para habilitar un indicador de "eliminar al cerrar el controlador".

Solicitud de configuración adicional

Los datos de configuración inicial se almacenan como cadenas cifradas dentro del binario. Una vez descifrados, estos datos se emplean para construir una solicitud siguiendo el patrón URI: <C2_ip_or_domain>/<resource_path>/<UUID>. El resource_path se especifica como api/handler. El UUID, empleado anteriormente para crear un mutex, se emplea como un identificador único para el seguimiento de la compilación.

Luego, EDDIESTEALER se comunica con su servidor C2 enviando una solicitud HTTP GET con el URI construido para recuperar una configuración de segunda etapa que contiene una lista de tareas que el malware debe ejecutar.

Los datos de configuración de la segunda etapa están encriptados con AES CBC y codificados en Base64. El IV codificado en Base64 se antepone en el mensaje antes de los dos puntos (:).

Base64(IV):Base64(AESEncrypt(data))

La clave AES para descifrar el mensaje del servidor al cliente se almacena sin cifrar en codificación UTF-8, en la sección .rdata . Se recupera a través de una función getter.

La configuración descifrada para esta muestra contiene lo siguiente en formato JSON:

• ID de sesión
• Lista de tareas (datos a los que apuntar)
• Clave AES para el cifrado de mensajes de cliente a servidor
• Bandera de autoeliminación

{
    "session": "<unique_session_id>",
    "tasks": [
        {
            "id": "<unique_task_id>",
            "prepare": [],
            "pattern": {
                "path": "<file_system_path>",
                "recursive": <true/false>,
                "filters": [
                    {
                        "path_filter": <null/string>,
                        "name": "<file_or_directory_name_pattern>",
                        "entry_type": "<FILE/DIR>"
                    },
                    ...
                ]
            },
            "additional": [
                {
                    "command": "<optional_command>",
                    "payload": {
                        "<command_specific_config>": <value>
                    }
                },
                ...
            ]
        },
        ...
    ],
    "network": {
        "encryption_key": "<AES_encryption_key>"
    },
    "self_delete": <true/false>
}

Para esta muestra en individua y en función de las tareas recibidas del servidor durante nuestro análisis, aquí está la lista de objetivos de exfiltración basados en el sistema de archivos:

• Monederos de criptomonedas
• Navegadores
• Gestores de contraseñas
• Clientes FTP
• Aplicaciones de mensajería

Puede encontrar una lista de extensiones de navegador específicas aquí.

Estos objetivos están sujetos a cambios ya que son configurables por el operador C2.

Luego, EDDIESTEALER lee los archivos de destino empleando funciones kernel32.dll estándar como CreateFileW, GetFileSizeEx, ReadFile y CloseHandle.

Tráfico C2 subsiguiente

Luego de recuperar exitosamente las tareas, EDDIESTEALER realiza un perfil del sistema para recopilar información sobre el sistema infectado:

• Ubicación del ejecutable (GetModuleFileNameW)
• ID de configuración regional (GetUserDefaultLangID)
• Nombre de usuario (GetUserNameW)
• Cantidad total de memoria física (GlobalMemoryStatusEx)
• Versión del sistema operativo (RtlGetVersion)

Siguiendo el mismo formato de datos (Base64(IV):Base64(AESEncrypt(data))) para los mensajes de cliente a servidor, la información inicial del host se cifra con AES empleando la clave recuperada de la configuración adicional y se envía a través de una solicitud HTTP POST a <C2_ip_or_domain>/<resource_path>/info/<session_id>. Posteriormente, para cada tarea completada, los datos recopilados también se cifran y se transmiten en solicitudes POST separadas a <C2_ip_or_domain>/<resource_path><session_id>/<task_id>, justo después de que se completa cada tarea. Esta metodología genera un patrón de tráfico C2 distintivo caracterizado por múltiples solicitudes POST específicas para cada tarea. Este patrón es particularmente fácil de identificar porque esta familia de malware se basa principalmente en HTTP en lugar de HTTPS para su comunicación C2.

Nuestro análisis descubrió cadenas cifradas que se descifran en cadenas de metadatos de pánico, revelando rutas de archivos fuente internos de Rust como:

• apps\bin\src\services\chromium_hound.rs
• apps\bin\src\services\system.rs
• apps\bin\src\structs\search_pattern.rs
• apps\bin\src\structs\search_entry.rs

Descubrimos que los mensajes de error enviados al servidor C2 contienen estas cadenas, incluido el archivo de origen exacto, el número de línea y el número de columna donde se originó el error, lo que permite al desarrollador de malware tener comentarios de depuración incorporados.

Capacidades específicas de Chromium

Desde la introducción del cifrado vinculado a aplicaciones, los desarrolladores de malware se adaptaron a métodos alternativos para eludir esta protección y obtener acceso a datos confidenciales no cifrados, como las cookies. ChromeKatz es una de las soluciones de código abierto mejor recibidas que vimos implementar por el malware. EDDIESTEALER no es una excepción: los desarrolladores de malware lo reimplementaron en Rust.

A continuación se muestra un fragmento de la lógica de verificación de la versión del navegador similar a COOKIEKATZ, luego de recuperar la información de la versión de %localappdata%\<browser_specific_path>\\User Data\\Last Version.

Patrón de firma COOKIEKATZ para detectar instancias de COOKIEMONSTER:

Patrón de firma CredentialKatz para detectar instancias de CookieMonster:

A continuación se muestra un ejemplo de la lógica exacta de copia y pegado de FindPattern de COOKIEKATZ, donde PatchBaseAddress está en línea.

Los desarrolladores introdujeron una modificación para manejar los casos en los que el navegador Chromium de destino no se ejecuta. Si está inactivo, EDDIESTEALER genera una nueva instancia de navegador empleando los argumentos de la línea de comando --window-position=-3000,-3000 https://google.com. Esto efectivamente posiciona la nueva ventana lejos de la pantalla, volviéndola invisible para el usuario. El objetivo es garantizar que el malware aún pueda leer la memoria (ReadProcessMemory) del proceso secundario necesario: el proceso de servicio de red identificado por el indicador --utility-sub-type=network.mojom.NetworkService . Para obtener una explicación más detallada de la interacción de este proceso del navegador, consulte nuestra investigación anterior sobre los robadores de información de MaaS.

Diferencias con las variantes

Luego del análisis, se identificaron muestras más recientes con capacidades adicionales.

La información recopilada en las máquinas víctimas ahora incluye:

• Running processes
• Información de la GPU
• Número de núcleos de CPU
• Nombre de la CPU
• Proveedor de CPU

El patrón de comunicación C2 se modificó ligeramente. El malware ahora envía de forma preventiva información del sistema host al servidor antes de aplicar su configuración descifrada. En algunos casos en los que la máquina víctima pudo acceder al servidor C2 pero recibió una lista de tareas vacía, el ajuste sugiere una táctica de evasión: los desarrolladores probablemente introdujeron verificaciones del lado del servidor para perfilar el entorno del cliente y retener la configuración principal si se detecta un entorno aislado o un sistema de análisis.

La clave de cifrado para la comunicación de cliente a servidor ya no se recibe de forma dinámica desde el servidor C2, sino que ahora está codificada en el binario. La clave empleada por el cliente para descifrar los mensajes del servidor al cliente también permanece codificada.

Los ejemplos compilados más nuevos muestran un uso extensivo de la expansión en línea de funciones, donde muchas funciones (tanto definidas por el usuario como de bibliotecas y cajas estándar) se incorporaron directamente en sus llamadas con mayor frecuencia, lo que da como resultado funciones más grandes y dificulta el aislamiento del código del usuario. Es probable que este comportamiento sea el resultado del uso del inliner de LLVM. Si bien algunas funciones permanecen sin incorporar, la incorporación generalizada complica aún más el análisis.

Para obtener todas las entradas del Administrador de contraseñas de Chrome, EDDIESTEALER comienza su rutina de robo de credenciales generando un nuevo proceso de Chrome con el indicador --remote-debugging-port=<port_num> , habilitando el protocolo DevTools de Chrome a través de una interfaz WebSocket local. Esto permite que el malware interactúe con el navegador sin necesidad de interacción visible del usuario.

Luego de iniciar Chrome, el malware consulta http://localhost:<port>/json/version para recuperar webSocketDebuggerUrl, que proporciona el punto final para interactuar con la instancia del navegador a través de WebSocket.

Al emplear esta conexión, emite un comando Target.createTarget con el parámetro chrome://password-manager/passwords, que indica a Chrome que abra su administrador de contraseñas interno en una nueva pestaña. Aunque esta página interna no expone su contenido al DOM ni a DevTools directamente, abrirla hace que Chrome descifre y cargue las credenciales almacenadas en la memoria. EDDIESTEALER explota este comportamiento en pasos posteriores a través del código similar a CredentialKatz, donde escanea la memoria del proceso de Chrome para extraer credenciales de texto sin formato después de que el navegador las cargó.

Según las cadenas descifradas os_crypt, encrypted_key, CryptUnprotectData, local_state_pattern y login_data_pattern, las variantes de EDDIESTEALER parecen ser compatibles con versiones anteriores y admiten versiones de Chrome que aún emplean el cifrado DPAPI.

Identificamos 15 muestras adicionales de EDDIESTEALER a través de similitudes de código e infraestructura en VirusTotal. La tabla de observaciones incluirá las muestras descubiertas, las direcciones IP/dominios C2 asociados y una lista de la infraestructura que aloja EDDIESTEALER.

Algunos consejos de análisis

Trazado

Para comprender mejor el flujo de control y señalar los destinos exactos de los saltos o llamadas indirectas en grandes bloques de código, podemos aprovechar técnicas de rastreo binario. Herramientas como TinyTracer pueden capturar un seguimiento de API y generar un archivo .tag , que asigna cualquier llamada de API seleccionada que se registrará en la línea de ejecución en ensamblaje. Las funciones de la biblioteca estándar de Rust llaman a WinAPIs bajo el capó, y esto también captura cualquier código que llame a funciones WinAPI directamente, evitando la abstracción de la biblioteca estándar. Luego, el archivo de etiqueta se puede importar a las herramientas de descompilación para marcar automáticamente los bloques de código empleando complementos como IFL.

Metadatos de pánico para la segmentación de código

Los metadatos de pánico (las rutas de los archivos fuente integrados (archivos .rs), los números de línea y los números de columna asociados con las ubicaciones de pánico) ofrecen pistas valiosas para segmentar y comprender las diferentes partes del binario. Sin embargo, esto sólo es así si dichos metadatos no se eliminaron del binario. Rutas como apps\bin\src\services\chromium.rs, apps\bin\src\structs\additional_task.rs o cualquier ruta que parezca parte de un proyecto personalizado generalmente apuntan a la lógica única de la aplicación. Las rutas que comienzan con library<core/alloc/std>\src\ indican código de la biblioteca estándar de Rust. Las rutas que contienen el nombre del paquete y la versión, como hashbrown-0.15.2\src\raw\mod.rs , apuntan a bibliotecas externas.

Si el proyecto de malware tiene una base de código algo organizada, las rutas de archivos en las cadenas de pánico pueden asignar directamente a módulos lógicos. Por ejemplo, la cadena descifrada apps\bin\src\utils\json.rs:48:39 está referenciada en sub_140011b4c.

Al examinar el árbol de llamadas en busca de llamadas entrantes a la función, muchas de ellas se remontan a sub_14002699d. Esta función (sub_14002699d) se llama dentro de una rutina de comunicación C2 conocida (jy::C2::RetrieveAndDecryptConfig), justo luego de descifrar datos de configuración adicionales que se sabe que tienen formato JSON.

Según la ruta json.rs y su contexto de llamada, una suposición fundamentada sería que sub_14002699d es responsable de analizar los datos JSON. Podemos comprobarlo recorriendo la llamada de función. De hecho, al inspeccionar la estructura de pila que se pasa como referencia a la llamada de función, ahora apunta a una dirección de montón rellena con campos de configuración analizados.

Para las bibliotecas estándar y los paquetes de terceros de código abierto, la ruta del archivo, el número de línea y (si está disponible) el hash de confirmación de rustc o la versión del paquete le permiten buscar el código fuente exacto en línea.

Reutilización de ranuras de pila

Una de las características de optimización implica reutilizar las ranuras de la pila para variables/estructuras de pila que no tienen líneas de tiempo superpuestas. Las variables que no están "activas" al mismo tiempo pueden compartir la misma ubicación de memoria de pila, lo que reduce el tamaño general del marco de pila. Básicamente, una variable está activa desde el momento en que se le asigna un valor hasta el último punto en el que se puede acceder a ese valor. Esto hace que la salida descompilada sea confusa, ya que el mismo desplazamiento de memoria puede contener diferentes tipos o valores en diferentes puntos.

Para manejar esto, podemos definir uniones que abarquen todos los tipos posibles que comparten el mismo desplazamiento de memoria dentro de la función.

Manejo de errores y enumeraciones de Rust

Las enumeraciones de Rust son uniones etiquetadas que definen tipos con múltiples variantes, cada una de las cuales puede contener datos opcionalmente, ideales para modelar estados como el éxito o el fracaso. Las variantes se identifican mediante un discriminante (etiqueta).

El código de manejo de errores se puede ver en todo el binario y constituye una parte significativa del código descompilado. El mecanismo principal de Rust para el manejo de errores es la enumeración genérica Result<T, E> . Tiene dos variantes: Ok(T), que indica éxito y contiene un valor de tipo T, y Err(E), que indica error y contiene un valor de error de tipo E.

En el fragmento de ejemplo a continuación, se emplea un valor discriminante de 0x8000000000000000 para diferenciar los resultados de la resolución de la API CreateFileW . Si CreateFileW se resuelve exitosamente, el tipo de variable reuse contiene el puntero de función API y se ejecuta la rama else . De lo contrario, se ejecuta la rama if , asignando una cadena de información de error de reuse a arg1.

Para obtener más información sobre cómo podrían ver otros tipos comunes de Rust en la memoria, ¡consulte esta hoja de trucos y esta asombrosa charla de Cindy Xiao!

Malware y MITRE ATT&CK

Elastic emplea el marco MITRE ATT&CK para documentar tácticas, técnicas y procedimientos comunes que las amenazas emplean contra las redes empresariales.

Táctica

• Acceso inicial
• Ejecución
• Evasión de defensa
• Exfiltración
• Acceso a credenciales
• Descubrimiento
• Colección

Técnicas

Las técnicas representan cómo un adversario logra un objetivo táctico mediante la realización de una acción.

• Phishing
• Inyección de contenido
• Intérprete de comandos y secuencias de comandos
• Credenciales de almacenes de contraseñas
• User Execution
• Información o archivos ofuscados
• Exfiltración a través del canal C2
• Evasión de virtualización/sandbox

Detecciones

YARA

Elastic Security creó las siguientes reglas YARA relacionadas con esta investigación:

• Windows.Infostealer.EddieStealer

Normas de prevención del comportamiento

• Suspicious PowerShell Execution
• Transferencia de herramientas de ingreso mediante PowerShell
• Descubrimiento potencial de información del navegador
• Potential Self Deletion of a Running Executable

Observaciones

En esta investigación se discutieron los siguientes observables.

Referencias

A lo largo de la investigación anterior se hizo referencia a lo siguiente:

• https:\/\/github.com\/N0fix\/rustbinsign
• https:\/\/github.com\/Meckazin\/ChromeKatz
• https:\/\/github.com\/hasherezade\/tiny_tracer
• https://docs.binary.ninja/dev/uidf.html
• https:\/\/www.unicorn-engine.org\/
• https:\/\/github.com\/LloydLabs\/delete-self-poc\/tree\/main
• https:\/\/cheats.rs\/#diseño-de-memoria
• https:\/\/www.youtube.com\/watch?v=SGLX7g2a-gw&t=749s
• https:\/\/cxiao.net\/posts\/2023-12-08-reversing-rust-panic-metadatos\/