En julio de 2026, Microsoft detalló cómo la banda de extorsión ShinyHunters se pasó un año drenando en silencio tenants de Salesforce en los sectores minorista, sanitario, aeronáutico y tecnológico, y lo hizo sin descifrar una sola contraseña. La campaña ShinyHunters Salesforce OAuth abusó de lo único que la autenticación multifactor nunca fue diseñada para detener: un usuario que voluntariamente pulsa «Permitir». Donde brechas anteriores robaban credenciales, esta robó confianza, engañando a los empleados para que autorizaran una connected app maliciosa que luego conservaba un token de API válido de forma indefinida.
Esa distinción importa a cualquiera que gestione un stack SaaS. Los atacantes rara vez tocaron la pantalla de inicio de sesión, así que las solicitudes de MFA, las reglas de viaje imposible y las alertas de acceso permanecieron mayormente en silencio. Si tu modelo de seguridad asume «tenemos MFA, así que estamos cubiertos», esta campaña es el caso práctico que demuestra lo contrario.
Qué ocurrió realmente
Entre mediados de 2025 y mediados de 2026, ShinyHunters (rastreado por Mandiant de Google como UNC6040 para la actividad de vishing y UNC6395 para el robo de tokens) llevó a cabo una operación a escala industrial contra clientes de Salesforce. El resumen de The Hacker News de la inteligencia de amenazas de Microsoft cifra las reclamaciones de los afiliados en cerca de 1,000 organizaciones afectadas, aunque muchas siguen sin confirmarse. El botín eran datos de CRM —registros de clientes, tickets de soporte, listas de contactos— que el grupo utilizaba después para la extorsión, amenazando con filtrarlos salvo que las víctimas pagaran.
La parte ingeniosa era la persistencia. Un token OAuth robado no caduca cuando se restablece una contraseña ni cuando el empleado víctima del phishing cambia su dispositivo de MFA. Como señaló Microsoft, la mayor parte del registro de Salesforce «no se construyó para mostrar» lo que sucede tras la autorización, de modo que las llamadas de API maliciosas se camuflaban entre el tráfico de automatización normal durante semanas.
Las tres vías de entrada
Microsoft y el equipo de inteligencia de amenazas de Google Cloud describen tres rutas de entrada distintas, todas las cuales terminan en el mismo punto: una concesión OAuth controlada por el atacante.
| Vía de ataque | Cómo funcionaba | Detalle clave |
|---|---|---|
| Phishing de voz (vishing) | Los que llamaban se hacían pasar por soporte de TI y guiaban a los empleados por la pantalla de consentimiento OAuth de Salesforce | Las víctimas autorizaban una app maliciosa que suplantaba a Data Loader de Salesforce, a veces renombrada «My Ticket Portal» |
| Robo de tokens en la cadena de suministro | Los atacantes vulneraban integraciones de confianza y reutilizaban sus tokens OAuth contra tenants posteriores | Salesloft/Drift (ago 2025), Gainsight (nov 2025) y Klue (junio 2026); las informaciones sitúan la exposición posterior en 700+ y 200+ organizaciones respectivamente |
| Acceso de invitado mal configurado | Roles de invitado de Experience Cloud con permisos excesivos permitían a usuarios no autenticados leer datos | Los actores usaban paginación de GraphQL para eludir el límite de consulta de 2,000 registros |
La vía del vishing es el titular porque no necesita ninguna vulnerabilidad de software en absoluto: solo una llamada telefónica convincente y un administrador distraído. La vía de la cadena de suministro es posiblemente peor: una única brecha en un proveedor como Salesloft entregaba a los atacantes un llavero completo hacia cientos de organizaciones cliente que nunca cometieron un error por sí mismas.
Por qué el abuso de OAuth pasa de largo ante la MFA
Este es el detalle que la mayoría de las coberturas pasa por alto, y es la razón por la que la campaña funcionó durante tanto tiempo. El consentimiento OAuth está diseñado para delegar acceso. Cuando un empleado aprueba una connected app, Salesforce emite un token de larga duración que permite a esa app llamar a la API en nombre del usuario, sin inicios de sesión repetidos ni un nuevo desafío de MFA. Ese es el propósito íntegro de OAuth, y por eso «basta con activar la MFA» no es una defensa aquí.
Una vez que el token existe, el atacante opera como una aplicación de confianza, no como un inicio de sesión sospechoso. No hay geolocalización anómala que señalar porque las llamadas de API se originan en la propia infraestructura de la app. Las políticas de riesgo de inicio de sesión nunca se activan porque no hay inicio de sesión. La rotación de contraseñas no sirve de nada porque no hay ninguna contraseña implicada. Revocar el token es el único interruptor de emergencia real, y solo puedes revocar lo que puedes ver, que es precisamente lo que el registro predeterminado de Salesforce dificultaba. Es la misma lección de que «la identidad es el nuevo perímetro» que hay detrás de las migraciones a zero trust: el borde de la red es irrelevante cuando el atacante llega con una credencial válida en la mano.
A quién golpeó
La lista de víctimas se lee como un quién es quién corporativo. Las informaciones públicas y las publicaciones en sitios de filtraciones vinculan la actividad más amplia de ShinyHunters en Salesforce con Google, Cloudflare, Zscaler, Palo Alto Networks, Proofpoint, Qantas, Allianz Life, Adidas, Chanel, Pandora y varias marcas de LVMH, entre otras. Los proveedores de seguridad no se libraron: Tanium, Huntress y Recorded Future también aparecen en las informaciones, un recordatorio contundente de que el riesgo del consentimiento OAuth es universal, no un problema de empresas pequeñas.
El sector sanitario atrajo una atención específica. Health-ISAC publicó orientación de mitigación después de que la actividad del grupo se extendiera al sector, y el regulador financiero FINRA publicó su propia alerta sobre Salesforce Experience Cloud que abarca la vía de la mala configuración del acceso de invitado.
Cómo blindar el consentimiento OAuth en tu propia organización
La solución es de gobernanza, no un parche, y se aplica a cualquier plataforma SaaS que admita la autorización de aplicaciones de terceros (Google Workspace y Microsoft 365 tienen la misma exposición). Una lista de comprobación práctica:
- Restringe quién puede dar consentimiento. Desactiva el consentimiento OAuth por parte del usuario final y encamina todas las nuevas aprobaciones de connected apps a través de una cola de revisión del administrador. En Salesforce, bloquea los ajustes de «Connected Apps OAuth Usage»; en Microsoft 365, usa políticas de consentimiento de aplicaciones y acceso condicional.
- Inventaría y depura las concesiones existentes. Revisa cada connected app autorizada y revoca todo lo que esté sin usar, no reconocido o inactivo. Un token de una app cuya instalación nadie recuerda es tu mayor riesgo.
- Vigila los registros correctos. Los registros de inicio de sesión no detectarán esto. Monitoriza en su lugar los eventos de autorización OAuth, el volumen de llamadas de API de las connected apps y los patrones de exportación masiva de datos. Las lecturas masivas repentinas desde una app poco usada son la señal reveladora.
- Forma al personal sobre el vishing en la pantalla de consentimiento. El clic final es humano. Asegúrate de que los empleados saben que TI nunca les telefoneará para guiarles por una solicitud OAuth de «Permitir».
- Examina a tus proveedores de integración. Las brechas de Salesloft y Gainsight demuestran que tu seguridad en Salesforce es solo tan fuerte como los terceros a los que has concedido tokens: la misma lección de la cadena de suministro que la crisis de la cadena de suministro de npm Shai-Hulud.
Preguntas frecuentes
¿ShinyHunters explotó una vulnerabilidad de Salesforce?
No. No hubo ningún fallo en Salesforce en sí. Los atacantes abusaron del consentimiento OAuth legítimo y del acceso de invitado mal configurado: un caso de funciones que trabajan según lo diseñado siendo vueltas contra los usuarios.
¿La MFA habría detenido esto?
No por sí sola. La MFA protege el inicio de sesión, pero el abuso de tokens OAuth ocurre después de que un usuario ya haya autorizado una app. La defensa es la gobernanza del consentimiento y la monitorización de tokens, no factores de inicio de sesión más fuertes.
¿Qué es una «connected app» en este contexto?
Es una aplicación de terceros a la que se concede acceso de API a una organización de Salesforce mediante OAuth. Las legítimas (Data Loader, herramientas de analítica) son habituales, que es justo por lo que un clon malicioso se cuela.
¿Cómo sé si me vi afectado?
Audita tus connected apps autorizadas y tus concesiones OAuth, revoca todo lo que no te resulte familiar y revisa los registros de llamadas de API en busca de exportaciones masivas inusuales. Si usas Salesloft, Gainsight o Klue, trata sus incidentes divulgados como un motivo para rotar tokens.
¿Es este solo un problema de Salesforce?
No. Cualquier plataforma SaaS con OAuth de terceros —Google Workspace, Microsoft 365, Slack, GitHub— conlleva el mismo riesgo de phishing de consentimiento. El manual anterior es independiente de la plataforma.
Sources
- Microsoft Security — Defensa de aplicaciones basadas en SaaS frente al abuso de OAuth de ShinyHunters (13 de julio de 2026) — divulgación primaria de inteligencia de amenazas y recomendaciones defensivas.
- The Hacker News — Microsoft cartografía un año de actividad de ShinyHunters — resumen de las vías de ataque, la escala y las informaciones sobre víctimas.
- Google Cloud Threat Intelligence — Defensa proactiva contra la extorsión SaaS de ShinyHunters — seguimiento de UNC6040/UNC6395 y orientación de detección.
- Varonis — Amenaza de vishing en Salesforce (UNC6040) — mecánica de la suplantación de Data Loader.
- Mitiga — ShinyHunters y UNC6395: las brechas de Salesforce y Salesloft — detalle del robo de tokens en la cadena de suministro.
- Health-ISAC — Impacto de ShinyHunters en el sector sanitario — orientación de mitigación para el sector.
- FINRA — Alerta de seguridad sobre Salesforce Experience Cloud — vía de la mala configuración del acceso de invitado.
Waqas Ahmed Waseer
Waqas Ahmed Waseer es desarrollador y creador de automatizaciones con más de 8 años construyendo sistemas en producción que usan más de 100.000 personas. Crea SaaS multiinquilino a medida, automatización con IA (n8n, flujos LLM, bots de WhatsApp) e infraestructura de hosting (WHM/cPanel, CloudLinux), y es el creador de WaSphere, FlowMaticX y la marca de hosting WaseerHost. Más de 100 proyectos entregados para pymes, agencias y startups financiadas.
