ESET participa en la Operación Endgame para interrumpir la botnet Amadey y el infostealer Stealc

Hace un año, ESET Research formó parte de dos grandes operaciones que interrumpieron algunas de las principales operaciones cibercriminales de ese momento, Lumma Stealer y Danabot. Más recientemente, nuestros investigadores están nuevamente colaborando con socios del sector privado y fuerzas de seguridad, pero esta vez apuntando a la botnet Amadey y al infostealer Stealc, ambos ofrecidos bajo el modelo de malware como servicio (MaaS). La Operación Endgame —coordinada por Microsoft Digital Crimes Unit (DCU), BitSight, Lumen, Mitsui Bussan Secure Directions (MBSD) y otros socios— tuvo como objetivo toda la infraestructura de red conocida utilizada por afiliados de Amadey y Stealc con el fin de paralizar sus operaciones cibercriminales.

ESET contribuyó a este esfuerzo con análisis técnicos, información estadística, servidores conocidos de comando y control (C&C), claves de cifrado, identificadores de campañas y de build, y otra inteligencia de amenazas recopilada durante nuestro seguimiento a largo plazo de ambas familias de malware.

Puntos clave de esta entrada del blog:

• ESET participó en la operación global coordinada Operation Endgame para desarticular Amadey y Stealc
• Operation Endgame impactó alrededor de 50 dominios y cerca de 200 servidores C&C activos basados en IP asociados a Amadey y Stealc.
• ESET proporcionó análisis técnicos, información estadística, servidores C&C conocidos, claves de cifrado, identificadores de campaña y otros insights.
• Ofrecemos un panorama del ecosistema MaaS a nivel de afiliados para ambas familias de malware.
• Describimos cómo realizamos el clustering de la actividad de Amadey y Stealc.
• Resumimos las propiedades técnicas más relevantes para el seguimiento y la disrupción, incluyendo comunicaciones C&C, identificadores embebidos y claves de cifrado.
• Detallamos las superposiciones entre la actividad de Amadey y afiliados de Lumma Stealer.

Contribución a la disrupción

ESET Research ha estado monitoreando tanto la botnet Amadey como el infostealer Stealc durante los últimos tres años. Para esta operación de disrupción, compartimos estadísticas que cubren desde el Q4 2025 hasta el H1 2026, junto con indicadores técnicos y datos de configuración extraídos de muestras de malware procesadas.

Nuestros sistemas automatizados han estado analizando en profundidad muestras de Amadey y Stealc, identificando los campos más relevantes para el tracking a gran escala. Estos incluyen servidores C&C, identificadores de build, claves de cifrado, paths de URL, identificadores de campaña y otros valores embebidos utilizados por estas familias de malware durante la comunicación con infraestructura controlada por los atacantes.

Uno de los principales objetivos de nuestro trabajo fue encontrar métodos confiables para manejar el alto volumen de muestras procesadas y agruparlas en clusters. Esto resultó particularmente relevante porque tanto Amadey como Stealc se comercializan como servicios. En consecuencia, las muestras de malware son distribuidas y operadas por afiliados, que con frecuencia gestionan su propia infraestructura, generan o solicitan sus propios builds y orquestan sus propias campañas. La identificación de clusters de actividad en estos ecosistemas permite detectar objetivos prioritarios para operaciones de disrupción como esta.

El intercambio de análisis técnicos, información estadística e inteligencia de amenazas — como listas de servidores C&C, identificadores de afiliados y claves de cifrado — permite a las fuerzas del orden identificar, priorizar y actuar sobre infraestructura con un alto grado de confianza. Los IoCs también ayudan a discriminar entre clusters individuales, infraestructura compartida y botnets de alto impacto cuya desarticulación probablemente genere el mayor efecto en el panorama de amenazas. En última instancia, la operación afectó alrededor de 50 dominios y casi 200 IPs activas utilizadas como servidores C&C para Amadey o Stealc.

Familias de malware desactivadas

Amadey es un malware loader modular. Su principal propósito es distribuir malware adicional en sistemas comprometidos, aunque también ofrece módulos para exfiltración de datos y acceso remoto.

Stealc, en contraste, es un infostealer típico ofrecido como servicio. Apunta a credenciales, cookies, wallets de criptomonedas, extensiones de navegador y archivos cuyos nombres coinciden con patrones definidos por los afiliados.

Ambas familias de malware se venden como servicios y se anuncian en foros de la darknet. Para obtener visibilidad sobre estos foros, utilizamos Flare.io, una plataforma de inteligencia de amenazas que monitorea comunidades underground. En ambos ecosistemas, los afiliados reciben un panel de administración self-hosted que debe desplegarse en su propia infraestructura de servidores. Esto requiere cierto nivel de habilidad técnica por parte de los afiliados y también les otorga control directo sobre los datos de las víctimas y la distribución de payloads.

Este modelo difiere de otros ecosistemas MaaS. Por ejemplo, los afiliados de Danabot pueden optar por alquilar infraestructura de C&C como servicio, mientras que Lumma Stealer utilizaba una red de exfiltración completamente gestionada por sus operadores. En el caso de Amadey y Stealc, los afiliados son responsables de desplegar y operar su propia infraestructura, lo que dificulta los esfuerzos de disrupción, motivo por el cual el enfoque de clustering fue esencial.

Si bien los métodos de distribución dependen en última instancia de cada afiliado individual, la telemetría de ESET mostró de forma consistente que ambas familias de malware eran distribuidas a través de una amplia variedad de canales. Los métodos más comunes incluyeron falsas actualizaciones de software, instaladores de software crackeado y loaders de malware de terceros.

Amadey utilizaba un modelo pay-per-rebuild. Los afiliados compraban una licencia y luego pagaban una tarifa adicional cada vez que necesitaban generar un nuevo build, por ejemplo, al rotar hacia un nuevo servidor de C&C. En otras palabras, los operadores de Amadey no proporcionaban a los afiliados una herramienta builder; en su lugar, las muestras se compilaban bajo solicitud para cada afiliado.

Stealc adoptó un enfoque más favorable para los afiliados, ofreciendo generación ilimitada de builds (Figura 1) como parte de su suscripción. Esto reducía el costo operativo de rotar la infraestructura de C&C y facilitaba que los afiliados generaran nuevas muestras según fuera necesario.

Intentando evitar estafas por suplantación de identidad, los operadores de ambos servicios instruían explícitamente a los potenciales afiliados en foros de la darknet a contactarlos únicamente a través de canales oficiales. Amadey dirigía a los compradores a mensajes privados en el foro de la darknet donde se anuncia, mientras que Stealc utilizaba mensajes privados en foros de la darknet o Telegram.

Amadey

Amadey es un malware loader modular que ha sido anunciado en foros de la darknet por la cuenta denominada InCrease desde octubre de 2018. Con el tiempo, se ha convertido en una de las familias de malware más estables y activamente mantenidas, con soporte continuo proporcionado a través de canales en foros de la darknet.

Nuestra tasa de detección en telemetría, mostrada en la Figura 2, indica que Amadey fue observado a nivel global sin un foco regional específico, aunque las tasas de detección más altas se registraron en India, Turquía, Egipto, México y España.

La función principal de Amadey es distribuir malware adicional a las víctimas. Además de eso, ofrece tres módulos para exfiltración de datos y acceso: monitoreo del portapapeles, robo de credenciales y acceso remoto basado en VNC.

El servicio tiene un precio de 600 dólares estadounidenses, pagados en Bitcoin, por una licencia única, con un cargo adicional de 50 dólares por cada rebuild. Esto significa que los afiliados incurren en un costo cada vez que generan un nuevo build, por ejemplo, al rotar hacia un nuevo servidor de C&C. Este esquema de precios se ha mantenido en gran medida sin cambios desde las primeras versiones anunciadas, lo que sugiere una base de clientes estable y consolidada.

A lo largo de los años hemos observado actualizaciones continuas de versiones (Figura 3) y desarrollo activo de Amadey. El hito más significativo en su desarrollo ocurrió en agosto de 2020 (v1.99.5), cuando el código base fue completamente reescrito. La segunda evolución importante llegó con el lanzamiento de la versión v5.03 en octubre de 2024, que incorporó una gran cantidad de nuevas capacidades: hVNC con conexión inversa, soporte para instaladores MSI silenciosos, habilitación de RDP, ejecución de cmd.exe con privilegios SYSTEM y soporte integrado para payloads cifrados. En general, la mayoría de las otras actualizaciones, de menor envergadura, cumplieron un propósito implícito pero constante: evadir las detecciones de antivirus (AV) a medida que estas surgían.

Descripción técnica

Cada muestra de Amadey contiene al menos una URL de servidor de C&C hardcodeada, mientras que la configuración permite hasta tres entradas. Las muestras también incorporan una clave RC4 utilizada para cifrar las comunicaciones con el servidor de C&C.

Nuestro análisis mostró que la clave RC4 extraída de cada muestra funciona como un identificador confiable de cluster, permitiéndonos agrupar las muestras en botnets individuales, lo cual abordamos con más detalle en la sección de Clustering.

Un segundo valor hardcodeado, denominado internamente como «sd», es una cadena hexadecimal de seis caracteres con apariencia aleatoria que sigue el patrón[0-9a-f]{6}. Se transmite durante el handshake inicial con el C&C y, muy probablemente, identifica un build específico dentro del despliegue de un afiliado. Aunque a veces los investigadores lo denominan ID de campaña o ID de Amadey, el modelo de negocio pay-per-build de Amadey sugiere que representa con mayor precisión un identificador de build.

Cada muestra también contiene un número de versión. Nuestro análisis se enfoca en la versión v5.x, que ha sido la variante dominante observada en la telemetría de ESET desde comienzos de 2025.

Este bot también verifica la distribución de teclado de la víctima. Si coincide con una asociada a un país de la CEI (CIS), toda la comunicación de red es rechazada de forma silenciosa. Los actores de amenazas que operan desde Europa del Este suelen utilizar este tipo de mecanismo de protección integrado para evitar afectar empresas y entidades gubernamentales de la región, reduciendo el riesgo de atraer atención o persecución por parte de autoridades locales. Además, estos operadores suelen seguir estas prácticas para evitar posibles represalias de sus pares por atacar “a los suyos” o por violar las reglas de los foros de la darknet donde anuncian sus servicios.

Esta sección proporciona solo una visión general de alto nivel de Amadey, ya que un análisis técnico profundo ya ha sido publicado en el informe de Swisscom.

Comunicaciones C&C

Amadey se comunica con su servidor de C&C a través de HTTP utilizando solicitudes POST. A grandes rasgos, la comunicación sigue un ciclo de vida de tres etapas:

• Beacon inicial – el bot envía una solicitud HTTP POST mínima con st=s al servidor de C&C. El servidor responde con un intervalo de espera, por ejemplo  <c>10<d>, indicando al bot que espere 10 minutos entre los siguientes check-ins.
• Registro – el bot transmite información del sistema cifrada con RC4, codificada como una cadena plana de pares clave-valor. Estos datos incluyen la versión del sistema operativo, nombre de usuario, nombre del equipo, producto antivirus instalado, privilegios de administrador, valor sd y otra información del host. Cabe destacar que la clave RC4 en sí nunca se transmite a través de la red. Según nuestra telemetría, no se observó que ningún servidor entregara tareas para más de una clave RC4 al mismo tiempo, lo que sugiere que cada muestra debe comunicarse con un servidor de C&C que ya conoce y espera exactamente esa clave RC4. El servidor responde con una lista de tareas.
• Asignación de tareas (tasking) – las tareas se entregan como cadenas de comandos estructuradas, delimitadas por etiquetas <c> y <d>, con comandos individuales separados por el carácter #, como se muestra en la Figura 4. Cada tarea codifica un tipo de comando, como descargar y ejecutar un EXE, iniciar VNC o ejecutar un plugin de stealer. Las tareas también incluyen parámetros como un flag de escalamiento de privilegios, el directorio de destino y la URL del payload.

Cada tarea tiene su propia lógica de procesamiento, que va desde comandos simples de descarga y ejecución hasta la ejecución más compleja de componentes hVNC o proxy. El funcionamiento interno ya ha sido documentado en reportes técnicos previos.

Clustering

Al analizar malware MaaS, un desafío clave es encontrar una forma confiable de agrupar muestras que pertenecen al mismo actor de amenazas. Comprender el modelo de negocio y cómo se distribuye la infraestructura de red es, por lo tanto, esencial para una disrupción efectiva, ya que permite a defensores y fuerzas del orden identificar los puntos críticos donde la acción tendrá el mayor impacto. En esta sección, explicamos nuestra metodología.

Las muestras de Amadey contienen tres valores de configuración clave hardcodeados:

• las URL de C&C,
• claves RC4 utilizadas para las comunicaciones C&C, y
• el valor «sd» transmitido durante el handshake inicial C&C.

A lo largo de nuestro seguimiento, observamos que las URL de C&C de Amadey siguen un patrón constante:

http(s)?://<C&C>/<random_path>/index.php

Además, la misma porción de URL  <random_path> se utilizó con distintos servidores de C&C (ver Figura 5). Dado que este valor parece ser una cadena aleatoria, observarlo asociado a múltiples servidores de C&C a lo largo del tiempo constituye un indicio sólido de que esos servidores son operados como parte del mismo cluster. Por lo tanto, descompusimos la URL de C&C en dos partes: la dirección IP o el dominio y el segmento de URL  <random_path>.

Utilizando valores de la configuración de las muestras, combinados con nuestra comprensión de su propósito, empleamos modelado de grafos para obtener visibilidad sobre la estructura del ecosistema de Amadey. A primera vista en la Figura 6, se observa claramente que no existe infraestructura compartida, sino varios sub-botnets más pequeños, con uno que domina claramente. Profundizamos en ese cluster más grande en la siguiente sección.

En conclusión, los principales hallazgos son:

1. Identificamos un total de 53 clústeres únicos dentro del ecosistema Amadey.
2. Cada valor «sd» está vinculado a una única clave RC4.
3. Es probable que las claves RC4 sean un identificador útil de afiliado, ya que los rebuilds preservan la clave mientras cambian el valor «sd ».
4. La parte <random_path> de la URL del servidor C&C se reutiliza ocasionalmente al rotar los servidores C&C, lo que constituye una prueba confiable de que los servidores pertenecen al mismo clúster.

El clúster más grande de la botnet Amadey

Un cluster se destaca como el más grande, representando casi el 34 % de todas las muestras de Amadey procesadas. Este cluster también fue el único activo a lo largo de todo el período analizado, como se muestra en nuestra línea de tiempo en la Figura 7.

La botnet más grande también dominó en el número promedio de payloads distribuidos a las víctimas por ejecución. Según nuestra metodología de clustering, las muestras de Amadey pertenecientes a la botnet más grande distribuían, en promedio, alrededor de 14 payloads a cada víctima simultáneamente (Figura 8).

El rango y la diversidad de las familias de malware distribuidas fue amplio, desde infostealers y RATs hasta malware empaquetado con protectores de código complejos. La Figura 9 ofrece una visión de los payloads que detectamos distribuidos durante el período de seguimiento.

Además, los investigadores de ESET pudieron obtener evidencia de que, en numerosas ocasiones, se entregaban múltiples muestras de Lumma Stealer a una misma víctima, cada una atribuida a un afiliado distinto (ver nuestra investigación previa sobre Lumma Stealer). Esto da como resultado que múltiples afiliados de Lumma Stealer terminen con los mismos datos robados. Esta observación nos lleva a concluir que los actores de amenazas que controlan este cluster más grande probablemente operaban su propio modelo pay-per-install (PPI), monetizando aún más sus bots.

Stealc

A diferencia de Amadey, Stealc es un representante típico de los infostealers. Apunta a un amplio conjunto de fuentes de datos, incluyendo credenciales almacenadas por navegadores web, clientes de correo electrónico, clientes FTP, plataformas de gaming, archivos de wallets de criptomonedas y extensiones de navegador.

Stealc fue introducido en un foro de la darknet en febrero de 2023, y comenzamos a rastrearlo poco después. Nuestra tasa de detección en telemetría, mostrada en la Figura 10, indica que Stealc se distribuyó globalmente sin un foco regional específico. Las tasas de detección más altas se observaron en Estados Unidos, Polonia e Italia.

Stealc es anunciado por un actor de amenazas que utiliza el alias «plymouth». Los operadores han mantenido activamente Stealc; cada vez que se lanzaba una nueva versión, publicaban notas de la versión en un post en foros de la darknet. En los últimos tres años se registraron 37 lanzamientos de este tipo. Stealc se comercializa como suscripción mensual, con un esquema de precios que ha evolucionado solo levemente:

• 300 dólares al mes
• 700 dólares estadounidenses por tres meses
• 1000 dólares estadounidenses por seis meses

En marzo de 2025, Stealc recibió una actualización arquitectural importante con la versión 2, que introdujo cambios significativos en el protocolo de red y en la estructura de configuración y, desde entonces, esta versión ha predominado en nuestra telemetría. Para junio de 2026, había alcanzado la versión 2.22.1, como se muestra en la Figura 11.

Además de sus objetivos principales, Stealc incluye un file grabber configurable que permite a los afiliados especificar patrones personalizados para definir qué archivos exfiltrar de los equipos comprometidas. Sus comunicaciones C&C y las cadenas embebidas están protegidas mediante cifrado RC4 con claves únicas por build.

Stealc no depende de un único método de distribución estandarizado: cada afiliado es responsable de sus propios mecanismos de entrega. Sin embargo, al igual que con Amadey, nuestra telemetría indica que ciertos vectores destacan de manera consistente, en particular instaladores de software troyanizados y loaders de malware establecidos (como Amadey).

Resumen técnico

Un análisis técnico detallado de Stealc v2 ya ha sido publicado por Lumma-Labs. En esta sección, nos enfocamos en las propiedades utilizables para clustering.

Las versiones actuales de Stealc incorporan dos claves RC4 distintas por muestra:

• una para descifrar cadenas ofuscadas en tiempo de ejecución, y
• una segunda para cifrar las comunicaciones de red con el C&C.

Además de las dos claves RC4, también hemos estado extrayendo el identificador build de las muestras de Stealc. Este valor representa una campaña individual de Stealc y, a diferencia de otras cadenas, no está protegido dentro del binario. Este valor es relevante porque se transmite como parte del handshake con el C&C (ver Figura 12).

La dirección del servidor C&C y el path de la URL utilizado para las comunicaciones se almacenan entre las cadenas cifradas con RC4 y han sido extraídos como parte de nuestro pipeline automatizado de desempaquetado de configuraciones.

Comunicaciones C&C

Stealc se comunica con su servidor de C&C a través de HTTP utilizando objetos JSON cifrados con RC4. La solicitud inicial enviada al C&C contiene tres valores:

• un identificador build,
• una huella digital del equipo comprometido (hwid) y
• el tipo de solicitud (esta solicitud inicial es de tipo «create»).

La huella de la máquina se deriva del número de serie del volumen del sistema y se formatea como una cadena UUIDv4. Un ejemplo de objeto JSON para esta solicitud inicial se muestra en la Figura 12.

El servidor de C&C responde con un objeto JSON complejo que define qué funcionalidades debe ejecutar Stealc. Junto con esto, la respuesta contiene un valor access_token generado aleatoriamente que actúa como clave de sesión y debe utilizarse en todas las solicitudes posteriores; de lo contrario, el servidor las rechaza. Además de las definiciones detalladas de los objetivos, el objeto JSON también indica si se debe tomar una captura de pantalla, autodestruirse al finalizar o descargar y ejecutar un payload adicional posteriormente. Un ejemplo de objeto JSON de respuesta se muestra en la Figura 13.

Cada respuesta del servidor también contiene un par clave-valor generado aleatoriamente al inicio; ninguna de las cadenas hexadecimales se reutiliza en comunicaciones posteriores con el C&C. Según la investigación de Zscaler, esto evita firmas de detección estáticas sobre tráfico cifrado con RC4, incluso cuando se reutiliza la misma clave de cifrado. En la Figura 13, el nonce generado aleatoriamente es "bf66e52": "03030ac3e9a8cebf".

Luego del registro inicial, Stealc utiliza tres tipos de operación adicionales, con nombres autoexplicativos, para ejecutar su funcionalidad:

• upload_file: exfiltra los datos recopilados;
• loader: descargar y ejecutar un payload posterior, y
• done: indicar finalización.

Clustering

Como se mencionó, a diferencia de Lumma Stealer, los operadores de Stealc no ofrecen infraestructura compartida a sus afiliados. De forma similar a nuestro enfoque de clustering para Amadey, aplicamos modelado de grafos a los valores extraídos de las configuraciones de Stealc, combinados con nuestra comprensión de su propósito, para comprender mejor la estructura del ecosistema de Stealc. El resultado fue un grafo que muestra que Stealc está efectivamente fragmentado en muchos clusters pequeños (ver Figura 14). Cada cluster se centra en un número reducido de servidores de C&C (a menudo solo uno) y, por lo general, está asociado a pocos identificadores de build o paths de URL de C&C. Por lo tanto, la disrupción de esta infraestructura resulta desafiante debido a la ausencia de un punto único de debilidad. En total, identificamos 73 clusters distintos (ver Figura 14) operando Stealc desde marzo de 2025.

Conclusión

Para operaciones de disrupción global como Operation Endgame contra Amadey y Stealc, es necesario el monitoreo automatizado a largo plazo del malware. Este artículo presenta información recopilada de esa manera, pero también proporciona detalles sobre el modelo de negocio MaaS específico detrás de cada familia y cómo esto se traduce en una infraestructura de red a menudo fragmentada, documenta sus principales identificadores estáticos y protocolos de comunicación con C&C, y describe cómo los investigadores de ESET contribuyeron a identificar puntos críticos para la disrupción. Nuestra inteligencia de amenazas sobre Amadey y Stealc, combinada con los datos compartidos por nuestros partners, proporcionó una base sólida tanto para la operación de disrupción como para las acciones de las fuerzas del orden.

Operation Endgame tuvo como objetivo tomar control o dejar inoperativos todos los servidores de C&C conocidos de Amadey y Stealc, interrumpiendo directamente la infraestructura de la que dependen los afiliados de ambos servicios MaaS. ESET continuará monitoreando ambas familias y rastreando cualquier intento de reconstruir infraestructura operativa tras esta disrupción.

IoC

En nuestro repositorio de GitHub se puede consultar una lista exhaustiva de indicadores de compromiso (IoC) y muestras.

Archivos

Red

Técnicas de MITRE ATT&CK

Esta tabla se ha elaborado utilizando la versión 19 del marco MITRE ATT&CK.