Muchos asistentes a Black Hat y DEFCON vuelven a casa con la bandeja de entrada llena de DM. Mientras se ponía al día con la red de contactos habitual tras la conferencia el mes pasado, un investigador de Huntress se dio cuenta de que era blanco de un intercambio en X con alguien que se hacía pasar por un ejecutivo de marketing de criptomonedas. El actor de amenazas envió un enlace a un Google Doc real con una barra lateral personalizada diseñada para engañar al destinatario y hacer que descargara malware: un infostealer AMOS en macOS, o una cadena de carga de PowerShell en Windows.
Al notar de inmediato la estafa, nuestro investigador no descargó ningún malware en su equipo, pero sí siguió conversando con el actor de amenazas, quien terminó enviando más malware y, finalmente, una oferta de un millón de dólares. Lo que empezó con un DM terminó con una autoridad de certificación fraudulenta alojada en el entorno de pruebas de Huntress.
Aunque no fueron ellos quienes recibieron los DM, los analistas del SOC de Huntress Ryan Dowd y Jon Semon hicieron el trabajo pesado de analizar cada giro de esta impredecible cadena de ataque, y compartieron sus hallazgos en la edición de este mes de Tradecraft Tuesday.
Lee su blog para conocer todos los detalles técnicos y mira los puntos destacados del episodio a continuación.
El DM inicial: una cara amigable, una petición maliciosa
En X, el actor de amenazas se hizo pasar por el jefe de marketing de CoinDesk, usando aparentemente el nombre de una persona y la foto de otra. Huntress confirmó que esta cuenta contactó a varios investigadores de seguridad al final de DEFCON, usando un señuelo genérico centrado en una próxima conferencia de criptomonedas. Ryan lo describe como una "jugada de volumen" en lugar de un ataque dirigido específicamente a los asistentes de DEFCON; nuestros analistas encontraron publicaciones en redes sociales de usuarios que señalaban el comportamiento sospechoso de esta cuenta desde octubre de 2025.
Figura 1: La cuenta de X @HartmansDoeke que le escribió a nuestro investigador, haciéndose pasar por la vicepresidenta y jefa de marketing de CoinDesk
Aunque varios medios y otros comentaristas señalaron el inglés imperfecto del usuario de X en sus comunicaciones como una señal clara de que era un estafador, Ryan y Jon cuestionaron esa suposición general.
"Creo que una de las cosas más grandes que olvidamos es que muchos de estos actores de amenazas son solo personas al otro lado", dijo Jon. "Y en la era de la IA y de todas las demás herramientas como Grammarly que la gente puede usar para lograr un inglés perfecto e impecable, hay cierta ventaja en usar un inglés con errores, una conversación más personal y natural con la gente."
El Google Doc: una barra lateral sospechosa
Después de algunas idas y venidas "amistosas", el actor de amenazas le envió a nuestro investigador un enlace a un Google Doc legítimo junto con una "clave de acceso" para desbloquear los detalles de planificación de la conferencia.
Una demostración del Google Apps Script malicioso
El Google Doc tenía una barra lateral que mostraba un falso mensaje de error de descifrado, con supuestas instrucciones de solución para usuarios de distintos sistemas operativos, incluida la opción de copiar y pegar ciertos comandos en la Terminal. Este señuelo de ClickFix, y el botón de "actualización manual" junto a él, fueron lo que en realidad entregó el malware. La barra lateral misma era un Google Apps Script vinculado al documento, así que no había que descargar nada para que se ejecutara. Jon describió el documento como "una especie de mecanismo de clasificación y entrega. Es un embudo."
El Apps Script se ejecutaba del lado del cliente en el navegador de la víctima, evitando así una solicitud de consentimiento de OAuth, y terminaba recopilando la dirección IP pública y la geolocalización de la víctima, además de buscar carteras cripto de MetaMask / Ethereum, Phantom, Tron y Solana.
Todo lo recopilado se enviaba directamente al actor de amenazas mediante la API de Telegram; el script enviaba un mensaje de baliza por cada uno de los códigos de acción que se muestran abajo.
Figura 2: Códigos de acción enviados de vuelta a través de Telegram
VIEW es el que vale la pena analizar con calma. Abrir el documento con sesión iniciada, sin hacer clic en nada ni descargar nada, bastaba para informar la dirección IP, ubicación, navegador del espectador, y si tenía instalada una extensión de cartera cripto. Todo lo que ocurre después es el actor evaluando al objetivo.
Encontramos comentarios en ruso en todo el código fuente, así como en archivos PCAP de las comunicaciones con el C2, lo que respalda, sin demostrar, que el operador habla ruso. También notamos una gran cantidad de emojis.
Figura 3: Mensajes de baliza llegando al Telegram del actor. Este es tráfico de prueba de Huntress y no una víctima real: 203.0.113.x es un rango reservado para documentación.
Ryan bromeó: "Esos íconos sí le dan un aire de 'vibe-coded', la verdad, pero no estoy aquí para juzgar."
Jon retomó más adelante en la transmisión el tema de la atribución incierta: "No podemos señalar a un solo grupo, ni decir que esto es un APT. Podría ser solo un tipo en su casa usando IA para desplegar malware, hasta donde sabemos, o supongo que también una mujer en su casa desplegando malware. No quiero descartar a nadie en eso."
Los usuarios de Windows y de Mac se colocan en rutas de ejecución distintas. Los visitantes desde celulares activaban una baliza MOBILE y nada más, porque el actor no veía sentido en entregar un payload a un teléfono.
El payload de macOS: elige tu propia ruta de ataque
Ryan señaló que las instrucciones específicas para cada sistema operativo, con varias opciones, podrían darle a la víctima la ilusión de tener el control. Los usuarios de Mac que optaron por pegar los comandos de ClickFix inician una cadena encadenada de zsh, mientras que los usuarios que descargaron el malware manualmente reciben un archivo de imagen de disco de Apple (DMG) desde el repositorio de GitHub del propio atacante.
Figura 4: Los usuarios de Mac recibieron el payload mediante un comando ZSH encadenado o una descarga manual desde el repositorio de GitHub del actor de amenazas.
El payload final parecía ser una variante del stealer AMOS que intentaba recopilar lo siguiente:
Datos del navegador
Datos de monederos de criptomoneda
Datos de Telegram
Datos de Apple Notes
Datos de cookies
Información del llavero de inicio de sesión de macOS
El archivo DMG también incluía instrucciones para evadir Gatekeeper y un aviso de contraseña.
Figura 5: Captura de pantalla del aviso de contraseña para evadir Gatekeeper
Al describir el payload como "diseñado para baja visibilidad, construido para el sigilo y la persistencia", Ryan señaló similitudes entre esta variante de AMOS y la cadena de ataque de seis etapas de MacSync stealer que cubrimos en el Tradecraft Tuesday del mes pasado.
Entrega en Windows: Tres certificados de firma de código robados
A los usuarios de Windows que abrieron el documento de Google se los dirigió por un camino distinto. Para la descarga manual, el mismo mensaje falso de error de descifrado indicaba a los usuarios de Windows que actualizaran un "Google API Connector", que en realidad lanzaba una aplicación firmada con un certificado perteneciente a una pequeña empresa noruega, ya sea robado o emitido de forma fraudulenta. Ese es el primero de tres certificados de firma de código abusados en esta cadena.
La aplicación aprovechó la función ClickOnce de Microsoft para implementarse. Como dijo Jon: "¿Para qué escribir un descargador personalizado o un instalador completo para una aplicación cuando puedes simplemente usar Microsoft para distribuirla?"
Después de la instalación, apareció un portal HTML del Google Workspace Marketplace para distraer a la víctima mientras el malware se descargaba en segundo plano.
Los usuarios de Windows que cayeron en el señuelo de ClickFix en la barra lateral del documento de Google terminaron ejecutando un comando de PowerShell codificado que obtenía un loader, el cual a su vez descargaba tres payloads cifrados. Los tres estaban fuera de línea para cuando fuimos a revisarlos, pero los tres ya estaban en VirusTotal, por lo que el kit claramente ya se había usado antes. Como un toque adicional, la cadena de ejecución le muestra al usuario una "barra de progreso" falsa para la supuesta remediación, un detalle que nuestros analistas calificaron de "tierno".
Figura 6: El script del loader muestra a la víctima una ventana de "instalando"
Ryan señaló: "Se puso mucho esfuerzo en hacer que esta barra de progreso se viera legítima, más que en otras partes de esta campaña, lo cual fue bastante gracioso".
Tienes un mensaje nuevo: Un segundo enlace de documento y un segundo certificado robado
En medio de nuestro análisis de malware, el actor de amenazas siguió enviándole mensajes directos a nuestro investigador, incluido un enlace a otro documento, esta vez compartido mediante DropBox DocSend. Una vez más, los usuarios de macOS y Windows fueron dirigidos por caminos distintos: a los usuarios de macOS se los envió a otro servidor que ofrecía el mismo payload de AMOS, y a los usuarios de Windows se les dijo que instalaran una aplicación de escritorio de DocSend.
El instalador en la cadena de Windows estaba firmado con un certificado robado de Discord Inc.; la firma no se validó.
Al final, en realidad no se instaló nada desde DropBox: a las víctimas se les guiaba a través de lo que Jon llamó "un pequeño carrusel de incorporación de 5 pantallas, que usaba una campaña de marketing real de Dropbox, enlaces reales de Dropbox y demás." Al igual que la barra de progreso falsa mencionada antes, estas páginas no tenían ninguna función más que distraer.
Jon explicó qué sucedía en segundo plano: "Hay tres bloques try, hay tres catches y hay tres retornos silenciosos. Básicamente, si el token de Git falla, o las funciones fallan, o el manejador que ejecuta el código falla, todo simplemente no devuelve nada. Entonces, ya sea que el servidor esté caído, que se rechace la conexión por alguna razón, o que haya un compromiso total en la máquina, todos producen exactamente lo mismo en la pantalla para el usuario final, que básicamente es nada en absoluto."
Reconstrucción de comunicaciones a partir de un endpoint inactivo
Cuando el endpoint de la muestra de DocSend devolvió un error HTTP 404, buscamos infraestructura relacionada en el mismo dominio, web12api[.]com:
Figura 7: Infraestructura relacionada con el dominio malicioso
Después de reconstruir el protocolo de registro a partir del propio módulo @sentry/electron de la muestra, enviamos la solicitud reconstruida al dominio gemelo activo de SignNow, que devolvió:
Aproximadamente 5,5 KB de JavaScript sin ofuscar
Un token de sesión
Una contraseña de archivo
Tres URL de payload
Los payloads de la tercera etapa recuperados
Manager.zip: NetSupport Manager 14.10.0004Localcertificate.zip: un proxy local que intercepta TLSasusdriverld.zip: un implante para billeteras Ledger
La etapa final
Antes de escribir nada en el disco, el cargador capturó y subió una captura de pantalla completa del escritorio. Luego descargó tres archivos protegidos con contraseña desde eu03hub[.]com/get_file, con la contraseña del archivo incluida en la respuesta del comando y control. Cada ejecutable se lanzó de forma separada y oculta, y luego se volvió a lanzar 20 segundos después con Start-Process -Verb RunAs para solicitar privilegios elevados.
Payload uno: NetSupport Manager
NetSupport Manager es una herramienta legítima de monitoreo y gestión remota (RMM) que los actores de amenazas suelen abusar con frecuencia. Este payload estaba configurado para redirigir datos hacia infraestructura hostil y deshabilitar las alertas de chat, mensajería, conexión y desconexión.
Jon explicó: "Esto también es lo que lleva toda la persistencia de estos tres módulos. Tiene un controlador filtro de teclado, un servicio de Windows, un Win logon, una clave Run, una tarea programada para reinstalarse a sí mismo... todas esas cosas molestas que vemos con estas herramientas RMM maliciosas que se usan indebidamente."
Durante la transmisión, Ryan buscó una de las direcciones IP con las que se comunicaba el payload de NetSupport Manager y encontró dos nombres de dominio nuevos registrados:
GTA6Mainserver[.]comyGTA6Mainweb[.]com. Quienquiera que esté detrás de esa dirección ahora también está usando un señuelo de Grand Theft Auto VI, dirigido a personas que buscan una copia filtrada del juego.Lee nuestro nuevo blog sobre otra variante de malware que usa un señuelo de GTA6.
Payload dos: la tercera autoridad certificadora robada
Jon consideró que el segundo payload era el más interesante, y a regañadientes reconoció el trabajo del actor de amenazas, calificándolo de "malicioso, pero bien hecho." Luego bromeó: "Sí creo que podrías haber hecho más con esto, solo ruego que nunca lo hagas."
Disfrazado como un paquete de controladores de Lenovo, el payload estaba firmado con un certificado legítimo robado de Lenovo, el tercer certificado de firma de código abusado en la cadena. La autoridad certificadora que termina construyendo es algo totalmente distinto: esa la genera él mismo. Vació MsBuild.exe e importó solo kernel32, estableciendo en última instancia lo que Jon llamó "infraestructura de clave pública construida a medida y funcional en tu equipo".
El payload carga dos certificados:
Una autoridad certificadora (CA) autofirmada en el almacén raíz del sistema, que se presenta como Google Trust Services con
CN=WR3Un certificado hoja de
www.virustotal.comcon una lista SAN que cubre el dominio legítimo y localhost.
Jon repasó técnicas más novedosas que él y los asistentes describieron como "aterradoras". Se agregó una entrada al archivo hosts y una regla de firewall para LocalProxy, lo que daba como resultado una conexión HTTPS respondida localmente que parecía válida, permitiendo que el operador bloqueara búsquedas o devolviera resultados falsos limpios sin advertencias de certificado. Si bien el proceso en sí moría al reiniciar, la CA, la entrada del archivo hosts y la regla de firewall persistían.
Como la CA se regeneraba por cada equipo infectado, bloquear una sola huella digital de certificado no sirve de nada.
Jon remarcó el punto: "El hecho de que pudieran instalar este almacén de certificados ahí, y no haya entrada en el archivo hosts, ni regla de firewall, ni nada que lo esté bloqueando... si el actor de amenazas quisiera instalar estos otros certificados para cualquiera de los dominios de criptomonedas que mencionamos, cualquiera de las billeteras que mencionamos, señales de actualización de antivirus, podrían simplemente interceptar, leer o bloquear todas esas cosas. Ese es un concepto aterrador para mí".
Payload tres: un implante para billetera Ledger
Después de hacerle algunos cumplidos al actor de amenazas, Jon aprovechó esta oportunidad para "criticarlos de nuevo". El tercer payload usó el mismo crypter, el mismo disfraz de Lenovo y la misma técnica de vaciado de MsBuild que el segundo payload. Después de crear una clave Run llamada Ledger Wallet Installer, buscó instalaciones de Ledger Live y Ledger Wallet. Ocultó su ID de bot como dieciséis caracteres hexadecimales en un archivo llamado app.crc32, escondido dentro de la carpeta de datos de una aplicación real, y luego empezó a consultar el servidor del actor en busca de comandos. Lo observamos consultar 18 veces. Cada respuesta volvía vacía, así que el canal funcionaba y simplemente el operador no le estaba asignando tareas al equipo infectado.
Jon continuó: "Lo increíble de esto es que tenemos ese almacén de certificados de antes, tan directo, y la persistencia estaba rota en esta parte. Apuntaron la entrada Run hacia msbuild y no le dieron nada. Sin argumentos, sin archivos de proyecto, sin aplicación que ejecutar, solo una invocación vacía de MS build que simplemente termina y muere. ¿Cómo pasas de este elegante almacén de certificados a esta basura?"
Si bien esta muestra fue el componente menos terminado, deja claro los objetivos financieros y de robo de criptomonedas de la campaña.
Lecciones aprendidas
Ryan y Jon cerraron con tres lecciones para llevarse:
Un Google Doc compartido es contenido ejecutable
Un Apps Script vinculado a un contenedor puede ejecutarse en el navegador de quien lo visualiza, reportar la dirección IP real de esa persona y evitar una ventana de consentimiento de OAuth.
Abre documentos desconocidos sin haber iniciado sesión
Esto elimina la capa de recolección de Apps Script sin costo alguno.
La CA fraudulenta es el artefacto con más probabilidades de sobrevivir a la limpieza
Reimagear el equipo la elimina; simplemente matar el proceso no.
Ryan compartió su perspectiva sobre los desafíos de reconocer y priorizar este tipo de actividad como analista del SOC: "Definitivamente no pienso de inmediato en cosas como una autoridad certificadora fraudulenta en el repositorio de certificados de confianza, y la remediación de ese tipo de artefactos es muy importante. Muchas de estas cosas se podrían pasar por alto durante la remediación, a menos que se haga algo como volver a crear la imagen completa del equipo, que es, ya sabes, lo último que quieres hacer. Quieres ser bastante metódico en esa limpieza."
Coda: ¿Qué tal un millón de dólares en su lugar?
Como giro final, el actor de amenazas envió un último mensaje directo desesperado preguntándole a nuestro investigador si buscaba financiamiento para algún proyecto, alegando tener un contacto dispuesto a invertir hasta… voz de Dr. Evil... un millón de dólares.
Figura 8: La última oferta desesperada del actor de amenazas
Jon tuvo la última palabra: "Hay que reconocerlo (sin juego de palabras, o tal vez sí). No se rinden cuando se trata de intentar entrar en los equipos de la gente. El vendedor escucha un no y cambia su discurso. Digan lo que quieran sobre su oficio, quienquiera que esté detrás de este ataque, no se da por vencido."
¿Te gustó lo que acabas de leer? Únete a nosotros cada mes para Tradecraft Tuesday, nuestro webinar en vivo donde exponemos técnicas de hackers y hablamos de temas técnicos con demostraciones en vivo. ¡Reserva tu lugar ahora!
