Grupos vinculados a ShinyHunters han vulnerado entornos de Salesforce sin explotar fallos técnicos, sino abusando de la confianza en conexiones OAuth. Utilizaron vishing a empleados, robo de tokens de proveedores externos y configuraciones incorrectas de acceso para invitados. Microsoft y Salesforce han lanzado nuevas herramientas de monitoreo y gobernanza para detectar este tráfico, que suele pasar desapercibido al imitar el uso legítimo de aplicaciones integradas.

Los atacantes cuyos métodos coinciden con el grupo de extorsión de datos ShinyHunters han pasado el último año entrando en entornos corporativos de Salesforce sin explotar ni una sola falla en la plataforma.

La vía de entrada ha sido la confianza que la organización ya había otorgado, generalmente a través de las conexiones OAuth que vinculan Salesforce con las aplicaciones y proveedores externos que lo rodean.

En una investigación publicada el 13 de julio Microsoft mapeó las campañas, que se extendieron desde mediados de 2025 hasta mediados de 2026, en tres técnicas distintas. También trabajó con Salesforce para implementar nuevas herramientas de detección y gobernanza destinadas a abordar la actividad que los registros de autenticación pasan por alto.

Eso es lo que hace que sea difícil de detectar. Cuando el acceso proviene de un usuario real que aprobó una aplicación conectada, o de una integración en la que la empresa ya confía, el tráfico se lee como un uso ordinario, y el monitoreo de inicio de sesión y autenticación apenas lo registra.

Lo que importa es lo que hace la aplicación o cuenta una vez que está dentro, y eso es exactamente lo que la mayoría de los registros de Salesforce no fueron diseñados para mostrar.

Microsoft agrupa la actividad en tres rutas de intrusión:

* llamadas de vishing que engañan a los empleados para que aprueben una aplicación conectada maliciosa,
* tokens de OAuth robados de proveedores de software comprometidos, y
* acceso de invitados mal configurado en sitios de Salesforce.

Cada una se corresponde con un incidente de Salesforce del último año, y Microsoft afirma haber visto esta actividad en clientes de industrias como el comercio minorista, la educación y la fabricación.

La llamada telefónica

La primera ruta es la que inició todo el proceso. A partir de mediados de 2025, los actores realizaron llamadas de phishing de voz (vishing) haciéndose pasar por soporte técnico de TI y guiaron a los empleados a través de la pantalla de consentimiento de OAuth de Salesforce, logrando que autorizaran una aplicación conectada controlada por el atacante y disfrazada como la herramienta Data Loader de Salesforce.

Una vez concedido el consentimiento, la aplicación podía realizar llamadas a la API como ese usuario, permitiendo a los atacantes enumerar los datos de Salesforce de la organización, mantener un acceso persistente a los registros de CRM y buscar credenciales que pudieran abrir la puerta a otras plataformas SaaS.

Sin malware, sin repetición de contraseñas robadas. Solo una llamada telefónica y un clic de consentimiento.

Esta es la campaña que el Grupo de Inteligencia de Amenazas de Google (GTIG) y Mandiant documentaron a mediados de 2025, rastreando el acceso inicial como UNC6040 y la extorsión posterior como UNC6240, ambos alegando ser ShinyHunters para presionar más a las víctimas.

Google confirmó que una de sus propias instancias corporativas de Salesforce fue afectada en junio de 2025, y los atacantes tomaron datos de contacto comercial mayormente públicos antes de que Google los bloqueara. La misma ola se vinculó públicamente a brechas en Chanel y Pandora, y también se nombró como objetivos a Adidas, Qantas, Allianz Life y varias marcas de LVMH.



El consejo de Mandiant para los defensores fue contundente: estas llamadas explotan el instinto de ayuda de un centro de soporte, los controles de identidad estándar a menudo no se aplican, y la medida segura es colgar y volver a llamar a través de un canal conocido y confiable.

Tokens robados de proveedores confiables

La segunda ruta ignora por completo al empleado. En lugar de hacer phishing a un usuario, los atacantes comprometen a un proveedor externo cuya aplicación ya tiene acceso OAuth a las organizaciones de Salesforce de sus clientes, roban los secretos o tokens de conexión y los utilizan para consultar y exportar datos de muchas instancias simultáneamente.

Debido a que el tráfico proviene de una integración aprobada, no activa las alarmas de inicio de sesión y se mezcla con la automatización normal.

Microsoft señala tres incidentes aquí. El compromiso de Salesloft Drift en agosto de 2025 es el más grande y claro: los atacantes robaron tokens de OAuth y de actualización vinculados a la integración de chat de IA de Drift y los utilizaron contra los entornos de clientes de Salesforce.

Google estimó que el robo de tokens de Drift expuso potencialmente a más de 700 organizaciones, entre ellas Cloudflare, Zscaler, Palo Alto Networks, Proofpoint, PagerDuty y Tanium. Google rastrea el grupo como UNC6395; Cloudforce One de Cloudflare lo llama GRUB1.

Salesloft rastreó posteriormente la causa raíz hasta el acceso del atacante a su cuenta de GitHub ya en marzo de 2025, que se utilizó para llegar al entorno de AWS de Drift y recolectar los tokens. Los operadores buscaban secretos, ejecutando consultas SOQL para filtrar casos de soporte y otros objetos en busca de claves de AWS, tokens de Snowflake y contraseñas, eliminando luego sus trabajos de consulta para retrasar a cualquier investigador.

El incidente de Gainsight de noviembre de 2025 siguió la misma jugada contra un proveedor diferente. Salesforce retiró las aplicaciones publicadas por Gainsight tras detectar una actividad API inusual, y GTIG vinculó la campaña a afiliados de ShinyHunters en más de 200 instancias afectadas de Salesforce.

Las personas detrás del nombre ShinyHunters afirmaron que las olas de Salesloft y Gainsight juntas alcanzaron cerca de 1,000 organizaciones, una cifra que no ha sido confirmada independientemente.

El caso más reciente, de junio de 2026, es el compromiso de Klue. Los atacantes entraron en la plataforma de inteligencia competitiva a través de una credencial heredada, largamente en desuso pero aún activa, que quedó de una integración de prueba que nunca se desplegó; enviaron una actualización de código que recolectó los tokens OAuth de los clientes y los usaron para acceder a datos de Salesforce y Gong pertenecientes a clientes de Klue, incluidos Huntress y Recorded Future.

Microsoft rastrea al actor de Klue como Storm-3138. Un detalle en la nomenclatura para quien compare informes: la mayor parte de la industria, incluidos Huntress y Datadog, vinculan la extorsión de Klue a un grupo que se hace llamar Icarus, y una cuenta de Telegram que afirma ser ShinyHunters también se adjudicó el ataque.

Las etiquetas se confunden porque estas identidades se superponen y se reclaman oportunamente, lo cual ocurre en todo este conjunto de campañas.

Acceso de invitados dejado abierto

La tercera ruta no necesita credenciales en absoluto. Microsoft observó un aumento en la actividad sospechosa de usuarios invitados contra los endpoints de Salesforce Aura, el framework detrás de los sitios de Experience Cloud. Donde los permisos de usuario invitado estaban mal configurados, los actores alcanzaron la funcionalidad de Aura sin autenticarse.

Llamando al controlador Aura de GraphQL, utilizaron la paginación basada en cursor para extraer registros más allá del límite estándar de consulta de 2,000 registros, llevándose mucho más de lo que el rol de invitado debía exponer.

La detección de Microsoft señala el uso de herramientas de AuraInspector para sondear estos endpoints. No hubo ningún exploit involucrado. La organización había dejado que el rol de invitado pudiera ver más de lo debido, y los actores lo aprovecharon al máximo.

Lo que microsoft y salesforce lanzaron para detectarlo

La señal que sí existe reside en lo que sucede después del acceso: qué aplicación conectada realizó una llamada, qué alcances (scopes) de OAuth posee, cuánto está consultando y si algo de eso es normal para el cliente.

Microsoft trabajó con Salesforce para hacer visible exactamente eso en Defender for Cloud Apps. Para los clientes que utilizan Salesforce Shield Event Monitoring, el conector de Salesforce actualizado incorpora el framework de Monitoreo de Eventos en Tiempo Real para una detección casi instantánea y añade la atribución de aplicaciones conectadas, vinculando la actividad a una identidad de aplicación específica y sus alcances de OAuth concedidos, junto con más contexto de sesión y API.

Junto con la detección, Microsoft añadió funciones de postura y gobernanza para aplicaciones OAuth conectadas: una vista de aplicaciones altamente privilegiadas con alcances elevados, una forma de detectar aplicaciones no utilizadas que han estado inactivas durante 90 días o más manteniendo permisos activos, y una puntuación de riesgo de 0 a 100 por aplicación que los equipos pueden vincular a alertas y políticas.

El objetivo es encontrar las integraciones olvidadas y con exceso de permisos antes de que alguien más lo haga.

Reduciendo la superficie de ataque oauth

La guía de Microsoft es práctica y coincide con lo que dijeron los proveedores después de cada incidente: conecta tus instancias de Salesforce a Defender for Cloud Apps para obtener telemetría adicional, activa y vigila realmente los registros de eventos de Salesforce, y bloquea el acceso de usuarios invitados de Experience Cloud.

Más allá de los pasos específicos del producto, las soluciones duraderas son las habituales. Haz un inventario de las aplicaciones conectadas, elimina las que nadie use, limita el resto al principio de menor privilegio y prepárate para revocar y rotar tokens en el momento en que una integración comience a comportarse de manera extraña.

El patrón en las tres rutas es el mismo. Los controles de identidad que la mayoría de las empresas pasaron la última década construyendo fueron diseñados para inicios de sesión humanos: MFA, acceso condicional y políticas de sesión. Las aplicaciones OAuth, las cuentas de integración y las credenciales de servicio que realizan el trabajo real en un stack moderno de Salesforce están mayormente fuera de todo eso, sin vigilancia y con demasiados permisos.

Los atacantes que descubrieron esto lo explotaron durante un año, y en más de una ocasión, la vía de entrada no fue más que una credencial que alguien olvidó desactivar.


Fuente:
THN