Kaspersky detecta CyberStrikeAI em educação

Resumo executivo

Kaspersky reconstruiu uma intrusão contra organizações educacionais em que o CyberStrikeAI, um framework modular de código aberto, foi usado para acelerar o post-exploitation com apoio de um LLM hospedado no servidor C2. A fonte não identifica países específicos da América Latina nem da África, e também não atribui a campanha com certeza a um grupo conhecido. Ainda assim, o relatório documenta uma cadeia técnica completa, com um operador humano definindo objetivos gerais e um modelo planejando ações, escolhendo ferramentas, gerando comandos e analisando resultados.

A cronologia mostra uma operação segmentada, com tempos muito diferentes entre o acesso inicial, a persistência e a fase final. A entrada começou por um SQL Server comprometido, versão 16.0.1000. Depois houve quase um dia de reconhecimento de rede, preparação de ferramentas e coleta básica de dados do host. Em seguida, veio uma pausa de duas semanas antes do implante CyberStrikeAI ser instalado. Uma vez ativo, a persistência e o reconhecimento local levaram cerca de dois minutos, o reconhecimento de domínio durou cinco horas e, após nova pausa de vários dias, a fase final começou. Do despliegue do agente até a tomada de contas de administrador de domínio, Kaspersky estima entre três e quatro dias.

O trecho final foi curto e agressivo. A operação inteira durou no máximo uma hora e incluiu movimento lateral por SMB e WMI, execução remota com WMIExec do Impacket, uso de compartilhamentos administrativos, distribuição do script p1.ps1 pela rede, dump massivo de credenciais, acesso ao LSASS, consultas LDAP ligadas a Kerberoasting e AS-REP Roasting, DCSync, Golden Ticket e exportação de bases de dados. O relatório também documenta persistência por meio de tarefa agendada SystemUpdate ou da chave HKCU\Software\Microsoft\Windows\CurrentVersion\Run no Windows, e via crontab com @reboot ou ~/.bashrc no Linux.

Um ponto central do informe é a arquitetura do CyberStrikeAI. O implante não contém IA, não chama serviços como ChatGPT ou Claude e não usa chaves de API. Ele funciona como um agente C2 convencional, que consulta periodicamente o servidor por HTTP/S, TCP ou WebSocket, executa comandos de shell e manipula arquivos. A camada de inteligência fica no C2: ali o LLM seleciona ferramentas, redige comandos, analisa respostas e pode produzir consultas SQL e LDAP adaptadas à tarefa. Em outras palavras, a automação não está no endpoint, mas na orquestração remota, com um mecanismo human-in-the-loop que deixa ao operador a possibilidade de aprovar ou corrigir ações.

Para a leitura regional, o valor do relatório está no alcance e nos limites. Kaspersky situa a atividade no ambiente de instituições educacionais da América Latina e da África, mas não publica países nem vítimas concretas neste caso. Também não consegue estabelecer com certeza que o mesmo operador esteja por trás das duas campanhas ou de toda a infraestrutura identificada. A fonte aponta indícios, como comentários em chinês em scripts, uso de serviços chineses, reinícios de servidores em horário UTC+8 e traços do próprio framework, que sugerem uma possível conexão com um operador de fala chinesa. Mesmo assim, isso não prova identidade nem localização. A partir do relatório, a Softonic levantou que este seria um dos primeiros casos públicos observados in the wild em que um LLM teve papel operacional central, mas essa leitura não é uma verificação independente.

Contexto e antecedentes

O material da Kaspersky descreve um framework que não nasceu como malware tradicional, mas como um ambiente modular de código aberto escrito em Go para automatizar testes de intrusão. O CyberStrikeAI reúne em um único processo um servidor C2, agentes ou beacons e uma camada de orquestração baseada em LLM. Essa arquitetura importa porque desloca a inteligência operacional para o lado do atacante, e não para a máquina comprometida. O implante faz o transporte e a execução, enquanto o C2 decide o que fazer com as informações recebidas.

Neste caso, o relatório insiste que o agente não contém funcionalidade de IA. Não há chaves de API nem chamadas a serviços externos de LLM a partir do endpoint. O beacon, por sua vez, age como um cliente clássico de C2, com consultas periódicas e capacidades normais de shell e sistema de arquivos. Essa distinção separa o discurso publicitário de "IA no malware" do que Kaspersky realmente observou: automação da orquestração na infraestrutura do atacante.

O material também posiciona a campanha em ambientes educacionais. A Softonic, citando o relatório da Kaspersky, contextualiza o interesse do setor pela concentração de registros de estudantes, dados financeiros, credenciais e pesquisa. Mas a publicação não traz medição própria sobre vítimas latino-americanas ou africanas e também não adiciona identificação geográfica que permita medir o alcance por país. Por isso, a leitura regional precisa manter o foco na técnica e nos limites da atribuição.

Tabela de fatos-chave

Linha do tempo da operação

Cadeia de ataque e TTPs

A cadeia observada pela Kaspersky é mais interessante pela arquitetura do que pela novidade de suas peças. O acesso inicial por SQL Server comprometido não é exótico, mas o uso posterior de um LLM hospedado no C2 muda a velocidade e a coordenação do operador. Em vez de uma sequência manual de comandos, um por um, o sistema pôde sugerir ações, preparar comandos e avaliar resultados a partir dos objetivos definidos pela pessoa no comando.

O relatório mostra que o implante em Windows usou PowerShell e Base64 para os comandos, e que a persistência foi estabelecida por meio da tarefa agendada SystemUpdate ou da chave HKCU\Software\Microsoft\Windows\CurrentVersion\Run. No Linux, a persistência foi documentada por crontab com @reboot ou ~/.bashrc. O beacon não faz processamento inteligente no endpoint. Ele consulta o servidor por HTTP/S, TCP ou WebSocket, executa shell e opera sobre arquivos, como qualquer agente C2 convencional.

A etapa de credenciais é uma das mais densas do caso. Kaspersky documentou consultas LDAP ligadas a Kerberoasting e AS-REP Roasting, extração de hives do registro com reg.exe, dump do LSASS com MiniDump de comsvcs.dll e, depois, DCSync e Golden Ticket com uma versão renomeada de Mimikatz. Essa progressão sugere uma sequência organizada para ampliar privilégios, consolidar acesso e mover-se lateralmente dentro do domínio. Também aparece o uso de um binário identificado como wdiag2.exe, classificado pela fonte como Mimikatz.

O movimento lateral documentado usou WMIExec do Impacket, compartilhamentos administrativos, WMI e Invoke-CimMethod. O script p1.ps1 foi distribuído pela rede com essas mesmas capacidades. Kaspersky também relatou transferência de arquivos pelo canal criptografado principal com o C2, por HTTP ou TCP, com dados em Base64 e encapsulados em respostas JSON do agente. A isso se soma a captura de tela ordenada pelo orquestrador LLM e executada pelo implante.

Persistência e execução no Windows e no Linux

A persistência documentada pela Kaspersky mostra que o CyberStrikeAI não dependeu de um único método. No Windows, o uso de SystemUpdate como tarefa agendada e da chave Run em HKCU oferece redundância. No Linux, a combinação de crontab com @reboot e ~/.bashrc cumpre função semelhante. São mecanismos conhecidos, mas no contexto do caso ajudam a mostrar uma operação que buscou sobreviver a reinícios sem adicionar complexidade desnecessária.

O detalhe do PowerShell com codificação Base64 também importa. O relatório menciona que o implante em Windows usou esse padrão para seus comandos, e a Kaspersky refletiu isso em regras de detecção específicas. Na prática, isso deixa rastros consistentes tanto em endpoints quanto em telemetria de execução de processos. Não é um traço exclusivo desta campanha, mas faz parte da assinatura técnica documentada.

Credenciais, domínio e escalada

A sequência Kerberoasting, AS-REP Roasting, extração de hives, dump do LSASS, DCSync e Golden Ticket indica uma escalada gradual em direção ao controle do domínio. Não se trata de um golpe único, mas de uma construção progressiva de privilégios e alcance. O ponto de virada é claro: do despliegue do agente até a tomada de contas de administrador de domínio passaram entre três e quatro dias, com um trecho final muito concentrado que explorou o acesso já consolidado.

O material não permite afirmar quantos hosts ficaram comprometidos nem o tamanho real de cada domínio. Mas deixa claro que a etapa de credenciais foi prioritária. A Kaspersky inclusive publicou regras SIEM e EDR para detectar esses padrões, o que sugere que o relatório foi pensado não apenas como análise retrospectiva, mas também como guia de caça defensiva.

Impacto regional

A reconstrução disponível não permite falar de um país latino-americano ou africano específico. Kaspersky situa o caso em organizações educacionais dessas regiões, mas não publica geografia fina das vítimas nem atribui o conjunto da infraestrutura a um único ator. Por isso, o impacto regional deve ser lido como um alerta técnico sobre um tipo de intrusão, e não como uma medição país por país.

Panorama regional

O caso combina um acesso inicial relativamente clássico com uma etapa posterior muito acelerada pela orquestração com LLM. Para instituições educacionais, isso tem um efeito claro sobre a janela de resposta. A primeira fase deixou margem temporal, com quase um dia de reconhecimento e uma pausa de duas semanas antes do beacon. Depois, no entanto, a atividade foi comprimida: persistência em minutos, domínio em horas e fase final em menos de uma hora.

Esse padrão importa para ambientes com redes híbridas, múltiplos subdomínios, serviços legados e credenciais compartilhadas. O relatório documenta que a operação terminou com tomada de privilégios de domínio, movimento lateral e exportação de bases de dados. Em um contexto educacional, isso pode envolver acesso a identidades, registros, informações financeiras e pesquisa, embora o relatório da Kaspersky não quantifique esses ativos para vítimas da região.

Leitura operacional para a América Latina

O material não traz casos confirmados por país na América Latina. Argentina, Chile, Paraguai, Bolívia, Peru, Colômbia, Brasil, México, Uruguai e Estados Unidos aparecem na estrutura editorial, mas não há fatos verificáveis específicos para essas jurisdições nesta campanha. Por isso, qualquer conclusão nacional seria especulativa.

O que é verificável é outra coisa. Os TTPs observados, como WMIExec, compartilhamentos administrativos, PowerShell com Base64, LSASS dumping, DCSync e Golden Ticket, são concretos o suficiente para orientar hunting e detecção. A infraestrutura publicada também permite buscas defensivas em logs, telemetria de rede e processos. O mapa geográfico fica em aberto, mas a técnica está bem definida.

Indicadores técnicos

IOC e marcas de infraestrutura

Os IOC publicados pela Kaspersky cobrem domínio, IP, hashes e caminhos de arquivo. No Windows, aparecem beacons associados a svchosts.exe e svcmon32.exe, além de um hash adicional para p1.ps1 e para wdiag2.exe, identificado como Mimikatz. No Linux, a fonte publicou dois hashes de beacon. Também constam fastcdn[.]bar, media.fastcdn[.]bar e 104.234.26[.]163 como parte da infraestrutura observada.

O domínio dnslog[.]cn aparece com uso diferente, ligado à verificação de conectividade com a internet e à obtenção do IP externo. Kaspersky também menciona a busca pelo diretório .azcopy como indício de uso do Microsoft Azure Storage Copy. Não é um IOC clássico de rede, mas é uma pista útil para hunting em ambientes onde se investigue exfiltração ou staging com ferramentas de armazenamento em nuvem.

Análise para equipes de segurança

A primeira leitura defensiva é que o despliegue de um LLM no C2 não elimina as técnicas conhecidas, mas acelera seu encadeamento. Isso muda o tipo de alerta que vale priorizar. Se a fase final pode ser executada em menos de uma hora depois que o acesso é consolidado, a detecção tardia perde valor. O foco deve ir para a observação precoce do reconhecimento, da persistência e da sequência de credenciais.

No Windows, as regras publicadas pela Kaspersky dão uma guia direta. Os sinais sobre schtasks.exe, PowerShell baixado e executado, shell lançado pelo agendador, acesso suspeito ao LSASS, dump com comsvcs.dll, uso de Mimikatz, DCSync e Golden Ticket formam uma matriz concreta para hunting. Em rede, a combinação de WMIExec do Impacket, compartilhamentos administrativos e uso de WMI para mover scripts como p1.ps1 permite priorizar telemetria de execução remota.

A fonte também publicou regras EDR Expert e SIEM que apontam para esses comportamentos. Entre elas estão 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 e winrm_send_command. Em SIEM aparecem ainda 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 e R450_41_Golden Ticket Attack.

A defesa também precisa olhar para a primeira fase. O acesso inicial passou por um SQL Server comprometido. Se esse vetor ficar fora do radar, a janela anterior ao implante pode ser perdida por completo. Neste caso, houve quase um dia de reconhecimento e duas semanas de espera antes do beacon. Isso abre espaço para detecção de anomalias em banco de dados, enumeração de rede, movimentação a partir de um host SQL e criação precoce de artefatos de staging.

Priorização prática

Primeiro, revisar exposição e hardening de SQL Server, especialmente se o host também funciona como pivô interno. Segundo, monitorar tarefas agendadas, chaves Run, crontab e modificações de shells no Linux. Terceiro, buscar padrões anômalos de autenticação e solicitações repetidas de TGS, além de extração de credenciais do registro e acesso ao LSASS. Quarto, observar WMI, WinRM e SMB quando usados em sequência para distribuir scripts ou binários.

O achado mais operacional do relatório é que o LLM ajuda a comprimir a tomada de decisão, não a esconder a técnica. Isso significa que as detecções baseadas em comportamento continuam sendo as mais úteis. Se o atacante consegue gerar mais rápido consultas LDAP ou SQL, a telemetria de domínio e endpoint seguirá mostrando Kerberoasting, AS-REP Roasting, DCSync, Golden Ticket e movimento lateral. O desafio está em juntar sinais dispersos antes que a fase final consuma o objetivo.

Perguntas frequentes

O que muda nesta campanha com o uso de um LLM no C2?

Muda a velocidade da orquestração, não a classe de técnicas usadas. Segundo a Kaspersky, o LLM fica no servidor C2, planeja ações, escolhe ferramentas, gera comandos e analisa resultados. O implante continua convencional. Isso acelera o post-exploitation, mas não substitui sinais como WMI, LSASS dumping, DCSync ou Golden Ticket.

A Kaspersky identificou países latino-americanos específicos afetados?

Não. O relatório situa o caso em organizações educacionais da América Latina e da África, mas não publica países específicos nem vítimas concretas. Também não permite separar o impacto por jurisdição. A seção de Impacto regional resume o que pôde ser verificado e destaca a ausência de segmentação nacional.

Quais técnicas de credenciais foram mais relevantes na operação?

A cadeia incluiu Kerberoasting, AS-REP Roasting, extração de hives do registro, dump do LSASS com comsvcs.dll, DCSync e Golden Ticket. A Kaspersky também associou o uso de Mimikatz renomeado e publicou regras SIEM para vários desses padrões. O bloco técnico do relatório reúne a sequência completa e sua leitura operacional.

Quais IOC públicos servem para buscar essa atividade?

A fonte publicou 185.186.245[.]144, fastcdn[.]bar, media.fastcdn[.]bar, 104.234.26[.]163, dnslog[.]cn, hashes de beacons Windows e Linux, e caminhos como c:\windows\temp\svchosts.exe, c:\windows\temp\svcmon32.exe e c:\ProgramData\p1.ps1. A tabela de Indicadores técnicos lista tudo com seu contexto de uso.

Por que a Kaspersky não atribui essa atividade com certeza?

Porque os dados disponíveis não permitem ligar a operação a um grupo conhecido nem afirmar que o mesmo operador está por trás das duas campanhas ou de toda a infraestrutura. A fonte menciona indícios, como comentários em chinês, serviços chineses e horários UTC+8, mas os considera insuficientes para uma atribuição firme.