Cómo un actor potenciado por IA vulneró más de 600 dispositivos FortiGate sin usar un exploit

Entre el 11 de enero y el 18 de febrero de 2026, un actor de habla rusa con motivación financiera comprometió más de 600 dispositivos de firewall FortiGate en más de 55 países, y lo hizo sin explotar ni una sola vulnerabilidad del producto. Amazon Threat Intelligence, que publicó la investigación el 20 de febrero de 2026, afirma que el actor encontró interfaces de administración expuestas a internet en los puertos 443, 8443, 10443 y 4443 y accedió con contraseñas reutilizadas habitualmente en cuentas sin autenticación multifactor. Las configuraciones de dispositivos que extrajo contenían credenciales SSL-VPN con contraseñas recuperables, credenciales de administrador, política de firewall y topología de red. En toda la operación se usaron grandes modelos de lenguaje comerciales, que escribieron herramientas de reconocimiento y redactaron planes de ataque; según el relato de un investigador independiente que encontró el propio servidor del actor, uno de los modelos también estaba configurado para ejecutar comandos ofensivos. Este incidente es una entrada en el Orca AI Incident Archive, que contiene el registro completo, sus fuentes y su calificación, junto con los casos adyacentes de la serie.

Lo que Amazon informó y cómo se enteró

El informe, «Un actor de amenazas aumentado por IA accede a dispositivos FortiGate a gran escala», se atribuye a CJ Moses, CISO de Amazon Integrated Security, y se publicó en el AWS Security Blog el 20 de febrero de 2026. Su primer hallazgo sustantivo es negativo: «No se observó explotación de vulnerabilidades de FortiGate». El acceso inicial fue en todo momento basado en credenciales: escaneo sistemático de interfaces de administración en los cuatro puertos anteriores, seguido de intentos de autenticación mediante credenciales reutilizadas con frecuencia.

Lo que hizo visible la campaña fue la propia seguridad operativa del actor. Amazon afirma que identificó la infraestructura que alojaba las herramientas maliciosas mediante labores rutinarias de inteligencia de amenazas, y que el mismo servidor contenía planes de ataque generados por IA, configuraciones de víctimas y el código fuente de herramientas personalizadas, almacenados sin cifrar. Ese descuido le dio a Amazon una visión casi completa de la metodología. «Es como una línea de montaje impulsada por IA para el cibercrimen», dice el informe.

Los archivos de configuración robados son el punto de pivote desde el dispositivo hacia la red que hay detrás. Según Amazon, contienen credenciales de usuario de SSL-VPN con contraseñas recuperables, credenciales administrativas, topología de red e información de enrutamiento completas, políticas de firewall que revelan la arquitectura interna y configuraciones de pares de VPN IPsec. El actor escribió scripts de Python asistidos por IA para analizarlos, descifrarlos y organizarlos.

La postexplotación, en palabras de la propia Amazon

Una vez dentro, el actor siguió una ruta estándar y bien documentada. Su documentación operativa, escrita en ruso, describe el uso de Meterpreter con el módulo mimikatz para ejecutar ataques DCSync contra controladores de dominio y extraer hashes de contraseñas NTLM de Active Directory. En compromisos confirmados, obtuvo bases de datos completas de credenciales de dominio. Amazon señala al menos un caso en el que la cuenta de Administrador de dominio utilizaba una contraseña en texto plano que se había reutilizado de la configuración de FortiGate o era débil de forma independiente.

A partir de ahí, las técnicas documentadas son pass-the-hash y pass-the-ticket contra infraestructura adicional, retransmisión NTLM mediante herramientas de envenenamiento estándar y ejecución remota de comandos en hosts Windows. El actor atacó específicamente servidores Veeam Backup & Replication con scripts de PowerShell, herramientas de descifrado compiladas e intentos contra vulnerabilidades conocidas de Veeam —un comportamiento que Amazon describe como "coherente con operaciones previas al ransomware", aunque el informe no registra que se haya desplegado ransomware.

Las notas del actor mencionan varias CVE, incluidas CVE-2019-7192, CVE-2023-27532 y CVE-2024-40711. BleepingComputer, que cubrió el informe el 21 de febrero de 2026, identifica la primera como una falla de ejecución remota de código de QNAP y las dos últimas como problemas de Veeam. Ninguna de ellas fue la vía de entrada. Más revelador aún, las mismas notas registran fallos repetidos: servicios ya parcheados, puertos cerrados, exploits que no aplicaban al sistema operativo objetivo. Para una víctima confirmada, la propia evaluación del actor concluyó que la infraestructura clave estaba "bien protegida" y "sin vectores de explotación vulnerables".

Vale la pena señalar claramente dos límites de la atribución. Amazon afirma que el actor «no se conoce que esté asociado con ningún grupo de amenazas persistentes avanzadas con recursos patrocinados por el Estado», y que no se observó que la infraestructura de AWS estuviera involucrada en la campaña.

Donde en realidad se sentó la IA

La descripción que hace Amazon de la capa de IA es específica sobre los roles, pero guarda silencio sobre los productos. El actor utilizó al menos dos proveedores comerciales distintos de LLM, según el informe: uno como desarrollador principal de herramientas, planificador de ataques y asistente operativo, y un segundo como planificador complementario cuando el actor necesitaba ayuda para pivotar dentro de una red concreta. En una instancia observada, el actor envió una topología interna completa —direcciones IP, nombres de host, credenciales confirmadas y servicios identificados— y solicitó un plan paso a paso para llegar a sistemas que sus herramientas existentes no podían tocar.

Las pruebas que aporta Amazon de que las herramientas fueron escritas por una máquina son de estilo, no forenses. Enumera comentarios redundantes que se limitan a repetir los nombres de las funciones, una arquitectura que invierte más en el formato de salida que en la funcionalidad, JSON analizado mediante coincidencia de cadenas en lugar de una deserialización adecuada, y capas de compatibilidad con documentación vacía. Las herramientas funcionaban para el caso concreto y limitado del actor, pero fallaban en los márgenes. El volumen, señala Amazon, normalmente implicaría un equipo de desarrollo; en este caso provenía de un único actor o de un grupo muy reducido.

Lo que el informe de AWS no contiene es ningún proveedor de modelos, ningún nombre de producto ni ninguna mención del Model Context Protocol. Esos aparecen en un segundo trabajo de investigación publicado al día siguiente.

El servidor, y los nombres que Amazon no publicó

El 21 de febrero de 2026, el blog de seguridad Cyber and Ramen publicó su propio análisis de un directorio abierto en 212.11.64[.]250:9999, alojado en AS4264 (Global-Data System IT Corporation, Zúrich), una de las dos direcciones que Amazon enumera como infraestructura de actores de amenaza. El investigador contó 1.402 archivos en 139 subdirectorios, incluidos copias de seguridad robadas de configuraciones de FortiGate, datos de mapeo de Active Directory, volcados de credenciales, plantillas de escaneo de Nuclei y herramientas de extracción de credenciales de Veeam, además de dos carpetas con el nombre de Claude que contenían más de 200 archivos de resultados de tareas, diferencias de sesión y estados de prompt en caché.

En ese análisis se nombran dos componentes personalizados. Se describe ARXON como un servidor Python de Model Context Protocol que ingiere reconocimiento por objetivo, llama a DeepSeek para generar planes de ataque y mantiene una base de conocimientos que crece con cada objetivo; también incluye scripts para la creación por lotes de cuentas VPN de FortiGate mediante SSH y la validación de credenciales de Domain Admin. CHECKER2 es un orquestador basado en Go y Docker para el escaneo paralelo de VPN, con registros que muestran 2.516 objetivos en 106 países. El investigador afirma que no se pudieron encontrar referencias públicas a ninguna de las dos herramientas, lo que indica que ambas se crearon para esta operación.

El mismo análisis describe una exposición en diciembre de 2025 del mismo servidor, esta vez con una copia de HexStrike, un framework MCP ofensivo de código abierto, y un archivo de configuración .claude que preautorizó a Claude Code para ejecutar las herramientas Impacket, Metasploit y hashcat contra credenciales de dominio incrustadas en el código que pertenecían a un empleado de una gran empresa asiática de medios de comunicación. Según el investigador, para febrero el actor había pasado de ese punto de partida de código abierto a ARXON y CHECKER2 — una progresión de aproximadamente ocho semanas.

BleepingComputer transmitió estos hallazgos en una actualización de su artículo del 21 de febrero. La distinción importa: ARXON, CHECKER2, DeepSeek y Claude Code son la interpretación del investigador de los archivos, registros y configuraciones de un directorio no protegido. Amazon, que tenía acceso independiente a la misma infraestructura, no nombró a ninguno de ellos. Ningún proveedor de modelos ha confirmado nada de ello.

Lo que está establecido, lo que se basa en una sola fuente.

Tres afirmaciones se sustentan en dos partes independientes. La propia entrada de blog de Fortinet del 6 de marzo de 2026, «Attacks at the Speed of AI», afirma que Fortinet «no observó explotación de vulnerabilidades de FortiGate» y que la campaña tuvo éxito mediante puertos de administración expuestos y credenciales débiles con autenticación de un solo factor, usando rociado de contraseñas. Eso corrobora el mecanismo de Amazon por parte del proveedor, sin que ninguna de las partes haya visto publicadas las pruebas de la otra.

Amazon es la única fuente de la escala —más de 600 dispositivos, más de 55 países, la ventana de enero a febrero— y del perfil del actor: de habla rusa, motivación financiera, nivel técnico bajo a medio, gran dependencia de la IA, escasa profundidad en la explotación posterior y seguridad operacional inadecuada. Ningún tercero ha replicado la cifra de 600.

Cyber y Ramen por sí solos constituyen la fuente de las herramientas mencionadas, los proveedores de modelos, los recuentos de archivos y los 2.516 objetivos de escaneo. Sus propios documentos probatorios confirmaron compromisos en una empresa de gas industrial en Asia-Pacífico, un proveedor de telecomunicaciones en Turquía y la empresa de medios de la exposición de diciembre, con reconocimiento que hace referencia a Corea del Sur, Egipto, Vietnam y Kenia — un conjunto de víctimas confirmadas en al menos cinco países, muy por debajo de los 55 que cita Amazon. Los dos números miden cosas diferentes, y ninguno se ha conciliado públicamente.

La respuesta de Fortinet, y la escala que no confirmó

La publicación de Fortinet, escrita por Carl Windsor y fechada el 6 de marzo de 2026, coincide con Amazon en el mecanismo y discrepa en la magnitud. «Según la investigación y el monitoreo de Fortinet, unos pocos clientes se vieron afectados por este ataque», se lee. «Estamos en proceso de notificar a esas organizaciones». No confirma 600 dispositivos, no adopta el recuento de países de Amazon y no identifica al actor.

El planteamiento de Fortinet es que la técnica es antigua y la automatización es nueva: rociado de contraseñas contra dispositivos de borde mal protegidos, ahora impulsado por conversaciones sin código basadas en prompts. Afirma que el ataque «habría sido imposible con MFA implementada» y «muy poco probable que tuviera éxito» con una política de complejidad de contraseñas habilitada. También publicó indicadores: acceso de administrador desde 212[.]11.64[.]250 o 185[.]196.11[.]225, la creación de cuentas llamadas fortiuser, fortinet-support o fortinet-tech-support, configuraciones o usuarios de VPN inesperados, y scripts programados para ejecutarse como mecanismo de persistencia.

Esto es una divergencia de alcance, no una disputa sobre si la campaña ocurrió. Nadie de los nombrados en el registro impugna la intrusión; el archivo la califica con A, sin marca de disputa, y registra un daño real.

¿Qué cambió después?

No hay ningún CVE ni ningún parche, porque no había ninguna vulnerabilidad. La remediación consiste en configuración, y ambas organizaciones convergieron en la misma lista. Amazon afirma que compartió indicadores de compromiso con los socios correspondientes, colaboró con socios del sector y ayudó a las organizaciones a adoptar medidas que redujeron la eficacia del atacante; el informe no indica cuántas organizaciones fueron notificadas. Fortinet afirma que está notificando directamente a los clientes afectados.

La orientación técnica es coherente en ambos casos: retirar el acceso administrativo de las interfaces expuestas a Internet y gestionarlo mediante una vía interna o fuera de banda; exigir MFA en el acceso administrativo y en el acceso VPN; aplicar complejidad de contraseñas; rotar las credenciales de SSL-VPN en cualquier dispositivo cuya interfaz de administración haya estado o pueda haber estado accesible; auditar la reutilización de contraseñas entre cuentas VPN de FortiGate y Active Directory; y aislar la infraestructura de copias de seguridad, aplicarle parches y mantener copias inmutables.

Para la detección, Amazon señala la actividad de DCSync (Event ID 4662 con GUID relacionados con la replicación), las nuevas tareas programadas con nombres que imitan servicios legítimos de Windows, las conexiones de administración remota inusuales procedentes de grupos de direcciones VPN, los artefactos de envenenamiento de LLMNR y NBT-NS, y el acceso no autorizado a almacenes de credenciales de copia de seguridad. También advierte de que la detección basada en firmas tiene un valor limitado en este caso, porque las herramientas se componen de utilidades legítimas de código abierto —Impacket, gogo, Nuclei— que aparecen en pruebas de penetración habituales.

Por qué el récord es un hito

El archivo lo marca como una entrada histórica, y la razón se ve en el contraste entre {{1}}lo que el actor logró{{/1}} y {{2}}lo que el actor podía hacer{{/2}}. Un único operador o un grupo muy pequeño, evaluado con un nivel de habilidad de bajo a medio, llevó a cabo intrusiones concurrentes en decenas de países, produjo un conjunto de herramientas que normalmente implicaría a un equipo de desarrollo y generó planes de ataque específicos para cada objetivo con la rapidez suficiente para mantener varias intrusiones activas al mismo tiempo.

El mismo informe proporciona el techo. El actor no podía compilar exploits personalizados, no podía depurar intentos fallidos de explotación y no podía improvisar cuando un plan se topaba con un objetivo endurecido, así que pasaba al siguiente en lugar de persistir. Su código generado por IA fallaba en los márgenes. Sus notas operativas son un registro de servicios parcheados y puertos cerrados. Lo que los modelos eliminaron fue trabajo, no juicio: el reconocimiento, el análisis, la documentación y la planificación se automatizaron; las partes que requerían adaptación quedaron fuera de alcance.

Eso también explica por qué las preguntas abiertas son anodinas y específicas. Cuántas organizaciones notificó realmente Fortinet resolvería la diferencia entre «unos pocos clientes» y más de 600 dispositivos. Un segundo examen del directorio ARXON, independiente del investigador que lo encontró, resolvería qué era el conjunto de herramientas y a qué modelos llamaba. Hasta entonces, el registro respalda una conclusión firme sobre el método y una mucho más débil sobre la magnitud.