Cuando las relaciones de confianza se convierten en un vector de ataque

Durante mucho tiempo, un ciberataque comenzaba con la búsqueda de una brecha: una contraseña robada, una vulnerabilidad aprovechada o un equipo comprometido. El objetivo era siempre el mismo: obtener un primer acceso al sistema de información. Este modelo sigue existiendo, pero ya no es el único. Hoy en día, un número cada vez mayor de ataques se basa en accesos ya autorizados. En ocasiones, el atacante ya no necesita explotar una vulnerabilidad ni eludir un mecanismo de seguridad. Basta con que recupere o desvíe una autorización concedida a una aplicación de terceros. OAuth, los tokens de acceso y las integraciones SaaS se han convertido en componentes indispensables de los entornos en la nube modernos. También se han convertido en una superficie de ataque especialmente atractiva.

El atacante ya no se centra únicamente en tus sistemas

El cambio es sutil, pero fundamental. En lugar de atacar directamente su entorno de Microsoft 365, Google Workspace, Salesforce o Slack, el atacante se centra ahora en las aplicaciones de terceros que están conectadas a ellos. La lógica es sencilla: cuando una aplicación ya dispone de acceso legítimo a sus datos a través de OAuth, comprometer dicha aplicación puede permitir acceder a los mismos recursos sin tener que sortear los controles de seguridad habituales. Varios incidentes recientes han ilustrado este modus operandi.

El caso relacionado con Salesloft y Drift, en particular, ha puesto de manifiesto cómo el compromiso de una aplicación SaaS podía dar lugar a la explotación de tokens OAuth utilizados para acceder a entornos de clientes. Los atacantes no necesitaron atacar directamente las plataformas utilizadas por las empresas afectadas. Aprovecharon la relación de confianza ya establecida entre dichas plataformas y la aplicación de terceros. También se ha observado un problema similar en torno a ciertas aplicaciones conectadas al ecosistema de Salesforce. En estos casos, los accesos utilizados eran perfectamente legítimos desde el punto de vista de los sistemas: las solicitudes procedían de aplicaciones autorizadas y se basaban en permisos válidos.

Estos ataques no eluden los mecanismos de seguridad. Los evitan. Para los sistemas de seguridad, la actividad suele parecer legítima, ya que los accesos utilizados están autorizados.

Por qué la MFA no es suficiente

La autenticación multifactorial es hoy en día un requisito de seguridad imprescindible. Sin embargo, no da respuesta a todos los escenarios de compromiso de seguridad. La MFA protege al usuario en el momento de la autenticación. No protege necesariamente los permisos ya delegados a las aplicaciones. Un token OAuth es lo que se denomina una «credencial de portador». En la práctica, cualquier persona o sistema que posea este token puede utilizarlo dentro de los límites de los permisos concedidos.

En otras palabras, un atacante que consiga un token válido no suele necesitar ni la contraseña del usuario ni su segundo factor de autenticación. Esta distinción es fundamental. Una organización puede contar con una implementación de MFA ejemplar y, aun así, seguir expuesta a cientos de autorizaciones OAuth cuyo ciclo de vida nadie supervisa realmente.

Los tokens olvidados: un riesgo a menudo invisible

Uno de los principales problemas radica en la vida útil de estos accesos. Una integración implementada para un proyecto puntual, una herramienta probada durante unas semanas o una automatización creada por un empleado puede seguir funcionando durante meses, o incluso años, sin ser revisada. Estos accesos suelen escapar a los controles habituales de gestión de identidades. Cuando un empleado abandona la empresa, por lo general se desactiva su cuenta y se revocan sus derechos. Sin embargo, las aplicaciones que haya conectado a su entorno profesional pueden seguir disponiendo de autorizaciones activas si no se ha previsto ningún proceso específico para identificarlas y eliminarlas. Cada acceso olvidado supone una oportunidad adicional para un atacante.

El phishing de OAuth: un ataque sin contraseña

OAuth también puede ser objeto de explotación sin que se vea comprometida ninguna aplicación de terceros. Las campañas denominadas «illicit consent grant» se basan en un enfoque especialmente eficaz: el atacante crea una aplicación que parece legítima y, a continuación, invita a los usuarios a concederle permisos. El usuario recibe una solicitud de autorización que le resulta familiar, similar a las que ve a diario cuando conecta una nueva herramienta a su entorno de Microsoft 365 o Google Workspace. Si acepta los permisos solicitados, la aplicación obtiene acceso directo a los recursos autorizados. En este escenario, no se roba ninguna contraseña, no se instala ningún malware ni se aprovecha ninguna vulnerabilidad. Es el propio usuario quien proporciona el acceso a través de un mecanismo totalmente legítimo. Eso es precisamente lo que hace que estos ataques sean difíciles de detectar.

El efecto amplificador de la IA

La rápida adopción de las herramientas de inteligencia artificial agrava aún más este problema. Para ser realmente útiles, muchos asistentes de IA necesitan acceder a los datos de la empresa: correo electrónico, documentos, herramientas colaborativas, CRM o plataformas de gestión de proyectos. Cada nueva conexión genera permisos adicionales, tokens adicionales y nuevas relaciones de confianza entre sistemas. Esta multiplicación de accesos favorece la aparición de la «Shadow AI»: asistentes, agentes y automatizaciones implementados sin la validación formal del departamento de TI o de los equipos de seguridad, pero que en ocasiones disponen de acceso directo a datos sensibles.

El reto ya no consiste únicamente en gestionar a los usuarios humanos. Consiste también en controlar el conjunto de identidades no humanas que interactúan a diario con los datos de la empresa: aplicaciones, cuentas de servicio, bots, claves API, agentes de IA e integraciones SaaS.

¿Qué medidas hay que adoptar?

El objetivo, evidentemente, no es renunciar a OAuth ni a las integraciones SaaS. Estos mecanismos se han convertido en indispensables para el funcionamiento de nuestras organizaciones. Sin embargo, su gobernanza debe considerarse un tema de seguridad en sí mismo. Esto comienza por una visibilidad completa de las aplicaciones conectadas, los permisos concedidos y los tokens activos.

El principio del privilegio mínimo también debe aplicarse de forma sistemática. Una aplicación solo debería disponer de los derechos estrictamente necesarios para su funcionamiento. La vigencia de los accesos debe controlarse mediante mecanismos de caducidad, rotación y revocación periódica. Por último, los procedimientos de incorporación y salida de los empleados deben incluir explícitamente la revisión y la supresión de los permisos OAuth asociados a su actividad. En un entorno SaaS moderno, la gestión de los tokens OAuth, las aplicaciones conectadas y las identidades no humanas ya no es un tema técnico secundario: ahora constituye un elemento central de la estrategia de ciberseguridad. Hoy en día, proteger las identidades ya no es suficiente. También es necesario controlar las autorizaciones concedidas a las aplicaciones que actúan en su nombre.