Actualización del 1 de septiembre de 2026: Se ha añadido un cuarto caso a raíz de los cargos presentados en agosto de 2026 contra dos presuntos operadores de TeamPCP, así como una sección final sobre lo que estas deficiencias aportan y lo que no aportan a los defensores.
--
Un grupo de ransomware puso en marcha un programa de afiliados con sus propios sistemas de gestión, accesibles a través de Internet. Un grupo que afirmaba haber sufrido una filtración de datos había estado, en realidad, husmeando en un honeypot. Un desarrollador que trabajaba en operaciones cibernéticas estatales tenía un programa de robo de información de uso común ejecutándose en su propio ordenador.
Los actores maliciosos invierten en herramientas, infraestructura y técnicas de evasión, y se esfuerzan por dar una imagen de disciplina. El informe que figura a continuación sugiere que dicha inversión es desigual.
A continuación se enumeran cuatro fallos de OPSEC documentados. Los tres primeros fueron comunicados por investigadores en diciembre de 2025, y el cuarto, en agosto de 2026. Los he agrupado según el aspecto en el que se produjo el fallo: proceso, comportamiento, aislamiento técnico e identidad.
Devman: Fallos procedimentales de OPSEC en operaciones de ransomware
En un artículo anterior, traté los detalles técnicos del ransomware Devman, incluyendo cómo funcionaba y qué reutilizaba del código de ransomware existente.
Tras el lanzamiento, Devman fue objeto de críticas públicas en X por lo que los investigadores describieron como «una seguridad operativa deficiente». El artículo de Ctrl Alt Intel documentaba cómo un grupo había dejado al descubierto su propia infraestructura mientras ponía en marcha una oferta de ransomware como servicio.
Los problemas notificados:
- Infraestructura interna expuesta durante el lanzamiento: se podía acceder desde Internet a los sistemas utilizados para gestionar la operación, incluidos los servicios internos.
- Los sistemas de gestión y comunicación presentaban una protección insuficiente, lo que permitió a los investigadores observar cómo se coordinaban algunas partes de la operación.
- Reutilización de herramientas sin endurecimiento: la operación se llevó a cabo con componentes existentes que no habían sido sometidos a pruebas desde el punto de vista de la seguridad operativa (OPSEC).
El lanzamiento se hizo público antes de que se hubiera solucionado nada de eso. Para un grupo dedicado a reclutar afiliados, el resultado fue la reputación pública de llevar a cabo una operación poco madura.
Lapsu$ dispersos Hunters: fallos de seguridad operativa (OPSEC) en la verificación de objetivos
Actores vinculados a SLSH denunciaron públicamente una brecha de seguridad en una empresa de ciberseguridad, publicaron capturas de pantalla y afirmaron que se habían sustraído datos confidenciales.
Los informes de seguimiento confirmaron que los sistemas a los que accedieron no eran de producción. Contenían datos sintéticos, la técnica de engaño que Resecurity documenta aquí, diseñada para pasar desapercibida ante una mirada superficial.
Los fallos:
- No se realizó ninguna validación del entorno de destino: se dio por hecho que los sistemas accesibles eran reales, sin comprobar si estaban aislados o bajo vigilancia.
- Los datos sintéticos se aceptaron como prueba de la violación de seguridad, ya que parecían legítimos.
- Los repetidos intentos de rastreo y acceso provocaron fallos en el servidor proxy que dieron lugar a la filtración de detalles técnicos útiles para el rastreo.
La afirmación se hizo pública antes de que se confirmara, y la credibilidad del grupo se esfumó cuando se desmintió dicha afirmación.
Operador norcoreano: fallos técnicos de seguridad operativa (OPSEC) en el aislamiento del sistema
Un equipo utilizado por un desarrollador implicado en operaciones cibernéticas de Corea del Norte estaba a su vez infectado con LummaC2, un malware de uso común destinado al robo de información. El análisis de los registros reveló credenciales y herramientas en el dispositivo, y los investigadores lo relacionaron con una infraestructura asociada al robo de criptomonedas de Bybit, atribuido a actores norcoreanos, entre ellos el Grupo Lazarus. Esta información tiene carácter secundario y no constituye un aviso primario, por lo que se recomienda tratar los detalles con la precaución que merecen.
Los fallos notificados:
- Falta de seguridad en los dispositivos finales: un sistema controlado por un atacante se vio comprometido por un programa de robo de información de uso común.
- Sin aislamiento: las herramientas, los dominios phishing y los activos operativos se encontraban en un único equipo, y las credenciales almacenadas en él estaban vinculadas a una infraestructura maliciosa conocida.
- Anonimización incompleta: el uso de una VPN no ocultó la configuración del navegador, los ajustes de idioma ni los patrones de uso.
En mayo de 2025, los desarrolladores del DanaBot malware infectaron accidentalmente sus propios equipos, y los investigadores utilizaron posteriormente los datos de credenciales recuperados.
Ambos casos muestran cómo los atacantes pueden convertirse en víctimas de las mismas amenazas que ellos mismos desplegan.
TeamPCP: detectar fallos de seguridad operativa (OPSEC) en la gestión de identidades
Las versiones maliciosas de Trivy y LiteLLM de las que informé en julio se atribuyen a TeamPCP según el aviso FLASH del FBI del 2 de julio. El 27 de agosto de 2026, la Policía Federal Australiana (AFP) presentó cargos contra dos hombres de Australia Occidental tras una operación conjunta de la AFP, el FBI y la Policía de Australia Occidental. Dichos cargos son meras acusaciones y aún no han sido probados ante los tribunales.
El Equipo de Amenazas Emergentes de Flare publicó ese mismo día una guía paso a paso sobre la desanonimización, y Brian Krebs informó por separado sobre los cargos. Lo importante es el proceso, no el resultado.
Flare comenzó con un único alias utilizado en operaciones anteriores de TeamPCP, lo suficientemente característico como para buscarlo directamente. Esto condujo a un perfil de un programa de recompensas por errores que incluía un nombre real, y a un perfil de una comunidad de aprendizaje automático que mostraba públicamente un dominio que más tarde se utilizó como infraestructura de mando y control para el Mini-Shai-Hulud worm. A partir de ahí, la cadena siguió el rastro de unas credenciales filtradas: una dirección de correo electrónico escolar, una contraseña expuesta en un volcado público y, a continuación, una cuenta de correo electrónico personal recuperada a partir de esa contraseña. Una de las cuentas registradas con esos datos tenía la misma foto que aparecía en la portada del canal de Telegram del grupo.
Los fallos:
- Un alias característico que se utiliza tanto en cuentas operativas como personales, y que aparece tanto en las herramientas de TeamPCP como en un perfil en el que figura un nombre real.
- Infraestructura operativa que figura en un perfil personal: según Flare, un dominio C2 utilizado en la campaña « worm » de mayo de 2026 estaba disponible públicamente en una cuenta personal.
- Reutilización de contraseñas: una única credencial aparecida en un archivo filtrado público vinculaba un correo electrónico del centro educativo a una cuenta personal, y esa cuenta a todos los servicios registrados a su nombre.
Nada de eso es técnico. La propia recomendación de Flare a los defensores deja las cosas claras: supervisa tus dominios en los registros de los programas de robo de credenciales y en las listas combinadas. La exposición de credenciales que permitió a los investigadores llegar a una identidad real es del mismo tipo que la que hizo que 2.500 organizaciones acabaran en el propio archivo de TeamPCP.
TeamPCP también se hizo notar a propósito: canales de Telegram, una cuenta de X que ya ha sido eliminada, burlas dirigidas a las víctimas y el código fuente de worm publicado bajo una licencia MIT con una broma adjunta. El grupo también concedió una entrevista a Forbes, en la que se describía a sí mismo como «un grupo informal de adolescentes y jóvenes adultos que no encontraban trabajo remunerado, por lo que se dedicaron a la ciberdelincuencia». Cada uno de esos elementos era un punto de partida para la investigación.
Lo que estos fallos aportan realmente a los defensores
Ctrl Alt Intel documentó los sistemas de gestión de Devman analizando su infraestructura desde el exterior. El programa de robo de información presente en el ordenador del operador norcoreano salió a la luz tras el análisis de los registros de otra persona. La cadena de Flare partió de un alias público y se ejecutó sobre datos públicos. En los cuatro casos , el error llegó a ser de dominio público a través de la investigación, a posteriori, y no a través de nada que hubiera detectado el propio sistema de supervisión de la víctima.
Esa distinción es importante, debido a cómo se presenta el caso habitual:
- Un atacante que utilice herramientas de administración nativas y binarios firmados no deja nada que pueda analizar malware : no parece haber nada raro.
- Si se presentan unas credenciales válidas y un token válido, se genera una entrada correcta en el registro de inicio de sesión: la autenticación se realiza con éxito.
- La superposición de los planos de «on-premises», «identidad» y « cloud » hace que ningún sistema disponga de una visión global: los movimientos no son visibles.
Esas son las tres brechas sobre las que escribo, y ninguno de los cuatro fallos mencionados anteriormente modificó ninguna de ellas mientras se estaban ejecutando los ataques.
El panel expuesto de Devman ayudó a los investigadores a perfilar una operación, no a que una víctima detectara una intrusión. El análisis paso a paso de Flare dio lugar a una atribución, no a una alerta. Estos errores sirven para la atribución, el enjuiciamiento y la información pública, tres aspectos que son importantes, pero ninguno de ellos es la detección. La detección debe partir de la base de que no se ha cometido ningún error.
Lo que sí revelan los fallos es el tipo de señal a la que conviene prestar atención. En cada caso, la pista era de carácter conductual más que estática: cómo actuaba el atacante tras obtener acceso, qué infraestructura se reutilizaba y dónde fallaba el aislamiento. Los entornos de engaño, los datos sintéticos y la supervisión basada en el comportamiento no evitan los ataques. Lo que hacen es poner de manifiesto el comportamiento cuando una suposición falla.
Los atacantes también están adoptando herramientas basadas en la inteligencia artificial, lo que acelera el reconocimiento, la selección de objetivos y la explotación sin eliminar el criterio humano del proceso. Esto conlleva sus propios riesgos: confiar en exceso en los resultados automatizados y ampliar una suposición errónea antes de que nadie se dé cuenta de que es falsa.
Los capítulos sobre las brechas en Mind Your Attack Gaps analizan cómo es la detección cuando el atacante acierta, que es el caso para el que vale la pena prepararse. En Vectra AI modelamos el comportamiento a partir del acceso a través de la identidad, el « cloud » y la red, porque esa señal perdura cuando el atacante no comete ningún error.
La tecnología cambia. Las personas no.