ConsentFix v3 la táctica que roba tokens aprovechando la confianza preconcedida en OAuth

Un nuevo vector de ataque conocido en foros como ConsentFix v3 está poniendo en evidencia una debilidad recurrente en arquitecturas que confían en flujos OAuth: no siempre es la contraseña o la MFA lo que determina la seguridad, sino cómo y a quién se concede la confianza. A diferencia de los ataques tradicionales de phishing, ConsentFix v3 automatiza y escala una técnica que aprovecha el flujo de autorización de OAuth2 para obtener tokens válidos a través de aplicaciones de Microsoft que ya están preaprobadas o dentro del conjunto de aplicaciones de confianza del inquilino.

La innovación técnica de esta variante no es un nuevo exploit criptográfico, sino la combinación de ingeniería social con herramientas cloud públicas para orquestar la campaña: páginas de phishing servidas desde Cloudflare Pages que inician un inicio de sesión legítimo de Microsoft, redirecciones a un localhost que contienen el código de autorización y una tubería automatizada que captura ese código y lo intercambia inmediatamente por tokens usando plataformas serverless como Pipedream. El resultado es una exfiltración de credenciales basada en tokens que puede sortear controles como MFA, porque la autorización la realiza el propio usuario en un flujo aparentemente legítimo.

Más allá de la técnica puntual, el problema de fondo es arquitectónico. Microsoft y otras nubes modernas utilizan aplicaciones “primero de la casa” (first-party) y mecanismos como Family of Client IDs (FOCI) que facilitan la experiencia de usuario pero también crean una superficie de ataque: cuando un cliente autorizado comparte permisos y refresh tokens, comprometer un flujo autorizado puede dar acceso a múltiples recursos sin pedir reautenticación frecuente. Los equipos de seguridad deben entender que la conveniencia de la confianza preconcedida incrementa el riesgo de abuso a escala. Para profundizar en cómo se identifican familias de clientes en Microsoft, puede consultarse la investigación pública en GitHub: Family of Client IDs.

Los efectos prácticos de una intrusión con tokens válidos van desde el robo de correo y archivos hasta el aprovechamiento de permisos automatizados para moverse lateralmente en el tenant. En campañas reportadas, los atacantes combinan ingeniería social avanzada —correos personalizados, PDFs alojados en servicios legítimos como DocSend— con automatización para reducir el tiempo entre que la víctima “autoriza” y la obtención efectiva del refresh token. Plataformas de integración como Pipedream se usan como webhook, motor de intercambio de códigos y recolector de tokens en tiempo real; en otros casos los tokens capturados se importan a paneles de control para posteriores exploraciones (por ejemplo, Specter u otras herramientas de abuso de tokens).

¿Qué pueden hacer los equipos de seguridad de inmediato? Primero, reconocer que la mitigación efectiva exige cambios en políticas y detección, no solo concienciación. Bloquear o restringir el consentimiento de aplicaciones a nivel de usuario reduce la superficie: forzar que las aplicaciones nuevas requieran consentimiento administrativo, limitar el uso de aplicaciones preaprobadas y revisar periódicamente las aplicaciones con permisos elevados. Aplicar políticas de Conditional Access que exijan dispositivos administrados o sesiones con tokens acotados por riesgo puede elevar el coste de la explotación automatizada.

Segundo, mejorar la telemetría y la detección. Auditar eventos de OAuth (emisión de códigos, canjes de códigos por tokens, emisión de refresh tokens) y crear reglas de comportamiento para detectar patrones atípicos —por ejemplo, intercambio de código desde ubicaciones o agentes inusuales, o canje inmediato desde dominios externos— permite responder más rápido. Complementar con bloqueo de infraestructura usada en campañas (hosts de páginas de phishing, endpoints de webhook usados recurrentemente) puede ayudar a interrumpir la automatización.

Tercero, medidas técnicas concretas que conviene revisar: limitar la extensión y duración de refresh tokens, establecer políticas de caducidad más agresivas, habilitar restricciones de aplicación (qué apps pueden solicitar ciertos scopes) y evaluar el uso de “token binding” o mecanismos de atado de token a dispositivos confiables donde estén disponibles. No existe una sola bala de plata: la defensa eficaz combina prevención de consentimiento excesivo, control del entorno de autenticación y detección de comportamiento. Para entender mejor el flujo de autorización y los puntos donde se ha de instrumentar la detección, la documentación de Microsoft sobre el flujo de autorización es una referencia útil: OAuth 2.0 authorization code flow (Microsoft).

No menos importante es la capacitación del personal con foco en técnicas concretas empleadas por estos ataques. Enseñar a reconocer interacciones extrañas que solicitan pegar o arrastrar URLs que apunten a localhost, y establecer reglas operativas en las que nunca se acepte pegar cadenas de redirección fuera de contextos verificados, reduce la eficacia del truco social que sustenta ConsentFix.

Por último, los equipos de respuesta deben preparar playbooks para revocación rápida de tokens y bloqueo de sesiones cuando detecten indicios de abuso. Como recordatorio, la presencia de una técnica en foros no implica su adopción masiva inmediata, pero la automatización que propone ConsentFix v3 hace que la barrera de entrada sea baja y, por tanto, el riesgo de escalada sea real. La combinación de políticas de consentimiento más estrictas, telemetría enfocada y controles de acceso basados en riesgo constituye la línea de defensa más efectiva hoy contra estos ataques.

Para auditar dependencias y puntos de exposición a estas técnicas, revisar las aplicaciones con permisos elevados y las integraciones externas es una tarea prioritaria que complementa la respuesta operativa y reduce la probabilidad de que un solo código de autorización comprometido se convierta en un dominio de ataques sostenidos.