Durante un año, un grupo de extorsión de datos ha entrado en decenas de entornos de Salesforce sin explotar ni un solo fallo de la plataforma. La vía de entrada ha sido la confianza que la propia organización ya había concedido: las conexiones OAuth que unen Salesforce con las apps y los proveedores de su alrededor. El 13 de julio de 2026, Microsoft publicó un análisis que ordena esa campaña —atribuida a la actividad de ShinyHunters— en tres caminos distintos, ninguno de los cuales deja rastro en los registros de inicio de sesión. Si usas Salesforce (o cualquier SaaS con apps conectadas), el problema te aplica.
El dato interesante es el mismo que atraviesa todo el caso: no hubo malware, ni contraseñas robadas reutilizadas, ni un exploit contra Salesforce. Hubo apps conectadas aprobadas, tokens de proveedores legítimos y permisos de invitado mal configurados. Cuando el acceso llega desde un usuario real que aprobó una integración, o desde un proveedor en el que la empresa ya confía, el tráfico se lee como uso normal y la monitorización de identidad apenas lo registra.
Según el blog de seguridad de Microsoft, recogido por The Hacker News, las campañas van de mediados de 2025 a mediados de 2026 y se han visto en sectores como el comercio minorista, la educación y la industria. Lo que sigue es la anatomía a nivel conceptual —sin recetas replicables— y, sobre todo, qué mirar y qué cerrar en tu propio entorno.
Tres caminos, ningún exploit
Microsoft agrupa la actividad en tres vías de intrusión: llamadas de voz (vishing) que engañan a un empleado para que apruebe una app conectada maliciosa; tokens OAuth robados a proveedores de software comprometidos; y acceso de invitado mal configurado en sitios de Salesforce. Cada una encaja con un incidente real del último año, y las tres comparten una característica: lo que importa no es cómo se entra, sino lo que la app o la cuenta hace una vez dentro.
1. La llamada de teléfono
Es la vía que arrancó todo. Desde mediados de 2025, los actores llamaban por teléfono haciéndose pasar por soporte informático y guiaban al empleado por la pantalla de consentimiento OAuth de Salesforce hasta que autorizaba una app conectada controlada por el atacante, disfrazada de la propia herramienta Data Loader de Salesforce. Concedido el consentimiento, la app podía hacer llamadas a la API en nombre de ese usuario: enumerar los datos de la organización, mantener acceso persistente al CRM y buscar credenciales que abrieran otras plataformas SaaS.
Sin malware y sin reutilizar una contraseña robada. Solo una llamada y un clic de consentimiento —por eso esquiva el MFA: el atacante no inicia sesión, hereda la sesión de la app que el usuario aprobó—. Es la campaña que el Grupo de Inteligencia de Amenazas de Google (GTIG) y Mandiant documentaron a mediados de 2025, siguiendo el acceso inicial como UNC6040 y la extorsión posterior como UNC6240; ambos se hacían pasar por ShinyHunters para presionar más a las víctimas. Google confirmó que una de sus propias instancias de Salesforce fue alcanzada en junio de 2025, con robo de datos de contacto en su mayoría públicos antes de cortar el acceso.
2. Tokens robados a proveedores de confianza
La segunda vía se salta al empleado. En lugar de engañar a un usuario, los atacantes comprometen a un proveedor cuyo software ya tiene acceso OAuth a los Salesforce de sus clientes, roban los secretos o tokens de esa conexión y los usan para consultar y exportar datos de muchas instancias a la vez. Como el tráfico procede de una integración aprobada, no dispara alarmas de inicio de sesión y se confunde con la automatización normal.
El caso más claro es el compromiso de Salesloft Drift, en agosto de 2025: los atacantes robaron tokens OAuth y de refresco de la integración de chat con IA y los volvieron contra los entornos de sus clientes. Google estimó que el robo expuso potencialmente a más de 700 organizaciones, según el análisis de Arctic Wolf; rastrea el grupo como UNC6395 y Cloudflare lo llama GRUB1. Salesloft situó después la causa raíz en el acceso del atacante a su cuenta de GitHub ya en marzo de 2025, usada para llegar a su entorno en AWS y cosechar los tokens; una vez dentro, los operadores lanzaban consultas para peinar casos de soporte en busca de claves de AWS, tokens de Snowflake y contraseñas, y borraban sus trabajos de consulta para entorpecer la investigación.
El patrón se repitió con Gainsight en noviembre de 2025 —Salesforce retiró las apps publicadas por el proveedor tras detectar actividad de API inusual, y GTIG lo vinculó a afiliados de ShinyHunters en más de 200 instancias— y con Klue en junio de 2026, donde el punto de entrada fue una credencial heredada de una integración anterior que seguía activa. Es un patrón común en cualquier organización con años de integraciones acumuladas, y precisamente por eso resulta instructivo: las credenciales que sobreviven a su propósito rara vez aparecen en los inventarios. Microsoft rastrea al actor de Klue como Storm-3138, aunque buena parte de la industria atribuye esa extorsión a un grupo que se llama Icarus, y una cuenta que dice ser ShinyHunters también se atribuyó el mérito. Las etiquetas se solapan porque estas identidades se reclaman de forma oportunista; conviene tenerlo presente al cruzar informes.
El propio grupo afirmó que las oleadas de Salesloft y Gainsight juntas alcanzaron cerca de 1.000 organizaciones, y en su portal de filtraciones sigue publicando presuntas víctimas y cifras de registros de muchos millones. Son afirmaciones del atacante que no están verificadas de forma independiente, y como tales conviene tratarlas. Un análisis de la Cloud Security Alliance ordena este mismo conjunto de campañas como un abuso sistemático del OAuth en la cadena de suministro del SaaS, más que como incidentes aislados.
3. Acceso de invitado mal configurado
La tercera vía no necesita credenciales. Microsoft observó un repunte de actividad sospechosa de usuarios invitados contra los endpoints Aura de Salesforce, el marco que hay detrás de los sitios de Experience Cloud. Donde los permisos del rol de invitado estaban mal configurados, los actores alcanzaban funcionalidad de Aura sin autenticarse y, mediante paginación por cursor, extraían registros muy por encima del límite estándar de 2.000 por consulta. No hubo exploit: la organización había dejado que el rol de invitado viera más de lo que debía, y lo leyeron por todo lo que valía.
Por qué la monitorización de identidad de siempre no lo ve
Aquí está el fondo del asunto. Los controles de identidad que la mayoría de las empresas ha construido en la última década se diseñaron para inicios de sesión humanos: MFA, acceso condicional y políticas de sesión. Pero las apps OAuth, las cuentas de integración y las credenciales de servicio que hacen el trabajo real en un Salesforce moderno son identidades no humanas y quedan, en su mayoría, fuera de todo eso: sin vigilar y con permisos excedidos.
Por eso ni el inicio de sesión ni la autenticación disparan nada. La señal que sí existe vive en lo que ocurre después del acceso: qué app conectada hizo la llamada, qué permisos OAuth tiene, cuánto está consultando y si algo de eso es normal para ese entorno. Ese es justo el plano que la mayoría del registro de Salesforce no fue pensado para mostrar, y donde se produce la exfiltración de datos.
Detección: mirar lo que hace la app, no el inicio de sesión
La detección eficaz aquí es de comportamiento y atribución, no de firmas. Microsoft trabajó con Salesforce para exponer esa señal en Defender for Cloud Apps: para quienes usan Salesforce Shield Event Monitoring, el conector actualizado incorpora la monitorización de eventos en tiempo casi real y añade atribución por app conectada, es decir, ata cada actividad a una identidad de app concreta y a los permisos OAuth que tiene concedidos, con más contexto de sesión y de API.
Junto a la detección, se añadieron capacidades de postura y gobierno para las apps OAuth: una vista de las apps muy privilegiadas que acumulan permisos elevados, una forma de sacar a la luz las apps inactivas —sin uso desde hace 90 días o más pero con permisos vivos— y una puntuación de riesgo de 0 a 100 por app que se puede enlazar con alertas y políticas. En la práctica, señales a vigilar: picos de consultas o exportaciones masivas por parte de una integración, apps con permisos amplios que casi no se usan, y cualquier cambio de comportamiento de un proveedor conectado. Un SOC gestionado con visibilidad de SaaS y capacidad de caza de amenazas es quien convierte esas señales en detección.
Defensa práctica
La mitigación duradera es la de siempre, aplicada a un terreno que se había quedado sin vigilancia. Inventaría las apps conectadas, corta las que nadie usa, ajusta el resto al mínimo privilegio y prepárate para revocar y rotar tokens en cuanto una integración se comporte de forma extraña. Restringe qué apps conectadas se pueden aprobar (aprobación por administrador en lugar de consentimiento libre del usuario) y limita el acceso por IP y por perfil. Es, en esencia, gobierno de identidades no humanas y gestión del riesgo de terceros llevados al SaaS.
Para las dos vías que no dependen del empleado, dos frentes concretos: bloquea y revisa el acceso de invitado de Experience Cloud para que el rol no exponga más de lo imprescindible; y trata los tokens OAuth que un proveedor tiene sobre tu Salesforce como lo que son, un acceso privilegiado de un tercero, con revisión periódica y rotación. Y como la primera vía es una llamada de teléfono, la defensa más barata es de proceso: ante una petición de soporte que empuja a aprobar una app o a dar acceso, la regla es colgar y devolver la llamada por un canal conocido. Refuerza la concienciación sobre ingeniería social y vishing en quien administra el CRM, no solo en el usuario final.
Nada de esto es exclusivo de Salesforce. El mismo razonamiento vale para Microsoft 365 y cualquier suite con apps conectadas; de hecho, la mecánica de heredar la sesión sin tocar la contraseña es prima del robo de tokens que vimos en el secuestro de cuentas de Microsoft 365. Y el eslabón del proveedor comprometido es el mismo que recorre las lecciones de la cadena de suministro digital y los avisos sobre credenciales comprometidas de integraciones olvidadas.
Cumplimiento: terceros, DORA y NIS2
El ángulo regulatorio es directo. Bajo DORA, las entidades financieras deben gestionar el riesgo de sus proveedores TIC y vigilar las dependencias con terceros; una integración SaaS con tokens OAuth sobre tu CRM es exactamente ese tipo de dependencia. NIS2 empuja en la misma dirección para las entidades esenciales e importantes: gestión del riesgo de la cadena de suministro y control de identidades y accesos como medidas mínimas. Un token de un proveedor que puede exportar tu CRM no es un detalle técnico menor: es un riesgo de terceros que un regulador esperaría ver gestionado.
El puente conceptual con el gobierno de identidades no humanas lo desarrollamos al comparar SPIFFE/SPIRE frente a OAuth en entornos cloud-native y al hablar de cómo blindar cuentas de servicio, tokens y API keys. La campaña de Salesforce es la versión SaaS del mismo problema: la identidad que trabaja de verdad no es la persona, es la app.
Lo que de verdad falla
La conclusión no es que Salesforce sea inseguro —no se explotó la plataforma— ni que un proveedor concreto fuera negligente. Es que el modelo de identidad que casi todas las empresas dan por bueno vigila a las personas y deja sin vigilancia a las apps, los tokens y las cuentas de integración que mueven los datos. Los atacantes que entendieron esto lo explotaron durante un año y, más de una vez, la puerta de entrada fue simplemente una credencial que alguien olvidó desactivar. La pregunta que deja el caso es corta: ¿sabes qué apps conectadas tienen permiso sobre tu SaaS, quién las aprobó y qué pueden llevarse?
Sobre las fuentes y la atribución: los incidentes citados se basan en divulgaciones públicas de las propias empresas afectadas, en comunicaciones de Salesforce y en informes de equipos de inteligencia de amenazas, con la información disponible en la fecha de publicación. Ninguna de las menciones implica un fallo de seguridad en los productos citados: el vector descrito es el abuso de accesos concedidos y la mala configuración. Las atribuciones a grupos concretos pueden evolucionar —las etiquetas de estos actores se solapan y se reclaman de forma oportunista— y las cifras difundidas por los propios atacantes no están verificadas de forma independiente.
Nota: este artículo incluye orientaciones de detección y gobierno de apps conectadas aplicables a entornos SaaS. Valídalas en un entorno controlado y adáptalas a tu configuración y a tu marco de cumplimiento antes de aplicarlas en producción.