{"id":761,"date":"2026-05-05T13:14:27","date_gmt":"2026-05-05T13:14:27","guid":{"rendered":"https:\/\/cybercolombia.co\/index.php\/2026\/05\/05\/la-puerta-trasera-que-los-atacantes-conocen-y-que-la-mayoria-de-los-equipos-de-seguridad-aun-no-han-cerrado-cyberdefensa-mx\/"},"modified":"2026-05-05T13:14:27","modified_gmt":"2026-05-05T13:14:27","slug":"la-puerta-trasera-que-los-atacantes-conocen-y-que-la-mayoria-de-los-equipos-de-seguridad-aun-no-han-cerrado-cyberdefensa-mx","status":"publish","type":"post","link":"https:\/\/cybercolombia.co\/index.php\/2026\/05\/05\/la-puerta-trasera-que-los-atacantes-conocen-y-que-la-mayoria-de-los-equipos-de-seguridad-aun-no-han-cerrado-cyberdefensa-mx\/","title":{"rendered":"La puerta trasera que los atacantes conocen y que la mayor\u00eda de los equipos de seguridad a\u00fan no han cerrado \u2013 CYBERDEFENSA.MX"},"content":{"rendered":"
\n

Cada herramienta de inteligencia artificial, automatizaci\u00f3n del flujo de trabajo y aplicaci\u00f3n de productividad que sus empleados conectaron a Google o Microsoft este a\u00f1o dejaron algo atr\u00e1s: un token OAuth persistente sin fecha de vencimiento, sin limpieza autom\u00e1tica y, en la mayor\u00eda de las organizaciones, nadie lo mira. Tus controles perimetrales no lo ven. Tu MFA no lo detiene. Y cuando un atacante consigue uno, no necesita una contrase\u00f1a.<\/p>\n

Las concesiones de OAuth no caducan cuando los empleados se van. No se restablecen cuando cambian las contrase\u00f1as. Y en la mayor\u00eda de las organizaciones, nadie los vigila.<\/p>\n

El modelo ten\u00eda sentido cuando un pu\u00f1ado de aplicaciones aprobadas por TI necesitaban acceso al calendario. No se sostiene cuando cada empleado conecta de forma independiente herramientas de inteligencia artificial, automatizaciones de flujo de trabajo y aplicaciones de productividad directamente a su entorno de Google o Microsoft, cada uno de los cuales recibe un token persistente y con alcance, sin vencimiento autom\u00e1tico y sin visibilidad centralizada.<\/p>\n

Eso no es una mala configuraci\u00f3n. As\u00ed es como est\u00e1 dise\u00f1ado para funcionar OAuth. La brecha es que la mayor\u00eda de los programas de seguridad no se crearon para tenerlo en cuenta a escala.<\/p>\n

Los CISO saben que es un problema. La mayor\u00eda no lo est\u00e1 resolviendo.<\/h2>\n

Nueva investigaci\u00f3n de Material Security<\/a> cuantifica la brecha entre conciencia y acci\u00f3n. El 80% de los l\u00edderes de seguridad consideran que OAuth no administrado representa un riesgo cr\u00edtico o significativo. La mayor\u00eda lo ha dicho durante a\u00f1os.<\/p>\n

\"\"<\/a><\/div>\n

Pero la conciencia no se traduce directamente en capacidad. Una parte sustancial de las organizaciones (45%) no est\u00e1 haciendo nada para monitorear las subvenciones de OAuth a escala. Muchos del resto (33%) ejecutan procesos manuales: rastrean las concesiones en hojas de c\u00e1lculo, revisan los permisos ad hoc y dependen de los empleados para detectar comportamientos inusuales en las aplicaciones.<\/p>\n

\"\"<\/a><\/div>\n

Las hojas de c\u00e1lculo no son una capacidad de respuesta a amenazas. Son un registro de cu\u00e1nta exposici\u00f3n una organizaci\u00f3n no sabe que tiene.<\/p>\n

No es un riesgo te\u00f3rico.<\/h2>\n

El argumento a favor de la visibilidad de OAuth a menudo se formula como si los empleados canalizaran informaci\u00f3n confidencial a herramientas de terceros sin visibilidad de TI. Ese es un problema real, pero es el m\u00e1s peque\u00f1o. El problema m\u00e1s apremiante es que las concesiones de OAuth son un vector de ataque activo. El incidente de deriva<\/a> lo hace concreto.<\/p>\n

Drift, una plataforma de participaci\u00f3n de ventas adquirida por Salesloft, mantuvo integraciones de OAuth con instancias de Salesforce en cientos de organizaciones de clientes. Un actor de amenazas rastreado por la Unidad 42 de Palo Alto como UNC6395 obtuvo tokens de actualizaci\u00f3n de OAuth v\u00e1lidos (probablemente a trav\u00e9s de campa\u00f1as de phishing anteriores) y los utiliz\u00f3 para acceder a entornos de Salesforce que pertenecen a m\u00e1s de 700 organizaciones.<\/p>\n

La estructura del ataque es una advertencia: los tokens eran leg\u00edtimos, la integraci\u00f3n era leg\u00edtima. Desde la perspectiva de cualquier control perimetral, no pasaba nada. MFA se omiti\u00f3 por completo porque el atacante no estaba iniciando sesi\u00f3n; estaba presentando un token cuyo uso ya se hab\u00eda concedido a Drift. Una vez dentro, UNC6395 export\u00f3 datos sistem\u00e1ticamente y los revis\u00f3 en busca de credenciales: claves de acceso de AWS, tokens Snowflake, contrase\u00f1as.<\/p>\n

Cloudflare, PagerDuty y decenas m\u00e1s se vieron afectados. A\u00fan se est\u00e1 evaluando el alcance total.<\/p>\n

El incidente de Drift no fue un ataque de una aplicaci\u00f3n desconocida y sospechosa. fue un ataque a trav\u00e9s de<\/em> uno de confianza. La lecci\u00f3n no es que las organizaciones deban restringir las integraciones de OAuth; es que confiar en una aplicaci\u00f3n en el momento de la instalaci\u00f3n no significa que siga siendo confiable, y que las concesiones de OAuth necesitan un monitoreo activo y continuo en lugar de una aceptaci\u00f3n pasiva.<\/p>\n

C\u00f3mo debe ser realmente el monitoreo<\/h2>\n

La generaci\u00f3n actual de herramientas de seguridad de OAuth aborda el riesgo de OAuth en el punto de instalaci\u00f3n. Comprueban si el alcance del permiso solicitado es excesivo. Pueden marcar aplicaciones de proveedores con mala reputaci\u00f3n. Eso es \u00fatil, pero no suficiente. En el caso de Drift, una aplicaci\u00f3n leg\u00edtima cuyas credenciales fueron posteriormente robadas y utilizadas como arma, no detecta nada.<\/p>\n

Para empezar, los niveles de confianza de los proveedores y el alcance de las aplicaciones son importantes, pero s\u00f3lo cuentan una parte de la historia. Monitorear el comportamiento real de la aplicaci\u00f3n (las llamadas a la API que realiza, las acciones que realiza) es fundamental para comprender qu\u00e9 es la aplicaci\u00f3n. de hecho<\/em> haciendo, no s\u00f3lo lo que podr\u00eda hacer. E incluso entonces, sin una visibilidad profunda de las cuentas a las que est\u00e1 vinculada la aplicaci\u00f3n, todav\u00eda est\u00e1s operando medio ciego. Una aplicaci\u00f3n riesgosa vinculada a la cuenta de un pasante es una cosa; la misma aplicaci\u00f3n utilizada por un VIP con acceso a innumerables correos electr\u00f3nicos, archivos y sistemas confidenciales es otra completamente distinta.<\/p>\n

El ataque Drift no involucr\u00f3 una aplicaci\u00f3n sospechosa que solicitara permisos inusuales durante la instalaci\u00f3n. Se trataba de una aplicaci\u00f3n leg\u00edtima cuyas credenciales fueron posteriormente comprometidas y utilizadas como arma. Una herramienta que s\u00f3lo eval\u00faa la subvenci\u00f3n en el momento de su creaci\u00f3n no habr\u00eda visto nada malo. El riesgo se materializ\u00f3 m\u00e1s tarde, cuando el token fue robado y utilizado por un actor completamente diferente.<\/p>\n

La seguridad efectiva de OAuth requiere:<\/p>\n