CyberStrikeAI en educación: C2

Resumen ejecutivo

Kaspersky reconstruyó una intrusión contra organizaciones educativas en la que CyberStrikeAI, un framework modular de código abierto, fue utilizado para acelerar el post-exploitation mediante un LLM alojado en el servidor C2. La fuente no identifica países concretos de América Latina ni de África, tampoco atribuye con certeza la campaña a un grupo conocido, pero sí documenta una cadena técnica completa, con un operador humano que fijó objetivos generales y un modelo que planificó acciones, eligió herramientas, generó comandos y analizó resultados.

La cronología muestra una operación segmentada, con tiempos muy distintos entre acceso inicial, persistencia y fase final. El ingreso inicial ocurrió a través de un SQL Server comprometido, versión 16.0.1000. Luego hubo casi un día de reconocimiento de red, preparación de herramientas y recopilación básica del host. Tras esa primera etapa se observó una pausa de dos semanas antes del despliegue del implante CyberStrikeAI. Una vez instalado, la persistencia y el reconocimiento local se completaron en unos dos minutos, el reconocimiento de dominio continuó durante cinco horas y, después de una nueva pausa de varios días, la fase final comenzó. Desde el despliegue del agente hasta la toma de cuentas de administrador de dominio transcurrieron entre tres y cuatro días, según Kaspersky.

El tramo final fue corto y muy agresivo. La operación completa duró no más de una hora e incluyó movimiento lateral por SMB y WMI, ejecución remota con WMIExec de Impacket, uso de carpetas administrativas compartidas, distribución del script p1.ps1 por red, volcado masivo de credenciales, acceso a LSASS, consultas LDAP vinculadas con Kerberoasting y AS-REP Roasting, DCSync, Golden Ticket y exportación de bases de datos. El reporte también documenta persistencia mediante tarea programada SystemUpdate o la clave HKCU\Software\Microsoft\Windows\CurrentVersion\Run en Windows, y mediante crontab con @reboot o ~/.bashrc en Linux.

Un punto central del informe es la arquitectura de CyberStrikeAI. El implante no contiene IA, no llama a servicios como ChatGPT o Claude y no utiliza claves API. Funciona como un agente C2 convencional que consulta periódicamente al servidor por HTTP/S, TCP o WebSocket, ejecuta comandos de shell y manipula archivos. La capa de inteligencia está en el C2: allí el LLM selecciona herramientas, redacta comandos, analiza respuestas y puede producir consultas SQL y LDAP adaptadas a la tarea. En otras palabras, la automatización no reside en el endpoint sino en la orquestación remota, con un mecanismo human-in-the-loop que deja al operador la posibilidad de aprobar o corregir acciones.

Para la lectura regional, el valor del reporte está en su alcance y en sus límites. Kaspersky sitúa la actividad en el entorno de instituciones educativas de América Latina y África, pero no publica países ni víctimas concretas para este caso. Tampoco puede establecer con certeza que el mismo operador esté detrás de ambas campañas o de toda la infraestructura identificada. Sí señala indicios, como comentarios en chino en scripts, uso de servicios chinos, reinicios de servidores en horario UTC+8 y rasgos del propio framework, que sugieren una posible conexión con un operador de habla china, aunque la propia fuente aclara que eso no prueba identidad ni ubicación. Softonic, a partir del reporte, planteó que se trataría de uno de los primeros casos públicos observados in the wild en los que un LLM tuvo un rol operativo central, pero esa lectura no es una verificación independiente.

Contexto y antecedentes

La pieza de Kaspersky describe un framework que no nació como malware tradicional, sino como un entorno modular de código abierto escrito en Go para automatizar pruebas de penetración. CyberStrikeAI combina en un solo proceso un servidor C2, agentes o beacons y una capa de orquestación basada en LLM. Esa arquitectura es relevante porque reubica la inteligencia operativa en el lado del atacante, no en el equipo comprometido. El implante hace de transporte y ejecución, mientras el C2 decide qué hacer con la información que recibe.

En este caso, el informe insiste en que el agente no contiene funcionalidad de IA. No hay claves API ni llamadas a servicios externos de LLM desde el endpoint. El beacon, en cambio, actúa como un cliente clásico de C2, con consultas periódicas y capacidades normales de shell y sistema de archivos. Esa distinción importa porque separa el discurso publicitario de “IA en el malware” de lo que Kaspersky realmente observó: una automatización de la orquestación en la infraestructura del atacante.

El material también ubica la campaña en entornos educativos. Softonic, citando el reporte de Kaspersky, contextualiza el atractivo del sector por la concentración de expedientes de estudiantes, datos financieros, credenciales e investigación. Pero esa publicación no aporta medición propia sobre víctimas latinoamericanas o africanas, y tampoco agrega identificación geográfica que permita precisar alcance por país. Por eso, el informe regional de Whalemate Labs debe mantener el foco en la técnica y en los límites de atribución.

Tabla de hechos clave

Timeline de la operación

Cadena de ataque y TTPs

La cadena observada por Kaspersky es más interesante por la arquitectura que por la novedad de sus piezas. El acceso inicial por SQL Server comprometido no es exótico, pero el uso posterior de un LLM alojado en el C2 sí cambia la velocidad y la coordinación del operador. En vez de una secuencia manual de comandos una por una, el sistema pudo sugerir acciones, preparar comandos y evaluar resultados en torno a los objetivos definidos por la persona al mando.

El reporte muestra que el implante Windows usó PowerShell y Base64 para los comandos, y que la persistencia se estableció mediante la tarea programada SystemUpdate o mediante HKCU\Software\Microsoft\Windows\CurrentVersion\Run. En Linux, la persistencia se documentó mediante crontab con @reboot o ~/.bashrc. El beacon no realiza procesamiento inteligente en el endpoint. Consulta al servidor por HTTP/S, TCP o WebSocket, ejecuta shell y opera sobre archivos, como cualquier agente C2 convencional.

La etapa de credenciales es una de las más densas del caso. Kaspersky documentó consultas LDAP relacionadas con Kerberoasting y AS-REP Roasting, extracción de hives del registro mediante reg.exe, volcado de LSASS mediante MiniDump de comsvcs.dll y, después, DCSync y Golden Ticket con una versión renombrada de Mimikatz. Esa progresión sugiere una secuencia organizada para ampliar privilegios, consolidar acceso y mover lateralmente dentro del dominio. También aparece el uso de un binario identificado como wdiag2.exe, catalogado por la fuente como Mimikatz.

El movimiento lateral documentado usó WMIExec de Impacket, carpetas administrativas compartidas, WMI e Invoke-CimMethod. El script p1.ps1 fue distribuido por la red con esas mismas capacidades. Kaspersky también informó transferencia de archivos por el canal cifrado principal con el C2, mediante HTTP o TCP, con datos en Base64 y encapsulados en respuestas JSON del agente. A eso se suma la captura de pantalla ordenada por el orquestador LLM y ejecutada por el implante.

Persistencia y ejecución en Windows y Linux

La persistencia documentada por Kaspersky muestra que CyberStrikeAI no dependió de un único método. En Windows, el uso de SystemUpdate como tarea programada y de la clave Run bajo HKCU ofrece redundancia. En Linux, la combinación de crontab con @reboot y ~/.bashrc cumple una función similar. Son mecanismos conocidos, pero en el contexto del caso resultan útiles porque encajan con una operación que buscó permanecer a través de reinicios sin introducir complejidad innecesaria.

El detalle de PowerShell con codificación Base64 también importa. El informe menciona que el implante Windows utilizó ese patrón para sus comandos, y Kaspersky lo reflejó en reglas de detección específicas. A nivel operativo, eso deja huellas consistentes tanto en endpoints como en telemetría de ejecución de procesos. No es un rasgo exclusivo de esta campaña, pero sí parte de su firma técnica documentada.

Credenciales, dominio y escalamiento

La sucesión Kerberoasting, AS-REP Roasting, extracción de hives, volcado de LSASS, DCSync y Golden Ticket indica una escalada escalonada hacia control del dominio. No se trata de un único golpe, sino de una construcción progresiva de privilegios y alcance. El punto de quiebre es claro: desde el despliegue del agente hasta la toma de cuentas de administrador de dominio pasaron entre tres y cuatro días, con un tramo final muy concentrado que explotó el acceso ya consolidado.

El material no permite afirmar cuántos hosts quedaron comprometidos ni el tamaño real de cada dominio. Sí permite ver que la etapa de credenciales fue prioritaria. Kaspersky incluso publicó reglas SIEM y EDR para detectar esos patrones, lo que sugiere que el informe fue pensado no solo como análisis retrospectivo sino como guía de búsqueda defensiva.

Impacto regional

La reconstrucción disponible no permite hablar de un país latinoamericano o africano específico. Kaspersky sitúa el caso en organizaciones educativas de esas regiones, pero no publica geografía fina de las víctimas ni atribuye el conjunto de la infraestructura a un único actor. En consecuencia, el impacto regional debe leerse como una advertencia técnica sobre un tipo de intrusión, no como una medición país por país.

Panorama regional

El caso combina un acceso inicial relativamente clásico con una etapa posterior muy acelerada por la orquestación con LLM. Para instituciones educativas, eso tiene un efecto claro sobre la ventana de respuesta. La primera fase dejó margen temporal, con casi un día de reconocimiento y una pausa de dos semanas antes del implante. Después, sin embargo, la actividad se comprimió: persistencia en minutos, dominio en horas y fase final en menos de una hora.

Ese patrón importa para ambientes con redes híbridas, múltiples subdominios, servicios heredados y credenciales compartidas. El reporte documenta que la operación culminó en toma de privilegios de dominio, movimiento lateral y exportación de bases de datos. En un contexto educativo, eso puede implicar acceso a identidades, registros, información financiera e investigación, aunque el reporte de Kaspersky no cuantifica esos activos para víctimas de la región.

Lectura operativa para América Latina

El material no ofrece casos confirmados por país en América Latina. Argentina, Chile, Paraguay, Bolivia, Perú, Colombia, Brasil, México, Uruguay y Estados Unidos aparecen en la plantilla editorial, pero en el research no hay hechos verificables específicos para esas jurisdicciones en esta campaña. Por eso, cualquier conclusión nacional sería especulativa.

Lo verificable es otra cosa. Los TTPs observados, como WMIExec, compartidos administrativos, PowerShell con Base64, LSASS dumping, DCSync y Golden Ticket, son suficientemente concretos para orientar hunting y detección. También lo es la infraestructura publicada, que permite búsquedas defensivas en logs, telemetría de red y procesos. El mapa geográfico queda abierto, pero la técnica está bien definida.

Indicadores técnicos

IOC y huellas de infraestructura

Los IOC publicados por Kaspersky cubren dominio, IP, hashes y rutas de archivo. En Windows aparecen beacons asociados a svchosts.exe y svcmon32.exe, con un hash adicional para p1.ps1 y para wdiag2.exe, identificado como Mimikatz. En Linux, la fuente publicó dos hashes de beacon. También figuran fastcdn[.]bar, media.fastcdn[.]bar y 104.234.26[.]163 como parte de la infraestructura observada.

El dominio dnslog[.]cn aparece con un uso distinto, vinculado a la comprobación de conectividad a Internet y a la obtención de la IP externa. Kaspersky además menciona la búsqueda del directorio .azcopy como indicio de uso de Microsoft Azure Storage Copy. Esa referencia no es un IOC clásico de red, pero sí una pista útil para hunting en entornos donde se investigue exfiltración o staging con herramientas de almacenamiento en la nube.

Análisis para equipos de seguridad

La primera lectura defensiva es que el despliegue de un LLM en el C2 no anula las técnicas conocidas, pero sí acelera su encadenamiento. Eso cambia el tipo de alerta que conviene priorizar. Si la fase final puede ejecutarse en menos de una hora una vez consolidado el acceso, la detección tardía pierde valor. El foco debe ir a la observación temprana del reconocimiento, la persistencia y la secuencia de credenciales.

En Windows, las reglas publicadas por Kaspersky dan una guía directa. Las señales sobre schtasks.exe, PowerShell descargado y ejecutado, shell lanzado por el scheduler, acceso sospechoso a LSASS, volcado con comsvcs.dll, uso de Mimikatz, DCSync y Golden Ticket forman una matriz muy concreta para hunting. En redes, la combinación de WMIExec de Impacket, carpetas administrativas compartidas y uso de WMI para mover scripts como p1.ps1 permite priorizar telemetría de ejecución remota.

La fuente también publicó reglas EDR Expert y SIEM que apuntan a esas conductas. Entre ellas figuran create_task_on_remote_host_using_standard_tool, scheduled_task_creation_as_system_via_schtasks, scheduled_task_with_powershell_execution, dumping_memory_with_com_services_dll, suspicious_lsass_memory_access, using_powershell_for_remote_execution_via_wmi y winrm_send_command. En SIEM aparecen, además, R034_01_Multiple TGS ticket requests, R452_18_AS-REP Roasting, R230_02_Copying data containing credentials from the Windows registry, R073_DC Sync attack y R450_41_Golden Ticket Attack.

La defensa también debe pensar en la primera fase. El acceso inicial pasó por un SQL Server comprometido. Si ese vector queda fuera del radar, la ventana previa al despliegue del implante puede perderse por completo. En este caso hubo casi un día de reconocimiento y dos semanas de espera antes del beacon. Eso deja espacio para detección de anomalías de base de datos, enumeración de red, movimiento desde un host SQL y creación temprana de artefactos de staging.

Priorización práctica

Primero, revisar exposición y hardening de SQL Server, especialmente si el host cumple funciones de pivot interno. Segundo, vigilar tareas programadas, claves Run, crontab y modificación de shells en Linux. Tercero, buscar patrones de autenticación anómalos y peticiones TGS repetidas, junto con extracción de credenciales desde el registro y accesos a LSASS. Cuarto, observar WMI, WinRM y SMB cuando se usan en secuencia para distribuir scripts o binarios.

El hallazgo más operativo del reporte es que el LLM ayuda a comprimir la toma de decisiones, no a ocultar la técnica. Eso significa que las detecciones basadas en comportamiento siguen siendo las más útiles. Si el atacante puede generar más rápido consultas LDAP o SQL, la telemetría del dominio y del endpoint seguirá mostrando Kerberoasting, AS-REP Roasting, DCSync, Golden Ticket y lateral movement. El reto está en unir señales dispersas antes de que la fase final consuma el objetivo.

Preguntas frecuentes

¿Qué cambia en esta campaña el uso de un LLM en el C2?

Cambia la velocidad de la orquestación, no la clase de técnicas empleadas. Según Kaspersky, el LLM vive en el servidor C2, planifica acciones, elige herramientas, genera comandos y analiza resultados. El implante sigue siendo convencional. Eso acelera el post-exploitation, pero no sustituye señales como WMI, LSASS dumping, DCSync o Golden Ticket.

¿Kaspersky identificó países latinoamericanos concretos afectados?

No. El reporte sitúa el caso en organizaciones educativas de América Latina y África, pero no publica países específicos ni víctimas concretas. Tampoco permite separar el impacto por jurisdicción. La sección de Impacto regional resume lo que sí se pudo verificar y marca la ausencia de segmentación nacional.

¿Qué técnicas de credenciales fueron más relevantes en la operación?

La cadena incluyó Kerberoasting, AS-REP Roasting, extracción de hives del registro, volcado de LSASS con comsvcs.dll, DCSync y Golden Ticket. Kaspersky además asoció Mimikatz renombrado y publicó reglas SIEM para varios de esos patrones. El bloque técnico del informe reúne la secuencia completa y su lectura operativa.

¿Qué IOC públicos sirven para buscar esta actividad?

La fuente publicó 185.186.245[.]144, fastcdn[.]bar, media.fastcdn[.]bar, 104.234.26[.]163, dnslog[.]cn, hashes de beacons Windows y Linux, y rutas como c:\windows\temp\svchosts.exe, c:\windows\temp\svcmon32.exe y c:\ProgramData\p1.ps1. La tabla de Indicadores técnicos los lista con su contexto de uso.

¿Por qué Kaspersky no atribuye con certeza esta actividad?

Porque los datos disponibles no permiten vincular la operación con un grupo conocido ni afirmar que el mismo operador esté detrás de ambas campañas o de toda la infraestructura. La fuente menciona indicios, como comentarios en chino, servicios chinos y horarios UTC+8, pero los considera insuficientes para una atribución firme.