CyberStrikeAI em ataques reais: o uso de IA contra organizações

Introdução

Como parte do monitoramento proativo, os especialistas em inteligência de ameaças da Kaspersky identificaram uma campanha maliciosa que usa agentes de C2 controlados por inteligência artificial. As vítimas confirmadas da campanha são organizações do setor educacional em países da África e da América Latina. O CyberStrikeAI desempenhou papel central na pós-exploração. Trata-se de um framework de código aberto em que um orquestrador LLM, no lado do servidor de controle, planeja as ações, seleciona as ferramentas e gera os comandos, enquanto o implante os executa nos nós comprometidos. Com o CyberStrikeAI, os invasores avançaram do reconhecimento ao comprometimento total do domínio.

Segundo nossos dados, esta é uma das primeiras descrições públicas de um comprometimento com uso de LLM em ambiente real. A campanha que detectamos mostra com clareza como está mudando o papel da IA no arsenal dos invasores. Até pouco tempo atrás, os modelos de linguagem eram usados sobretudo nos estágios preparatórios, para redigir e-mails de phishing, depurar código ou procurar vulnerabilidades. Agora, eles se integram ao próprio núcleo do ataque e automatizam as ações em todos os estágios: execução do payload, persistência no host, reconhecimento, movimentação lateral e, por fim, coleta e exfiltração de dados. A pós-exploração ocupa um lugar especial neste contexto. É o estágio que, por tradição, exigia o trabalho manual de um operador experiente.

A principal característica de um esquema baseado em um framework de IA é que o implante deixa de ser um simples meio de execução dos comandos do operador. As decisões se dividem em dois níveis. O operador define a tarefa em termos gerais e o modelo determina como cumpri-la, quais comandos enviar ao host e em que ordem. Assim, a intenção estratégica fica com o ser humano, a escolha dos estágios técnicos passa para o modelo e o implante executa essas decisões.

Para entender como este esquema funciona na prática, examinaremos a cadeia de ações dos invasores que nossos analistas reconstruíram durante a investigação dos incidentes.

Cronologia do ataque

Analisaremos a cronologia do ataque com base em um dos incidentes da campanha detectada.

A primeira fase segue um procedimento padrão. Um operador humano obtém acesso à infraestrutura da vítima por meio de um servidor SQL comprometido, versão 16.0.1000, e depois coleta informações básicas sobre o host, implanta seu conjunto de ferramentas e faz o reconhecimento da rede. Toda essa atividade leva quase 24 horas e é seguida por uma pausa de duas semanas.

A segunda fase é radicalmente diferente. O primeiro passo é a implantação do agente de C2 do CyberStrikeAI, que recebe comandos do orquestrador LLM no servidor. Nessa fase, o agente realiza:

• persistência e reconhecimento local em 2 minutos;
• reconhecimento do domínio nas 5 horas seguintes;
• após uma breve pausa de alguns dias, a transição para o estágio final (movimentação lateral via SMB e WMI, coleta em massa de credenciais nos hosts e extração do banco de dados), atividade que leva no máximo 1 hora.

Detalharemos esses estágios na próxima seção.

Detalhes técnicos

Sobre o CyberStrikeAI

O CyberStrikeAI é uma plataforma escrita em Go, modular e de código aberto, para automação de pentest. Sua principal característica é que um único processo de servidor reúne a orquestração do ataque por LLM e um servidor C2 integrado com agentes (beacon).

Toda a camada “inteligente” fica isolada no servidor de controle. As funções de C2 (chamada de utilitários de reconhecimento e exploração, gerenciamento de conexões de web shell, atribuição de tarefas aos agentes e leitura de resultados) ficam disponíveis para o modelo como ferramentas MCP. O implante, por sua vez, é um agente de C2 clássico, sem funções de IA. Ele não tem chaves de API, não faz chamadas a APIs de serviços de IA nem tem lógica autônoma. Ele consulta o servidor de escuta (listener) em intervalos regulares via HTTP/S, TCP ou WebSocket, executa comandos de shell e opera no sistema de arquivos. Para a vítima, a atividade parece uma sessão comum de administração remota em que, em vez de um operador humano, o orquestrador LLM do servidor coloca as tarefas na fila. O LLM influencia a forma como as decisões são tomadas, mas não a forma como os comandos correspondentes chegam ao host.

Embora o CyberStrikeAI seja de acesso público, é possível vincular amostras específicas do framework a determinados invasores ou campanhas. Os seguintes indícios permitem a detecção e a atribuição:

• Painel de controle: na inicialização, é gerado um certificado TLS autoassinado cujos campos de emissor e titular contêm o nome do framework. O certificado é criado na memória a cada inicialização, por isso o campo not_before registra o horário de início do processo. Assim, como no Cobalt Strike, o histórico de varreduras permite reconstruir a cronologia de reinicializações.
  

  Certificado TLS autoassinado do painel de controle do CyberStrikeAI

• Implante: os metadados de compilação (go version -m) contêm o caminho do pacote principal, com dados que apontam para o gerador integrado do CyberStrikeAI, um diretório temporário com o identificador da compilação. Esse caminho é idêntico em todos os payloads, o que o torna uma assinatura estável. Além disso, o campo build info inclui metadados do sistema de controle de versão, úteis para correlacionar amostras entre si.
• Autenticação: ao se comunicar com o servidor, o implante envia na solicitação HTTP o cabeçalho X-Implant-Token com um valor fixo. O token é exclusivo de cada servidor C2 e fica incorporado ao payload malicioso desde a compilação, por isso serve tanto como indicador de rede quanto como sinal de que as amostras pertencem ao mesmo servidor.

Parâmetros do cabeçalho HTTP que o implante envia ao servidor

Vale considerar que a versão do implante não reflete a versão do servidor. O implante pode operar por meses enquanto o operador atualiza o componente do servidor, pois as configurações dos listeners e as chaves são mantidas após a atualização. Nos incidentes detectados, observamos o uso de uma única versão do agente durante todo o incidente. Nesse caso, a data de compilação da amostra pode indicar o limite inferior da implantação da infraestrutura do CyberStrikeAI, mas ainda assim não permite estimar a duração do comprometimento.

Execution & Privilege Escalation

Os primeiros comandos maliciosos nos sistemas das vítimas da campanha analisada partiram do processo sqlservr.exe, o que aponta para o provável vetor de acesso inicial e para o contexto em que os invasores obtiveram a capacidade de executar código. Vale destacar que o próprio invasor, de forma manual e no contexto desse processo, executou os comandos marcados como executados antes da instalação do agente. Nesse estágio, ainda não se trata de atividade automatizada do implante, mas de ações manuais do operador.

Antes de executar o agente nas máquinas, os invasores verificaram a presença dele com um script do PowerShell, que revela os caminhos padrão de instalação: C:\Windows\Temp\, C:\Windows\, C:\ProgramData\, C:\Temp. Além disso, o invasor pode disfarçar o nome do agente como o de processos legítimos do sistema. No exemplo abaixo, ele imita o svchost.exe (svchosts.exe)

Como a maioria dos agentes de C2 para Windows, o CyberStrikeAI usa o PowerShell para executar o payload. Quando o operador solicita, o agente também codifica os comandos em Base64 para contornar a detecção por palavras-chave.

Comando decodificado:

Com privilégios administrativos (por exemplo, com uma conta de administrador de domínio), em vez de executar os comandos de forma direta, o agente costumava criar tarefas agendadas nos hosts remotos para que o payload malicioso rodasse com privilégios de SYSTEM:

Uma alternativa sem o schtasks é criar a tarefa por meio do objeto COM Schedule.Service:

O payload (p1.ps1) do exemplo acima é um shell reversa (reverse shell) que se conecta ao servidor no endereço 185.186.245[.]144:5501:

Os invasores propagaram o p1.ps1 e scripts semelhantes pela rede por meio de compartilhamentos administrativos de rede e do protocolo WMI, como detalhamos na seção Lateral Movement.

Stealth

Além da codificação de comandos em Base64 e da ofuscação de consultas SQL/LDAP, que descreveremos nas seções Collection & Exfiltration e Discovery, respectivamente, os invasores dividiam o payload malicioso em vários arquivos. Chama a atenção que os scripts eram transferidos dessa forma antes mesmo da instalação do agente, ou seja, em um estágio em que costuma atuar uma pessoa, mas apresentam traços evidentes de geração por LLM.

Abaixo, a gravação sequencial de vários trechos do script no arquivo d3.b64.

Em seguida, os invasores usaram o utilitário certutil para decodificar o arquivo resultante e o executaram com o seguinte comando:

Depois de montado e decodificado, o conteúdo do script era o seguinte:

O script é uma ferramenta para descriptografar segredos da DPAPI a partir do arquivo C:\ProgramData\dsn_line.txt. O arquivo, por sua vez, é preenchido pelo seguinte comando, que procura a string DSN com as configurações de conexão no arquivo de configuração do SQL Server Reporting Services rsreportserver.config e copia o conteúdo dela para dsn_line.txt.

Vale destacar que vários scripts transferidos e executados pelo método descrito contêm comentários em chinês (## indica comentários do pesquisador).

Persistence

Após a entrega bem-sucedida do implante do CyberStrikeAI, o primeiro passo era garantir a persistência no sistema-alvo. Para isso, o agente criava uma tarefa agendada chamada SystemUpdate, com o caminho do implante como ação a executar:

A análise do código-fonte do framework revelou outro método de persistência, que consiste em adicionar uma chave ao ramo do registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run, com nome igual ao da tarefa (SystemUpdate).

Em sistemas Linux, a persistência do agente também tem duas variantes. Uma delas é adicionar a entrada @reboot <path_to_beacon> & ao crontab do usuário (o processo inicia com o sistema); a outra é adicionar a linha (nohup <path_to_beacon> &>/dev/null &) ao ~/.bashrc (o agente inicia ao abrir um shell bash interativo).

Vale notar que o CyberStrikeAI delega a escolha do método de persistência ao LLM conectado. No entanto, graças ao mecanismo Human-in-the-Loop (HITL, humano no circuito), o operador mantém controle total do processo, pois os comandos gerados pelo modelo podem exigir aprovação ou ajuste manual obrigatório antes da execução.

Discovery

Local Discovery

Antes de instalar o agente no host sob seu controle, os invasores coletavam de forma manual informações básicas sobre o sistema com um conjunto de comandos bastante corriqueiro:

Também de forma manual, para verificar o acesso à internet e obter o IP externo das máquinas infectadas, os invasores usavam o serviço chinês dnslog[.]cn. O serviço gera um domínio aleatório de terceiro nível e, em seguida, o invasor tenta resolvê-lo na máquina comprometida.

Se a máquina tiver acesso à internet, a consulta é resolvida e os invasores obtêm, na página do serviço, o endereço IP externo do dispositivo sob seu controle.

Já o agente gera, para o reconhecimento, um script mais complexo, cujo objetivo é traçar um caminho para escalonar privilégios por meio do comprometimento do SCCM ou da exploração do msiexec (chave AlwaysInstallElevated):

Para encontrar formas de escalonar privilégios no âmbito local, o agente também executava scripts para inventariar os serviços iniciados com contas de domínio e as tarefas em execução como SYSTEM:

Durante a atividade, os invasores verificavam em intervalos regulares os alertas do Microsoft Defender:

Remote Discovery

Após coletar informações sobre o host sob seu controle, os invasores passavam ao reconhecimento dentro da rede. No estágio preparatório do ataque, eles coletavam de forma manual informações adicionais sobre os nós remotos com o utilitário net.exe.

No estágio principal, para descobrir os nós disponíveis sem utilitários adicionais (nmap, fscan etc.), o agente usava a funcionalidade nativa do PowerShell:

Consultas LDAP correspondentes a objetos do Active Directory também ajudavam a mapear a rede:

Além disso, verificava-se via WMI a presença de um agente já instalado nos hosts remotos:

Domain Discovery

O estágio seguinte era obter informações sobre o domínio das vítimas. Para isso, antes de instalar o agente, os invasores usavam utilitários padrão do sistema operacional:

Depois, no entanto, o implante do CyberStrikeAI realizava o reconhecimento com scripts do PowerShell gerados:

Além das informações básicas do domínio, o agente executava consultas LDAP para coletar informações voltadas a ataques de Kerberoasting / AS-REP Roasting:

Além disso, o agente verificava a presença de LAPS e do Microsoft Azure no domínio:

Para detectar indícios de uso do Microsoft Azure na infraestrutura, os invasores também procuravam a pasta .azcopy, criada pelo utilitário AzCopy (Microsoft Azure Storage Copy), nos diretórios pessoais dos usuários:

Credential Access

Após concluir o reconhecimento e mapear a rede, os invasores passavam ao estágio seguinte, o dump de credenciais. Para isso, o agente usava um conjunto clássico de utilitários LOLBIN e ferramentas conhecidas de terceiros.

O agente fazia o dump dos hives do registro que contêm credenciais com o utilitário reg.exe:

O agente fazia o dump do processo lsass.exe por meio da função MiniDump da biblioteca comsvcs.dll. Em vez do nome do processo-alvo, ele usava o PID para dificultar a detecção estática por linha de comando:

Após comprometer contas de domínio privilegiadas (em especial, a do administrador de domínio integrado), os invasores também executavam, por meio do agente, ataques DCSync e Golden Ticket com uma versão renomeada do utilitário mimikatz:

Lateral Movement

Para se propagar pela rede com as contas comprometidas, os invasores usam utilitários do conjunto Impacket, em especial o WMIExec, como mostra a linha de comando característica do utilitário:

Já o agente, depois de instalado, prefere usar mecanismos padrão do sistema operacional, como compartilhamentos de rede.

Outro método que o agente usa para executar comandos remotos é o protocolo WMI. Com ele, o agente propagou, em especial, o script de shell reversa p1.ps1 mencionado acima. Para isso, usou contas comprometidas de usuários com privilégios de administrador local nos hosts-alvo:

A segunda variante de movimentação lateral via WMI usa o cmdlet Invoke-CimMethod:

Command & Control

Para entregar esse conjunto de ferramentas (scripts maliciosos, mimikatz e o próprio agente) aos nós iniciais da cadeia de infecção, os invasores usavam utilitários padrão do sistema operacional:

Depois de instalado, o agente verifica a disponibilidade das portas do servidor C2. Os mecanismos para isso são praticamente ilimitados e dependem da “imaginação” do LLM conectado ao servidor de agentes:

Para baixar utilitários adicionais, o implante do CyberStrikeAI também usava utilitários nativos (LOLBINs). O conjunto de ferramentas podia ficar hospedado em servidores próprios ou ser baixado diretamente do GitHub:

Collection & Exfiltration

O estágio de coleta de dados merece atenção especial. Nele se manifesta outra capacidade da orquestração por LLM, a geração automática de consultas SQL e LDAP adaptadas a uma tarefa específica.

Em um dos incidentes da campanha, os invasores instalaram o implante do CyberStrikeAI no servidor SQL de uma instituição de ensino e coletavam informações do banco de dados via PowerShell. Exemplo de comando executado pelo agente:

Versão normalizada do script executado, com comentários:

Antes de acessar os dados, o agente verificava os privilégios da conta que usava para se conectar ao banco de dados:

Decodificada, a verificação é a seguinte:

Nos recursos de rede, antes de coletar os arquivos, o agente percorria os diretórios de forma recursiva para identificar os arquivos de interesse.

Para interagir com o sistema de arquivos, o implante oferece uma interface integrada com suporte a upload e download diretos de arquivos. A transferência de arquivos ocorre pelo principal canal criptografado de comunicação com o C2 (HTTP ou TCP), e o implante codifica os dados em Base64 e os empacota nas respostas JSON padrão do agente.

As primitivas integradas do implante também incluem a captura de tela da máquina infectada. Como nas demais ações, o implante não a inicia por conta própria. O orquestrador LLM emite o comando de captura e o agente apenas o executa e devolve o resultado pelo mesmo canal de controle.

No Windows, o comando para capturar a tela é o seguinte:

A variante para Linux é a seguinte:

Nos ataques que detectamos, a coleta de dados foi o último elo. A cadeia terminava ali e não observamos atividade posterior.

Atribuição

O principal artefato para a atribuição nesta campanha são os metadados de compilação dos implantes. Os invasores compilavam o payload malicioso dentro de um clone git do projeto, por isso o compilador Go incorporava aos binários informações do sistema de controle de versão: hash e horário do commit, além da flag vcs.modified=true (equivalente ao sufixo +dirty), que indica alterações locais não confirmadas na cópia de trabalho. Juntos, esses campos formam uma impressão digital única de cada compilação.

Por esta impressão digital, as amostras se dividem em dois grupos independentes; em cada um, o implante para Windows e o implante para Linux têm metadados de compilação idênticos. A coincidência indica que, dentro de cada grupo, os invasores compilaram os dois payloads na mesma cópia de trabalho do projeto.

No entanto, esses grupos são independentes entre si. Eles não compartilham infraestrutura de C2, e os servidores de controle executam versões diferentes do CyberStrikeAI. Ou seja, os metadados de compilação permitem vincular com segurança as amostras dentro de cada grupo, mas não justificam agrupar os dois conjuntos em um só.

Os dados disponíveis não permitem vincular a atividade a nenhum grupo conhecido de invasores nem afirmar com certeza que o mesmo operador está por trás dos dois grupos. Dois fatores impedem isso. Primeiro, a ferramenta é de acesso público. Por isso, operadores diferentes podem tê-la implantado por conta própria e compilado o payload malicioso em condições semelhantes. Segundo, a geração de comandos pelo modelo. Quem define, em grande parte, o “estilo” característico de um operador é o LLM, e não uma pessoa. Por um lado, isso aumenta a diversidade dos comandos. Um mesmo comando, gerado várias vezes, pode apresentar diferenças na forma. Por outro, isso elimina traços individuais e reduz o valor das métricas comportamentais para fins de atribuição.

No entanto, os comentários em chinês encontrados nos scripts dos invasores e o uso de serviços chineses permitem supor que a atividade esteja ligada a um operador de língua chinesa. Além disso, os analistas observaram a distribuição dos horários de reinicialização dos servidores de controle. Como o certificado TLS autoassinado é recriado a cada inicialização do processo, o campo not_before registra o momento da reinicialização, e a maioria dessas reinicializações ocorreu durante o horário comercial no fuso UTC+8.

A origem da própria ferramenta aponta de forma indireta na mesma direção. O CyberStrikeAI surgiu na comunidade chinesa de segurança da informação, onde é bastante conhecido.

Conclusão

O CyberStrikeAI é um exemplo representativo, mas não único, da mudança em curso na classe de frameworks de C2. O orquestrador LLM deixa de ser um complemento do reconhecimento e se torna a camada de controle da pós-exploração. Se o HexStrike AI e seus equivalentes cobrem a etapa de “encontrar e invadir”, e Sliver/Mythic/Havoc, a de “persistir e controlar”, o CyberStrikeAI fecha o ciclo. Um único processo de servidor escrito em Go chama utilitários via MCP, gerencia conexões de web shell e atribui tarefas ao implante, enquanto o modelo analisa os resultados e decide o próximo passo.

A principal conclusão é que, por enquanto, a presença da IA na cadeia de ataque não impõe novos desafios à detecção. Toda a parte “inteligente” permanece do lado do invasor, e ao host comprometido chegam ações conhecidas, que vão do reconhecimento a técnicas como Kerberoasting e AS-REP Roasting, além de dump do LSASS, DCSync e Golden Ticket. Trata-se de um conjunto típico e bem documentado de técnicas de comprometimento de domínio. A novidade do ataque não está nos métodos, mas na velocidade e na facilidade com que os invasores os executaram. A orquestração por IA reduziu os requisitos de qualificação do operador, mas não levou o ataque além do que os defensores já conhecem e sabem detectar. Os tempos também são reveladores. Algumas fases-chave da atividade, como a persistência, a movimentação lateral e a obtenção de credenciais, levaram poucas horas, e o ataque completo, da instalação do agente ao comprometimento das contas de administrador do domínio, durou de 3 a 4 dias.

No entanto, a arquitetura do CyberStrikeAI não se limita ao cenário descrito. Os mesmos mecanismos permitem montar, sob demanda, cadeias mais complexas, incluindo a extração de segredos da DPAPI e ataques ao SCCM e ao Azure IMDS. Tudo isso fica ao alcance do mesmo tipo de grupo de agentes de ameaça, cuja barreira de entrada é bastante baixa. À medida que os modelos evoluírem, a distância entre a complexidade da orquestração e o nível das técnicas empregadas vai diminuir, e o papel do operador vai migrar de forma gradual da atribuição de tarefas para a supervisão das ações do modelo.

Detecção com as soluções da Kaspersky

Pode parecer que ataques com agentes de IA exigem regras de detecção de natureza nova. Sem dúvida, para detectar a atividade de um agente LLM instalado em um host da infraestrutura, é necessário criar uma lógica de detecção baseada nas particularidades dos agentes. As regras de detecção desta atividade estão disponíveis no Hunt Hub com o seguinte filtro.

No entanto, no ataque descrito, a lógica é outra. A principal diferença está na arquitetura do próprio ataque. O agente LLM não estava dentro do perímetro da rede corporativa. Ele operava de forma remota por meio do agente de C2, orquestrava as ações e não deixava rastros de sua presença na infraestrutura, como solicitações de API específicas para LLMs locais ou padrões anômalos de consumo de recursos nos hosts.

A principal diferença entre esta atividade e o ataque conduzido por um invasor experiente está, em grande parte, na velocidade. Do ponto de vista tático, técnico e metodológico, a IA usa, em geral, as mesmas ferramentas, utilitários e técnicas que um pentester humano. Ela não escreve exploits exclusivos do zero. Em vez disso, combina métodos conhecidos, adapta-os de forma dinâmica à situação e contorna, por conta própria, as falhas dessas ferramentas.

Como as ações executadas sob o controle de um agente de IA na rede são indistinguíveis das realizadas por humanos, para detectá-las bastam regras clássicas e bem ajustadas de correlação e análise comportamental. Veja alguns exemplos de como o Kaspersky Next EDR Expert detecta o ataque descrito.

• Para detectar a execução de um script malicioso por meio de uma tarefa agendada remota, é necessário monitorar a criação do processo schtasks.exe com o argumento /s. O EDR Expert detecta esta atividade com as regras create_task_on_remote_host_using_standard_tool, scheduled_task_creation_as_system_via_schtasks e scheduled_task_with_powershell_execution.
  
• Durante o ataque, o invasor precisa acessar as credenciais da vítima. Neste caso, um dos métodos para obtê-las é uma técnica bem conhecida que usa ferramentas legítimas para fazer o dump do LSASS, por meio da chamada da função MiniDump da comsvcs.dll. O EDR Expert detecta esta atividade com as regras dumping_memory_with_com_services_dll e suspicious_lsass_memory_access.
  
• A movimentação lateral é parte importante da cadeia de ataque, pois permite ao invasor se deslocar pela infraestrutura e atingir seus objetivos. Neste caso, ele usa o protocolo WinRM e inicia as conexões a partir do PowerShell. É uma técnica padrão que permite ao invasor executar comandos em máquinas remotas sem túneis de rede adicionais. O EDR Expert detecta essa atividade com as regras using_powershell_for_remote_execution_via_wmi e winrm_send_command.
  

Para detectar atividade maliciosa no tráfego de rede, usamos o Kaspersky Anti Targeted Attack (KATA). Os agentes do CyberStrikeAI se comunicam com o servidor de comando e controle sem recorrer a plataformas de IA como ChatGPT ou Claude. Em vez disso, assim como em ataques sem agentes de IA, a infraestrutura que os invasores prepararam de antemão cumpre o papel de servidor C2 do agente. A análise do tráfego de rede descriptografado por soluções NDR permite identificar sinais de comunicação característicos da atividade dos agentes do CyberStrikeAI. Ao detectá-los, o KATA gera um alerta com o veredicto Backdoor.CyberStrikeAI.HTTP.C&C.

Para detectar atividade de pós-exploração, além da tecnologia IDS, é possível usar a NAD (Network Anomaly Detection). Ela analisa todo o tráfego em busca de sinais suspeitos que não correspondam à atividade de rede típica do nó.

Por exemplo, a regra de NDR:NAD chamada “Reconhecimento de contas de domínio via consultas LDAP” detecta as ações que o CyberStrikeAI realiza no estágio Domain Discovery.

Saiba mais sobre a tecnologia NDR:NAD em nosso artigo no Securelist.

Além disso, na seção Research Graph do portal Kaspersky Threat Intelligence, é possível visualizar e analisar as relações entre os endereços C2 e os arquivos usados pelos invasores. Também é possível rastrear o surgimento de novos implantes do CyberStrikeAI que se comunicam com endereços maliciosos.

Além disso, o serviço Threat Lookup, disponível no portal, permite atribuir arquivos maliciosos ao CyberStrikeAI por meio de mecanismos de atribuição baseados no código do executável.

O Kaspersky SIEM detecta todos os estágios do ataque executado pelo agente CyberStrikeAI. O repositório do produto disponibiliza mais de 100 regras para detectar as técnicas analisadas, das quais listamos as mais críticas.

Execução de vários comandos a partir do processo sqlservr.exe:

• R300_04_Windows shell started by a web application

Download e execução do payload via PowerShell:

• R110_03_PowerShell code downloaded and executed

Criação de tarefas agendadas do Windows:

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

Persistência via crontab ou bashrc:

• R099_06_Suspicious cron job activity
• R405_02_UNIX shell configuration modification

As regras do pacote localizado em KUMA Packages/SOC package/Configuration discovery detectam a coleta de informações sobre hosts, configurações de rede e o domínio por meio de diversos utilitários de reconhecimento. Regras que agregam as detecções por ferramenta de reconhecimento:

• 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

Coleta de dados para Kerberoasting e AS-REP Roasting:

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

Dump de hives do registro com credenciais por meio do utilitário reg.exe:

• R230_02_Copying data with credentials from the Windows registry

Dump do processo lsass.exe por meio da função MiniDump da biblioteca comsvcs.dll:

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

Ataques DCSync e Golden Ticket com uma versão renomeada do utilitário mimikatz:

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

Movimentação lateral com o WMIExec:

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

Para que as regras funcionem, é necessário configurar o envio para o SIEM dos seguintes eventos:

• Inicialização de processos (Windows security log – 4688, auditd – execve) e comandos do PowerShell (4104)
• Autenticação de usuários no sistema (Windows security log – 4624, 4768, 4769)
• Ações realizadas em objetos variados (Windows security log – 4662, 4663, 4656, auditd – openat)
• Interação com recursos compartilhados (Windows security log – 5145)

Indicadores de comprometimento

Indicadores de arquivo:

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

Indicadores de rede:

185.186.245[.]144	Servidor C2 para Windows Beacon
fastcdn[.]bar	Servidor C2 para Windows Beacon
media.fastcdn[.]bar	Servidor C2 para Linux Beacon
104.234.26[.]163	Servidor C2 para entrega do payload + Linux Beacon