Introducción

Esta publicación es la segunda parte de la serie “Ecosistema de robo de datos”. Si no leíste la primera parte, puedes hacerlo aquí.

El ecosistema de robo de datos ha experimentado una transformación radical en los últimos cuatro años, sobre todo en volumen. Esto ha producido un desplazamiento del foco de atención desde la interrupción de sistemas hacia la extracción silenciosa y automatizada de activos digitales. En el epicentro de esta evolución se encuentra LummaC2, también conocido como Lumma Stealer, un malware de tipo infostealer que ha redefinido parte del modelo de negocio de robo de datos mediante una infraestructura de Malware-as-a-Service (MaaS) altamente profesionalizada. A diferencia de las amenazas tradicionales que buscaban la notoriedad a través del daño sistémico, LummaC2 operaba bajo la premisa de la invisibilidad, priorizando la recolección de credenciales, cookies de sesión, wallets de criptomonedas y secretos corporativos para su posterior monetización en mercados secundarios.

Este informe plasma lo que considero que es el mayor hito del ecosistema de robo de datos, LummaC2. Analizaremos su funcionamiento desde dentro, el modelo operativo y el impacto global, basándonos en datos, mi experiencia habiendo estudiado el fenómeno los últimos años, evidencia recolectada de sus propios paneles de control y datos sacados de canales de Telegram públicos.


Contexto

Para comprender la relevancia de LummaC2, es imperativo analizar el cambio de paradigma en los vectores de intrusión. Según informes de inteligencia de ENISA para el año 2025, el phishing, en sus variantes de malspam, vishing y malvertising, sigue siendo el vector predominante, representando aproximadamente el 60% de las intrusiones observadas, superando con creces la explotación de vulnerabilidades técnicas, que se sitúa en un 21,3%. En este escenario, el robo de credenciales se ha consolidado como la principal vía de acceso inicial en entornos corporativos europeos. El informe Verizon Data Breach Investigations Report 2025 refuerza esta tesis, señalando que las credenciales robadas son el vector de acceso inicial en el 22% de los más de 22.000 incidentes analizados a nivel global.

La efectividad de los infostealers radica en su capacidad para actuar como el primer eslabón de una cadena de ataque mucho más destructiva. No se trata simplemente de un robo de contraseñas; es el facilitador crítico para el robo de identidad digital que deriva en ataques de ransomware, fraudes de compromiso de correo electrónico empresarial (BEC) y brechas de datos masivas y hasta ransomware. Los atacantes han comprendido que no es necesario desarrollar exploits complejos cuando pueden simplemente “entrar por la puerta principal” utilizando credenciales legítimas o secuestrando sesiones activas mediante tokens y cookies, lo que les permite incluso evadir sistemas de 2FA.

Todo esto, si estás en el mundillo ciber, posiblemente ya lo conocerás, pero vamos a seguir analizando evoluciones con números. No te saltes esta parte, que es importante para luego.

Veamos esta tabla de la gente de deepstrike:

Metric2024 Estimate2025 EstimateTrend YoY
Credentials stolen via infostealers~200 million1.8 billion↑ ~9× — 800% surge
Devices infected by stealers~700,000 – 1 million5.8 million↑ ~6× — 600%+
Infostealer logs/bots sold major market~300,000 est.>400,000 est.↑ ~30%
Global avg. cost per data breach$4.88M$4.44M↓ 9% — first drop in years
Share of breaches involving stolen creds76% (Verizon DBIR 2024 est.)86%↑ credentials dominant
Global cybercrime annual cost$8.4T est.$10.5T↑ 25% projected

Lo que vemos aquí sorprende. Resulta que, en solo un año, hemos visto un incremento de un 800% en el número de credenciales robadas por infostealer. ¿Se te ocurre el motivo de esto? Párate un momento a pensarlo… Hay muchos factores que pueden haber influido en esta evolución, pero uno en concreto se lleva la palma, y está relacionado con operaciones policiales y LummaC2. Luego profundizaremos en esto.

Para realizar la investigación que te traigo a continuación, una de las cosas que hice fue analizar una buena cantidad de stealer logs, sacados de canales de Telegram públicos. Tras haberlo procesado todo y haber sacado estadísticas de todas las clases, lo primero que llamaba la atención era la distribución geográfica de las víctimas. Mira el siguiente mapa:

Distribución geográfica de dispositivos infectados en la muestra analizada Distribución geográfica de todos los dispositivos infectados en la muestra analizada. Llama la atención que Rusia aparezca prácticamente desierto de infecciones.

Lo que tenemos aquí es la distribución geográfica de todos los dispositivos que fueron infectados en la muestra que analizamos. Llama la atención que Rusia esté desierto de infecciones. Este fenómeno posiblemente lo explique en detalle en otro post, pero para que te hagas a la idea responde principalmente a las políticas de Rusia de no perseguir (o hacerlo de manera muy laxa) los ataques que salen de su nación hacia fuera. Tanto es así que, en la gran mayoría de grupos rusos que he investigado, te encuentras la orden directa de no atacar a Rusia o sus aliados. Esto no solo se ve en las “normas del grupo”, de hecho también se ha llegado a ver malware que no detona si la IP de la víctima corresponde a Rusia o incluso si el teclado está configurado en ruso. Ahora bien, esto nos permite hacernos preguntas bastante lógicas: ¿Significa esto que un porcentaje altísimo (casi la totalidad) de operadores de infostealer están en Rusia? porque de no ser así, veríamos también infecciones en Rusia también… bueno, ahí lo dejo… mi intuición profesional me dice que sí, pero no es algo que haya podido comprobar ni probar en esta investigación, pues quedaba fuera del scope inicial. Lo dicho, esto lo comentaremos en otro momento, porque amerita su propio post.

Vamos a ver otra métrica interesante, la de la distribución temporal de las infecciones.

Distribución temporal de infecciones, enero 2022 – 2025 Distribución temporal de las infecciones.

Esta gráfica es especialmente importante, porque en ella se esconde la justificación de que hoy estemos hablando de LummaC2. Desde enero de 2022 hasta octubre de 2024 observamos una gráfica con una marcada tendencia lateral. No hay grandísimas variaciones en el número de infecciones. Esta es la época de Redline, MetaStealer, Raccoon, Vidar, StealC, etc. Ojo, LummaC2 nace a finales de 2022, pero no tenía tan buen marketing como los otros, que eran más usados. ¿Qué ocurre en octubre del 24? La operación Magnus (página oficial de la operación). El Departamento de Justicia de los EEUU junto con otras instituciones europeas tumban la infraestructura de RedLine y MetaStealer, los dos infostealers más usados del momento. Te voy a dejar el vídeo oficial del “Final Update” de la Operación Magnus, que no tiene desperdicio…

Esta operación supuso un durísimo golpe a la killchain de muchos actores (como los Traffers de la investigación anterior), que dependían del robo de credenciales con este malware para su operativa. Pronto empezaron a arder los foros y la gente se buscó una alternativa… ¿Cuál? LummaC2, el otro infostealer as a service con cierto nombre que quedaba en el mercado. En este caso, la gente de LummaC2 se benefició enormemente de la operación policial contra Redline, absorbiendo la mayor parte de sus clientes. Pero ¿Por qué se dio ese incremento casi vertical en las infecciones? Aunque posiblemente haya algún otro factor, el principal es que LummaC2 estaba mejor desarrollado, implementaba mejores técnicas anti-detección (luego hablaremos de esto) y mantenía un ciclo de actualizaciones y parches extremadamente ágil, con mejoras publicadas casi a diario en ciertos períodos.

No es que aumentaran los intentos de infección, es que el malware funcionaba mejor y se detectaba menos, aumentando así la tasa de infección por intento. Como consecuencia directa de esta migración de clientela y de la mayor efectividad del malware, el volumen de credenciales robadas se multiplicó por nueve, como hemos visto antes, entre finales de 2024 y mediados de 2025. Este incremento tan grande en el volumen de infecciones atrajo la atención de las autoridades, culminando en una operación conjunta entre el Departamento de Justicia de EEUU y Microsoft que terminó por tumbar la infraestructura de LummaC2. Podríamos decir que murieron de éxito.

Por último, antes de continuar, vamos a ver la gráfica de distribución de familias de malware:

Distribución de familias de infostealer en la muestra analizada Distribución de familias de infostealer. LummaC2 representa el 85% de todos los stealer logs analizados en este estudio.

Lo que vemos aquí termina de confirmar la teoría que te he expuesto un poco más arriba… resulta que el 85% de stealer logs que he analizado para este estudio provienen de LummaC2. La variación entre familias es abismal y deja patente la importancia y el impacto que este malware ha tenido en el ecosistema.

LummaC2 debería de considerarse un aviso para toda la comunidad. La organización creció muy rápido en poco tiempo, e intentaron hacerse también con el mercado de stealer logs creando LummaMarket e integrándolo con su panel de control. Es decir, el usuario podía emplear el malware y, después, desde el mismo panel de control, poner lo que había robado a la venta. Sin intermediarios. Sin fricciones. Esto duró poco, pero supone un cambio muy sustancial en la actividad habitual del típico actor que desarrolla malware. Se estaban metiendo en el negocio del mercadeo de datos robados, querían convertirse en el grupo de Traffers definitivo, y lo estaban consiguiendo.

Hecha esta introducción contextual, en la que creo que ha quedado patente el impacto de LummaC2 y sus pretensiones, vamos a analizar en qué consistía el servicio.


LummaC2 desde fuera

Esta sección va a estar dedicada a las cuestiones técnicas del malware en sí, concretamente desde la perspectiva del reversing (análisis desde fuera). Esta sección está basada en la magnífica investigación de reversing que hizo mi buen amigo Alberto Marín, del que siempre aprendo algo. Al César lo que es del César. Su trabajo aquí fue brillante y lo considero más que suficiente para entender la calidad y complejidad del desarrollo de este malware. Una publicación sobre LummaC2 que se precie debería mencionar la investigación de Alberto. Si quieres profundizar más y entrar en detalle desde el reversing, visita su blog, no tiene desperdicio: malwareinternals.com

Cuando se leen los análisis (como el de Alberto) de LummaC2, queda patente la intención de sus desarrolladores de que el malware fuera difícilmente analizable. Se trata de un binario bien protegido que despliega las siguientes técnicas clave:

1) Arquitectura de Empaquetado (Packer) de Doble Capa: El Payload principal de LummaC2 no se encuentra expuesto, sino que está protegido por un packer de dos etapas diseñado para complicar el desensamblado. Vamos a ver las dos capas:

  • Primera capa: Emplea técnicas de anti-emulación mediante grandes bucles de código inútil y confunde a los desensambladores inyectando instrucciones basura y patrones como push+ret o jz+jnz
  • Segunda capa: Descifra y ejecuta la versión final de LummaC2 cargándola directamente desde un recurso del binario. En lugar de generar procesos adicionales en el sistema, inyecta el código en su propio espacio de memoria virtual y transfiere la ejecución utilizando la API CreateThread.

2) Ofuscación del Flujo de Control (Control Flow Flattening): En sus builds por defecto, Lumma aplica Control Flow Flattening, una técnica que “aplana” y rompe el flujo lógico original del programa. Utiliza predicados opacos (condiciones que añaden ramas complejas pero cuyo resultado es determinista) para desorientar al analista. A nivel de registros, el malware reserva un gran espacio extra en la pila, gestionado casi íntegramente a través del registro ESI, para controlar hacia dónde debe saltar la ejecución.

3) Ocultación de las llamadas API (API Hashing): Para evadir la detección estática de sus capacidades, LummaC2 no incluye sus llamadas a la API de Windows en la tabla de importaciones. En su lugar, emplea API Hashing utilizando el algoritmo MurmurHash2 con una semilla de valor 32. En tiempo de ejecución, el malware carga librerías (como ntdll.dll), recorre la Tabla de Exportaciones y hashea cada nombre hasta encontrar una coincidencia con el hash hardcodeado que busca, guardando la dirección final en el registro EAX para ejecutarla.

4) Técnica Anti-Sandbox basada en Trigonometría: Para asegurar que el entorno de infección pertenece a una víctima real y no a una sandbox, LummaC2 utiliza un novedoso método de detección de comportamiento humano. El malware captura 5 posiciones consecutivas del ratón con pequeños intervalos de 50 milisegundos. Tratando estas posiciones como vectores euclidianos, utiliza fórmulas de distancia euclidiana y producto escalar para calcular los ángulos de movimiento del cursor. Si detecta que el ángulo entre dos vectores supera el umbral de 45 grados (lo que indicaría movimiento mecánico, tortuoso o emulado), retrasa la detonación indefinidamente.

5) Medidas anti-Leak y ofuscación de cadenas:

  • Los desarrolladores de LummaC2 forzaron el uso de un crypter para evitar que los analistas extraigan versiones limpias del binario. El malware comprueba activamente si ha sido desempaquetado leyendo su propio archivo ejecutable en busca de una marca hardcodeada en un offset específico. Si detecta que el binario está unpacked, detiene su flujo y muestra una alerta inofensiva al usuario para frustrar la ejecución para el análisis.
  • Ofuscación de cadenas: Aunque sus técnicas a nivel arquitectónico son complejas, la ofuscación de cadenas de texto parece ser bastante rudimentaria. Por ejemplo, inyectando la cadena inútil "edx765" en medio de rutas críticas, bastando con buscar y eliminar esa cadena para revelar los directorios objetivo del stealer.

Como ves estamos ante un malware que implementa medidas anti detección bastante buenas. Esto, sumado al continuo mantenimiento y parcheo por parte de los desarrolladores, alargó bastante su vida útil e hizo que su impacto, como hemos visto en el apartado anterior, fuera tremendo. Vamos a sumergirnos ahora en la experiencia de usuario, en cómo este malware fue diseñado para ser el infostealer definitivo, a nivel de usabilidad.


LummaC2 desde dentro

LummaC2 era un Malware as a Service, es decir, toda la infraestructura, incluido el panel de control, estaba gestionado por sus administradores. Se trataba de un malware relativamente sencillo de conseguir. Se anunciaba a bombo y platillo en foros como exploit[.]in y XSS[.]is, aunque en sus últimos días los desarrolladores optaron por un foro más discreto y de más difícil acceso, RAMP (foro tumbado por el FBI en enero de 2026). En la siguiente imagen podemos ver uno de sus post en este foro mostrando uno de sus parches semanales para evadir Windows Defender:

Post de LummaC2 en el foro RAMP mostrando uno de sus parches semanales para evadir Windows Defender Post de LummaC2 en el foro RAMP mostrando uno de sus parches semanales para evadir Windows Defender.

El precio del malware estaba organizado por Tiers, tal y como se puede ver en la siguiente captura de pantalla sacada del foro ruso XSS, antes de que también lo cerraran (esta vez EUROPOL junto con la Brigade De Lutte Contre la Cybercriminalité, policía francesa. Mis respetos para ellos).

Estructura de precios de LummaC2 por Tiers, capturada del foro XSS Estructura de precios de LummaC2 organizada por Tiers, capturada del foro ruso XSS.

La compra era un proceso sencillo: Un mensaje de Telegram, una transferencia de criptomoneda y te daban una URL del panel y las llaves. Fácil y sin fricciones. En este punto, teniendo en cuenta lo que viene ahora, quiero mencionar que hay otra manera de conseguir acceder a un panel de LummaC2 (y en verdad a casi cualquier malware): la ingeniería social. En esta investigación no se financió el ciber crimen en ningún momento (ni en ninguna otra de las que hago)… se hizo algo más simple: pedir una demo. Con algo más de trámite y charla, claro, pero en esencia fue eso: Una demo rápida con una transacción prometida que nunca llegó a culminarse. El que no llora no mama, y el que no corre… vuela. Bien, hecho este disclaimer, veamos cómo es el panel por dentro, ya que conseguimos verlo y bichearlo, sería una pena no enseñártelo.

El panel principal

Lo que tienes delante es la landpage donde aterrizas cuando haces login en el panel. Se trata de un dashboard en el que podemos filtrar los stealer logs que hayamos capturado (en mi caso hice una sola prueba detonando el malware en una sandbox). Podemos filtrar por IP, por si tiene o no (y cuál) wallets de criptomoneda, por país, por Build Tag (especialmente útil cuando el actor tiene varias campañas en curso), por fecha y, en definitiva por todo lo que ves en la imagen.

Panel principal de LummaC2: dashboard de stealer logs con múltiples filtros disponibles Panel principal de LummaC2. Dashboard de stealer logs con filtros por IP, país, wallet, Build Tag y fecha, entre otros.

Detalle curioso, se permiten poner hasta anuncios…

Generación de builds

En esta sección, como su nombre indica, se pueden generar builds. Las opciones que ofrece no son muchas: podemos elegir la versión del malware, podemos añadir un tag a la build y podemos elegir un gasket. Los gaskets son la infraestructura intermedia que empleará el malware para conectarse con el C2. Ahora veremos en qué consisten y qué tipos de gasket hay.

Ventana de generación de builds en el panel de LummaC2 Ventana de generación de builds. Permite seleccionar versión del malware, tag identificativo y gasket de conexión al C2.

Gaskets e Improved Gaskets

Los gaskets son, como acabamos de decir, la infraestructura intermedia que utiliza el malware para conectarse con el C2 y evitar tener en el binario la IP real del C2. Si no se especifica lo contrario se usan gaskets compartidos, que son dominios preconfigurados por los propios administradores de Lumma. Estos gaskets pueden ser usados por varios usuarios a la vez y tienden a quemarse pronto. Es por esto por lo que también se ofrece la opción de configurar un gasket personalizado por el módico precio de 50 dólares, como podéis ver en la siguiente captura:

Configuración de gaskets personalizados en el panel de LummaC2 Opciones de gaskets en el panel de LummaC2. Los gaskets personalizados tienen un coste adicional de 50$.

Al principio, en la build se introducían unos 3 gaskets. Uno principal y otros dos de respaldo, para que en el caso de que se tumbaran los dominios el malware pudiera seguir operando. Con el tiempo vieron que este número era insuficiente y lo subieron a 10, pero las builds seguían teniendo una vida corta. Para solucionar esto atacaron a la lógica del problema. Idearon otro sistema: los improved gaskets. Este sistema era más sofisticado. En lugar de meter los dominios dentro de la build, se configuraba un canal público de Telegram y, ahora sí, en el nombre del canal de Telegram se ponía el dominio cifrado. ¿Qué ventajas da esto? sencillo… si nos tumban un gasket simplemente tenemos que cambiar el nombre del canal de Telegram para que el malware vuelva a estar operativo. Esta nueva medida fue implementada en febrero de 2025, en la Update 9.02 del malware.

Sistema de Improved Gaskets: el dominio cifrado se almacena en el nombre de un canal público de Telegram Sistema de Improved Gaskets. El dominio del C2, cifrado, se publica en el nombre de un canal de Telegram, permitiendo actualizarlo sin recompilar la build.

Publicación de la Update 9.02 de LummaC2 en el foro exploit[.]in anunciando la implementación de los Improved Gaskets (febrero 2025) Publicación de la Update 9.02 de LummaC2 en el foro exploit[.]in, anunciando la implementación de los Improved Gaskets (febrero 2025).

Como ves, el flujo de desarrollo que tenían era muy dinámico, se adaptaban rápidamente a las situaciones y tenían una respuesta de desarrollo de calidad empresarial, siempre buscando la mejor experiencia para sus clientes. Posiblemente este sea otro de los pilares de su éxito.

API completa

Otro de los elementos diferenciadores de LummaC2 era su API. Sí, daban la opción de hacer todas (o casi todas) las gestiones vía API, que por cierto, estaba perfectamente documentada. Esto abría un mar de posibilidades con respecto a la automatización de flujos. En la H-c0n, en febrero, di una charla sobre LummaC2 (junto a mi querido amigo Alfonso Muñoz), sobre esta investigación, y al público le lancé la siguiente reflexión: imaginad lo que se podría hacer con esto y n8n… o simplemente con Python. Desde la automatización de checkeo de credenciales robadas on the fly hasta la automatización de pipelines de generación de builds —> generación de vídeos —> publicación en redes sociales, y un amplísimo etcétera que dejaré a tu imaginación. Te dejo por aquí capturas de parte de la documentación de su API, por si tienes curiosidad:

Documentación de la API de LummaC2 — parte 1

Documentación de la API de LummaC2 — parte 2

Documentación de la API de LummaC2 — parte 3

Integración con Telegram

Otra de las características fundamentales es la integración que tenían con Telegram. ¿Recuerdas la investigación anterior sobre Traffers? si no la has leído te invito a ello, puedes hacerlo aquí. Podría decirse que uno de los principales motivos de que esta característica exista es, precisamente, el modelo de negocio de los Traffers. En este panel se puede configurar un bot de Telegram para hacer forward directo de los stealer logs que llegan al panel. De esta manera los Traffers pueden hacer forward de los stealer logs directamente a sus canales privados de pago. Con este método sus clientes reciben los stealer logs casi en el momento de la exfiltración de los datos, garantizando así la mayor frescura posible. Este es uno de los usos, pero también se puede configurar para simplemente mandar estadísticas (o todo a la vez), como se puede ver en la siguiente captura:

Configuración de la integración con Telegram en el panel de LummaC2 Integración con Telegram en el panel de LummaC2. Permite hacer forward de stealer logs o estadísticas directamente a un bot o canal de Telegram.

LummaMarket

Aquí tenemos uno de los elementos que más diferencian a este grupo. LummaMarket. Si bien es una iniciativa “tardía”, es un buen reflejo de cómo el crecimiento de su negocio les fue empujando a querer abarcar más. Tradicionalmente la compra/venta de stealer logs no había sido gestionada por los propios desarrolladores del malware. Era algo que hacían los Traffers y antes de los Traffers marketplaces especializados como RussianMarket o 2Easy, donde los individuos subían sus stealer logs y, cuando se cerraba la venta el marketplace se llevaba una comisión y el vendedor el resto del dinero. Pues bien, la gente de Lumma, aprovechando el tirón y la fama que estaban adquiriendo, decidieron montar su propio market oficial, para tratar de cerrar el círculo y abarcar el negocio completo. Aquí te traigo la sección donde se podía poner a la venta los stealer logs.

Sección de venta de stealer logs integrada en el panel de control de LummaC2 (LummaMarket) Sección de LummaMarket integrada en el panel de control. Permitía poner a la venta stealer logs directamente desde el mismo panel, sin intermediarios.

Y aquí te dejo cómo se veía la web externa de LummaMarket y el canal de Telegram oficial donde se podían comprar stealer logs:

Web externa de LummaMarket Web externa de LummaMarket, el marketplace oficial de LummaC2 para la compra y venta de stealer logs.

Canal oficial de Telegram de LummaMarket para la compra de stealer logs Canal oficial de Telegram de LummaMarket, donde se comercializaban los stealer logs de forma directa.


Palabras finales

El ascenso y la caída de LummaC2 marcan un antes y un después en la historia del robo de datos. Lo que comenzó como un competidor discreto a finales de 2022 terminó convirtiéndose en un leviatán que acaparaba más del 80% de las infecciones por infostealer. El éxito de Lumma radica en la sofisticación técnica, la agilidad y un enfoque casi obsesivo en la experiencia de usuario. He estado siguiendo a este grupo casi desde que empezó… de hecho diría que vi casi en directo su primera publicación en foros. En lo que a mí respecta, observándolos, he aprendido mucho sobre el proceso de evolución de este tipo de actores. Estas investigaciones son necesarias, son necesarias para entender la psicología de un mercado que no descansa, el del ciber crimen. Analizar binarios y recopilar IOCs está bien, es absolutamente necesario y es lo que, en última instancia, resulta accionable por los SOCs. Pero estarás conmigo en que conocer el panorama general, entender las mecánicas que operan bajo los movimientos de los actores, así como desarrollar la intuición profesional, es lo que luego se traduce en estrategias defensivas sólidas y coherentes, a alto nivel.

Publicar y compartir este tipo de contenido es lo que nos permite pasar de una postura reactiva a una proactiva. Porque, aunque Lumma haya desaparecido, el modelo de “robo silencioso” que perfeccionaron ha llegado para quedarse. Alguien tomará el relevo. La próxima amenaza ya se está gestando en algún foro, y la mejor forma de combatirla es, precisamente, no dejar de observar desde el prisma de lo que ya conocemos.

Nos vemos en la siguiente.

Stay safe, stay sharp!

o7

Jacobo