CyberStrikeAI en el mundo real: un orquestador de LLM alcanzó el nivel de administrador de dominio en objetivos del sector educativo en América Latina y África

El 2 de noviembre de 2026, Kaspersky publicó un informe de Securelist y un comunicado de prensa en los que describía intrusiones en organizaciones del sector educativo de varios países de América Latina y África en las que el trabajo de postexplotación fue dirigido por un modelo de lenguaje grande. La herramienta era CyberStrikeAI, un marco de pruebas de penetración de código abierto basado en Go cuyo servidor de mando y control aloja un LLM que selecciona herramientas y escribe comandos mientras un implante común los ejecuta en el host víctima. En el único caso que Kaspersky reconstruye en detalle, un operador humano entró a través de un Microsoft SQL Server comprometido, hizo una pausa de dos semanas y luego dejó actuar al agente: las cuentas de administrador de dominio cayeron en un plazo de tres a cuatro días, y la última etapa —movimiento lateral, volcado masivo de credenciales y exportación de una base de datos— terminó en menos de una hora. Kaspersky no nombra ninguna institución ni ningún país, no da una cifra de víctimas y afirma que observó la actividad entre septiembre y octubre de 2026. El registro completo de esta campaña, con su calificación de gravedad, su nivel de confianza y su lista completa de fuentes, se archiva en el Orca AI Incident Archive, junto con las demás entradas sobre intrusiones asistidas por IA.

Lo que Kaspersky publicó realmente

El documento principal es «CyberStrikeAI in the wild: the use of AI in real-world attacks on organizations», publicado en Securelist el 2 de noviembre de 2026 y atribuido a Kirill Antonov, Vladislav Vlasov y Dmitry Chizhmak, del equipo de investigación de amenazas de Kaspersky. Lo acompaña el comunicado de prensa de Kaspersky, emitido el mismo día, que resume los mismos hallazgos. El grado de confianza A del archivo describe hasta qué punto coinciden ambos documentos entre sí y cuán específico es el detalle técnico; no es una declaración de que una segunda organización haya verificado la intrusión de forma independiente.

La cobertura secundaria de este informe no proporciona esa segunda organización. Cybersecuritynews.com, Cyberpress, SecurityOnline y TechTrends Kenya, con sede en Nairobi, publicaron artículos entre el 2 y el 3 de noviembre de 2026, y cada uno deriva del comunicado de Kaspersky y no de una investigación propia; el artículo del medio keniano se construye en torno a la misma cita del comunicado de prensa de Nikita Nazarov, jefe de Exploración de Amenazas de Kaspersky. A 9 de noviembre de 2026, ninguna universidad afectada, ministerio de educación ni equipo nacional de respuesta a emergencias informáticas había confirmado públicamente las intrusiones, y Kaspersky no ha publicado las identidades de las víctimas. Esa ausencia es en sí misma parte del registro: lo que se documenta en detalle son las técnicas operativas, no el daño a ninguna institución nombrada.

La declaración de alcance de Kaspersky es deliberadamente limitada. Las víctimas confirmadas, en sus palabras, fueron "organizaciones del sector educativo en varios países de África y América Latina". No dice cuántas, qué países ni cómo se detectó la campaña en primer lugar; solo que el equipo la encontró "como parte del monitoreo proactivo de amenazas".

Aquí importa una distinción, porque es fácil difuminarla. Organizaciones independientes ya han informado de CyberStrikeAI en intrusiones reales, pero no en estas intrusiones. Team Cymru vinculó la infraestructura que ejecutaba la herramienta con la campaña de enero a febrero de 2026 contra más de 600 dispositivos FortiGate, tras observar 21 direcciones IP únicas que la servían entre el 20 de enero y el 26 de febrero de 2026. La unidad TrendAI de Trend Micro, en una investigación publicada el 23 de octubre de 2026, describió a un operador que ejecutaba 44 agentes CyberStrikeAI coordinados que sometieron a al menos 19 organizaciones identificables, al menos 16 de ellas en Japón, a actividad de validación en un breve intervalo de tiempo ese octubre. La nota de investigación de Cloud Security Alliance del 28 de octubre de 2026 reúne ambas y concluye que ninguna fuente publicada había vinculado aún las campañas separadas de CyberStrikeAI a un único actor. Ese conjunto de trabajos corrobora la premisa —que este marco se está utilizando para atacar redes reales— y no dice nada sobre las víctimas del ámbito educativo de América Latina y África en el informe de Kaspersky.

La herramienta, y dónde se sentó realmente la IA

CyberStrikeAI, tal como lo describe Kaspersky, es «una plataforma modular de código abierto escrita en Go para automatizar pruebas de penetración». Su decisión de diseño definitoria es que toda la capa inteligente reside en el servidor de control del atacante, no en la máquina de la víctima. Las utilidades de reconocimiento y explotación, la gestión de webshells, la asignación de tareas a los agentes y la lectura de resultados se exponen al modelo como herramientas MCP dentro de un único proceso de servidor, y es el modelo el que decide cuál de ellas invocar a continuación.

El implante es la otra mitad, y es deliberadamente tonto. Kaspersky escribe que es «un agente C2 clásico sin funcionalidad de IA: sin claves de API, sin llamadas a las API de servicios de IA y sin lógica autónoma». Consulta al listener por HTTP/S, TCP o WebSocket, ejecuta comandos de shell y accede al sistema de archivos. No es un modelo que se ejecute en la red de una víctima y nunca contacta con un proveedor de IA. La división del trabajo es la frase que Kaspersky utiliza para explicar todo el esquema: «Las decisiones se distribuyen en dos niveles: el operador define la tarea en términos generales, mientras que el modelo determina cómo ejecutarla».

Se mantiene el control humano en lugar de eliminarlo. Kaspersky señala un mecanismo de «humano en el bucle» mediante el cual "el operador conserva el control total sobre el proceso", y que los comandos generados por el modelo "pueden requerir aprobación o corrección manual antes de ejecutarse". La IA escribe los pasos; una persona todavía puede rechazarlos.

Una intrusión reconstruida, en el orden en que Kaspersky le asigna fecha

El informe sigue un único incidente dentro de la campaña, y su primera fase parece un trabajo manual ordinario con teclado. Los comandos en los sistemas de la víctima provinieron del proceso sqlservr.exe, lo que apunta a "un SQL Server comprometido (versión 16.0.1000)" como la probable vía de entrada. Luego, el operador recopiló información básica del host, desplegó herramientas y mapeó la red manualmente. Eso llevó "casi un día", tras lo cual los atacantes permanecieron inactivos durante aproximadamente dos semanas.

La segunda fase es donde cambia el ritmo. Con el agente CyberStrikeAI desplegado, la persistencia y el reconocimiento local se realizaron "en 2 minutos": una tarea programada llamada SystemUpdate que apuntaba al implante, con una clave Run del registro en HKCU\Software\Microsoft\Windows\CurrentVersion\Run como alternativa del framework en Windows, y una entrada @reboot de crontab o una línea nohup en ~/.bashrc como sus alternativas en Linux. El reconocimiento de dominio se ejecutó "durante las siguientes 5 horas", usando scripts de PowerShell que generó el modelo y consultas LDAP contra Active Directory, incluidas las búsquedas necesarias para preparar Kerberoasting y AS-REP Roasting, y comprobaciones de LAPS, Azure y directorios .azcopy. Tras "una breve pausa de varios días", la etapa final —movimiento lateral mediante SMB y WMI, volcado masivo de credenciales y una exportación de base de datos— tardó "no más de una hora".

La línea de resumen de Kaspersky es la que vale la pena conservar: todo el ataque, «desde el despliegue del agente hasta el compromiso de los administradores de dominio», se completó en 3–4 días.

El trabajo con credenciales es un catálogo de técnicas de Windows bien conocidas más que algo nuevo: colmenas del registro copiadas con reg.exe, lsass.exe volcado mediante la función MiniDump de comsvcs.dll usando el ID de proceso en lugar de su nombre para evadir la coincidencia en la línea de comandos, y —una vez comprometida la cuenta de administrador de dominio integrada— ataques DCSync y Golden Ticket ejecutados mediante un binario de Mimikatz renombrado, wdiag2.exe. El movimiento lateral utilizó WMIExec de Impacket, carpetas administrativas compartidas y WMI, con un script de shell inversa, p1.ps1, enviado a hosts remotos y que llamaba de vuelta a 185.186.245[.]144:5501. Las cargas útiles se dividieron en fragmentos como d3.b64 y se reensamblaron con certutil, y un beacon se hizo pasar por svchosts.exe.

La recolección fue lo último. El agente generó consultas SQL adaptadas a la tarea, pero verificó los privilegios de la cuenta de base de datos antes de ejecutarlas, escaneó los recursos compartidos de red de forma recursiva antes de extraer archivos y devolvió todo por el mismo canal C2 cifrado, con los datos codificados en Base64 dentro de JSON. Las capturas de pantalla en Windows y Linux estaban disponibles, pero, según Kaspersky, solo se tomaban cuando el orquestador emitía la orden. El informe afirma que la recolección de datos «fue la etapa final del ataque: la cadena terminó allí y no observamos más actividad».

Qué se tomó y qué no dice el registro

Kaspersky documenta que el agente exportó registros de bases de datos del servidor SQL de la organización educativa y recopiló archivos de recursos de red, y describe el mecanismo en detalle. No dice cuántos registros o archivos salieron, si la exportación se completó ni de quién eran los datos que había en las tablas. Los resúmenes secundarios van más allá de lo que dice el informe en este punto: el artículo de SecurityOnline afirma que el agente «generó consultas SQL dirigidas para robar registros de estudiantes y del personal de tablas de bases de datos», mientras que el texto de Kaspersky describe las consultas contra un servidor SQL educativo sin especificar qué contenían las tablas. Los lectores deben considerar la descripción «registros de estudiantes y personal» como una caracterización secundaria, no como un hallazgo de Kaspersky.

También está ausente del registro: si alguna víctima detectó la intrusión en sí, qué hizo cada institución después, si se notificó a los reguladores o a las autoridades de protección de datos de los países afectados y si la campaña sigue en curso. Kaspersky solo dice que la recopilación de datos fue el último paso observado en los incidentes que examinó. El comunicado de prensa no contiene orientaciones de remediación para las organizaciones afectadas; sus recomendaciones están dirigidas a los defensores en general.

Atribución: qué respalda la evidencia y qué no

Kaspersky es explícito en que no puede nombrar a un actor. «Los datos disponibles no nos permiten vincular la actividad con ningún grupo de atacantes conocido, ni afirmar con certeza que el mismo operador esté detrás de ambas campañas». El artefacto en el que se apoya son los metadatos de compilación de Go dentro de los implantes, que contienen hashes de control de versiones, horas de commit y un indicador de copia de trabajo con cambios sin confirmar — «una huella única para una compilación específica». Sobre esa base, las muestras se dividen en dos grupos y, dentro de cada grupo, las cargas útiles de Windows y Linux comparten metadatos idénticos, lo que significa que provienen de la misma copia de trabajo.

Los grupos no están vinculados entre sí. «No comparten una infraestructura C2 común», y en los dos conjuntos de servidores de control se ejecutaban versiones diferentes de CyberStrikeAI. Kaspersky ofrece dos razones por las que aquí la atribución resulta difícil: el framework es de acceso público, por lo que distintos operadores podrían haber creado cargas útiles de forma independiente en condiciones similares, y los propios comandos son generados por el modelo, lo que incrementa su variedad a la vez que elimina los hábitos individuales de los que depende la atribución conductual.

Lo que queda es sugerente más que concluyente. Algunos scripts llevaban comentarios en chino, los atacantes usaron el servicio chino dnslog[.]cn para confirmar el acceso a Internet desde hosts víctimas, y la mayoría de los reinicios del servidor de control —recuperables porque el certificado TLS autofirmado se regenera en memoria en cada arranque, de modo que su campo not_before registra la hora del reinicio— cayeron dentro del horario laboral de UTC+8. CyberStrikeAI se desarrolló dentro de la comunidad china de ciberseguridad. El comunicado de prensa de Kaspersky traza la línea con claridad: estos artefactos "no establecen la identidad ni la ubicación de los atacantes", y la empresa "no pudo atribuir la actividad a un grupo de amenaza conocido ni confirmar que el mismo operador controlara toda la infraestructura identificada". Un operador de habla china es una inferencia, no un hallazgo.

Por qué Kaspersky dice que esto no es una emergencia de detección

La conclusión del informe rebate la idea de que un LLM en la cadena de ataque requiera una nueva clase de defensa. Dado que el modelo reside en el servidor del atacante, «no dejó rastro de su presencia en la infraestructura (como solicitudes de API específicas a LLM locales o patrones anómalos de consumo de recursos por parte de los hosts)». Lo que los defensores ven, en cambio, es una intrusión con forma humana: las mismas utilidades, las mismas secuencias, las mismas entradas del registro de eventos. El veredicto de Kaspersky es que «la introducción de la IA en la cadena de ataque aún no plantea desafíos fundamentalmente nuevos para la detección», que «las reglas clásicas y bien ajustadas de correlación y análisis de comportamiento son suficientes», y que la novedad «no reside en los métodos en sí, sino en la velocidad y la facilidad con que se ejecutaron».

Las detecciones publicadas siguen esa lógica en lugar de inventar otras nuevas. Kaspersky Anti Targeted Attack emite el veredicto de red Backdoor.CyberStrikeAI.HTTP.C&C sobre el tráfico del implante; una regla de detección de anomalías de red denominada «Scanning domain records via LDAP queries» detecta el reconocimiento de dominio; Kaspersky SIEM incluye más de 100 reglas que cubren las técnicas del informe, incluidas DCSync, Golden Ticket, Kerberoasting e Impacket WMIExec; y los implantes se clasifican como HEUR:HackTool.Win64.CyberStrike.gen y HEUR:HackTool.Linux.CyberStrike.gen. Las recomendaciones de Kaspersky a sus clientes son convencionales: detección y respuesta en endpoints, detección de red, inteligencia de amenazas y monitorización fuera del horario laboral o mediante un servicio gestionado.

La declaración de Nazarov en el comunicado de prensa es el mismo argumento en una sola frase: los atacantes «utilizaron un agente de IA basado en CyberStrikeAI para llevar a cabo una cadena de ataque completa y adaptar sus siguientes pasos dentro de redes comprometidas», pero «el framework seguía dependiendo de técnicas y procedimientos conocidos, incluidos el descubrimiento, el volcado de credenciales, el movimiento lateral y la recopilación y exfiltración».

Qué está establecido y qué no

Dicho claramente: el mecanismo está documentado hasta un nivel que permitiría a un defensor cazarlo mañana —la ascendencia de procesos a partir de sqlservr.exe, una tarea programada llamada SystemUpdate, el acceso a LSASS mediante comsvcs.dll, DCSync desde un equipo que no es controlador de dominio, la cabecera HTTP X-Implant-Token y las direcciones C2 que Kaspersky enumera—. La campaña en torno a ese mecanismo no lo está. Kaspersky no publicó ninguna lista de víctimas, ningún desglose por país, ninguna estimación del volumen de datos ni ningún actor. Todo lo que un lector podría querer saber sobre quién resultó afectado y con qué gravedad se detiene en el sector y la región.

Hay dos detalles que merece la pena señalar para cualquiera que acuda al informe esperando más. En primer lugar, Kaspersky describe el ataque como «una de las primeras descripciones públicas de un compromiso en el que interviene un LLM en estado salvaje» en lugar de la primera, una matización que limita la afirmación a lo que el equipo pudo encontrar en informes públicos. En segundo lugar, el informe señala que la versión del implante no sigue a la del servidor, que las configuraciones y claves de los listeners sobreviven a las actualizaciones del operador y que la fecha de compilación de una muestra solo indica la fecha de despliegue posible más temprana, no la duración de un compromiso. La cifra de 3–4 días es una medición de un único incidente reconstruido, no un límite de cuánto tiempo se prolongó cualquiera de estas intrusiones antes de que alguien las detectara.