Analizamos la brecha Salesloft Drift Salesforce: cronología, empresas afectadas, datos expuestos y medidas para proteger tokens OAuth en tu CRM.
Qué ocurrió: cronología del ataque (ago 2025)
En agosto de 2025, actores maliciosos aprovecharon una cadena de consentimiento OAuth en integraciones de Salesloft y Drift para acceder a instancias de Salesforce. Según reportes iniciales, la brecha Salesloft Drift Salesforce siguió una secuencia predecible: acceso inicial, expansión mediante tokens y abuso de APIs con permisos excesivos.
Fase 1: acceso inicial (primera semana)
Campañas de spear‑phishing dirigidas a equipos de ventas y ops simularon avisos de “actualización de integración”. Varias víctimas autorizaron una app maliciosa con scopes amplios en Salesloft/Drift (correo, contactos, actividades), lo que otorgó a los atacantes refresh tokens legítimos y persistentes. No se requirieron credenciales robadas ni MFA para mantener acceso.
Fase 2: movimiento lateral y abuso de OAuth
Con los tokens y conectores activos, los atacantes pivotaron hacia las organizaciones de Salesforce vinculadas. Usaron APIs para listar Connected Apps, exportar Leads/Contacts/Activities y configurar endpoints de webhook que facilitaban exfiltración continua. En varios casos, la brecha Salesloft Drift Salesforce se amplificó por scopes de integración demasiado amplios y ausencia de rotación de tokens.
Fase 3: detección y contención (segunda mitad de agosto)
Las alertas surgieron por picos de llamadas API, IPs atípicas y reutilización de tokens desde ASNs desconocidos. Los equipos revocaron consentimientos, rotaron secretos, forzaron reautorización de Connected Apps y limitaron scopes al principio de mínimo privilegio. Además, revisaron Audit Logs, invalidaron sesiones y añadieron reglas para patrones similares a la brecha Salesloft Drift Salesforce.
Empresas afectadas: Zscaler, Palo Alto y SpyCloud
La brecha Salesloft Drift Salesforce expuso riesgos en integraciones de ventas que operan con tokens OAuth y permisos amplios. Entre las organizaciones señaladas están Zscaler, Palo Alto Networks y SpyCloud, con posibles accesos no deseados a objetos de CRM y automatizaciones conectadas. Su respuesta temprana y los controles aplicados marcan el estándar.
Zscaler
La compañía habría detectado actividad anómala en integraciones de cadencias y sincronización de leads. El riesgo principal: lectura de contactos, tareas y metadatos de campañas a través de tokens OAuth con refresco.
- Revocar tokens en Salesforce: Setup → Connected Apps OAuth Usage → Revoke.
- Rotar el usuario de integración y limitar scopes (evitar refresh_token si no es imprescindible).
- Auditar Event Monitoring: ConnectedAppOauthUsage, LoginHistory y límites de API.
Palo Alto Networks
En entornos con alto volumen de partners, el impacto potencial incluyó notas de oportunidades y actividad de cuentas vinculadas a apps de Salesloft/Drift. Se priorizó el principio de mínimo privilegio.
- Crear un perfil dedicado “solo lectura” para integraciones comerciales.
- Restringir Connected Apps a usuarios permitidos y sesiones de alta garantía.
- Alertas por anomalías de API (picos, IPs no reconocidas, cambios de scopes).
SpyCloud
Como proveedor de inteligencia sobre credenciales, su enfoque apuntó a contención rápida y hardening continuo frente a la brecha Salesloft Drift Salesforce.
- Forzar reconsentimiento de OAuth y rotar secretos de las apps conectadas.
- Adoptar flujos con tokens de vida corta y políticas de expiración estrictas.
- Bloquear refresh_token offline_access salvo casos justificados y auditados.
Datos expuestos y objetivos del actor UNC6395
Qué datos quedaron expuestos
La brecha Salesloft Drift Salesforce permitió el acceso a tokens OAuth con amplios alcances, abriendo la puerta a la lectura y exportación de datos de CRM y herramientas de engagement comercial. Entre la información comprometida destacan contactos, leads, cuentas, oportunidades, actividades y transcripciones de emails sincronizados.
En Salesloft, el actor pudo visualizar secuencias, plantillas, notas de llamadas y métricas de desempeño, útiles para replicar el tono y la cadencia de mensajes legítimos. En Drift, es plausible el acceso a transcripciones de chat, rutas de playbooks, enlaces de reuniones y datos de intención, valiosos para ingeniería social de alto impacto.
Adicionalmente, los tokens comprometidos suelen incluir metadatos de sesión y permisos de API que permiten crear o modificar registros, activar webhooks y extraer datasets masivos sin disparar autenticaciones adicionales.
Objetivos y modus operandi de UNC6395
El objetivo principal de UNC6395 parece ser la monetización rápida mediante exfiltración de listas de clientes y spear phishing con alto índice de respuesta. Con la información y el contexto de Salesloft/Drift, el actor puede enviar correos o chats que imitan campañas activas, aumentando la tasa de clics y credenciales robadas.
También busca persistencia: el uso de refresh tokens y apps conectadas en Salesforce permite reestablecer acceso incluso tras un reset de contraseñas. A partir de ahí, el grupo puede pivotar, crear usuarios integradores, registrar webhooks maliciosos o manipular campos sensibles (por ejemplo, datos bancarios en oportunidades).
Para mitigar impactos de la brecha Salesloft Drift Salesforce: revocar y rotar tokens OAuth en las apps conectadas, auditar scopes efectivos, limitar apps por perfil y red, segregar usuarios de integración, establecer expiraciones cortas sin refresh tokens cuando sea posible, y monitorizar exportaciones inusuales con Event Monitoring/Shield en Salesforce. Estas acciones reducen superficie y dificultan la persistencia de UNC6395 en entornos afectados por la brecha Salesloft Drift Salesforce.
Medidas y recomendaciones para integraciones OAuth
Gobernanza de tokens y permisos
Tras la brecha Salesloft Drift Salesforce, adopta privilegio mínimo y segmenta accesos por integración. Define scopes granulares evitando “full” o equivalentes; usa usuarios técnicos dedicados con perfiles y permisos restringidos. Emite access tokens de corta vida (5–15 min) y habilita rotación de refresh tokens con detección de reuso. Almacena secretos y tokens solo en un cofre de secretos, nunca en código o tickets. Refuerza la emisión con mTLS o DPoP cuando aplique, y valida audiencia/recurso del token.
Endurecimiento de apps conectadas en Salesforce
En Connected Apps, permite solo flujos necesarios: JWT Bearer para server-to-server o Web Server con PKCE para apps confidenciales. Exige client secret, firmantes confiables y políticas de sesión de alta seguridad; no relajes IP ni horas sin justificación. Configura la política de refresh token para rotación y expiración corta. Implementa Named Credentials/External Credentials, y usa un “run-as” con API Only y scopes mínimos. Revisa y revoca accesos en Connected Apps OAuth Usage y fuerza reautorización en integraciones afectadas como Salesloft y Drift. Documenta cambios aprendidos de la brecha Salesloft Drift Salesforce.
Monitoreo, detección y respuesta
Activa Event Monitoring y correlación en tu SIEM para OAuthAuthorization, API Usage y LoginHistory. Crea alertas por anomalías: incremento súbito de llamadas, cambio de IP/UA, geografía imposible o scopes fuera de patrón. Mantén un playbook: revocar tokens, rotar client secrets, deshabilitar la app, reemitir credenciales y verificar auditorías. Programa pruebas de respuesta trimestrales y escaneo de secretos en repositorios. Integra estas rutinas en el ciclo de vida de proveedores para mitigar futuras exposiciones como la brecha Salesloft Drift Salesforce.
