GTIG: IA crea vulnerabilidad día cero que elude el 2FA

El Google Threat Intelligence Group publicó el 11 de mayo su GTIG AI Threat Tracker, reporte trimestral sobre el uso ofensivo de inteligencia artificial. La revelación más significativa: por primera vez, GTIG documentó una vulnerabilidad de día cero que elude el 2FA, desarrollada con ayuda de IA y orientada a una explotación masiva contra una popular herramienta de administración de sistemas de código abierto.

El ataque fue frenado antes de ejecutarse. La intervención proactiva de GTIG —que coordinó la divulgación responsable con el proveedor afectado— habría impedido la campaña planificada. Pero el hallazgo tiene un peso que va más allá del incidente puntual: la IA ya está siendo usada para descubrir y armar vulnerabilidades de día cero, no como hipótesis futura sino como práctica documentada en el ecosistema del cibercrimen organizado.

La atribución al uso de IA no es directa sino de alta confianza. GTIG señala que, aunque no cree que Gemini haya sido utilizado, la estructura del código delata la autoría de un modelo de lenguaje: comentarios educativos que explican el código paso a paso, un puntaje CVSS alucinado incluido como si fuera real, y un estilo Python “de manual de texto” altamente característico de los datos de entrenamiento de los grandes modelos de lenguaje.

Los autores de delitos cibernéticos utilizaron la inteligencia artificial para identificar y aprovechar una vulnerabilidad de día cero

Día cero que burla el 2FA

Esta vulnerabilidad de día cero que elude el 2FA no sigue los patrones que detectan las herramientas de análisis tradicionales. No hay corrupción de memoria ni sanitización de entradas deficiente. El fallo es un error semántico de lógica de alto nivel: el desarrollador codificó de forma fija una excepción de confianza que contradice la lógica de aplicación del doble factor en el resto del sistema. La evasión además requiere credenciales válidas del usuario objetivo, lo que la sitúa en cadenas de ataque más sofisticadas.

Las herramientas de análisis estático están optimizadas para detectar crashes y flujos de datos. Esta clase de fallo no produce ninguno. Los modelos de lenguaje de frontera, en cambio, realizan razonamiento contextual: leen la intención del desarrollador y correlacionan la lógica de aplicación del 2FA con las contradicciones de sus excepciones codificadas. Esa capacidad de identificar lo que está “estratégicamente roto pero funcionalmente correcto” es exactamente el diferenciador que hace a la IA especialmente peligrosa para descubrir este tipo de fallas.

Chile y la Ley 21.663 ante este riesgo

En Chile, el 2FA es un control de seguridad explícitamente recomendado bajo los marcos normativos derivados de la Ley Marco de Ciberseguridad (Ley 21.663) y forma parte de los controles mínimos esperados por la CMF para entidades del sector financiero. El hallazgo de GTIG no invalida el 2FA como control, pero obliga a reconsiderar su jerarquía dentro de la arquitectura de identidad y su suficiencia como única barrera para accesos críticos.

El CSIRT Nacional y la ANCI no han emitido una alerta específica sobre este vector al cierre de este artículo. Sin embargo, el reporte tiene implicancias directas para cualquier organización chilena que utilice herramientas de administración de sistemas open source con acceso expuesto a internet, categoría frecuente en entornos de TI corporativos y de gobierno.

La recomendación no es desactivar el 2FA, sino entender sus límites y complementarlo. Los estándares FIDO2/WebAuthn y las passkeys son resistentes estructuralmente a este tipo de vulnerabilidad de día cero porque la clave de autenticación nunca abandona el dispositivo del usuario y no depende de lógica de servidor que pueda contener excepciones codificadas.

Tres acciones concretas: revisar qué herramientas de administración de sistemas están expuestas a internet con 2FA como único control de acceso; verificar el estado de actualizaciones en herramientas open source de administración de servidores; evaluar la migración a FIDO2 para los accesos más críticos. La vulnerabilidad fue frenada esta vez. La capacidad ya existe.

Fuente: Google Threat Intelligence Group — https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access