Google Threat Intelligence Group publicó un nuevo AI Threat Tracker el 11 de mayo de 2026. Lo importante no es solo que los atacantes estén usando IA. El cambio real está en cómo la usan: de escritura, traducción y reconocimiento pasan a investigación de vulnerabilidades, validación de PoC, ofuscación de malware y orquestación automática de ataques.
Hay dos puntos que se mezclan con facilidad, así que conviene separarlos.
Primero, Google dijo que identificó lo que considera el primer exploit zero-day desarrollado con ayuda de IA. Ese caso corresponde a un grupo de ciberdelincuencia no identificado. El objetivo era una herramienta popular y open source de administración web, y la vulnerabilidad permitía saltarse 2FA cuando el atacante ya tenía credenciales válidas. Google afirmó que trabajó con el proveedor afectado para la divulgación responsable y que pudo haber evitado una explotación masiva.
Segundo, APT45 no fue atribuido como responsable de ese zero-day. GTIG señaló por separado que APT45, un grupo vinculado a Corea del Norte, fue observado enviando grandes volúmenes de prompts repetitivos a modelos de IA para analizar recursivamente distintos CVE y validar exploits PoC. Es decir, APT45 está usando IA como herramienta de investigación de vulnerabilidades y gestión de arsenal, no solo como asistente para escribir correos de phishing.
Qué muestra el caso del zero-day asistido por IA
Este zero-day no era un fallo típico de corrupción de memoria, filtrado de entrada o mala configuración simple. GTIG lo describió como una falla lógica semántica de alto nivel: el desarrollador había codificado una suposición de confianza dentro del flujo de autenticación, creando una contradicción entre la lógica de 2FA enforcement y sus excepciones.
Este tipo de vulnerabilidad no es cómodo para los escáneres tradicionales. El análisis estático y el fuzzing son mejores encontrando crashes, sinks peligrosos, rutas de entrada y salida, y patrones conocidos. No siempre entienden qué garantía quería preservar el desarrollador y en qué excepción se rompe esa garantía.
Ahí aparece el riesgo de los modelos grandes. No necesariamente son mejores que un investigador de seguridad experto, pero son buenos leyendo contexto, explicando intención, comparando rutas de código parecidas y señalando inconsistencias de lógica de negocio. Cuando los atacantes conectan esa capacidad a procesos automatizados, fallos lógicos que antes requerían mucha lectura manual pueden filtrarse a mayor escala.
GTIG también observó señales de generación por IA en el exploit, como docstrings educativos, una puntuación CVSS inventada y una estructura Python de estilo casi didáctico. Google también indicó que no cree que se haya usado Gemini, aunque tiene alta confianza en que el actor utilizó algún modelo de IA para apoyar el descubrimiento y la weaponization de la vulnerabilidad.
Por qué el cambio de APT45 merece atención
APT45 se sigue desde hace años como un grupo de amenazas vinculado a Corea del Norte, con actividades de espionaje, obtención de ingresos e inteligencia estratégica. Lo que GTIG destacó esta vez fue su forma de usar IA: análisis masivo, repetitivo y recursivo de CVE, validación de PoC exploit y acumulación de capacidades de ataque más fiables.
Eso no es lo mismo que pedirle a la IA que escriba un script.
Si una organización puede conectar IA con triaje de vulnerabilidades, validación de PoC, ajuste de payloads y entornos de prueba, cambia su cuello de botella humano. Antes, cuántas vulnerabilidades podía estudiar un equipo dependía del número de investigadores, su experiencia y el tiempo disponible. Ahora la IA puede absorber parte de la lectura repetitiva, el resumen, las pruebas de variantes y el juicio inicial, dejando a las personas más tiempo para seleccionar objetivos, confirmar explotabilidad y preparar la entrega.
Para los defensores, esto significa que la ventana de exposición de vulnerabilidades conocidas se acorta.
Después de que se divulga un CVE, los atacantes no tienen que leer desde cero el aviso, revisar el patch diff, montar el entorno y arreglar un PoC manualmente. La IA puede ayudar a entender impacto, generar ideas de prueba, depurar fallos y resumir diferencias entre versiones objetivo. Aunque el resultado aún requiera corrección humana, el rendimiento total sube.
Esto no significa que la IA pueda hackearlo todo sola
No hace falta interpretar esto como prueba de que la IA ya puede completar intrusiones enteras por sí sola.
El informe de GTIG dice algo más concreto: varias fases de la cadena de ataque están siendo aceleradas por IA. Investigación de vulnerabilidades, ofuscación de malware, reconocimiento, ingeniería social, operaciones de información, automatización de UI móvil y abuso de cadena de suministro ya muestran señales de participación de IA.
Pero la IA todavía falla. Puede alucinar vulnerabilidades, juzgar mal la explotabilidad, generar código que no funciona o perderse en lógica de autorización empresarial compleja. El peligro real no es que la IA sea perfecta, sino que los atacantes pueden probar barato. Cuando el ensayo masivo es suficientemente barato, las salidas malas se filtran y las útiles entran en la operación.
Por eso importan casos como APT45. Los grupos estatales o cercanos al Estado tienen objetivos y paciencia. Si la IA reduce el trabajo repetitivo, pueden dedicar más recursos a objetivos de alto valor.
La defensa debe mirar menos “si hay zero-day” y más “cuánto dura la ventana”
Muchas empresas solían dividir el riesgo en dos grupos: vulnerabilidades conocidas mediante gestión de parches y zero-days mediante defensa en profundidad. Cuando la IA entra en la investigación de vulnerabilidades, esa frontera se vuelve menos clara.
Las preguntas prácticas son:
- Tras publicarse un nuevo CVE, ¿cuánto tarda un atacante externo en producir un exploit utilizable?
- ¿Puede el inventario de activos decir el mismo día qué sistemas están afectados?
- ¿Pueden WAF, EDR, logs e identidad detectar intentos anómalos?
- ¿Los sistemas de alto riesgo usan MFA, mínimo privilegio y aislamiento de red por defecto?
- ¿Los componentes open source, plugins de AI agent y conectores de terceros entran en la revisión de cadena de suministro?
Los zero-days asistidos por IA no invalidan la seguridad básica. Al contrario, castigan los entornos donde esa base lleva demasiado tiempo descuidada.
Si el ciclo de parches es lento, el inventario no está claro, la exposición a internet no tiene dueño, los logs no se pueden consultar y los permisos de cuentas son excesivos, que el atacante use IA solo cambia la eficiencia. El problema ya existía.
La cadena de suministro de IA también es superficie de ataque
GTIG también señaló que los atacantes empiezan a mirar el ecosistema de software de IA: agent skills, conectores de datos de terceros, librerías wrapper open source y frameworks de automatización. El riesgo no siempre viene de que el modelo sea comprometido. También puede venir de herramientas contaminadas alrededor del modelo.
Esto importa para cualquiera que use AI coding, AI Agent o plugins de automatización.
Un skill malicioso, una dependencia con backdoor o un conector con permisos excesivos pueden convertir un sistema de IA de ayudante en ruta de ejecución para el atacante. Cuando un agent puede acceder a archivos, navegador, terminal, cuentas cloud o datos empresariales, la revisión de cadena de suministro no puede quedarse en la capa tradicional de aplicaciones.
Como mínimo:
- No instalar agent skills ni plugins de origen dudoso.
- Aislar herramientas que ejecutan comandos, leen archivos o acceden a secretos.
- No ejecutar scripts generados por IA sin revisar directamente en producción.
- Escanear dependencias, GitHub Actions, paquetes PyPI / npm y componentes de proyectos de IA.
- Aplicar mínimo privilegio y monitoreo de filtraciones a model API keys, secretos cloud y GitHub Token.
Consejos prácticos para equipos de seguridad
Primero, adelantar la respuesta a vulnerabilidades. Los CVE de alto riesgo no deberían esperar a una ventana mensual de parches, sobre todo en VPN, gateways, paneles de administración, sistemas de identidad, CI/CD y herramientas de administración remota.
Segundo, construir un inventario de activos consultable. Si la IA ayuda a los atacantes a ubicar objetivos más rápido, los defensores también deben responder rápido: ¿tenemos este sistema, qué versión y dónde está expuesto?
Tercero, complementar firmas con detección de comportamiento. Los exploits y malware generados por IA pueden cambiar rasgos superficiales, pero bypass de autenticación, inicios de sesión anómalos, exploración masiva, patrones de solicitudes fallidas y elevación de privilegios dejan huellas de comportamiento.
Cuarto, incluir las herramientas de IA en la gobernanza de seguridad. Coding agents, browser agents, document agents, scripts de automatización y mercados de plugins internos necesitan aprobación, revisión, logs y rollback.
Quinto, no reducir la defensa con IA a comprar un modelo de seguridad. Lo útil es poner IA en priorización de vulnerabilidades, análisis de logs, evaluación de impacto de parches, revisión de código y comprobación de baselines de configuración, para que la velocidad defensiva también suba.
Resumen
El informe de GTIG envía una señal clara: la IA está acelerando el ritmo del ataque y la defensa.
El zero-day asistido por IA muestra que los fallos lógicos y bypasses de autenticación pueden ser más fáciles de detectar con modelos. El caso APT45 muestra que grupos maduros ya usan IA para analizar CVE y validar PoC a escala. PROMPTSPY, la ofuscación generada por IA y los ataques a la cadena de suministro de agents muestran que la IA está entrando en la cadena de herramientas ofensivas.
No es el fin del mundo, pero tampoco es una noticia cualquiera.
Para las organizaciones, la respuesta práctica no es el pánico. Es hacer que parches, activos, logs, identidad, cadena de suministro y permisos de herramientas de IA sean más rápidos, claros y verificables. La IA aumenta la velocidad de prueba de los atacantes. Los defensores también deben aumentar la velocidad de descubrimiento, juicio y remediación.