La campaña de tokens Drift de Salesforce convirtió el consentimiento OAuth en una frontera de responsabilidad

Resumen

• Google Threat Intelligence Group informó que, desde el 8 de agosto hasta al menos el 18 de agosto de 2025, UNC6395 atacó instancias de clientes de Salesforce utilizando tokens OAuth comprometidos asociados con la aplicación de terceros Salesloft Drift.
• El aviso de confianza de Salesforce indicó que Salesloft, en colaboración con Salesforce, invalidó los tokens de acceso y actualización activos y eliminó Drift de AppExchange; el problema no se debió a una vulnerabilidad en la plataforma central de Salesforce.
• El Centro de Confianza de Salesloft declaró posteriormente que Mandiant investigó una intrusión sospechosa que afectó al producto Drift y que la investigación evaluó la causa raíz, el alcance, la contención, la remediación y la segmentación entre las aplicaciones Drift y Salesloft.
• El incidente demuestra que el consentimiento OAuth no es un proceso administrativo secundario. Una integración con permisos profundos puede convertirse en una vía de acceso a los datos de CRM de los clientes, casos de soporte, credenciales incrustadas en registros y sistemas en la nube posteriores.
• La responsabilidad sigue al control. Salesloft controlaba el producto Drift y la custodia de los tokens. Salesforce controlaba la gobernanza de las aplicaciones conectadas en la plataforma, la respuesta de AppExchange, los canales de notificación a clientes, la visibilidad de auditoría y la revocación de tokens de emergencia. Los clientes controlaban las aprobaciones de aplicaciones conectadas y la higiene de datos, pero a menudo solo después de que la plataforma y el proveedor pusieran la integración a disposición.

La cronología pública comienza con autoridad delegada

El aviso de Google Threat Intelligence Group,Robo generalizado de datos apunta a instancias de Salesforce a través de Salesloft Drift, es la fuente técnica central. GTIG dijo que, desde el 8 de agosto hasta al menos el 18 de agosto de 2025, el actor rastreado como UNC6395 atacó instancias de clientes de Salesforce mediante tokens OAuth comprometidos asociados con la aplicación de terceros Salesloft Drift. GTIG dijo que el actor exportó grandes volúmenes de datos de numerosas instancias corporativas de Salesforce y buscó secretos como claves de acceso de AWS, contraseñas y tokens de Snowflake.

El propioAviso de Seguridadde Salesforce enmarcó el límite de la plataforma. Salesforce dijo que el incidente involucró la aplicación Drift publicada por Salesloft, que Salesloft en colaboración con Salesforce invalidó los tokens de acceso y actualización activos, y que Drift fue eliminado de AppExchange. El aviso también dijo que el problema no se debió a una vulnerabilidad dentro de la plataforma central de Salesforce. Esa declaración es importante y debe preservarse. El incidente no es evidencia de que los atacantes explotaran una vulnerabilidad central de software de Salesforce.

ElCentro de Confianzade Salesloft describió posteriormente la investigación de Mandiant sobre una intrusión sospechosa que afectó al producto Drift. Dijo que Mandiant fue contratada el 26 de agosto de 2025 para determinar la causa raíz y el alcance, ayudar en la contención y remediación, y verificar la segmentación entre las aplicaciones Drift y Salesloft. Esa fuente es importante porque coloca la investigación en la capa del proveedor, no solo en la capa de la plataforma Salesforce.

La secuencia de respuesta pública importa. Google y Salesforce describen actividad a principios y mediados de agosto. El aviso de Salesforce dice que los tokens fueron invalidados y Drift eliminado de AppExchange. Elanálisis de AppOmni sobre la brecha de Drift-Salesforceregistra de manera similar que Salesloft y Salesforce revocaron los tokens OAuth de Drift y que las organizaciones afectadas fueron notificadas directamente por Salesforce. Elinforme de amenazas de Unit 42rastrea la campaña como credenciales OAuth comprometidas utilizadas para exfiltrar datos de entornos de Salesforce afectados.

El hecho crítico de responsabilidad es la autoridad delegada. OAuth permite a un usuario o administrador otorgar a una aplicación acceso a datos y acciones sin compartir la contraseña del usuario. Ese diseño es esencial para el SaaS moderno. También es peligroso cuando una aplicación de terceros tiene alcances amplios, tokens de actualización de larga duración, custodia débil de tokens y acceso a datos de CRM de alto valor. El token se convierte en la autoridad.

Esto no fue un robo de contraseñas común

Muchos protocolos de respuesta a brechas aún asumen un inicio de sesión humano. Restablecer la contraseña, agregar MFA, revisar el historial de inicio de sesión y seguir adelante. La campaña de Drift muestra por qué eso es insuficiente. Un token OAuth no es lo mismo que un usuario escribiendo una contraseña. Puede representar una aplicación de confianza que ya tiene consentimiento para acceder a los datos. Puede eludir algunos controles de inicio de sesión humano porque se espera que la aplicación llame a las API sin una persona presente.

Eso no significa que MFA sea irrelevante. MFA puede prevenir el compromiso inicial del usuario y puede proteger los flujos de trabajo de consentimiento administrativo. Pero después de que existe un token de aplicación válido, los controles importantes son los alcances de la aplicación, el almacenamiento de tokens, la duración del token de actualización, la revisión de la aplicación, la velocidad de revocación, la monitorización de API y la detección de anomalías en el acceso a datos. Un cliente puede tener una buena MFA humana y aún estar expuesto si se roba el token de una aplicación de terceros.

El aviso TLP:CLEAR del FBI e IC3,Grupos criminales cibernéticos UNC6040 y UNC6395 comprometiendo plataformas Salesforce, advirtió que UNC6395 utilizó tokens OAuth comprometidos para la aplicación Salesloft Drift y que el mecanismo de acceso difería de otras campañas centradas en Salesforce. Laalerta de ciberseguridad de FINRA sobre el ataque a la cadena de suministro de IA de Salesloft Driftenmarcó el incidente para las empresas financieras reguladas, diciendo que los tokens de autenticación OAuth robados permitieron a los actores de amenazas hacerse pasar por la aplicación Drift de confianza y obtener acceso no autorizado a los entornos de los clientes.

Esos dos avisos muestran por qué esto fue un problema de gobernanza, no solo una brecha del proveedor. Las empresas reguladas tuvieron que examinar si una aplicación de terceros tenía acceso a datos de Salesforce, si se almacenaban secretos en registros de CRM y si clientes o prospectos habían quedado expuestos. El problema del proveedor y la plataforma se convirtió en un problema de cumplimiento para el cliente.

La documentación de Salesforce sobreaplicaciones conectadasdescribe el modelo básico de integración de aplicaciones externas con Salesforce. Su documentación de OAuth para aplicaciones conectadas, incluida laconfiguración de OAuth, muestra por qué los alcances y las políticas importan. Estos documentos no son evidencia del incidente. Explican la superficie de control.

Los alcances convirtieron la confianza en radio de explosión

Los alcances de OAuth definen lo que una aplicación puede hacer. En un diseño mínimo, una aplicación obtiene solo el acceso necesario para una tarea específica. En un diseño amplio, puede leer o escribir grandes clases de registros, llamar a API, actualizar accesos y operar en una amplia superficie de datos. La campaña de Drift pregunta si la conveniencia de la integración superó la disciplina de alcance.

GTIG informó que UNC6395 consultó y exportó sistemáticamente datos de los entornos de Salesforce y buscó credenciales en los registros. Eso significa que la exposición no se limitó a una lista de campos propiedad de Salesloft. Involucró datos de Salesforce de los clientes accesibles a través de la integración. Si un cliente tenía secretos en casos de Salesforce, notas, hilos de soporte, transcripciones de chat, campos personalizados o archivos adjuntos, esos secretos podrían convertirse en la siguiente etapa del riesgo.

Esta es una diferencia clave respecto a una brecha de la tabla de clientes propia de un proveedor. El token comprometido permitió al atacante llegar al entorno de Salesforce de cada cliente conectado. El daño dependía de lo que cada cliente almacenaba, cómo estaba configurada su organización de Salesforce, a qué objetos podía acceder la aplicación y si los secretos estaban incrustados en los registros. La misma clase de token robado podía producir daños diferentes entre clientes.

El análisis de AppOmni enfatizó la prevención SaaS-a-SaaS y la dificultad de visibilidad a través de aplicaciones conectadas. Elboletín de seguridad de Arctic Wolfenmarcó de manera similar el evento en torno a tokens OAuth de Salesloft Drift comprometidos y robo de datos de Salesforce. Estas fuentes son análisis de proveedores, pero refuerzan el mismo punto de control: las integraciones SaaS crean identidades no humanas que merecen gobernanza de ciclo de vida.

El término "identidad no humana" puede sonar abstracto. En este incidente, significa una credencial de aplicación que puede actuar sin un humano en el teclado. Puede aprobarse una vez y luego persistir. Puede tener acceso amplio porque el acceso amplio hace que la integración sea útil. Puede no aparecer en los paneles de inicio de sesión de usuarios ordinarios. Puede sobrevivir al proceso de negocio que la justificó. Una vez robada, puede moverse rápidamente porque las llamadas API son normales para esa identidad.

El mercado de aplicaciones conectadas es parte de la cadena de control

El aviso de Salesforce dijo que Drift fue eliminado de AppExchange a la espera de una investigación adicional. Esa respuesta importa porque AppExchange no es solo un directorio. Es una señal de confianza. Los clientes a menudo infieren que las aplicaciones listadas en el mercado han pasado un proceso de revisión y son apropiadas para instalar. El mercado no elimina la diligencia debida del cliente, pero influye en las elecciones del cliente.

Cuando una aplicación del mercado se convierte en una vía de acceso de campaña, la responsabilidad de la plataforma no es que haya causado la brecha del proveedor. La responsabilidad es que tiene que detectar, comunicar, deshabilitar y ayudar a los clientes a recuperarse más rápido de lo que permitiría el descubrimiento cliente por cliente. Una plataforma ve las instalaciones de aplicaciones en todos los inquilinos. Puede identificar qué clientes instalaron la aplicación. Puede coordinar la revocación de tokens. Puede notificar a los clientes afectados. Puede eliminar o suspender la lista.

Esa visibilidad entre clientes es precisamente por qué la gobernanza de la plataforma importa.

Salesforce parece haber utilizado ese rol de plataforma en el registro público: su aviso dice que trabajó con Salesloft, invalidó tokens, eliminó la aplicación y notificó a las organizaciones afectadas. La cuestión de responsabilidad es cuán rápido ocurrió eso en relación con la primera actividad sospechosa y si los clientes tuvieron suficiente acceso a registros para determinar su propia exposición. GTIG informó que la actividad de la campaña comenzó tan temprano como el 8 de agosto; se informó de la revocación de tokens el 20 de agosto. El público puede ver el intervalo aproximado, pero no el proceso de decisión de detección interna.

Los clientes también tienen responsabilidades. Eligen aplicaciones, aprueban alcances, almacenan secretos en registros, monitorean el comportamiento de las API y revisan las aplicaciones conectadas. Pero la responsabilidad del cliente está limitada por las capacidades de la plataforma. Si las revisiones de aplicaciones conectadas son difíciles de entender, si los alcances son demasiado amplios, si los registros son difíciles de acceder, si el inventario de tokens está fragmentado, o si la confianza del mercado es vaga, los clientes toman decisiones con visibilidad incompleta.

Por lo tanto, el incidente no debe enmarcarse como un simple ejercicio de culpabilidad a tres bandas. Es una cadena: Salesloft tenía que proteger Drift y sus tokens; Salesforce tenía que gobernar la confianza de las aplicaciones conectadas y la revocación de emergencia; los clientes tenían que restringir el acceso a las aplicaciones y eliminar secretos de los datos de CRM; los atacantes explotaron la cadena.

Los datos de CRM se convirtieron en una superficie de búsqueda de secretos

El hallazgo más inquietante de GTIG no fue meramente que se exportaron registros de CRM. Fue que el actor buscó secretos. Un entorno de Salesforce puede contener casos de soporte, notas de ventas, detalles de incorporación de clientes, hilos de resolución de problemas técnicos, claves de API pegadas en tickets, puntos finales de VPN, identificadores de cuentas en la nube, credenciales de integración, contraseñas almacenadas accidentalmente en comentarios de casos o archivos adjuntos con datos operativos sensibles. Ese material no debería estar en los registros de CRM, pero en organizaciones reales a menudo lo está.

Esto desplaza el daño de la privacidad al riesgo lateral. Si un atacante utiliza una exportación de CRM para encontrar claves de AWS, tokens de Snowflake, credenciales de VPN u otros secretos, la brecha puede pasar de la exposición de datos del cliente a un compromiso de infraestructura. El sistema CRM se convierte en un mapa de otros sistemas. Es el lugar donde los equipos de soporte documentan problemas, y esa documentación puede incluir las pistas necesarias para atacar los sistemas que se están soportando.

El aviso público de GTIG dice que las organizaciones deben buscar secretos y rotar credenciales. Ese consejo es operativamente costoso porque los clientes tienen que buscar en sus propios datos material que nunca deberían haber almacenado allí. Por lo tanto, el incidente expone una falla de higiene de datos en la capa del cliente. Pero el desencadenante fue el compromiso de una integración confiable. Es posible que los clientes no se hubieran dado cuenta de que un chatbot o una integración de flujo de trabajo de ingresos podía alcanzar registros que contenían credenciales.

Salesforce y los clientes pueden reducir este riesgo tratando el escaneo de secretos como un control de CRM. Los registros deben ser escaneados en busca de patrones de claves. Los flujos de trabajo de soporte deben desalentar el pegado de contraseñas o tokens. Los campos sensibles deben ser enmascarados. Los alcances de la aplicación no deben incluir objetos que no se necesitan. Las exportaciones deben ser monitoreadas. Estos no son controles exóticos; son respuestas prácticas a la realidad de que los sistemas CRM contienen datos operativos desordenados.

El riesgo también explica por qué la notificación al cliente importa. Si una organización cliente se vio afectada, su equipo de seguridad necesitaba saberlo lo suficientemente rápido como para buscar registros, rotar los secretos expuestos, verificar los registros de la nube posteriores y advertir a sus propios clientes donde fuera necesario. Un aviso tardío o vago podría permitir que los secretos robados permanecieran válidos.

La revocación fue necesaria, pero no fue recuperación por sí misma

La revocación de tokens cierra la vía de acceso delegada inmediata. El aviso de Salesforce y GTIG describen la revocación o invalidación de los tokens de acceso y actualización de Drift. Eso fue necesario. No eliminó, por sí mismo, los datos ya exportados o los secretos ya recolectados. La recuperación tenía que continuar dentro de los entornos de los clientes.

El primer paso de recuperación es la determinación del alcance de la exposición: ¿qué objetos de Salesforce fueron accedidos, qué registros fueron consultados, qué trabajos de API se ejecutaron y qué integraciones se utilizaron? Ladocumentación de monitoreo de eventos y seguridad de transaccionesde Salesforce y los registros de API pueden ser importantes aquí, pero la disponibilidad de registros varía según la edición, la configuración, la retención y la madurez del cliente. Los avisos públicos no pueden sustituir la evidencia a nivel de inquilino.

El segundo paso es la rotación de secretos. Si los registros contenían claves de AWS, tokens de Snowflake, credenciales de VPN, claves de API, contraseñas o secretos de webhook, esos secretos necesitaban ser encontrados y rotados. Eso es difícil porque los secretos pueden estar en campos de texto libre, archivos adjuntos, comentarios de casos, registros de chat u objetos personalizados. La búsqueda automatizada ayuda, pero puede pasar por alto formatos inusuales. La revisión manual es lenta.

El tercer paso es la notificación a clientes y terceros posteriores. Un cliente de Salesforce cuyos datos de CRM fueron exportados puede tener obligaciones con sus propios clientes, empleados, prospectos, socios y reguladores. Eso crea una cascada. El incidente de Salesloft se convirtió en el incidente de la plataforma Salesforce, que se convirtió en el incidente de cada cliente afectado, que puede convertirse en el aviso al cliente de cada cliente afectado. El costo de un compromiso OAuth viaja hacia afuera.

El cuarto paso es la revisión de la gobernanza de aplicaciones. Los clientes deben preguntarse qué otras aplicaciones conectadas tienen alcances similares, si todavía se necesitan, si los tokens de actualización son de larga duración, si se conocen los propietarios de las aplicaciones, si las revisiones de riesgo de proveedores están actualizadas y si existen protocolos de revocación de emergencia. El incidente de Drift debe tratarse como un ensayo para cualquier otra integración SaaS con permisos profundos.

La marca de IA no cambió el problema de responsabilidad

Algunas discusiones públicas enmarcaron a Drift como una integración de chatbot de IA. Eso importa para el contexto del producto, pero la falla de seguridad no fue mágica debido a la IA. El problema clave fue el acceso delegado a SaaS. Un chatbot, una herramienta de participación de ventas, un widget de soporte, un conector de análisis, una herramienta de enriquecimiento de datos o una plataforma de automatización de marketing pueden volverse peligrosos si contienen tokens amplios hacia los sistemas de los clientes.

La IA puede aumentar el apetito por las integraciones porque las empresas quieren que las herramientas conversacionales vean más contexto. Un chatbot de ventas o soporte es más útil si puede leer registros de CRM, responder preguntas de los clientes, actualizar casos, enrutar clientes potenciales y personalizar respuestas. Cada alcance adicional aumenta la utilidad y el riesgo. Si se roba el token detrás de ese alcance, el atacante recibe el mismo contexto amplio que hizo atractivo el producto.

Esta es la economía de seguridad de la automatización SaaS. Los proveedores venden flujos de trabajo más fluidos. Los clientes aprueban el acceso porque el flujo de trabajo ahorra trabajo. Las plataformas alojan el modelo de permisos porque las integraciones expanden el valor del ecosistema. El riesgo es que ninguna de las partes valora completamente el costo de un compromiso de token hasta después de una campaña. El incidente de Drift es un caso de estudio de ese riesgo subvalorado.

La alerta de FINRA importa porque las empresas financieras reguladas no pueden tratar esto como una noticia tecnológica general. Si una empresa financiera usó Drift con Salesforce, tenía que evaluar si los datos de clientes, prospectos o internos quedaron expuestos y si las credenciales en los registros de CRM creaban un riesgo posterior. La misma lógica se aplica en salud, educación, software, contratación del sector público y cualquier sector donde Salesforce contenga contexto operativo sensible.

El incidente expuso una asimetría de visibilidad

Las plataformas ven patrones que los clientes individuales no pueden. Un solo cliente puede notar un comportamiento extraño de API en su propia organización de Salesforce. Salesforce puede ver instalaciones de aplicaciones de AppExchange, invalidaciones de tokens y patrones entre clientes. Salesloft puede ver telemetría del producto Drift y custodia de tokens. Google Threat Intelligence puede ver actividad de amenazas entre clientes y sus propias investigaciones. Ningún cliente puede ver la campaña completa.

Esa asimetría crea deberes. La parte con visibilidad entre clientes debe advertir rápidamente. La parte con telemetría del producto debe investigar y contener rápidamente. La plataforma debe ayudar a identificar qué clientes están afectados. Los clientes deben actuar rápidamente una vez notificados. Si alguna parte espera evidencia perfecta, el atacante puede seguir usando autoridad válida.

El registro público sugiere una acción coordinada, pero no la velocidad exacta de la escalada interna. GTIG dijo que la campaña comenzó tan temprano como el 8 de agosto. El aviso de Salesforce informó acciones de invalidación y eliminación. El Centro de Confianza de Salesloft dice que Mandiant fue contratada el 26 de agosto. Esas fechas muestran movimiento, pero no muestran cuándo cada parte supo lo suficiente para actuar o qué señales estaban disponibles antes.

Esa cronología faltante importa porque las campañas OAuth son rápidas. Una vez que los tokens son robados, el atacante puede automatizar consultas y exportaciones. Una diferencia de días puede determinar si los clientes rotan los secretos antes o después del uso. Un análisis post mortem de alta calidad mostraría el tiempo de detección, el tiempo de decisión, el tiempo de invalidación de tokens, el tiempo de notificación al cliente y el tiempo de disponibilidad de registros.

Lo que los clientes deben aprender sin ser culpados

Los clientes tienen responsabilidades, pero la lección no debe convertirse en "los clientes deberían haber sabido más". Muchos clientes instalan aplicaciones del mercado porque confían en las señales de confianza de la plataforma. Aprueban alcances porque los proveedores dicen que los alcances son necesarios. Almacenan datos operativos en CRM porque los empleados usan CRM como la memoria compartida del trabajo con clientes. Esos son comportamientos comerciales normales, no actos imprudentes por defecto.

La mejor lección es una gobernanza disciplinada de aplicaciones conectadas. Los clientes deben inventariar aplicaciones conectadas, propietarios, alcances, duración de tokens, fechas de último uso y estado de riesgo del proveedor. Deben eliminar aplicaciones que ya no se necesitan. Deben restringir los perfiles y conjuntos de permisos disponibles para las aplicaciones. Deben escanear datos de CRM en busca de secretos. Deben monitorear el comportamiento de API por aplicación, no solo por usuario. Deben tener un protocolo para la revocación de tokens de emergencia.

Salesforce puede hacer esas responsabilidades del cliente más fáciles o más difíciles. Explicaciones claras de permisos de aplicaciones, puntuación de riesgo de aplicaciones, advertencias de administrador para alcances amplios, inventario de tokens simple, mejor caducidad predeterminada, alertas de anomalías y una revisión sólida de AppExchange pueden reducir la carga del cliente. El diseño de la plataforma moldea el comportamiento del cliente.

Salesloft y otros proveedores SaaS también pueden reducir la carga almacenando tokens de forma segura, minimizando los alcances requeridos, rotando credenciales, publicando actualizaciones de incidentes rápidamente y demostrando segmentación. La referencia del Centro de Confianza de Salesloft a verificar la segmentación entre las aplicaciones Drift y Salesloft es importante porque los clientes necesitan confianza en que el compromiso de un producto no se convirtió en un compromiso más amplio del proveedor.

Los estándares OAuth explican por qué los tokens portadores requieren disciplina adicional

OAuth está diseñado para la autorización delegada. La especificación central de OAuth 2.0,RFC 6749, permite a un cliente obtener tokens de acceso a recursos con la autorización del propietario del recurso. El diseño es poderoso porque el usuario no necesita darle al cliente su contraseña. El riesgo es que un token de acceso es a menudo una credencial al portador: quien lo posee puede usarlo dentro de su alcance hasta que expire o sea revocado.

El modelo de amenazas y las consideraciones de seguridad de OAuth en laRFC 6819advierten sobre la fuga de tokens, el almacenamiento de tokens, la reproducción, el phishing, el abuso de redirección y la necesidad de limitar el alcance y la duración. La Práctica Actual Recomendada de Seguridad de OAuth 2.0 más reciente,RFC 9700, continúa esa dirección al enfatizar patrones defensivos modernos. Estos estándares no son informes de incidentes de Salesforce. Explican por qué la campaña de Drift fue estructuralmente peligrosa.

Si un token de Drift tenía acceso amplio a Salesforce, el token mismo encarnaba la confianza. Un equipo de seguridad podía eliminar la contraseña del usuario, hacer cumplir MFA, y aún enfrentar riesgo si el token de la aplicación seguía siendo válido. Es por eso que la revocación del token fue la acción de emergencia. También es por qué la siguiente capa es la minimización del alcance. Un token robado con alcance limitado puede ser dañino pero acotado. Un token robado con amplio acceso de lectura puede convertirse en una herramienta de exportación de datos.

La técnica de MITRE ATT&CKRobo de Token de Acceso a Aplicacióndescribe a los adversarios robando tokens de acceso a aplicaciones para acceder a sistemas remotos y API. Su técnica paraUsar Material de Autenticación Alternativocubre el patrón más amplio de usar artefactos de autenticación válidos en lugar de contraseñas. Estos marcos ayudan a nombrar la clase de ataque sin exagerar los hechos específicos de Salesforce: el problema fue material delegado válido en manos equivocadas.

La lección estándar es simple pero operativamente difícil. Los tokens deben tratarse como secretos. Los tokens de actualización deben tratarse como secretos especialmente sensibles porque pueden acuñar acceso futuro. Los alcances deben ser tan limitados como el producto pueda tolerar. Los tokens deben ser rotables y revocables. Los registros deben mostrar el uso de tokens por aplicación y por objeto. Los clientes deben saber qué identidades no humanas pueden leer sus datos. Las plataformas deben hacer que los alcances peligrosos sean difíciles de aprobar silenciosamente.

La higiene de aplicaciones conectadas necesita un propietario, no una hoja de cálculo después de la brecha

Muchas organizaciones descubren sus aplicaciones conectadas durante un incidente. Eso es demasiado tarde. Un inventario de aplicaciones conectadas debería existir antes de la campaña: nombre de la aplicación, proveedor, propietario comercial, propietario técnico, alcances, perfiles instalados, último uso, política de tokens de actualización, objetos de datos tocados, estado del contrato y procedimiento de eliminación. Si nadie es dueño de la aplicación, nadie es dueño del riesgo.

La documentación de Salesforce paragestionar aplicaciones conectadasypolíticas de OAuth para aplicaciones conectadasmuestra que la plataforma ofrece controles administrativos. La cuestión es si los clientes tienen el personal, el conocimiento y los incentivos para usarlos bien. Una pequeña empresa puede instalar una herramienta de chat de ventas y nunca revisar sus alcances. Una gran empresa puede tener cientos de aplicaciones conectadas y ninguna cadencia de revisión unificada.

Aquí es donde el diseño de la plataforma debería reducir el error. Los alcances peligrosos deberían ser visibles en lenguaje sencillo. Las aplicaciones conectadas no utilizadas deberían ser fáciles de encontrar. Las aplicaciones con tokens de actualización deberían ser destacadas. Las aplicaciones de alto riesgo deberían tener opciones de caducidad o reautorización periódica. Los administradores deberían poder revocar el acceso a la aplicación sin romper flujos de trabajo no relacionados. Los equipos de seguridad deberían recibir alertas de anomalías de API específicas de la aplicación.

Los clientes también necesitan políticas. Ninguna aplicación debería recibir acceso amplio sin un propietario designado y una fecha de revisión. Ninguna aplicación debería permanecer instalada después de que el propietario comercial se vaya. Ninguna aplicación debería almacenar secretos en registros de CRM simplemente porque es conveniente. Ninguna aplicación debería estar exenta de los protocolos de incidentes porque es "solo una herramienta de ventas". La campaña de Drift mostró que una herramienta de ventas puede convertirse en una vía de incidente de seguridad.

El problema es en parte económico. Las aplicaciones conectadas ahorran trabajo. Revisar cuesta trabajo. Si el beneficio es inmediato y el riesgo es raro, las organizaciones subinvierten en revisión. La plataforma y el proveedor pueden reducir ese desequilibrio al reducir el costo de una buena gobernanza: paneles claros, puntuaciones de riesgo, recomendaciones automatizadas y valores predeterminados más seguros.

Los registros deben responder preguntas sobre las que el cliente pueda actuar

La guía de incidentes a menudo dice a los clientes que revisen los registros. Ese consejo solo es útil si los registros responden a las preguntas correctas. Para la campaña de Drift, los clientes necesitaban saber qué tokens de aplicación se usaron, qué objetos de Salesforce fueron consultados, qué registros fueron exportados, desde qué IPs, con qué contexto de usuario, en qué ventana de tiempo y si las consultas buscaron cadenas similares a secretos.

El monitoreo de eventos de Salesforce, los registros de API y los informes de aplicaciones conectadas pueden ayudar, pero el acceso a evidencia completa puede depender de licencias, retención y configuración. Un cliente que carece de la edición adecuada o del pipeline de exportación de registros puede recibir un aviso y aún tener dificultades para determinar la exposición. Eso es un problema de gobernanza de la plataforma. Cuando una integración del mercado es abusada en todos los clientes, la plataforma está en la mejor posición para suministrar paquetes de evidencia normalizados.

Los clientes también necesitan una ruta de triaje repetible. Primero, identificar si Drift estaba instalado y conectado. Segundo, determinar si los tokens estaban activos durante la ventana de la campaña. Tercero, inspeccionar la actividad de API atribuida a la aplicación. Cuarto, identificar el acceso a objetos y campos. Quinto, buscar en los registros exportados o accesibles en busca de secretos. Sexto, rotar cualquier secreto que pueda haber estado expuesto. Séptimo, notificar a las partes posteriores si estuvieron involucrados datos regulados o de clientes.

El aviso del FBI/IC3 y la guía de GTIG apuntan a los clientes hacia este tipo de acción, pero la ejecución varía ampliamente. Una gran empresa financiera puede tener un equipo de operaciones de seguridad y un lago de registros. Una pequeña empresa SaaS puede tener un administrador de Salesforce, un proveedor de seguridad gestionado y una acumulación de trabajo. La misma campaña por lo tanto crea cargas de recuperación desiguales.

Esa desigualdad importa para la responsabilidad. Las plataformas que sirven a empresas de niveles de madurez muy diferentes no deben asumir que todos los clientes pueden interpretar registros en bruto o indicadores de inteligencia de amenazas. La evidencia procesable y específica del inquilino reduce el costo de la respuesta y la posibilidad de que los secretos robados permanezcan válidos.

Los secretos en los registros de CRM son una falla prevenible pero común

Una lección incómoda es que los clientes deben dejar de tratar el CRM como un lugar seguro para secretos operativos. Los equipos de soporte y ventas a menudo pegan claves de API, credenciales, tokens de portador, secretos de webhook, detalles de VPN o capturas de pantalla en casos y notas porque están tratando de resolver un problema. El CRM se convierte en un archivo de conveniencia. Cuando una integración puede leerlo, el archivo de conveniencia se convierte en un repositorio de secretos.

LaHoja de Referencia de Gestión de Secretosde OWASP explica por qué los secretos necesitan almacenamiento controlado, rotación y disciplina de acceso. La campaña de Drift aplica ese principio a los datos de CRM. Si los secretos aparecen en los registros, una exportación de CRM puede convertirse en un llavero.

La reparación es en parte técnica: escanear registros en busca de patrones de secretos, enmascarar campos sensibles, restringir archivos adjuntos y alertar cuando aparezcan formatos de clave conocidos. También es cultural: capacitar a los equipos de soporte para que no soliciten ni almacenen secretos, proporcionar canales de ingesta seguros para material de diagnóstico necesario y facilitar la purga de secretos cuando se descubran. Si la organización castiga el soporte lento pero no las notas de soporte inseguras, los empleados seguirán tomando atajos.

Salesforce y los proveedores de integración pueden ayudar construyendo características de detección de secretos y advirtiendo a los clientes cuando los alcances amplios de las aplicaciones incluyen objetos que probablemente contengan datos operativos sensibles. Pero los clientes siguen siendo dueños de la higiene de datos dentro de sus organizaciones. El incidente de Drift no creó la mala práctica de almacenar secretos en CRM; reveló cómo esa práctica puede amplificar un compromiso de token de terceros.

El registro público debe preservar lo que no sucedió

Es igual de importante afirmar lo que el registro público no muestra. Las fuentes no muestran que los atacantes explotaran una vulnerabilidad central de Salesforce. No muestran que todos los clientes de Salesforce se vieran afectados. No muestran que cada cliente conectado a Drift tuviera los mismos datos exportados. No muestran que cada registro exportado contuviera secretos. No muestran que el conjunto de productos más amplio de Salesloft se viera comprometido más allá de lo que la investigación de Salesloft describió.

Esos límites protegen la equidad. También hacen que la lección real sea más nítida. El incidente es grave sin exageración porque una integración confiable se convirtió en una vía de acceso delegado a los entornos de los clientes. La gravedad proviene del modelo de confianza, no de la necesidad de inventar un día cero en la plataforma.

El incidente tampoco debe reducirse a "riesgo de terceros" en un sentido vago. El riesgo de terceros específico fue la custodia de tokens y la autoridad de la aplicación conectada. Un proveedor puede tener informes SOC, contratos y cuestionarios de seguridad mientras aún posee tokens que requieren una protección excepcional. Las revisiones de riesgo de proveedores de los clientes deben preguntar cómo las integraciones SaaS almacenan tokens, qué alcances requieren, qué tan rápido se pueden revocar los tokens y qué evidencia puede proporcionar el proveedor después de un incidente.

La revisión de AppExchange de la plataforma también necesita especificidad. No solo debe verificar si una aplicación funciona y cumple con los requisitos de seguridad de referencia en el momento de la inclusión. Debe apoyar el monitoreo continuo, la suspensión rápida, la notificación al cliente y la revalidación posterior al incidente. La confianza en un mercado es una obligación continua, no una insignia única.

Qué evidencia cambiaría la evaluación

La evaluación podría cambiar en cualquier dirección con más evidencia. Si un detalle forense posterior muestra que los tokens comprometidos eran extremadamente limitados, que las exportaciones fueron limitadas y que los clientes afectados recibieron registros completos a nivel de objeto rápidamente, la gravedad operativa debería reducirse. Si la evidencia posterior muestra alcances más amplios, tokens de larga duración, almacenamiento de tokens débil, revocación retrasada o exposición generalizada de secretos, la gravedad debería aumentar.

Si Salesforce publica más detalles sobre mejoras en el monitoreo de AppExchange, características de inventario de tokens, paquetes de registros para clientes o valores predeterminados más seguros para aplicaciones conectadas, eso fortalecería el registro de reparación. Si Salesloft publica más detalles sobre la causa raíz, la custodia de tokens, la segmentación y la remediación del cliente, eso fortalecería la responsabilidad del proveedor. Si los reguladores emiten hallazgos, esos deben evaluarse por separado del registro actual de avisos públicos.

Hasta entonces, la evidencia respalda una conclusión de control de alta confianza: los ecosistemas SaaS necesitan una gobernanza de aplicaciones conectadas que trate los tokens delegados como credenciales de producción, no como tubería de integración.

Esa conclusión es útil precisamente porque evita exagerar. Permite a los clientes fortalecer las aplicaciones conectadas sin esperar un registro judicial definitivo. Permite a las plataformas mejorar los controles de mercado y tokens sin admitir una falla central de la plataforma que la evidencia no muestra. Permite a los proveedores tratar la custodia de tokens como una obligación de seguridad del producto. La lección de la campaña no es especulativa: el acceso delegado puede ser robado, y cuando lo es, el ecosistema debe saber quién puede revocarlo, quién puede explicarlo y quién puede probar qué tocó.

Los simulacros de revocación deberían ser rutinarios

La forma más rápida de aprender si la gobernanza de OAuth es real es ejecutar un simulacro de revocación antes de un incidente. Elija una aplicación conectada no crítica. Identifique al propietario comercial, los alcances, los usuarios, los tokens, los registros, los flujos de trabajo dependientes y la ruta de reversión. Revocar el acceso en una ventana controlada y medir qué se rompe. Luego documentar quién aprobó la restauración y qué evidencia mostró que la aplicación era segura para reconectar.

Ese simulacro convierte el inventario abstracto de aplicaciones en conocimiento operativo. Muestra si la seguridad puede encontrar la aplicación, si los administradores pueden revocarla, si el negocio entiende el flujo de trabajo, si los usuarios reciben instrucciones claras y si los registros pueden probar lo que la aplicación accedió. También revela dónde los equipos tienen miedo de tocar integraciones antiguas porque nadie sabe por qué existen.

La campaña de Drift muestra por qué esa práctica importa. En un compromiso real, la organización no puede pasar días descubriendo quién es dueño de una integración mientras los atacantes usan tokens robados. Un cliente preparado puede revocar primero, investigar rápidamente y reconectar solo con evidencia. Un cliente no preparado puede dudar porque cada token parece continuidad del negocio.

La prueba de responsabilidad

La campaña de Drift-Salesforce debe juzgarse a través de siete controles.

Primero, custodia de tokens: ¿protegió Salesloft los tokens de acceso y actualización como credenciales altamente sensibles, y su arquitectura minimizó la exposición de tokens entre Drift y otros productos?

Segundo, diseño de alcance: ¿solicitó la integración de Drift solo los permisos de Salesforce que necesitaba, y entendieron los clientes el radio de explosión de aprobar esos permisos?

Tercero, gobernanza del mercado: ¿redujo el proceso de revisión, monitoreo y eliminación de emergencia de AppExchange de Salesforce el riesgo del cliente lo suficientemente rápido una vez que la aplicación del proveedor se volvió insegura?

Cuarto, detección entre clientes: ¿identificaron Salesforce, Salesloft y los socios de inteligencia de amenazas los patrones de la campaña lo suficientemente rápido como para revocar los tokens antes de más exportaciones?

Quinto, evidencia del inquilino: ¿recibieron los clientes afectados suficientes registros, evidencia de acceso a objetos y orientación para determinar qué fue consultado y si los secretos fueron expuestos?

Sexto, higiene de secretos: ¿almacenaron los clientes contraseñas, claves de API, tokens de nube o credenciales de VPN en los registros de Salesforce, y los rotaron después de la exposición?

Séptimo, comunicación pública: ¿preservaron los avisos la distinción crítica de que el núcleo de Salesforce no fue explotado, al tiempo que dejaban claro que se accedió a los datos de los clientes de Salesforce a través de tokens de aplicaciones confiables?

La conclusión final no es que Salesforce fuera el producto vulnerable. El registro público dice lo contrario: el problema no se debió a una vulnerabilidad central de la plataforma Salesforce. La conclusión es que el límite de confianza de Salesforce incluye aplicaciones conectadas porque los clientes experimentan la plataforma a través de su ecosistema. Los tokens OAuth son autoridad delegada. Cuando una integración confiable pierde esa autoridad, la plataforma, el proveedor y el cliente tienen deberes distintos.

La campaña de Drift hizo visibles esos deberes de la manera más incómoda: convirtiendo una integración de productividad aprobada en una llave en manos de un atacante.