El 11 de abril de 2026, una publicación en un sitio web de filtraciones bajo el nombre de ShinyHunters reveló que se habían filtrado aproximadamente 80 millones de registros de Rockstar Games. El origen de la filtración no fue Rockstar, sino Anodot, un proveedor de análisis SaaS que formaba parte de la cadena de suministro de Rockstar. Los tokens de autenticación robados de Anodot se utilizaron para consultar plataformas de datos posteriores. Una víctima diferente.
Otro proveedor. El mismo patrón.
Lo importante no es la plataforma en la que se produjo el impacto final, sino cómo se obtuvo y se abusó de ese acceso.
Cada pocos meses, aparece un nuevo titular
Los titulares repiten:
- 2024: Clientes de Snowflake, a través de credenciales obtenidas de los registros de un programa de robo de información que se remontan hasta 2020.
- Agosto de 2025: Clientes de Salesforce , a través de tokens OAuth sustraídos de Salesloft Drift. Google estimó que más de 700 organizaciones dependientes podrían haber quedado expuestas en este incidente relacionado con un único proveedor.
- Noviembre de 2025: De nuevo Salesforce , a través de tokens OAuth de Gainsight que afectan a más de 200 instancias.
- Abril de 2026: De nuevo Snowflake , a través de los tokens Anodot.
- Junio de 2026: De nuevo clientes de Salesforce , a través del backend de integración de Klue. Se utilizó una credencial de cuenta de servicio obsoleta, que nunca se había renovado, para autenticarse en los sistemas de Klue; a continuación, una actualización de código malicioso recopiló tokens OAuth que conectaban Klue con las instancias de Salesforce, Gong, HubSpot y Slack de los clientes. Unos scripts automatizados realizaron consultas a la API REST de Salesforce a un ritmo aproximado de 1.000 llamadas cada 15 minutos durante 24 horas seguidas. Salesforce desactivó la integración de Klue Battlecards el 11 de junio de 2026. Icarus llevó a cabo la intrusión; ShinyHunters reivindicó la autoría en la fase de extorsión. Microsoft registra esta actividad como Storm-3138.
Diferentes puntos de acceso. Diferentes plataformas.
El patrón sigue siendo el mismo porque ShinyHunters no es un grupo concreto. Se trata de una marca que se utiliza en el momento de la extorsión.
La brecha de seguridad de Klue, ocurrida en junio de 2026, ilustra esto a la perfección. Icarus llevó a cabo la intrusión. ShinyHunters se atribuyó la autoría en la fase de extorsión. Operador diferente, misma marca. El registro de auditoría de Salesforce registró llamadas legítimas a la API de aplicaciones conectadas durante todo el proceso. Nada en el entorno del cliente indicaba que se estuviera produciendo una intrusión.
Si lo consideras como un único actor malintencionado, corres el riesgo de buscar en el lugar equivocado. Haz un seguimiento del comportamiento, no de la marca.
El verdadero nexo común
En las campañas atribuidas a ShinyHunters se repiten cuatro métodos de acceso diferentes:
- Se han utilizado credenciales robadas para iniciar sesión
- Ingeniería social a través del servicio de asistencia técnica (vishing) para restablecer la autenticación multifactorial (MFA) y obtener acceso
- Uso indebido de OAuth/tokens a través de proveedores de SaaS comprometidos
- Acceso de invitado mal configurado a los puntos finales de SaaS (vulnerabilidad en el marco Aura de Salesforce mediante consultas GraphQL sin autenticación, documentada en junio de 2026)
Diferentes habilidades, mismo resultado: un acceso válido que se comporta como un usuario o una aplicación legítimos.
Los informes públicos suelen destacar a Snowflake o Salesforce porque es ahí donde, en última instancia, se almacenan los datos. Pero la vía de acceso es la identidad.
En la mayoría de los entornos empresariales, esa identidad se integra en plataformas como Microsoft 365. Esto hace que M365 sea uno de los primeros lugares en los que esta actividad se hace visible. No porque sea el objetivo, sino porque es allí donde opera la identidad comprometida.
Análisis de un ataque al estilo ShinyHunters
Independientemente del método de acceso, el ataque sigue un patrón similar:
- Acceso: inicia sesión con credenciales o tokens válidos.
- Establecer: hacer que ese acceso sea permanente.
- Ampliar: explorar datos en todas las aplicaciones SaaS.
- Exfiltrar: extraer datos de los sistemas posteriores.
Snowflake y otras plataformas similares se sitúan en la última etapa. Todo lo que importa para la detección precoz ocurre antes de eso.
Lo que realmente se puede ver antes de las fases de impacto
Acceso inicial: un inicio de sesión «normal» que no es normal
El inicio de sesión se ha realizado correctamente. Sin embargo:
- La ubicación es nueva
- La conexión procede de una infraestructura VPN o de proxy, como Mullvad, Oxylabs, NetNut o un nodo de salida de Tor.
- Las acciones realizadas tras iniciar sesión no se ajustan al patrón de comportamiento habitual del usuario.
En un proveedor de identidad como Entra ID, esto parece un inicio de sesión válido y correcto. Sin embargo, si se analiza con suficiente contexto, no lo es.
Persistencia: garantizar que el acceso sea duradero
Una vez dentro, el actor se asegura de poder volver:
- Nuevos métodos de MFA incorporados
- Nuevos dispositivos registrados
- Aplicaciones OAuth a las que se ha concedido acceso
Cada acción es legítima por sí sola. Sin embargo, en conjunto, en los minutos posteriores a un nuevo inicio de sesión, cuentan una historia diferente.
Exploración: adentrándonos en el mundo del SaaS
Antes de acceder a los almacenes de datos, los atacantes se cuelan en los sistemas que los empleados utilizan a diario. Para muchas organizaciones, eso significa Microsoft 365 o plataformas SaaS similares:
- Enumeración de SharePoint y OneDrive
- Acceso a bibliotecas de documentos que el usuario nunca ha consultado
- Búsquedas por palabras clave de contenido sensible
- Amplio acceso a archivos
En esta fase, el atacante se plantea una pregunta sencilla: ¿A qué puede acceder esta identidad comprometida?
A continuación, se extienden a otras plataformas SaaS y a los sistemas de datos posteriores.
Métodos diferentes, mismas señales
Esta tendencia se mantiene en los cuatro enfoques:
- Credenciales robadas (2024): inicio de sesión inusual pero exitoso
- Vishing y elusión de la autenticación multifactorial (2025-2026): inicio de sesión seguido de una rápida actividad de persistencia y enumeración de servicios SaaS.
- Vulnerabilidad en el proveedor/OAuth (2025-2026): comportamiento anómalo en el acceso a aplicaciones de confianza.
- Configuración incorrecta del acceso de invitado (2026): gran volumen de llamadas a la API desde un contexto de invitado no autenticado. No se ha producido ningún evento de inicio de sesión que justifique una alerta.
El punto de entrada cambia. El comportamiento tras la autenticación no cambia.
Caso práctico: la filtración de datos de Klue, junio de 2026
La filtración de Klue es el ejemplo más claro de los últimos tiempos sobre el recorrido de la cadena de suministro. El atacante (identificado como Icarus, y del que posteriormente ShinyHunters se atribuyó la autoría con fines de extorsión) utilizó unas credenciales de una cuenta de servicio caducadas, que nunca se habían renovado, para autenticarse en el backend de integración de Klue. No hubo ningún exploit. Las credenciales eran válidas y habían sido emitidas por la propia organización. No se detectó ninguna anomalía en el inicio de sesión.
A continuación, una actualización de código malicioso recopiló tokens OAuth que conectaban Klue con las instancias de Salesforce, Gong, HubSpot y Slack de los clientes. Los tokens se transfirieron a través de canales cifrados. Parecía una implementación de código rutinaria. No se detectó ninguna malware . A partir de ahí, unos scripts automatizados en Python realizaron consultas a la API REST de Salesforce a un ritmo de aproximadamente 1.000 llamadas cada 15 minutos durante 24 horas seguidas. Cada llamada a la API se autenticaba con un token válido, indistinguible del tráfico normal de integración. Se produjo una filtración masiva de datos del CRM.
Salesforce desactivó la integración con Klue Battlecards el 11 de junio. Recorded Future, Tanium, Jamf y Huntress figuraban entre las organizaciones notificadas. Microsoft identificó el grupo como «Storm-3138» en su comunicado del 13 de julio de 2026.
Sobre la cuestión de la atribución: el análisis anterior atribuye correctamente esta operación a Icarus como operador. El hecho de que ShinyHunters se atribuya la autoría durante la extorsión no supone una corrección de dicha atribución. Esa es precisamente la cuestión. La marca se aplica en el momento de la extorsión, sea quien sea quien lleve a cabo la operación. Deja la atribución al operador Icarus en la diapositiva y añade una nota indicando que ShinyHunters se atribuyó el mérito en el momento de la extorsión, porque esa distinción es precisamente en lo que se basa el argumento de «rastrear el comportamiento, no la marca».
Dónde Vectra AI
Las campañas de ShinyHunters tienen éxito porque utilizan un acceso legítimo: credenciales reales, flujos de autenticación multifactorial (MFA) reales, tokens OAuth reales y aplicaciones reales. La mayoría de los controles de seguridad están diseñados para detener a los atacantes antes de la autenticación. Estas campañas tienen éxito después.
Vectra AI el comportamiento de los atacantes tras una autenticación correcta, tanto en el ámbito de la identidad como en el de los servicios SaaS, cloud y la red. La pregunta no es«¿cómo se obtuvo el acceso?», sino: «¿se ajustan las acciones de la identidad a su perfil de comportamiento?».
Cómo se correlaciona la detección con el patrón de ataque
Acceso: un inicio de sesión válido desde una nueva ubicación, a través de una infraestructura de proxy, que no se ajusta al perfil de referencia de la identidad.
Configuración: métodos de autenticación multifactorial añadidos, dispositivos registrados y aplicaciones OAuth autorizadas, inmediatamente después de iniciar sesión.
Ampliar: actividad correlacionada entre Microsoft 365, Salesforce y otras plataformas SaaS, lo que permite identificar cuentas que están explorando nuevas vías como nunca antes lo habían hecho.
Exfiltración: las descargas masivas y la extracción de datos a través de la API se revelaron como el final de una secuencia, no como sucesos aislados.
¿Por qué esto funciona en todos los métodos?
No importa cómo se haya obtenido el acceso: ya sea mediante credenciales robadas, una llamada al servicio de asistencia o un token de un proveedor comprometido. El atacante sigue teniendo que iniciar sesión, establecer persistencia, explorar el sistema y sustraer datos. Este patrón de comportamiento es inevitable. Y eso es precisamente lo que Vectra está diseñada para detectar.
Reducir la brecha en la detección
Las recomendaciones habituales siguen siendo importantes: autenticación multifactorial (MFA) phishing, rotación de credenciales, revisión de los ámbitos de OAuth y verificación de identidad en el servicio de asistencia técnica (véanse las recomendaciones de refuerzo de seguridad de GTIG para UNC6040 y el aviso FLASH del FBI). Pero ya no basta con eso. Las campañas actuales están diseñadas para eludir esos controles.
La detección no falla. Es incompleta.
ShinyHunters no es un único grupo. Se trata de un patrón de ataques basado en una idea: si la autenticación se lleva a cabo con éxito, el atacante puede hacerse pasar por una identidad legítima.
Las primeras señales no aparecen en la plataforma de datos mencionada en los titulares. Aparecen en las plataformas de identidad y SaaS, donde el atacante debe actuar en primer lugar. El problema no es la visibilidad, sino que la detección se inicia en el punto equivocado del ataque.
En mi libro electrónico «Mind Your Attack Gaps», describo tres brechas de detección. ShinyHunters se centra en la brecha n.º 2: la autenticación se realiza con éxito. Credenciales reales, códigos de un solo uso reales, tokens OAuth reales, cookies de sesión reales. El registro de auditoría recoge un inicio de sesión correcto.
La guía de medidas de seguridad de 2024 sigue siendo válida, pero ya no abarca la vía de acceso.