Drift: el robo de llaves que afectó a 700 empresas

Qué pasó con Drift y por qué nadie lo vio durante meses

Drift era un chatbot que muchas empresas tenían en su web. Conversaba con las visitas y, cuando alguien dejaba su nombre o pedía una reunión, lo apuntaba automáticamente en Salesforce, el CRM donde esas compañías guardaban la información de sus clientes. Lo vendía Salesloft, una empresa de software de ventas que, pese al parecido del nombre, no tiene nada que ver con Salesforce.

Para apuntar esos contactos, cada empresa autorizaba una vez al chatbot a entrar en su CRM. Esa autorización se convertía en una llave digital, y la llave no la guardaba cada cliente: la guardaba Drift, en sus propios sistemas. El atacante fue a por ellas.

En agosto de 2025 empezó a usarlas. Un programa automatizado recorría los CRM de los clientes uno tras otro, sin elegir víctimas: fue a por todos los clientes de Drift. Los investigadores de Google que analizaron el ataque calculan que más de 700 organizaciones pudieron verse afectadas, entre ellas varias de las mayores firmas de ciberseguridad del mundo.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El dato que más incomoda del caso es el tiempo. El atacante llevaba dentro de Salesloft desde la primavera, meses antes del robo, y nadie lo había detectado. No forzó ninguna puerta ni engañó al chatbot: entró con las llaves.

La dimensión real del robo: 1.500 millones de registros

Según el análisis publicado por GCN, los atacantes explotaron tokens OAuth comprometidos de la aplicación Drift entre el 8 y el 18 de agosto de 2025 y accedieron a aproximadamente 760 organizaciones cliente de Salesforce, de donde extrajeron cerca de 1.500 millones de registros de las tablas de cuentas, contactos, casos, oportunidades y usuarios.

La lista de víctimas confirmadas incluye a BeyondTrust, Bugcrowd, Cato Networks, Cloudflare, CyberArk, Elastic, Google, JFrog, Nutanix, PagerDuty, Palo Alto Networks, Qualys, Rubrik, SpyCloud, Tanium, Tenable y Zscaler. Es, literalmente, el listado de empresas que le venden seguridad a todo el resto.

Pero los contactos no eran el premio. El objetivo era recolectar credenciales: claves de acceso de AWS, contraseñas y tokens de servicios en la nube como Snowflake. Muchas empresas guardan esos secretos dentro del CRM, y los casos de soporte son justo el lugar donde un ingeniero pega una clave temporal para pedir ayuda. Una de las víctimas encontró entre lo robado más de cien claves de acceso a sus servicios.

El mecanismo de entrada también es una lección: según GCN, el grupo usó TruffleHog, una herramienta gratuita que escanea repositorios de código en busca de secretos mal guardados, contra el propio repositorio de GitHub de Salesloft. Encontró tokens OAuth vivos dentro del código. El compromiso inicial de ese repositorio ocurrió en marzo de 2025.

¿Por qué la llave de un agente vale más que la de un chatbot?

El caso deja tres problemas a la vista, y los tres empeoran cuando el protagonista es un agente de IA en lugar de un chatbot.

El valor está en lo que abre la llave. El chatbot solo necesitaba apuntar contactos, pero su llave abría todo el CRM, incluidos los casos de soporte donde se pegaban otras claves. Con un agente, una llave amplia no es un exceso: es lo que necesita para trabajar en varios sistemas. Y no solo abre, también permite actuar. En Drift el atacante se limitó a leer; con la llave de un agente podría además enviar, aprobar o modificar.

La llave la protege un tercero. Cada empresa autorizó la conexión, pero quien guardaba la llave era Drift. La seguridad de cientos de compañías dependía de un sistema que ninguna controlaba ni podía ver, y ese sistema falló sin que nadie lo notara. Por eso cayeron también empresas que viven de la seguridad: el atacante no entró por sus defensas, sino por el proveedor que guardaba sus llaves.

El robo puede pasar por trabajo normal. El CRM veía la llave del chatbot y abría la puerta, sin saber quién la usaba. Lo que cambiaba era el comportamiento: el chatbot apuntaba contactos de uno en uno y el atacante se llevaba todo de golpe. Con un agente esa diferencia se estrecha, porque su trabajo cambia con cada tarea y lo que haga quien robe su llave será más difícil de separar de la operación legítima.

El mismo patrón, otra vez: el caso Klue

No es un incidente aislado. BleepingComputer reportó que el proveedor de inteligencia de mercado Klue sufrió una brecha de OAuth que permitió al grupo de extorsión Icarus robar datos de Salesforce de múltiples organizaciones. El atacante usó una credencial heredada que Klue había creado para una integración prototipo, robó los tokens OAuth de los clientes y consultó directamente sus entornos de Salesforce.

Según Infosecurity Magazine, entre las afectadas que lo confirmaron están Huntress, Recorded Future, Jamf y Tanium, además de compañías fuera de la ciberseguridad como Insurity y Sprout Social. Klue desactivó sus integraciones con Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive y Slack mientras respondía al incidente. BleepingComputer señala que Icarus se lanzó en abril de 2026. Y según GCN, en noviembre de 2025 ya hubo una campaña similar contra aplicaciones publicadas por Gainsight que alcanzó a más de 200 instancias de clientes de Salesforce.

El patrón es idéntico: no se rompe la plataforma, se roba la confianza que alguien ya otorgó.

¿Qué significa esto para tu startup?

Si tu equipo usa un CRM, un help desk o cualquier SaaS conectado por OAuth, ya tienes llaves circulando fuera de tu control. Y si estás desplegando agentes, el problema se multiplica: un despliegue suma muchas herramientas de proveedores distintos, y con cada una crecen los tres problemas anteriores.

Los números del sector van en esa dirección. Gartner calcula que en 2026 hasta el 40% de las aplicaciones empresariales incluirá agentes especializados, frente a menos del 5% un año antes, y proyecta que más del 40% de los proyectos de agentes de IA se cancelarán antes de que acabe 2027. Según ZDNET, el propio Gartner advierte que para 2028 el 25% de las brechas de seguridad empresariales se remontará al abuso de agentes de IA por privilegios de máquina mal gestionados y prácticas heredadas de credenciales.

La conclusión práctica: gobernar agentes es, en buena parte, gobernar sus llaves.

Cuatro medidas concretas antes de que tu agente entre en producción

Documenta qué abre cada llave y quién responde por ella. Antes de producción tiene que constar por escrito qué sistemas abre, si solo permite leer o también actuar, y qué contienen los datos a los que llega. Si en el correo o en las incidencias hay contraseñas pegadas, el agente llega a ellas. Cada llave necesita un responsable con nombre, que decida cuándo se renueva y cuándo se anula.
Negocia las llaves antes de firmar con el proveedor. Con un agente ajeno, la protección de sus llaves se negocia antes de la firma, no después del incidente. Tres preguntas: dónde las guarda, cuánto tarda en avisar si se las roban y cuánto tarda en anularlas. Y una condición que recomendaron los investigadores tras el ataque: que la llave solo funcione desde la red del proveedor, para que quien la robe no pueda usarla desde fuera.
Exige a tus agentes internos lo mismo que a un proveedor. Con un agente propio, tu empresa es su propio Drift. Guarda las llaves fuera del código, ponles fecha de caducidad y vigila el lugar donde se almacenan. Lo que pedirías en un contrato, pídelo a los equipos de casa.
Define el trabajo normal de cada agente y alerta cuando se salga. Es la única forma de detectar un uso robado sin esperar el aviso de otro. Significa saber qué sistemas toca, cuántos datos mueve, desde dónde se conecta y en qué horario. En un agente esa referencia es más difícil de fijar que en un chatbot, así que conviene establecerla desde el primer día.

Añade una quinta tarea que casi nadie planifica: saber retirar un agente. Un agente cancelado deja de trabajar, pero sus llaves siguen funcionando hasta que alguien las anula. La última tarea de un agente debería ser devolver sus llaves.

Conclusión

El fallo de Drift no estuvo en Salesforce, que confirmó que su plataforma no tenía ninguna vulnerabilidad, ni en la inteligencia artificial del chatbot: el atacante no lo engañó ni tocó su IA. Estuvo en una llave amplia, guardada por un tercero y usada durante meses sin que nadie notara la diferencia.

Para un founder, la lección es que comprar o construir un agente no es solo una decisión de negocio y de arquitectura. También es una decisión de seguridad: define quién guarda las llaves del agente y quién responde si alguien las roba. Cuanto más útil es un agente, más vale su llave para quien la robe.