Agentes de IA reducen una brecha de dos semanas a 10 horas, y entregan una auditoría de 80 páginas
Unit 42 de Palo Alto Networks afirma que un atacante usó modelos de frontera y frameworks agénticos para vulnerar una empresa en menos de 10 horas. Sin día cero.
En esta página
Durante años, el discurso de la IA en seguridad ha sido defensivo: triaje más rápido, respuesta automatizada, menos analistas agotados por la fatiga de alertas. Esta semana, la unidad de respuesta a incidentes Unit 42 de Palo Alto Networks publicó un informe que muestra la otra cara de la moneda. Un atacante humano, armado con modelos de IA de frontera y frameworks agénticos específicos de ataque, vulneró una red corporativa, recolectó credenciales de root y se movió por su infraestructura de nube en menos de 10 horas, un trabajo que la unidad calcula que a un equipo rojo humano le llevaría unas dos semanas.
Lectura relacionada: La IA Muse de Meta entregó todo su sistema de archivos tras una ligera insistencia · Un modelo Gemini de Google escapó de las pruebas y hackeó tres empresas.
El informe, publicado el 2 de septiembre, es uno de los relatos más claros hasta ahora de cómo se ve realmente la ofensiva a "velocidad de máquina" en el mundo real.
El ataque, paso a paso
Lo llamativo es lo corrientes que eran las debilidades subyacentes. No hubo un día cero novedoso ni técnicas poco comunes. El resumen de Unit 42 es tajante: la velocidad provino de la eficiencia operativa asistida por IA, no del hacking de élite.
La intrusión siguió una secuencia ya conocida, pero a un ritmo que los humanos rara vez sostienen:
- Acceso inicial. El atacante vulneró un servicio web de acceso público y lo usó para abrir un túnel hacia la red corporativa.
- Reconocimiento. Un agente automatizado mapeó los microservicios internos y descubrió servicios accesibles en todo el entorno.
- Cosecha de credenciales. Subagentes peinaron repositorios de código fuente en busca de tokens codificados, contraseñas de servicio y secretos.
- Escalada de privilegios. Con los tokens obtenidos, los agentes llegaron a la plataforma de gestión de secretos y extrajeron credenciales administrativas maestras, obteniendo acceso root.
- Movimiento lateral. "Agentes pivote especializados" validaron el acceso a entornos de nube, identidad, CI/CD, contenedores y SaaS.
- Secuestro de infraestructura. El atacante abusó de flujos de trabajo personalizados en una aplicación de código empresarial para exfiltrar claves de acceso a la nube e intentó insertar puertas traseras en configuraciones de Terraform. Los controles de protección de ramas bloquearon la manipulación de la infraestructura como código, una de las pocas cosas que funcionó.
- Reutilización de la víctima. Con las claves de nube robadas, el atacante invocó los propios endpoints de IA de la víctima, convirtiendo el cómputo de la empresa en infraestructura posterior al compromiso.
Ese último paso merece una segunda mirada. Al ejecutar su orquestación a través de los servicios de IA legítimos de la víctima, los atacantes podían mezclar actividad maliciosa con tráfico de modelos aparentemente normal, al tiempo que trasladaban la factura de cómputo a la organización que acababan de robar.
La señal: más de 50 técnicas ATT&CK en un solo bucle
Unit 42 contó más de 50 técnicas distintas de MITRE ATT&CK comprimidas en un único bucle automatizado. Los métodos eran en su mayoría conocidos. La diferencia fue que los agentes monitoreaban la salida de las herramientas, evaluaban opciones, actuaban y volvían a planificar en tiempo real, sin esperar a que un humano leyera una pantalla.
Cómo supieron que había IA
La atribución siempre es resbaladiza, pero Unit 42 señaló varios indicadores compatibles con operaciones agénticas:
- Llamadas paralelas a varios modelos de lenguaje grandes.
- Archivos Markdown estructurados usados para pasar contexto entre agentes y sesiones.
- Scripts de automatización personalizados con rasgos de código generado por IA.
El operador humano mantuvo el control de los objetivos y las decisiones consecuentes. Los agentes se encargaron del reconocimiento, la recolección de credenciales, la escalada de privilegios y la persistencia.
La parte que suena a sátira
Tras alcanzar sus objetivos, el atacante hizo que los agentes compilaran un informe técnico de 80 páginas documentando la postura de seguridad de la víctima y "docenas de hallazgos explotados": un informe de pruebas de penetración automatizado, entregado por el intruso.
Es tentador tomarlo como una fanfarronada. Pero también es una señal de lo barato que puede productivizarse hoy la capacidad ofensiva. La misma automatización que produce una auditoría de nivel profesional para un cliente puede producirla para una víctima.
Qué deberían hacer los defensores
Las recomendaciones de Unit 42 tienen menos que ver con defensas de IA exóticas y más con el ritmo operativo, porque la ventaja del atacante es la velocidad, y la única respuesta a la velocidad es la automatización.
Los playbooks de contención automatizados deberían, en paralelo:
• revocar credenciales
• terminar sesiones de OAuth
• congelar pipelines de CI/CD
• aislar cuentas de nube
Tratar la IA como infraestructura crítica:
• inventariar cada endpoint de modelo, clave de API y pasarela MCP
• aplicar límites de tasa y políticas de mínimo privilegio
• hacer que las credenciales sean de vida corta
La conclusión incómoda
Los autores sostienen que la única forma de defender a velocidad de máquina es luchar a velocidad de máquina, con agentes de IA encargándose de la contención. Es una admisión significativa: la herramienta defensiva y la ofensiva son, cada vez más, la misma tecnología apuntando en direcciones opuestas.
La lección más amplia es conocida pero ahora más urgente. Los repositorios, los pipelines de CI/CD, la infraestructura como código y la gestión de secretos forman parte hoy de la superficie de ataque. Los agentes no descubrieron esta semana una nueva clase de vulnerabilidad. Simplemente recorrieron las antiguas más rápido de lo que un equipo humano podía responder.
Etiquetas
TPW Editorial
Redacción
El equipo editorial de TechPastWeek investiga y edita cada artículo que publicamos. Cada historia se contrasta con fuentes primarias y secundarias fiables, y un editor la revisa antes de publicarse.
