CyberStrikeAI entra en circulación: uso de la IA en ataques reales contra organizaciones

Introducción

Durante el monitoreo proactivo de amenazas, los especialistas en inteligencia de amenazas de Kaspersky identificaron una campaña maliciosa que emplea agentes de C2 controlados por inteligencia artificial. Las víctimas confirmadas de la campaña son organizaciones del sector educativo en países de África y América Latina. CyberStrikeAI desempeñó un papel clave en la posexplotación: se trata de un framework de código abierto en el que un orquestador LLM, operando del lado del servidor de control, planifica las acciones, selecciona las herramientas y genera los comandos, mientras que el implante los ejecuta en los nodos comprometidos. Con CyberStrikeAI, los atacantes avanzaron desde la etapa de reconocimiento hasta lograr comprometer la totalidad del dominio.

Según nuestros datos, este análisis es uno de los primeros informes públicos sobre un ataque real llevado a cabo mediante un LLM. La campaña que detectamos ilustra con claridad cómo está cambiando el papel de la IA en el arsenal de los atacantes. Hasta hace poco, los modelos de lenguaje se usaban sobre todo en las etapas preparatorias: para redactar correos de phishing, depurar código o buscar vulnerabilidades. Ahora forman parte del núcleo mismo del ataque y automatizan todas sus etapas: la ejecución de la carga útil, la persistencia en el host, el reconocimiento, el movimiento lateral y, por último, la recopilación y la exfiltración de datos. Merece especial atención la posexplotación, una etapa que solía exigir el trabajo manual de un operador experimentado.

La característica clave de un esquema de ataque basado en un framework de IA es que el implante deja de ser una mera herramienta para ejecutar los comandos del operador. La toma de decisiones se reparte en dos niveles: el operador plantea la tarea en términos generales y el modelo determina cómo cumplirla, es decir, qué comandos concretos enviar al host y en qué orden. Así, la intención estratégica sigue en manos humanas, la elección de los pasos técnicos recae en el modelo y el implante se limita a ejecutar sus decisiones.

Para entender cómo funciona este esquema en la práctica, veamos la cadena de acciones de los atacantes que nuestros especialistas reconstruyeron al investigar los incidentes.

Cronología del ataque

Revisemos la cronología del ataque a partir de un incidente de la campaña detectada.

La primera fase sigue un enfoque estándar: un operador humano obtiene acceso a la infraestructura de la víctima a través de un servidor SQL comprometido, versión 16.0.1000; después, recopila información básica del host, despliega sus herramientas y realiza el reconocimiento de la red. Toda esta actividad toma casi 24 horas, y le sigue una pausa de dos semanas.

La segunda fase es muy distinta. Su primer paso consiste en desplegar el agente de C2 de CyberStrikeAI, que recibe comandos del orquestador LLM del servidor. Durante la segunda fase, el agente se encarga de:

• la persistencia y reconocimiento local en 2 minutos;
• el reconocimiento del dominio durante las 5 horas siguientes;
• tras una breve pausa de varios días, de realizar la transición a la etapa final: el movimiento lateral mediante SMB y WMI, la recopilación masiva de credenciales en los hosts y la exfiltración de la base de datos. Toda estas actividades toman menos de una hora.

En la siguiente sección describimos estas etapas en detalle.

Detalles técnicos

Acerca de CyberStrikeAI

CyberStrikeAI es una plataforma en Go modular y de código abierto para automatizar pruebas de penetración. Su característica clave: un solo proceso de servidor reúne la orquestación del ataque mediante LLM y un servidor C2 integrado con agentes (beacon).

Toda la capa “inteligente” permanece aislada en el servidor de control. El modelo accede a las funciones del C2 (ejecución de utilidades de reconocimiento y explotación, gestión de conexiones con web shells, asignación de tareas a los agentes y lectura de los resultados) mediante herramientas MCP. El implante, por su parte, es un agente de C2 clásico sin funciones de IA: no contiene claves de API, no realiza llamadas a las API de servicios de IA ni tiene lógica autónoma. Consulta de forma periódica al servidor de escucha (listener) por HTTP/S, TCP o WebSocket, ejecuta comandos de shell y opera con el sistema de archivos. Para la víctima, la actividad parece una sesión común de administración remota en la que, en lugar de un operador humano, el orquestador LLM del servidor pone las tareas en cola. El LLM influye en cómo se toman las decisiones, pero no en cómo llegan al host los comandos correspondientes.

Aunque CyberStrikeAI es de acceso público, es posible vincular muestras concretas del framework con atacantes o campañas específicos. Estos indicios permiten la detección y la atribución:

• Panel de control: al iniciarse, genera un certificado TLS autofirmado en cuyos campos de emisor y sujeto figura el nombre del framework. El certificado se crea en memoria con cada arranque, por lo que el campo not_before registra la hora de inicio del proceso. Así, como ocurre con Cobalt Strike, el historial de escaneos permite reconstruir la cronología de reinicios.
  

  Certificado TLS autofirmado del panel de control de CyberStrikeAI

• Implante: los metadatos de compilación (go version -m) contienen la ruta al paquete principal, con datos que apuntan al generador integrado de CyberStrikeAI: un directorio temporal con el identificador de compilación. Esta ruta es idéntica en todas las cargas útiles, lo que la convierte en una firma estable. Además, el campo build info incluye metadatos del sistema de control de versiones, útiles para correlacionar muestras entre sí.
• Autenticación: al comunicarse con el servidor, el implante envía en la solicitud HTTP el encabezado X-Implant-Token con un valor fijo. El token es único para cada servidor C2 y se incrusta en la carga maliciosa durante la compilación, por lo que funciona como indicador de red y como señal de que las muestras pertenecen a un mismo servidor.

Cabe considerar que la versión del implante no refleja la versión del servidor. El implante puede operar durante meses mientras el operador actualiza el componente del servidor: la configuración de los listeners y las claves se conservan tras la actualización. En los incidentes detectados, observamos el uso de una sola versión del agente durante todo el incidente. En ese caso, la fecha de compilación de la muestra puede indicar el límite inferior del despliegue de la infraestructura de CyberStrikeAI, pero no permite estimar la duración del compromiso.

Execution & Privilege Escalation

Los primeros comandos maliciosos en los sistemas de las víctimas de la campaña analizada provenían del proceso sqlservr.exe, lo que apunta al presunto vector de acceso inicial y al contexto en el que los atacantes obtuvieron la capacidad de ejecutar código. Es importante señalar que el propio atacante ejecutó de forma manual, en el contexto de ese proceso, los comandos marcados como ejecutados antes de la instalación del agente. En esta etapa aún no se trata de actividad automatizada del implante, sino de acciones manuales del operador.

Antes de ejecutar el agente en los equipos, los atacantes verificaban su presencia con un script de PowerShell, del cual se deducen sus rutas de ubicación predeterminadas: C:\Windows\Temp\, C:\Windows\, C:\ProgramData\, C:\Temp. Además, el atacante puede disfrazar el nombre del agente como el de procesos legítimos del sistema. En el siguiente ejemplo, imita svchost.exe (svchosts.exe):

Como la mayoría de los agentes de C2 para Windows, CyberStrikeAI usa PowerShell para ejecutar la carga útil. Cuando el operador lo solicita, el agente codifica además los comandos en Base64 para evadir la detección por palabras clave.

Comando decodificado:

Con privilegios administrativos (por ejemplo, con una cuenta de administrador de dominio), en lugar de ejecutar los comandos de forma directa, el agente solía crear tareas programadas en los hosts remotos para que la carga maliciosa se ejecutara con privilegios de SYSTEM:

Una alternativa sin schtasks consiste en crear la tarea mediante el objeto COM Schedule.Service:

La carga útil (p1.ps1) del ejemplo anterior es una shell inversa (reverse shell) que se conecta al servidor en la dirección 185.186.245[.]144:5501:

Los atacantes propagaron p1.ps1 y scripts similares por la red mediante recursos compartidos administrativos de red y el protocolo WMI, como describimos en detalle en la sección Lateral Movement.

Stealth

Además de codificar comandos en Base64 y ofuscar consultas SQL/LDAP, como describimos en las secciones Collection & Exfiltration y Discovery, los atacantes dividían la carga maliciosa en varios archivos. Llama la atención que los scripts se transfirieron así incluso antes de instalar el agente, es decir, en una etapa del proceso que suele requerir de intervención humana, aunque presentan rasgos evidentes de haber sido generados por un LLM.

A continuación se muestra la escritura secuencial de varios fragmentos del script en el archivo d3.b64:

Después, los atacantes usaron la utilidad certutil para decodificar el archivo resultante y lo ejecutaron con el siguiente comando:

Una vez ensamblado y decodificado, el contenido del script era el siguiente:

El script es una herramienta para descifrar secretos de DPAPI del archivo C:\ProgramData\dsn_line.txt. Este archivo, a su vez, se genera mediante el siguiente comando, que busca en el archivo de configuración de SQL Server Reporting Services rsreportserver.config la cadena DSN que contiene los parámetros de conexión y la copia en dsn_line.txt.

Cabe destacar que varios de los scripts que se transfieren y ejecutan con el método descrito contienen comentarios en chino (## — comentarios del investigador).

Persistence

Una vez instalado con éxito el implante de CyberStrikeAI, el primer objetivo era establecer su persistencia en el sistema objetivo. Para ello, el agente creaba una tarea programada llamada SystemUpdate, con la ruta al implante como acción a ejecutar:

El análisis del código fuente del framework reveló otro método de persistencia: agregar una clave en la rama del registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run, cuyo nombre coincide con el de la tarea (SystemUpdate).

En sistemas Linux, la persistencia del agente también admite dos variantes: agregar la entrada @reboot <path_to_beacon> & al crontab del usuario (el proceso se inicia con el arranque del sistema) o agregar la línea (nohup <path_to_beacon> &>/dev/null &) a ~/.bashrc (el agente se inicia al abrir una shell interactiva de bash).

Cabe destacar que CyberStrikeAI delega la elección del método de persistencia al LLM conectado. Sin embargo, gracias al mecanismo Human-in-the-Loop (HITL), el operador conserva el control total del proceso: los comandos que genera el modelo pueden requerir aprobación o ajuste manual obligatorios antes de su ejecución.

Discovery

Local Discovery

Antes de instalar el agente en el host bajo su control, los atacantes recopilaban de forma manual información básica del sistema con un conjunto de comandos bastante sencillos:

También de forma manual, para verificar el acceso a internet y obtener la IP externa de los equipos infectados, los atacantes usaron el servicio chino dnslog[.]cn. El servicio genera un dominio aleatorio de tercer nivel y, después, el atacante intenta resolverlo desde el equipo comprometido.

Si el equipo tiene acceso a internet, la consulta se resuelve y los atacantes obtienen en la página del servicio la dirección IP externa del dispositivo bajo su control.

El agente, en cambio, genera para el reconocimiento un script más complejo, cuyo objetivo es trazar una ruta para escalar privilegios mediante el compromiso de SCCM o la explotación de msiexec (clave AlwaysInstallElevated):

Para buscar formas de escalar privilegios en el ámbito local, el agente también ejecutaba scripts que inventariaban los servicios que se ejecutan con cuentas de dominio y las tareas que se ejecutan como SYSTEM:

Durante su actividad, los atacantes revisaban de forma periódica las alertas de Microsoft Defender:

Remote Discovery

Tras recopilar información sobre el host bajo su control, los atacantes pasaban al reconocimiento dentro de la red. En la etapa preparatoria del ataque, recopilaban de forma manual información adicional sobre los nodos remotos con la utilidad net.exe.

En la etapa principal, el agente utilizaba las funciones integradas de PowerShell para identificar los nodos disponibles, sin recurrir a herramientas adicionales como nmap, fscan, etc.

Las consultas LDAP correspondientes a objetos de Active Directory también ayudaban a mapear la red:

Además, el agente verificaba con WMI si ya estaba instalado en los hosts remotos:

Domain Discovery

El siguiente paso era obtener información sobre el dominio de las víctimas. Con este fin, los atacantes usaron utilidades estándar del sistema operativo antes de instalar el agente:

Sin embargo, después, el implante de CyberStrikeAI realizó el reconocimiento con scripts de PowerShell generados para esta tarea:

Además de la información básica del dominio, el agente ejecutaba consultas LDAP para recopilar información destinada a ataques de Kerberoasting / AS-REP Roasting:

Además, el agente verificaba la presencia de LAPS y Microsoft Azure en el dominio:

Para detectar indicios del uso de Microsoft Azure en la infraestructura, los atacantes también buscaban el directorio .azcopy, que crea la utilidad AzCopy (Microsoft Azure Storage Copy), en los directorios personales de los usuarios:

Credential Access

Tras completar el reconocimiento y mapear la red, los atacantes pasaban a la siguiente etapa: el volcado de credenciales. Para ello, el agente usaba un conjunto clásico de utilidades LOLBIN y herramientas conocidas de terceros.

El agente volcaba los subárboles del registro que contienen credenciales con la utilidad reg.exe:

El agente volcaba el proceso lsass.exe mediante la función MiniDump de la biblioteca comsvcs.dll. En lugar del nombre del proceso objetivo, usaba su PID para dificultar la detección estática por línea de comandos:

Tras comprometer cuentas de dominio privilegiadas (en particular, la del administrador de dominio integrado), los atacantes también ejecutaron, mediante el agente, ataques DCSync y Golden Ticket con una versión renombrada de la utilidad mimikatz:

Lateral Movement

Para propagarse por la red con las cuentas comprometidas, los atacantes emplean utilidades del conjunto Impacket, en particular WMIExec, como lo demuestra la línea de comandos característica de la utilidad:

Una vez instalado, el agente prefiere usar mecanismos estándar del sistema operativo, como los recursos compartidos de red.

Otro método que usa el agente para ejecutar comandos de forma remota es el protocolo WMI. Con él, el agente propagó, entre otros, el script de shell inversa p1.ps1 mencionado antes. Para ello, usó cuentas comprometidas de usuarios con privilegios de administrador local en los hosts objetivo:

La segunda variante de movimiento lateral mediante WMI usa el cmdlet Invoke-CimMethod:

Comand & Control

Para entregar estas herramientas (scripts maliciosos, mimikatz y el propio agente) a los nodos iniciales de la cadena de infección, los atacantes usaron utilidades estándar del sistema operativo:

Una vez instalado, el agente verifica la disponibilidad de los puertos del servidor C2. Los mecanismos para hacerlo son casi ilimitados y dependen de la “imaginación” del LLM conectado al servidor de agentes:

Para descargar utilidades adicionales, el implante de CyberStrike también usaba utilidades integradas (LOLBINS). Las herramientas podían alojarse en servidores propios o descargarse de GitHub sin intermediarios:

Collection & Exfiltration

La etapa de recopilación de datos merece atención especial. En ella se manifiesta otra capacidad de la orquestación con LLM: la generación automática de consultas SQL y LDAP adaptadas a una tarea concreta.

En uno de los incidentes de la campaña, los atacantes desplegaron el implante de CyberStrikeAI en el servidor SQL de una institución educativa y recopilaron información de la base de datos mediante PowerShell. Este es un ejemplo de un comando que ejecutó el agente:

Versión normalizada del script ejecutado, con comentarios:

Antes de acceder a los datos, el agente verificaba los privilegios de la cuenta con la que se conectaba a la base de datos:

Decodificada, la verificación es la siguiente:

En los recursos de red, antes de recopilar archivos, el agente recorría los directorios de forma recursiva para identificar los archivos de interés.

Para interactuar con el sistema de archivos, el implante ofrece una interfaz integrada que admite carga y descarga directas de archivos. Los archivos se transfieren por el canal cifrado principal de comunicación con el C2 (HTTP o TCP), y los datos se codifican en base64 y se empaquetan en las respuestas JSON estándar del agente.

Las primitivas integradas del implante también incluyen la captura de pantalla del equipo infectado. Como ocurre con las demás acciones, el implante no la ejecuta por iniciativa propia: el orquestador LLM emite el comando de captura y el agente solo lo ejecuta y devuelve el resultado por el mismo canal de control.

En Windows, el comando para capturar la pantalla es el siguiente:

La variante para Linux es la siguiente:

En los ataques que detectamos, la recopilación de datos fue el último eslabón: la cadena terminaba allí y no observamos actividad posterior.

Atribución

El artefacto clave para la atribución en esta campaña son los metadatos de compilación de los implantes. Los atacantes compilaban la carga maliciosa dentro de un clon git del proyecto, por lo que el compilador de Go incrustó en los binarios información del sistema de control de versiones: el hash y la hora del commit, además del indicador vcs.modified=true (equivalente al sufijo +dirty), que señala cambios locales sin confirmar en la copia de trabajo. En conjunto, estos campos forman una huella única de cada compilación.

Según esta huella, las muestras se dividen en dos grupos independientes; en cada uno, el implante para Windows y el implante para Linux tienen metadatos de compilación idénticos. Esta coincidencia indica que, dentro de cada grupo, ambas cargas útiles se compilaron en la misma copia de trabajo del proyecto.

Sin embargo, estos grupos no se cruzan entre sí. No comparten infraestructura de C2, y sus servidores de control ejecutan versiones distintas de CyberStrikeAI. Es decir, los metadatos de compilación vinculan con solidez las muestras dentro de cada grupo, pero no justifican unir ambos grupos.

Los datos disponibles no permiten vincular la actividad con ningún grupo de atacantes conocido ni afirmar con certeza que un mismo operador está detrás de ambos grupos. Dos factores lo impiden. Primero, la apertura de la herramienta: CyberStrikeAI es de acceso público, por lo que distintos operadores pueden haberlo desplegado por su cuenta y compilado la carga maliciosa en condiciones similares. Segundo, la generación de comandos por el modelo: el “estilo” característico de un operador no lo define un ser humano, sino que lo hace en gran medida el LLM. Por un lado, esto aumenta la diversidad de los comandos: un mismo comando generado varias veces puede verse distinto. Por otro, les quita rasgos individuales, lo que reduce el valor de las métricas de comportamiento para la atribución.

No obstante, los comentarios en chino hallados en los scripts de los atacantes y el uso de servicios chinos dan a entender que la actividad está vinculada con un operador de habla china. Además, los analistas observaron la distribución de las horas de reinicio de los servidores de control: como el certificado TLS autofirmado se regenera con cada inicio del proceso, su campo not_before registra el momento del reinicio, y la mayoría de esos momentos coincidió con el horario laboral en UTC+8.

El origen de la herramienta apunta de forma indirecta en la misma dirección: CyberStrikeAI se desarrolló en la comunidad china de ciberseguridad, donde goza de reconocimiento.

Conclusiones

CyberStrikeAI es un ejemplo representativo, aunque no único, del cambio que se está produciendo en la clase de los frameworks de C2: el orquestador LLM deja de ser un complemento del reconocimiento y se convierte en la capa de control de la posexplotación. Si HexStrike AI y sus equivalentes cubren la etapa de “encontrar y vulnerar”, y Sliver/Mythic/Havoc, la de “persistir y controlar”, CyberStrikeAI cierra el ciclo: un único proceso de servidor en Go invoca utilidades mediante MCP, gestiona conexiones de web shell y asigna tareas al implante, mientras el modelo analiza los resultados y decide el siguiente paso.

La conclusión clave es que, por ahora, la presencia de IA en la cadena de ataque no plantea retos de detección nuevos en esencia. Toda la parte “inteligente” permanece del lado del atacante, y al host comprometido llegan acciones conocidas: desde el reconocimiento para Kerberoasting y AS-REP Roasting hasta el volcado de LSASS, DCSync y Golden Ticket. Se trata de un conjunto típico y bien documentado de técnicas de compromiso de dominio. La novedad del ataque no reside en los métodos, sino en la rapidez y la facilidad con que se ejecutaron: la orquestación con IA redujo los requisitos de cualificación del operador, pero no llevó el ataque más allá de lo que los defensores ya conocen y saben detectar. Los tiempos también son reveladores: algunas fases clave de la actividad (como la persistencia, el movimiento lateral y la obtención de credenciales) tomaron apenas unas horas, y el ataque completo, desde la instalación del agente hasta el compromiso de los administradores de dominio, duró de 3 a 4 días.

Sin embargo, la arquitectura de CyberStrikeAI no se limita al escenario descrito. Los mismos mecanismos permiten construir, bajo demanda, cadenas más complejas, con extracción de secretos de DPAPI y ataques a SCCM y Azure IMDS, y todo ello queda al alcance del mismo grupo de actores, cuya barrera de entrada es bastante baja. A medida que evolucionen los modelos, se reducirá la brecha entre la complejidad de la orquestación y el nivel de las técnicas empleadas, y el papel del operador cambiará de forma gradual: pasará de asignar tareas a supervisar las acciones del modelo.

Detección con las soluciones de Kaspersky

A simple vista parecería que los ataques con agentes de IA requieren renovar las reglas de detección por completo. Sin duda, para detectar la actividad de un agente LLM instalado en un host dentro de la infraestructura, es necesario crear lógica de detección basada en las particularidades de los agentes. Las reglas de detección de esta actividad están disponibles en Hunt Hub con el siguiente filtro.

Sin embargo, en el ataque descrito opera otra lógica. La diferencia principal radica en la arquitectura del propio ataque: el agente LLM no se encontraba dentro del perímetro de la red corporativa. Operaba en remoto a través del agente de C2, orquestaba las acciones y no dejaba rastros de su presencia en la infraestructura (por ejemplo, solicitudes de API específicas a LLM locales o patrones anómalos de consumo de recursos en los hosts).

La diferencia clave entre esta actividad y las amenazas de un atacante experimentado radica, en gran medida, en la velocidad. En lo táctico, técnico y metodológico, la IA usa, en general, las mismas herramientas, utilidades y técnicas que un pentester humano. No escribe exploits únicos desde cero, sino que combina métodos conocidos, los adapta de forma dinámica a la situación y resuelve por sí misma los errores de esas herramientas.

Como las acciones que se ejecutan bajo el control de un agente de IA en la red son indistinguibles de las humanas, para detectarlas basta con reglas clásicas y bien ajustadas de correlación y análisis de comportamiento. Estos son algunos ejemplos de cómo Kaspersky Next EDR Expert detecta el ataque descrito:

• Para detectar la ejecución de un script malicioso mediante una tarea programada remota, es necesario monitorear la creación del proceso schtasks.exe con el argumento /s. EDR Expert detecta esta actividad con las reglas create_task_on_remote_host_using_standard_tool, scheduled_task_creation_as_system_via_schtasks, scheduled_task_with_powershell_execution
  
• Durante la intrusión, el atacante necesita acceder a las credenciales de la víctima; en este caso, uno de los métodos para obtenerlas es una técnica muy conocida que usa herramientas legítimas para volcar LSASS: la llamada a la función MiniDump de comsvcs.dll. EDR Expert detecta esta actividad con las reglas dumping_memory_with_com_services_dll y suspicious_lsass_memory_access.
  
• El movimiento lateral es una parte importante de la cadena de ataque, ya que permite al atacante desplazarse por la infraestructura y alcanzar sus objetivos. En este caso, el atacante usa el protocolo WinRM e inicia las conexiones desde PowerShell. Es una técnica estándar que le permite ejecutar comandos en equipos remotos sin túneles de red adicionales. EDR Expert detecta esta actividad con las reglas using_powershell_for_remote_execution_via_wmi y winrm_send_command
  

Para detectar actividad maliciosa en el tráfico de red, usamos Kaspersky Anti Targeted Attack (KATA). Los agentes de CyberStrikeAI se comunican con el servidor de comando y control sin recurrir a plataformas de IA como ChatGPT o Claude. En su lugar, como en los ataques sin agentes de IA, la infraestructura que los atacantes prepararon de antemano cumple la función de servidor C2 del agente. El análisis del tráfico de red descifrado con soluciones NDR permite identificar rasgos de comunicación característicos de la actividad de los agentes de CyberStrikeAI. Cuando los detecta, KATA genera una alerta con el veredicto Backdoor.CyberStrikeAI.HTTP.C&C.

Para detectar actividad de posexplotación, además de la tecnología IDS, es posible usar NAD (Network Anomaly Detection). Esta tecnología analiza todo el tráfico en busca de indicios sospechosos que no corresponden a la actividad de red típica del nodo.

Por ejemplo, la regla de NDR:NAD llamada “Reconocimiento de cuentas de dominio mediante consultas LDAP”, detecta las acciones que CyberStrikeAI realiza durante la etapa Domain Discovery.

Para conocer más sobre la tecnología NDR:NAD, consulte nuestro artículo en Securelist.

Además, en la sección Research Graph del portal Kaspersky Threat Intelligence es posible visualizar y analizar las relaciones entre las direcciones C2 y los archivos que usan los atacantes. También es posible rastrear la aparición de nuevos implantes de CyberStrikeAI que se comunican con direcciones maliciosas.

Asimismo, el servicio Threat Lookup, disponible en el portal, permite atribuir archivos maliciosos a CyberStrikeAI mediante mecanismos de atribución basados en el código del ejecutable.

El Kaspersky SIEM detecta todas las etapas del ataque que ejecuta el agente CyberStrikeAI. El repositorio del producto ofrece más de 100 reglas para detectar las técnicas analizadas, de las cuales enumeramos las más críticas.
Ejecución de diversos comandos desde el proceso sqlservr.exe:

• R300_04_Windows shell started by a web application

Descarga y ejecución del payload mediante PowerShell:

• R110_03_PowerShell code downloaded and executed

Creación de tareas programadas de Windows:

• R099_04_Suspicious arguments when running schtasks.exe
• R300_03_Windows shell started by the scheduler

Persistencia mediante crontab o bashrc:

• R099_06_Suspicious cron job activity
• R405_02_UNIX shell configuration modification

Las reglas del paquete ubicado en KUMA Packages/SOC package/Configuration discovery detectan la recopilación de información sobre los hosts, la configuración de red y el dominio por medio de diversas utilidades de reconocimiento. Las siguientes reglas agrupan las detecciones según la herramienta de reconocimiento utilizada:

• R224_14_Windows reconnaissance activity
• R224_09_System information discovery by running multiple utilities within a short period
• R224_04_System information discovery via standard Linux tools

Recopilación de datos para Kerberoasting y AS-REP Roasting:

• R034_01_Multiple TGS ticket requests (Kerberoasting)
• R452_18_AS-REP Roasting

Volcado de subárboles del registro con credenciales mediante la utilidad reg.exe:

• R230_02_Copying data with credentials from the Windows registry

El volcado del proceso lsass.exe se realizó mediante la función MiniDump de la biblioteca comsvcs.dll:

• R233_04_Process memory dump via comsvcs.dll
• R262_Suspicious access to the LSASS process

Ataques DCSync y Golden Ticket con una versión renombrada de la utilidad mimikatz:

• R073_DC Sync attack
• R450_41_Golden Ticket Attack
• R100_03_Traces of Mimikatz use via cmd

Movimiento lateral con WMIExec:

• R460_08_Lateral movement using WMIexec Impacket
• R460_09_Lateral movement using WMIexec Impacket

Para que las reglas funcionen, es necesario configurar el envío de los eventos correspondientes al SIEM:

• Inicio de procesos (Windows security log – 4688, auditd – execve) y comandos de PowerShell (4104)
• Autenticación de usuarios en el sistema (Windows security log – 4624, 4768, 4769)
• Manipulación de diversos objetos (Windows security log – 4662, 4663, 4656, auditd – openat)
• Interacción con recursos compartidos (Windows security log – 5145)

Indicadores de compromiso

Indicadores de archivo:

CyberStrikeAI Windows Beacon
D726A8B4886C636F76CA6D30EF6A6FF4	c:\windows\temp\svchosts.exe
2770562d104391b92b42671c270079bb	c:\windows\temp\svcmon32.exe c:\programdata\svcmon32.exe
CyberStrikeAI Linux Beacon
09e1da2afa1216ecc55648ec8e122d2a
805B9E4AE74C903787416800999B8418
Tools & Scripts
29EFD64DD3C7FE1E2B022B7AD73A1BA5	C:\Windows\Temp\wdiag2.exe (Mimikatz)
74F57B3E897A4960DCDD5B7E8A54F9DF	c:\rwx\RogueWinRM.exe
0BBD08AF95F877F1D568B03DE2EB76B4	c:\ProgramData\p1.ps1 (Reverse Shell PS Script)

Indicadores de red:

185.186.245[.]144	C2 para Windows Beacon
fastcdn[.]bar	C2 para Windows Beacon
media.fastcdn[.]bar	C2 para Linux Beacon
104.234.26[.]163	C2 para la entrega de la carga útil + Linux Beacon