Salesloft: cuando un token abre demasiadas puertas
Tabla de contenidos
El 20 de agosto de 2025, se detectó un incidente originado en la integración Salesloft Drift. Se ha confirmado cerca de una veintena de compañías afectadas, entre ellas grandes compañías tecnológicas, con entornos Salesforce y otros servicios asociados, por lo que la afectación podría ser mucho mayor dada la utilización de entornos Salesforce y otros servicios asociados. El caso ilustra cómo un único eslabón vulnerable en la cadena puede tener un impacto exponencial en múltiples empresas a nivel global.
COMUNICADOS OFICIALES DE ORGANIZACIONES AFECTADAS
Anatomía del ataque: hipótesis de lo ocurrido
- Compromiso inicial: Los atacantes comprometieron el repositorio de GitHub de Salesloft entre marzo y junio de 2025. Las principales hipótesis apuntan que el acceso inicial se produjo mediante la obtención de credenciales, empleando ingeniería social o credenciales expuestas en filtraciones previas. Una vez dentro, descargaron código fuente de repositorios privados, añadieron un usuario invitado y configuraron workflows sospechosos que les dieron visibilidad y posible persistencia en el entorno.
- Explotación de Drift en AWS: A través de este acceso inicial, realizaron reconocimiento limitado en el entorno de Salesloft y, de forma más profunda, en la infraestructura de Drift alojada en AWS, donde lograron obtener tokens OAuth y refresh asociados a clientes, que después utilizaron para acceder de forma ilegítima a instancias de Salesforce y otros servicios (Google Workspace, Snowflake, AWS).
- Exfiltración: Una vez dentro de Salesforce, ejecutaron consultas de reconocimiento para mapear objetos clave y posteriormente emplearon la Bulk API 2.0 para exfiltrar datos a gran escala.
La información comprometida incluía campos de texto en casos de soporte, registros de clientes y credenciales sensibles como claves de AWS, tokens de Snowflake y contraseñas corporativas.
Además, para ocultar su actividad, los atacantes borraron los jobs de exportación tras la descarga, así como no exceder los límites de Bulk API, dificultando la detección y el análisis inmediato.
DIAGRAMA DE ATAQUE INCIDENTE DE SALESLOFT DRIFT
Autoría del incidente
Aunque la autoría de este incidente no ha sido confirmada en su plenitud el principal candidato se trata de un actor emergente que no se había observado en otras campañas. El grupo malicioso se denomina UNC6395, también identificado como GRUB1 por Cloudflare.
- Google Threat Intelligence Group (GTIG) fue la primera entidad en identificar a UNC6395 como responsable del abuso de tokens OAuth de Drift para acceder a entornos de Salesforce y Google Workspace.
- Cloudflare, víctima directa, designó al actor con el alias GRUB1, confirmando que la información técnica obtenida coincidiría con los hallazgos de Google.
- Obsidian Security, también plantean la posibilidad de que UNC6395 haya colaborado con otros grupos como ShinyHunters o Scattered Spider. No obstante, no se existen evidencias que afirmen esta hipótesis.
- Desde el MxDR de Tarlogic se corroboran los anteriores puntos validando que el modus operandi utilizado es similar pero no idéntico al utilizado por estos grupos hasta la fecha.
ANÁLISIS COMPARATIVOS DE HALLAZGOS SELECCIONADOS
| Shiny Hunters | Scattered Spider | Lapsu$ | UNC6395 | |
|---|---|---|---|---|
| Solapamientos de infraestructura (VPNs, paneles de phishing, dominios fraudulentos) | X | |||
| Coincidencia en TTPs (ingeniería social, abuso de credenciales -OAuth-) | X | X | X | X |
| Historial de campañas previas similares | X | X | X | |
| Afirmación pública de atribución de autoría | ||||
| Evidencias técnicas (IOCs) | X | |||
| Modelo de extorsión: difusión en Telegram | X | X |
Impacto directo y su efecto dominó
Más allá de las víctimas confirmadas, el incidente revela cómo un compromiso en un tercero puede desencadenar un impacto masivo en la cadena de suministro SaaS. El uso generalizado de Salesforce y su integración con múltiples plataformas (Slack, Google Workspace, herramientas de CRM, marketing automation, etc.) multiplica el riesgo: un único punto de compromiso puede propagarse a decenas o cientos de organizaciones sin que estas sean conscientes de inmediato.
Los tokens OAuth funcionaron como puerta trasera al evadir controles tradicionales de autorización, mostrando un alcance descontrolado donde una sola integración comprometida afectó potencialmente a un número indeterminado de clientes a través de ecosistemas interconectados como Salesforce, Slack o Google Workspace. Cabe destacar que muchas de estas soluciones son consideradas funciones críticas en multiplicidad de organizaciones.
Este caso pone de manifiesto el impacto colateral de esta tipología de incidentes, caracterizado por:
- Dependencia excesiva en integraciones SaaS donde se suele asumir los más estrictos controles de seguridad.
- Visibilidad insuficiente, de las acciones realizadas por parte del actor malicioso, dificultando a la víctima identificar patrones anómalos o maliciosos.
- Persistencia del riesgo, ya que los tokens comprometidos pueden mantener acceso aun después de que se descubra el incidente.
- Riesgo reputacional y regulatorio para las empresas de la cadena que, aún no siendo víctimas iniciales, pueden ver expuestos datos de clientes, socios o empleados.
Además, demuestra cómo una integración aparentemente menor puede transformarse en un vector de riesgo crítico para toda la organización, amplificando su efecto en toda la cadena de suministro. En un ecosistema interconectado, una brecha localizada no solo compromete a la víctima inicial, sino que puede propagarse como un efecto dominó hacia clientes, proveedores y socios, erosionando la confianza y exponiendo datos críticos más allá del perímetro de la organización.
Indicadores de Compromiso identificados
El trabajo de investigación realizado desde el MxDR de Tarlogic ha permitido recopilar los siguientes Indicadores de Compromiso:
CADENAS DE USER-AGENT MALICIOSAS
| › Salesforce-Multi-Org-Fetcher/1.0 | › Salesforce-CLI/1.0 | › python-requests /2.32.4 | › Python/3.11 aiohttp/3.12.15 |
DIRECCIONES IP MALICIOSAS
| › 208[.]68[.]36[.]90 (DigitalOcean) › 179[.]43[.]159[.]198 (Nodo de salida TOR) › 185[.]220[.]101[.]143 (Nodo de salida TOR) › 185[.]220[.]101[.]180 (Nodo de salida TOR) › 192[.]42[.]116[.]20 (Nodo de salida TOR) | › 44[.]215[.]108[.]109 (Amazon Web Services) › 185[.]130[.]47[.]58 (Nodo de salida TOR) › 185[.]220[.]101[.]164 (Nodo de salida TOR) › 185[.]220[.]101[.]185 (Nodo de salida TOR) › 194[.]15[.]36[.]117 (Nodo de salida TOR) | › 154[.]41[.]95[.]2 (Nodo de salida TOR) › 185[.]207[.]107[.]130 (Nodo de salida TOR) › 185[.]220[.]101[.]167 (Nodo de salida TOR) › 185[.]220[.]101[.]33 (Nodo de salida TOR) › 195[.]47[.]238[.]178 (Nodo de salida TOR) | › 176[.]65[.]149[.]100 (Nodo de salida TOR) › 185[.]220[.]101[.]133 (Nodo de salida TOR) › 185[.]220[.]101[.]169 (Nodo de salida TOR) › 192[.]42[.]116[.]179 (Nodo de salida TOR) › 195[.]47[.]238[.]83 (Nodo de salida TOR) |
¿Qué pueden hacer las compañías?
A continuación, ofrecemos algunas sugerencias:
- Comprobar si la organización se ha visto afectada:
• Revisar las integraciones de terceros que puedan haberse visto afectas y realizar una rotación de credenciales.
• Realizar una revisión de los diferentes logs, especialmente entre las fechas del 8 al 18 de agosto, en busca de los IOCs identificados o de algún otro comportamiento extraño.
• Estar al día de eventuales terceros que puedan resultar afectadas. - Medidas de detección y preventivas en atención a la tendencia alza que están teniendo los ataques a la cadena de suministro.
• Mantener un conocimiento actualizado de los modus operandi que se están utilizando en este tipo de ataques.
• Implementar procedimientos de evaluación para las integraciones con terceros realizando una evaluación individual de riesgos, así como auditorías periódicas de tal manera que se asegure la integridad de la cadena de suministro.
• Contar con detecciones, alertas y remediaciones tanto automáticas (i.e.: listas de bloqueo) como manuales (Threat Hunting Proactivo) en busca no solo de IOCs sino TTPs.
• Hacer uso de técnicas seguras para compartición de credenciales de cualquier tipo (contraseñas, tokens, etc) para evitar que queden almacenadas en plano, por ejemplo, tickets de soporte alojados en terceros.
• Anticipar amenazas en la cadena de suministro y mejorar la visibilidad sobre accesos y riesgos externos mediante el uso de servicios de Business Digital Protection y de Threat Intelligence Advisory.
• Evaluar detenidamente los riesgos que suponen los chatbot, como Drift, a la hora de ser implementados.
• Realizar ejercicios de pentesting en entornos SaaS, orientados a detectar vulnerabilidades, así como configuraciones e integraciones inseguras.