El 2 de septiembre de 2026, Unit 42 de Palo Alto Networks publicó los detalles de una investigación sobre la intrusión en una red corporativa. La cifra que sostenía el informe: el atacante empezó en un servicio web de acceso público y terminó con acceso de nivel root en todo el entorno en menos de diez horas, un trabajo que a un equipo humano le lleva aproximadamente dos semanas.

El detalle que importa más es lo que no intervino. Ningún zero-day. Ninguna técnica excepcional. La intrusión utilizó más de 50 técnicas ya catalogadas en el marco MITRE ATT&CK, es decir, técnicas documentadas y publicadas que los defensores conocen. Lo que cambió no fue el método, sino el ritmo. En lugar de ejecutar cada etapa a mano, el operador dirigió agentes de IA que vigilaban, evaluaban, actuaban y replanificaban en un único ciclo ininterrumpido que nunca se detenía y nunca dormía.

Qué ocurrió dentro de esas diez horas

La secuencia tal como la describe el informe:

  1. Entrada. Se vulneró un servicio web de acceso público y, desde ahí, se abrió un túnel hacia la red interna.
  2. Reconocimiento. Un agente automatizado mapeó los microservicios internos sin intervención humana.
  3. Recolección de secretos. Unos subagentes rastrearon los repositorios de código en busca de tokens de acceso y contraseñas de servicios escritos directamente en el código.
  4. Escalada. Esos tokens abrieron el sistema de gestión de secretos, que entregó credenciales administrativas maestras con acceso root en todo el entorno.
  5. Los pipelines. Los pipelines de compilación y despliegue fueron secuestrados mediante flujos de trabajo personalizados para exfiltrar claves de acceso a la nube.
  6. La inversión. Esas claves se usaron para convertir los propios endpoints de IA de la víctima en infraestructura del atacante tras el compromiso.

Vuelva a leer ese último paso. La propia suscripción de IA de la empresa se convirtió en una herramienta en manos de quien entró, funcionando con su cuenta y con cargo a su factura. Es un patrón nuevo que vale la pena añadir a su registro de riesgos: cada clave de API de un modelo de IA es a la vez un activo operativo y una partida de gasto.

La cifra que le concierne no son las diez horas

Diez horas es una cifra llamativa, pero procede de un solo incidente. La cifra que de verdad debería cambiar su planificación aparece en el CrowdStrike 2026 Global Threat Report, que mide el tiempo de breakout: el intervalo entre el primer acceso de un atacante y el momento en que empieza a moverse hacia otros sistemas dentro de la red.

  • El tiempo medio de breakout del eCrime ha bajado a 29 minutos, un aumento de velocidad del 65% interanual.
  • El caso más rápido registrado: 27 segundos.
  • Un aumento del 89% en los ataques atribuidos a adversarios que usan IA.
  • El 82% de las detecciones en 2025 fueron sin malware, es decir, el atacante inicia sesión con credenciales válidas en lugar de plantar un virus.
  • Un aumento del 266% en las intrusiones orientadas a la nube por parte de actores vinculados a Estados.

Lo que significan 29 minutos en la práctica: un plan de respuesta que da por hecho que alguien verá la alerta por la mañana y que el equipo se reunirá después de comer es un plan para una época que ya terminó. Y la cifra del 82% dice algo todavía más duro. Su antivirus no ve el ataque porque el ataque no lleva nada que pueda ver. Una intrusión moderna no es un archivo malicioso que llega, es una cuenta legítima usada de forma indebida.

Por qué funcionó: secretos escritos en el código

Los agentes no rompieron ningún cifrado ni inventaron ninguna vulnerabilidad. Encontraron contraseñas escritas donde nunca deberían estar, dentro de los archivos del proyecto. Un solo token válido abrió el gestor de secretos, y el gestor de secretos lo abrió todo.

No es un problema reservado a las grandes empresas. Repase esta lista con sus propios proyectos:

  • Claves de la pasarela de pago o del servicio de mensajería en un archivo de configuración guardado junto al código.
  • Una contraseña de base de datos dentro de un viejo script de despliegue que nadie abre.
  • Tokens de acceso de un empleado o de un desarrollador externo que se fue hace un año y que siguen siendo válidos.
  • Un repositorio que era privado y pasó a ser público tras una migración o un cambio de cuenta.
  • Una copia de seguridad de un archivo de configuración en el portátil de alguien.

La diferencia entre un agente y un atacante humano aquí no es la inteligencia, sino la paciencia y la capacidad. El agente lee el repositorio entero, cada rama y cada versión antigua del historial, no se salta ningún archivo y termina en minutos. Cualquier secreto que guardó una vez y borró después sigue vivo en el historial del repositorio, y ese historial es exactamente donde busca.

Qué hacer esta semana

Cinco pasos. El primero no necesita presupuesto ni proveedor externo:

  1. Analice sus repositorios en busca de secretos. Las herramientas de detección de secretos están disponibles e integradas en las principales plataformas de código. Ejecútelas sobre todo el historial, no solo sobre la versión actual.
  2. Haga de la rotación de claves una rutina, no una medida de emergencia. Una clave que no ha cambiado en dos años es una clave filtrada que todavía no ha descubierto. Y cuando la rote tras una filtración, rótela en todos los lugares donde se usaba, no en uno solo.
  3. Prepare un único manual de revocación. Es la recomendación directa de Unit 42: poder ejecutar una contención sincronizada que revoque a la vez credenciales, sesiones OAuth, pipelines de CI/CD y cuentas en la nube. Si revoca solo la mitad, le regala al atacante tiempo para volver a entrar por la otra mitad.
  4. Gobierne la IA como infraestructura central. Mantenga un inventario de cada modelo y cada clave en uso, establezca límites de solicitudes, aplique el principio de mínimo privilegio y active el registro de diagnóstico. El informe lo recomienda explícitamente, y es lo que convierte el incidente anterior de un desastre silencioso en una alerta temprana.
  5. Exija revisión de código por varias personas y protección de ramas. Sobre todo en los repositorios de infraestructura como código, ya que esa es la puerta por la que un cambio de una sola línea planta una puerta trasera. Junto a ello, vigile el comportamiento y no las firmas: las ráfagas de solicitudes a la API y los cambios rápidos de estado son la huella de un agente automatizado.

En el contexto saudí, estos pasos no son una buena práctica opcional. Los Controles Esenciales de Ciberseguridad de la Autoridad Nacional de Ciberseguridad (NCA) incluyen dominios explícitos para la gestión de identidades y accesos y para la seguridad de los cambios y del desarrollo, y la responsabilidad de proteger los datos personales recae en la organización según la Ley de Protección de Datos Personales (PDPL). Una intrusión que empezó con una clave escrita en el código fuente no reduce en nada esa responsabilidad.

La visión de Origami

Leemos este incidente como el fin de una idea: que la seguridad es un conjunto de herramientas que se compran. El atacante aquí nunca se enfrentó a un firewall ni esquivó un antivirus, porque ninguno de los dos se interponía en su camino. Entró con una clave válida que encontró escrita y actuó con permisos que se le habían concedido de verdad. Ningún producto que compre arregla eso. Lo que lo arregla es la disciplina en cómo se escribe el código, cómo se guardan los secretos y cómo se conceden y retiran los permisos.

Un patrón que vemos una y otra vez con los clientes: los secretos más peligrosos rara vez están en el sistema principal. Están en los proyectos secundarios, un script de migración de datos escrito una sola vez, un panel interno de informes que construyó un contratista, una integración temporal con un proveedor que lleva dos años funcionando. Nunca pasan por una revisión de seguridad porque nadie los cuenta como sistema. El atacante no hace esa distinción. Cuando revisamos el entorno de un cliente empezamos exactamente aquí: dónde están las claves, quién tiene cada permiso y qué pasa si una clave se filtra esta noche. Si quiere una revisión desde ese ángulo, nos encontrará en la página de contacto.

Conclusión

El método de ataque no cambió. Su velocidad sí. Más de 50 técnicas conocidas se ejecutaron en menos de diez horas porque unos agentes automatizados las ejecutaron sin pausa, y el tiempo medio de breakout dentro de la red es ahora de 29 minutos. Una defensa que depende de que alguien se dé cuenta a tiempo ya no basta. Empiece por la pregunta más sencilla y más difícil: ¿sabe dónde están sus claves ahora mismo y quién puede leerlas?

Fuentes