{"id":912,"date":"2026-05-19T13:46:44","date_gmt":"2026-05-19T13:46:44","guid":{"rendered":"https:\/\/cybercolombia.co\/index.php\/2026\/05\/19\/como-el-consentimiento-de-oauth-evita-mfa-cyberdefensa-mx\/"},"modified":"2026-05-19T13:46:44","modified_gmt":"2026-05-19T13:46:44","slug":"como-el-consentimiento-de-oauth-evita-mfa-cyberdefensa-mx","status":"publish","type":"post","link":"https:\/\/cybercolombia.co\/index.php\/2026\/05\/19\/como-el-consentimiento-de-oauth-evita-mfa-cyberdefensa-mx\/","title":{"rendered":"C\u00f3mo el consentimiento de OAuth evita MFA \u2013 CYBERDEFENSA.MX"},"content":{"rendered":"
\n

En febrero de 2026, una plataforma de phishing como servicio (PhaaS) llamada tokens malvados<\/a> sali\u00f3 en vivo. En cinco semanas, hab\u00eda comprometido a m\u00e1s de 340 organizaciones de Microsoft 365 en cinco pa\u00edses. <\/p>\n

Los objetivos de la plataforma recibieron un mensaje pidi\u00e9ndoles que ingresaran un c\u00f3digo corto en microsoft.com\/devicelogin y completaran su desaf\u00edo MFA normal, luego se marcharon creyendo que hab\u00edan verificado un inicio de sesi\u00f3n de rutina. De hecho, le hab\u00edan entregado al operador un token de actualizaci\u00f3n v\u00e1lido destinado a su buz\u00f3n, unidad, calendario y contactos, con la vida \u00fatil de una pol\u00edtica de inquilino en lugar de una sesi\u00f3n.<\/p>\n

El operador nunca necesit\u00f3 una contrase\u00f1a, nunca activ\u00f3 un mensaje de MFA y nunca produjo un evento de inicio de sesi\u00f3n que pareciera una intrusi\u00f3n. El ataque tuvo \u00e9xito porque la pantalla de consentimiento de OAuth se convirti\u00f3 en un clic instintivo y los controles creados para detener el phishing de credenciales no miran la capa de consentimiento.<\/p>\n

Los investigadores de seguridad llaman a la condici\u00f3n resultante phishing de consentimiento o abuso de concesi\u00f3n de OAuth. El clic de phishing que import\u00f3 la \u00faltima d\u00e9cada entreg\u00f3 una contrase\u00f1a. El clic de phishing que importa ahora entrega un token de actualizaci\u00f3n y se ubica estructuralmente debajo de los controles de identidad que la mayor\u00eda de las organizaciones todav\u00eda consideran como per\u00edmetro.<\/p>\n

Por qu\u00e9 MFA no puede ver una concesi\u00f3n de OAuth<\/b><\/h2>\n

Un phishing de credenciales entrega un nombre de usuario y una contrase\u00f1a que deben reproducirse en alg\u00fan lugar, y la mayor\u00eda de las pilas de identidades ahora exigen un segundo factor en la repetici\u00f3n. Incluso los kits de adversario en el medio (AiTM) producen una cookie de sesi\u00f3n vinculada a un evento de inicio de sesi\u00f3n que el SIEM correlaciona con la geograf\u00eda, el dispositivo y los patrones de viaje.<\/p>\n\n\n\n\n
\"\"<\/a><\/td>\n<\/tr>\n
Figura 1: El phishing de credenciales deja un rastro de inicio de sesi\u00f3n que SIEM puede correlacionar.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Una concesi\u00f3n de OAuth no produce credenciales repetidas. El usuario se autentica en el proveedor de identidad leg\u00edtimo, finaliza la verificaci\u00f3n de MFA en el dominio leg\u00edtimo y hace clic en Aceptar. La se\u00f1al que se lleva el atacante es que el sistema funciona seg\u00fan lo dise\u00f1ado. Est\u00e1 firmado por el proveedor de identidad, tiene como alcance lo que el usuario acord\u00f3 y es actualizable. MFA no puede bloquearlo porque MFA ya ocurri\u00f3.<\/p>\n\n\n\n\n
\"\"<\/a><\/td>\n<\/tr>\n
Figura 2: Una concesi\u00f3n de OAuth no deja repetici\u00f3n, solo un token actualizable.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

El otro problema es que los tokens de actualizaci\u00f3n ampl\u00edan la ventana. Los tokens emitidos por EvilTokens sobrevivieron a los restablecimientos de contrase\u00f1as y permanecieron v\u00e1lidos durante semanas o meses, seg\u00fan la configuraci\u00f3n del inquilino. Rotar la contrase\u00f1a no invalid\u00f3 la concesi\u00f3n. S\u00f3lo la revocaci\u00f3n expl\u00edcita, o una pol\u00edtica de acceso condicional que exig\u00eda un nuevo consentimiento, lo cerr\u00f3.<\/p>\n

C\u00f3mo se normaliz\u00f3 el consentimiento<\/b><\/h2>\n

Este vector de ataque existe desde que OAuth se convirti\u00f3 en est\u00e1ndar. Lo que cambi\u00f3 es el entorno en el que opera. Los usuarios han sido capacitados para hacer clic en las pantallas de consentimiento al mismo ritmo que una vez hicieron clic en los carteles de cookies. Cada agente de IA instala Surface One. Cada integraci\u00f3n de productividad genera una. Cada extensi\u00f3n del navegador que toca una cuenta SaaS muestra una. El volumen de consentimiento leg\u00edtimo que ve un trabajador del conocimiento en un mes excede todo lo que exist\u00eda cuando se escribieron los modelos de amenazas originales de OAuth.<\/p>\n

Los propios alcances utilizan un lenguaje que no se relaciona claramente con el riesgo. Un alcance llamado \u00abLeer su correo\u00bb parece limitado, pero en la pr\u00e1ctica cubre todos los mensajes, archivos adjuntos e hilos compartidos al que puede acceder el usuario. Un alcance llamado \u00abAcceder a archivos cuando no est\u00e9 presente\u00bb significa un token de larga duraci\u00f3n emitido sin que el usuario est\u00e9 frente a una pantalla para revocarlo. La brecha entre el lenguaje de consentimiento y el alcance operativo es exactamente donde operan los atacantes.<\/p>\n

Formulario de combinaciones t\u00f3xicas debajo del propietario de la aplicaci\u00f3n<\/b><\/h2>\n

Un consentimiento \u00fanico de OAuth le da al atacante un punto de apoyo dentro de una aplicaci\u00f3n. El riesgo m\u00e1s profundo se forma cuando esos puntos de apoyo se unen.<\/p>\n

Un usuario de finanzas otorga a un resumidor de reuniones de IA acceso a su calendario y buz\u00f3n de correo. Posteriormente, el mismo usuario otorga acceso a un asistente de productividad al disco compartido de la empresa. Una tercera subvenci\u00f3n conecta una herramienta de enriquecimiento de CRM con la base de datos de clientes. Cada uno fue aprobado uno a la vez. Ning\u00fan propietario de la aplicaci\u00f3n aprob\u00f3 la combinaci\u00f3n. La superficie de riesgo ahora son tres \u00e1mbitos que se cruzan a trav\u00e9s de una identidad humana, donde el compromiso del resumidor de la reuni\u00f3n puede llegar a borradores de contratos y registros de clientes a trav\u00e9s de la misma persona.<\/p>\n

Esto se llama un combinaci\u00f3n t\u00f3xica. Consiste en un desglose de permisos entre aplicaciones, unido por una concesi\u00f3n de OAuth, una integraci\u00f3n o un agente de IA, que ning\u00fan propietario de la aplicaci\u00f3n jam\u00e1s autoriz\u00f3 como su propia superficie de riesgo. No puede ser visto por el registro de auditor\u00eda de ninguna aplicaci\u00f3n porque el puente existe fuera de todas ellas.<\/a><\/p>\n\n\n\n\n
\"\"<\/a><\/td>\n<\/tr>\n
Figura 3: Una combinaci\u00f3n t\u00f3xica entre dos aplicaciones SaaS que ning\u00fan propietario aprob\u00f3 juntas.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

La instalaci\u00f3n de MCP, el clic de consentimiento de OAuth y la concesi\u00f3n de extensi\u00f3n del navegador: cada uno es un puente emitido a la velocidad de un solo clic. Los servidores Model Context Protocol (MCP) est\u00e1n surgiendo como la pr\u00f3xima superficie de ataque estilo OAuth, permitiendo a los agentes adquirir alcance a trav\u00e9s del mismo mecanismo de confianza que ya utilizan las pantallas de consentimiento.<\/p>\n

El Salesloft-Drift 2025 incidente<\/a> mostr\u00f3 c\u00f3mo se ve esto a escala. Un conector descendente comprometido se extendi\u00f3 entre m\u00e1s de 700 inquilinos de Salesforce a trav\u00e9s de tokens OAuth que los clientes hab\u00edan aprobado leg\u00edtimamente. Cada cliente autoriz\u00f3 la integraci\u00f3n. Ninguno autoriz\u00f3 la cascada.<\/p>\n

Qu\u00e9 comprobar<\/b><\/h2>\n

Para cerrar esta brecha es necesario tratar el consentimiento de OAuth de la misma manera que el programa de seguridad ya trata la autenticaci\u00f3n. Un peque\u00f1o conjunto de preguntas expone d\u00f3nde reside la verdadera brecha.<\/p>\n\n\n\n\n\n\n\n\n\n
\n

\u00c1rea a revisar\n <\/p>\n<\/td>\n

\n

C\u00f3mo se ve en la pr\u00e1ctica\n <\/p>\n<\/td>\n<\/tr>\n

\n

Inventario de aplicaciones OAuth\n <\/p>\n<\/td>\n

\n

Todas las aplicaciones de terceros que contienen tokens de actualizaci\u00f3n en el inquilino se actualizan continuamente en lugar de en el momento de la auditor\u00eda.\n <\/p>\n<\/td>\n<\/tr>\n

\n

Edad de concesi\u00f3n y reconsentimiento\n <\/p>\n<\/td>\n

\n

Los tokens emitidos hace m\u00e1s de 30 d\u00edas sin nuevo consentimiento aparecieron como una cola.\n <\/p>\n<\/td>\n<\/tr>\n

\n

Identidades entre aplicaciones\n <\/p>\n<\/td>\n

\n

Identidades que poseen subvenciones para tres o m\u00e1s aplicaciones SaaS, marcadas para revisi\u00f3n.\n <\/p>\n<\/td>\n<\/tr>\n

\n

Puentes de agentes y de integraci\u00f3n\n <\/p>\n<\/td>\n

\n

Agentes de IA e integraciones que unen dos sistemas que ning\u00fan propietario de aplicaci\u00f3n aprob\u00f3 juntos.\n <\/p>\n<\/td>\n<\/tr>\n

\n

Acceso condicional al consentimiento\n <\/p>\n<\/td>\n

\n

Pol\u00edticas que se reactivan en eventos de consentimiento, no solo en eventos de inicio de sesi\u00f3n.\n <\/p>\n<\/td>\n<\/tr>\n

\n

Revocaci\u00f3n a nivel de token\n <\/p>\n<\/td>\n

\n

Un manual que revoca un \u00fanico token de OAuth en lugar de suspender al usuario.\n <\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

La disciplina procesal s\u00f3lo escala hasta ahora. Los puentes viven en un gr\u00e1fico que ninguna aplicaci\u00f3n individual posee y se crean a la velocidad de una instalaci\u00f3n de MCP o un clic de consentimiento de OAuth. Ver ese gr\u00e1fico continuamente requiere una plataforma construida para observar la capa de tiempo de ejecuci\u00f3n donde realmente se forman los puentes.<\/p>\n

D\u00f3nde encajan las plataformas de seguridad de IA<\/b><\/h2>\n

Una nueva clase de plataformas maneja mucho de esto autom\u00e1ticamente. Mapean cada concesi\u00f3n de OAuth, agente de IA e integraci\u00f3n de terceros en el gr\u00e1fico de identidad en el momento en que se emite, en lugar de esperar a la siguiente auditor\u00eda, y luego muestran los puentes, los tokens no utilizados y las desviaciones de pol\u00edticas como una cola operativa continua.<\/p>\n

Un ejemplo destacado es Reco. Re\u00fane la seguridad de los agentes de IA, el control de identidades y la detecci\u00f3n de amenazas en un solo plano de control. Su Identity Knowledge Graph conecta identidades humanas y no humanas con las aplicaciones, subvenciones de OAuth e integraciones a las que pueden acceder en todo el patrimonio SaaS.<\/p>\n\n\n\n\n
\"\"<\/a><\/td>\n<\/tr>\n
Figura 4: Vista de Reco de las concesiones OAuth y las cuentas conectadas de un agente de IA.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

La plataforma descubre continuamente agentes de IA y concesiones de OAuth a medida que aparecen, asigna cada alcance a la identidad que lo aprob\u00f3, monitorea el comportamiento para detectar desviaciones de pol\u00edticas y revoca el acceso a nivel de token en lugar de a la cuenta de usuario. Esto brinda a los equipos de seguridad visibilidad de la capa de tiempo de ejecuci\u00f3n donde realmente se forman estas relaciones de confianza.<\/p>\n

El phishing de consentimiento probablemente no permanecer\u00e1 al margen por mucho m\u00e1s tiempo. La autenticaci\u00f3n resistente al phishing ha recibido a\u00f1os de inversi\u00f3n y escrutinio, mientras que la capa de consentimiento todav\u00eda funciona en gran medida bas\u00e1ndose en la confianza. Cerrar esa brecha significa tratar las concesiones de OAuth y las conexiones de agentes de IA con la misma disciplina de visibilidad, monitoreo y revocaci\u00f3n que ya se aplica a la autenticaci\u00f3n misma.<\/p>\n

\n

Obtenga m\u00e1s informaci\u00f3n sobre la plataforma de seguridad de IA de Reco<\/a>.<\/p>\n<\/blockquote>\n

\u00bfEncontr\u00f3 interesante este art\u00edculo? Este art\u00edculo es una contribuci\u00f3n de uno de nuestros valiosos socios.<\/span> S\u00edguenos en noticias de google<\/a>, Gorjeo<\/a> y LinkedIn<\/a> para leer m\u00e1s contenido exclusivo que publicamos.<\/div>\n<\/div>\n