El 4 de abril de 2026, Anodot informó de cortes generalizados en sus conectores Snowflake, Amazon S3 y Amazon Kinesis. El 7 de abril, BleepingComputer informaba de que se estaban utilizando tokens de autenticación robados a Anodot para acceder a datos en más de una docena de entornos de clientes de Anodot. El 11 de abril, ShinyHunters había incluido a Rockstar Games en su sitio web de filtraciones con una fecha límite del 14 de abril. La fecha límite expiró. Se filtraron datos parciales.
Esta ha sido la segunda gran campaña de robo de datos relacionada con Snowflake en dos años, y el punto de entrada no fue un usuario afectado ni credenciales expuestas. Se produjo una brecha de seguridad en un proveedor de integración SaaS, se sustrajeron tokens de autenticación y, posteriormente, esos tokens se utilizaron para acceder a datos en múltiples entornos de clientes.
A simple vista, no parece haber ningún problema. Los sistemas implicados funcionaron según lo previsto. El acceso se concedió a través de mecanismos válidos y la actividad se desarrolló por canales legítimos. Por eso este tipo de incidentes se repiten una y otra vez sin que se active la respuesta que deberían.
No se trata de Snowflake
Si echamos la vista atrás al incidente de 2024 que Mandiant identificó como UNC5537, el patrón ya nos resulta familiar. Los atacantes utilizaron credenciales robadas, obtenidas de los registros de programas de robo de información, para acceder a instancias de Snowflake y acceder directamente a los datos. Ninguna de las cuentas afectadas tenía habilitada la autenticación de dos factores (MFA). El 79,7 % de las credenciales utilizadas habían sido expuestas previamente por programas de robo de información.
Lo que cambió en 2026 no fue el resultado, sino el camino.
En el incidente anterior, los atacantes utilizaron credenciales para acceder al sistema y tokens para mantenerse en él. En el incidente de Anodot, empezaron directamente con los tokens.
El acceso directo ha sido sustituido por el acceso indirecto a través de integraciones. El atacante ya no necesita interactuar con el entorno de una forma que genere señales evidentes. La plataforma se convierte en el último eslabón de la cadena, no en el punto donde comienza el problema.
Esto concuerda con lo que ya hemos observado en los recientes incidentes relacionados con la cadena de suministro, en los que la vulneración inicial tiene mucha menos importancia que el uso que se hace del acceso posteriormente.
Si se plantea esto como un problema específico de Snowflake, se pasa por alto el cambio subyacente. El mismo patrón se está observando en el sector del SaaS, cloud y las plataformas de datos. El factor común no es el proveedor, sino la forma en que se concede y se reutiliza el acceso entre los distintos sistemas.
La cadena de suministro ya está operativa
Antes, las integraciones se consideraban como una especie de «tuberías». Transportan datos, automatizan flujos de trabajo y conectan sistemas que, de otro modo, permanecerían aislados.
En la práctica, ahora funcionan como capas de acceso distribuidas.
Una sola integración puede contener tokens de larga duración, funcionar en múltiples entornos y ejecutar acciones en nombre de usuarios o servicios. Cuando esa integración se ve comprometida, el atacante no necesita establecer un punto de acceso. Simplemente se apropia de uno que ya existe y que ya goza de confianza.
Hemos observado un patrón similar en los casos de vulnerabilidades de la cadena de suministro, en los que una acción realizada dentro de un entorno de confianza se traduce inmediatamente en un acceso aprovechable, que luego se reutiliza en distintos sistemas.
Ese acceso suele abarcar:
- plataformas de datos
- sistemas de almacenamiento
- Aplicaciones SaaS
El trasvase entre estos sistemas no requiere nuevas técnicas. Sigue los mismos procedimientos que la empresa utiliza a diario.
En ese momento, el atacante ya no tiene que encargarse del movimiento lateral. La arquitectura lo hace por él.
Los tokens eliminaron discretamente el último obstáculo
El cambio de las credenciales a los tokens es sutil, pero modifica el funcionamiento del acceso.
Los tokens están diseñados para garantizar la persistencia y la automatización. Se emiten una sola vez y se reutilizan sin necesidad de autenticarse repetidamente. Funcionan a través de API, a menudo sin intervención del usuario, y suelen tener una vigencia superior a la de las rotaciones de contraseñas o los reinicios de sesión.
En muchos entornos, tampoco se realiza un seguimiento adecuado de ellos. Los eventos de inicio de sesión se supervisan de cerca. El uso de tokens suele considerarse una actividad secundaria.
Durante las intrusiones relacionadas con Snowflake de 2024, uno de los atacantes describió la situación de una manera que resulta difícil de ignorar:
Aún puedo ejecutar comandos porque tengo el «masterToken» de todas las cuentas 🤣
Ellyel8
Lo importante no es la cita en sí misma, sino cómo se mantuvo ese acceso. Al leer la documentación disponible públicamente, el atacante comprendió cómo funcionaban los tokens y los utilizó para mantener su acceso incluso después de que se hubieran protegido las cuentas.
El hecho de eliminar al atacante no impidió el acceso.
Esto da lugar a una situación en la que el acceso puede mantenerse incluso después de que se hayan tomado medidas correctivas. La cuenta de usuario puede estar protegida, mientras que el token vinculado a una integración permanece activo y sigue proporcionando el mismo nivel de acceso.
Desde el punto de vista de un atacante, se trata de una forma de persistencia más limpia y fiable que cualquier método que implique el uso de malware.
Esa cuenta (la que originó la cita anterior «Todavía puedo ejecutar comandos») estaba gestionada por Connor Riley Moucka, quien fue detenido en Canadá en noviembre de 2024. Su juicio está previsto para el 19 de octubre de 2026. El acceso del que alardeaba siguió vigente a pesar de su detención, ya que los tokens no dependen del operador que los acuñó.
¿Por qué esta actividad encaja perfectamente?
Desde el punto de vista de la detección, hay muy pocos elementos aquí que se asemejen a una intrusión tradicional.
Lo que muestra el entorno concuerda con el funcionamiento habitual:
- los eventos de autenticación son válidos
- Las llamadas a la API siguen los patrones esperados
- las integraciones funcionan dentro del ámbito previsto
Lo que falta es el contexto que conecta esas acciones entre los distintos sistemas.
Un acceso a los datos que, considerado de forma aislada, parece razonable, puede resultar sospechoso cuando se analiza junto con la actividad en otra plataforma. Un token utilizado por una integración puede parecer inofensivo hasta que empieza a acceder a los datos de una forma que no se ajusta al comportamiento habitual.
La mayoría de las herramientas no están diseñadas para ofrecer una visión global que abarque todos los sistemas. Funcionan dentro de un único ámbito, lo que significa que validan acciones individuales, pero rara vez se preguntan cómo se relacionan esas acciones entre sí.
Es en esa brecha donde se produce este tipo de ataque.
Un patrón recurrente, no un incidente aislado
Esta actividad se ha relacionado con la red de extorsión ShinyHunters, que se dedica a monetizar datos robados a gran escala a través de múltiples equipos que operan de forma independiente. Los operadores concretos importan menos que la coherencia de la técnica.
El estudio de Resecurity de enero de 2026 describe a «ShinyHunters» como un alias colaborativo; según señala el informe, «el nombre cambia con mucha frecuencia y de forma intencionada, normalmente por iniciativa de los propios autores, que desean ocultar su autoría». GTIG rastrea la actividad actual en al menos tres grupos distintos: UNC6240 se encarga de la extorsión bajo esta marca; UNC6661 y UNC6671 llevaron a cabo campañas paralelas de vishing en enero de 2026 contra proveedores de identidad, con registradores distintos (NICENIC y Tucows) y tonos de extorsión distintos que sugieren que se trata de operadores separados. La actividad de Anodot/Snowflake es, de nuevo, operativamente distinta. La misma marca. Equipos diferentes.
Lo que tienen en común es lo que define el modus operandi: la autenticación de los usuarios, no la infraestructura. Cualquier operador que tenga acceso a los tokens de una plataforma de integración de uso generalizado puede reproducir el mismo resultado. A medida que más organizaciones recurren a servicios SaaS interconectados, el número de vías de acceso indirectas sigue aumentando.
También hemos visto cómo este tipo de reutilización de accesos puede evolucionar hacia un sistema más automatizado y que se propaga por sí mismo, en el que se aprovechan las relaciones de confianza comprometidas para ampliar el alcance sin necesidad de interacción directa.
Al mismo tiempo, los atacantes están optando por métodos que requieren menos esfuerzo y generan menos alertas. Comprometer a un proveedor externo o recopilar tokens a gran escala ofrece una mayor rentabilidad que intentar infiltrarse en entornos individuales. Por eso los incidentes relacionados con la cadena de suministro son cada vez más frecuentes. Ofrecen un mayor alcance, consistencia y un nivel de sigilo que se adapta a la forma en que se construyen los entornos modernos.
El ataque no es encubierto. Es fragmentado.
Los equipos de seguridad no ignoran esta actividad. Ven parte de ella todos los días:
- Una plataforma de identidad registra una autenticación correcta.
- Una aplicación SaaS registra el uso válido de la API.
- Una plataforma de datos muestra las consultas y exportaciones previstas.
Cada sistema valida lo que observa. Ninguno de ellos relaciona esas acciones.
Ahí es donde este modelo empieza a fallar.
El atacante no necesita eludir la detección en todos los controles. Solo necesita que cada control valide su propia parte de la actividad. Los tokens facilitan esta tarea. Las integraciones la amplían a todos los sistemas. Para cuando se forma el patrón, este ya se extiende a dominios que rara vez se analizan conjuntamente.
Por eso, aunque los incidentes de este tipo parecen estar controlados, los datos siguen saliendo del entorno.
¿Qué se puede hacer al respecto?
Las medidas de seguridad convencionales para la campaña «Snowflake» de 2024 (aplicar la autenticación de dos factores en cloud , rotar las credenciales robadas e incluir el almacén de datos en la lista de permitidos de la red) siguen siendo válidas, pero ya no cubren esta vía de acceso. Los tokens de servicio emitidos por los proveedores no incluyen factores de autenticación de dos factores. Los clientes no pueden rotarlos; solo el proveedor puede hacerlo. El manual de medidas de seguridad de 2024 protege contra el modus operandi de 2024. El modus operandi de 2026 requiere una capa diferente.
Esa capa establece las bases de lo que cada entidad —usuario, entidad de servicio, cliente OAuth— hace realmente a lo largo del tiempo, y se activa cuando el patrón cambia en varios ejes a la vez.
Tres preguntas que debes hacerte sobre tu propio entorno:
- En el caso de cada integración SaaS de terceros con acceso de lectura autenticado entre tenants, ¿sabes cuál es su cadencia habitual de API y su patrón de recursos, con valores de referencia por cada entidad?
- ¿Cuándo se revisó por última vez cada token de proveedor?
- ¿Cuándo fue la última vez que el proveedor los rotó?
El libro electrónico Vectra AI , «Mind Your Attack Gaps», aborda la vulnerabilidad «Authentication succeeds» que aprovecha esta campaña. Si quieres que te expliquemos en una sola conversación cómo se aplica el modus operandi de la cadena de suministro a tu infraestructura específica, ponte en contacto con nosotros.