
CyberStrikeAI em Ambiente Real: Um Orquestrador de LLM Alcançou Administrador de Domínio em Alvos Educacionais na América Latina e na África
- GoogleNOVOGoogle: Gemini 4 Carbon2026-11-10$2.00 / $10.00 por 1M de tokens · 87 tok/s
- AnthropicNOVOAnthropic: Claude Fable 5.22026-11-09$8.00 / $40.00 por 1M de tokens · 96 tok/s
- orcaNOVOOrca: OrcaC2 1.02026-11-0717 tok/s
- OrcaNOVOOrcaCyber: GLM 5.3 Abliterated / Uncensored2026-11-04$3.00 / $5.00 por 1M de tokens · 88 tok/s
- OrcaNOVOOrcaCyber: Hy4 Abliterated / Uncensored2026-11-04$0.80 / $1.60 por 1M de tokens · 163 tok/s
- OrcaNOVOOrcaCyber: Kimi K3.1 Pro Abliterated / Uncensored2026-11-04$4.00 / $20.00 por 1M de tokens · 63 tok/s
- OrcaOrcaCyber: MiniMax M3.1 Flash Abliterated / Uncensored2026-10-29$0.80 / $1.60 por 1M de tokens · 129 tok/s
- OrcaOrcaCyber: GLM 5.3 Flash Abliterated / Uncensored2026-10-27$0.80 / $1.60 por 1M de tokens · 66 tok/s
- OrcaOrcaCyber: Qwen3.8 Flash Next Abliterated / Uncensored2026-10-26$0.80 / $1.60 por 1M de tokens · 94 tok/s
- OrcaOrcaCyber: MiMo V2.6 Flash Abliterated / Uncensored2026-10-26$0.80 / $1.60 por 1M de tokens · 42 tok/s
- MoonshotMoonshotAI: Kimi K3.1 Pro2026-10-2447Inteligência
- OrcaOrcaCyber: DeepSeek V4.1 Flash Abliterated / Uncensored2026-10-23$0.80 / $1.60 por 1M de tokens · 187 tok/s
- minimaxMiniMax: M3.1 Flash2026-10-1929Inteligência
- OrcaOrca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 por 1M de tokens · 203 tok/s
- deepseekDeepSeek: DeepSeek V4.1 Flash 10172026-10-1733Inteligência
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-10-1740Inteligência
- OrcaOrca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 por 1M de tokens · 122 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2955Inteligência
- anthropicAnthropic: Claude Sonnet 5.52026-09-2855Inteligência
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 por 1M de tokens · 313 tok/s
Em 2 de novembro de 2026, a Kaspersky publicou um relatório da Securelist e um comunicado de imprensa descrevendo intrusões em organizações do setor educacional em vários países da América Latina e da África, nas quais o trabalho de pós-exploração foi conduzido por um modelo de linguagem de grande porte. A ferramenta era o CyberStrikeAI, um framework de testes de penetração de código aberto baseado em Go, cujo servidor de comando e controle hospeda um LLM que seleciona ferramentas e escreve comandos, enquanto um implante comum os executa no host da vítima. No único caso que a Kaspersky reconstrói em detalhes, um operador humano entrou por um Microsoft SQL Server comprometido, pausou por duas semanas e então deixou o agente agir: contas de administrador de domínio foram comprometidas em três a quatro dias, e o último estágio — movimento lateral, extração massiva de credenciais e exportação de um banco de dados — foi concluído em menos de uma hora. A Kaspersky não nomeia nenhuma instituição nem país, não informa o número de vítimas e afirma ter observado a atividade entre setembro e outubro de 2026. O registro completo desta campanha, com seu grau de gravidade, classificação de confiança e lista completa de fontes, está arquivado no Orca AI Incident Archive, ao lado das demais entradas sobre intrusões assistidas por IA.
O que a Kaspersky realmente publicou
O documento principal é "CyberStrikeAI in the wild: o uso de IA em ataques do mundo real a organizações", publicado na Securelist em 2 de novembro de 2026 e creditado a Kirill Antonov, Vladislav Vlasov e Dmitry Chizhmak, da equipe de pesquisa de ameaças da Kaspersky. Ele é acompanhado pelo comunicado de imprensa da própria Kaspersky, emitido no mesmo dia, que resume os mesmos achados. O grau de confiança A do arquivo descreve o quão bem esses dois documentos concordam entre si e quão específico é o detalhe técnico; não é uma declaração de que uma segunda organização tenha verificado a intrusão de forma independente.
A cobertura secundária deste relatório não fornece essa segunda organização. Cybersecuritynews.com, Cyberpress, SecurityOnline e o TechTrends Kenya, sediado em Nairóbi, publicaram matérias entre 2 e 3 de novembro de 2026, e cada uma delas deriva do comunicado da Kaspersky, e não de investigação própria; a matéria do veículo queniano é construída em torno da mesma citação do comunicado de imprensa de Nikita Nazarov, chefe de Exploração de Ameaças da Kaspersky. Em 9 de novembro de 2026, nenhuma universidade afetada, ministério da educação ou equipe nacional de resposta a emergências cibernéticas havia confirmado publicamente as intrusões, e a Kaspersky não publicou as identidades das vítimas. Essa ausência é, ela própria, parte do registro: o que está documentado em detalhe são as técnicas de atuação, não o dano a qualquer instituição nomeada.
A declaração de escopo da Kaspersky é deliberadamente limitada. As vítimas confirmadas, nas palavras dela, foram "organizações do setor educacional em vários países da África e da América Latina". Ela não diz quantas, quais países, nem como a campanha foi detectada inicialmente — apenas que a equipe a encontrou "como parte do monitoramento proativo de ameaças".
Uma distinção importa aqui, porque é fácil confundi-la. Organizações independentes já relataram o CyberStrikeAI em intrusões reais — mas não nestas intrusões. A Team Cymru vinculou a infraestrutura que executava a ferramenta à campanha de janeiro–fevereiro de 2026 contra mais de 600 dispositivos FortiGate, após observar 21 endereços IP exclusivos servindo-a entre 20 de janeiro e 26 de fevereiro de 2026. A unidade TrendAI da Trend Micro, em pesquisa publicada em 23 de outubro de 2026, descreveu um operador executando 44 agentes CyberStrikeAI coordenados que submeteram pelo menos 19 organizações identificáveis, pelo menos 16 delas no Japão, a atividade de validação em uma curta janela naquele outubro. A nota de pesquisa da Cloud Security Alliance de 28 de outubro de 2026 reúne ambos e conclui que nenhuma fonte publicada havia ainda vinculado as campanhas separadas do CyberStrikeAI a um único ator. Esse conjunto de trabalhos corrobora a premissa — de que este framework está sendo usado para atacar redes reais — e não diz nada sobre as vítimas de educação na América Latina e na África no relatório da Kaspersky.
A ferramenta, e onde a IA realmente estava situada
Como a Kaspersky o descreve, o CyberStrikeAI é "uma plataforma modular de código aberto escrita em Go para automatizar testes de penetração". Sua escolha de design definidora é que toda a camada inteligente reside no servidor de controle do atacante, e não na máquina da vítima. Utilitários de reconhecimento e exploração, gerenciamento de webshell, atribuição de tarefas aos agentes e leitura de resultados são todos expostos ao modelo como ferramentas MCP dentro de um único processo de servidor, e é o modelo que decide qual delas chamar em seguida.
O implante é a outra metade e é deliberadamente estúpido. A Kaspersky escreve que ele é "um agente C2 clássico sem funcionalidade de IA — sem chaves de API, sem chamadas às APIs de serviços de IA e sem lógica autônoma". Ele faz polling no ouvinte via HTTP/S, TCP ou WebSocket, executa comandos de shell e acessa o sistema de arquivos. Não é um modelo em execução na rede de uma vítima e nunca entra em contato com um provedor de IA. A divisão de trabalho é a frase que a Kaspersky usa para explicar todo o esquema: "As decisões são distribuídas em dois níveis: o operador define a tarefa em termos gerais, enquanto o modelo determina como executá-la."
O controle humano é mantido, e não removido. A Kaspersky observa um mecanismo de human-in-the-loop segundo o qual "o operador mantém controle total sobre o processo", e que os comandos gerados pelo modelo "podem exigir aprovação ou correção manual antes de serem executados". A IA escreve as etapas; uma pessoa ainda pode recusá-las.

Uma intrusão reconstruída, na ordem em que a Kaspersky a data.
O relatório acompanha um único incidente dentro da campanha, e sua primeira fase parece um trabalho comum de operação manual no teclado. Os comandos nos sistemas da vítima vieram do processo sqlservr.exe, apontando para "um SQL Server comprometido (versão 16.0.1000)" como a provável via de entrada. O operador então coletou informações básicas do host, implantou ferramentas e mapeou a rede manualmente. Isso levou "quase um dia", após o que os atacantes ficaram silenciosos por cerca de duas semanas.
A segunda fase é onde o ritmo muda. Com o agente CyberStrikeAI implantado, a persistência e o reconhecimento local foram realizados "em até 2 minutos" — uma tarefa agendada chamada SystemUpdate apontando para o implante, com uma chave Run no registro em HKCU\Software\Microsoft\Windows\CurrentVersion\Run como alternativa do framework no Windows, e uma entrada @reboot no crontab ou uma linha nohup em ~/.bashrc como suas alternativas no Linux. O reconhecimento de domínio foi executado "ao longo das 5 horas seguintes", usando scripts PowerShell gerados pelo modelo e consultas LDAP ao Active Directory, incluindo as pesquisas necessárias para preparar Kerberoasting e AS-REP Roasting e verificações de LAPS, Azure e diretórios .azcopy. Após "uma breve pausa de vários dias", o estágio final — movimento lateral via SMB e WMI, despejo massivo de credenciais e uma exportação de banco de dados — levou "não mais de uma hora".
A frase de resumo da Kaspersky é a que vale a pena manter: todo o ataque, “desde a implantação do agente até o comprometimento dos administradores de domínio – foi concluído em 3–4 dias.”

O trabalho de credenciais é um catálogo de técnicas conhecidas do Windows, e não algo novo: colmeias do Registro copiadas com reg.exe, lsass.exe despejado por meio da função MiniDump do comsvcs.dll usando o ID do processo em vez de seu nome para burlar a correspondência na linha de comando e — depois que a conta de administrador de domínio incorporada foi comprometida — ataques DCSync e Golden Ticket executados por meio de um binário Mimikatz renomeado, wdiag2.exe. O movimento lateral usou o WMIExec do Impacket, pastas administrativas compartilhadas e WMI, com um script de shell reverso, p1.ps1, enviado a hosts remotos e retornando conexão para 185.186.245[.]144:5501. Os payloads foram divididos em fragmentos como d3.b64 e remontados com certutil, e um beacon se disfarçou de svchosts.exe.
A coleta veio por último. O agente gerou consultas SQL adaptadas à tarefa, mas verificou os privilégios da conta do banco de dados antes de executá-las, varreu compartilhamentos de rede recursivamente antes de coletar os arquivos e retornou tudo pelo mesmo canal C2 criptografado, com os dados codificados em Base64 dentro de JSON. Capturas de tela em Windows e Linux estavam disponíveis, mas, segundo a Kaspersky, foram feitas apenas quando o orquestrador emitiu o comando. O relatório afirma que a coleta de dados "foi a etapa final do ataque: a cadeia terminou ali, e não observamos mais nenhuma atividade."
O que foi levado, e o que o registro não diz
A Kaspersky registra que o agente exportou registros de banco de dados do servidor SQL da organização de ensino e coletou arquivos de recursos de rede, e descreve o mecanismo em detalhes. Não informa quantos registros ou arquivos saíram, se a exportação foi concluída ou de quem eram os dados nas tabelas. Resumos secundários vão além do relatório nesse ponto: o texto do SecurityOnline afirma que o agente "gerou consultas SQL direcionadas para roubar registros de alunos e funcionários de tabelas de banco de dados", enquanto o próprio texto da Kaspersky descreve as consultas contra um servidor SQL de ensino sem especificar o que as tabelas continham. Os leitores devem tratar a descrição "registros de alunos e funcionários" como uma caracterização secundária, e não como uma constatação da Kaspersky.
Também não consta no registro: se alguma vítima detectou a própria intrusão, o que cada instituição fez depois, se os reguladores ou as autoridades de proteção de dados nos países afetados foram notificados e se a campanha ainda está em andamento. A Kaspersky diz apenas que a coleta de dados foi a última etapa observada nos incidentes que examinou. O comunicado de imprensa não contém orientações de remediação para as organizações afetadas — suas recomendações são direcionadas aos defensores em geral.
Atribuição: o que as evidências sustentam e o que não sustentam
A Kaspersky é explícita ao afirmar que não pode nomear um ator. "Os dados disponíveis não nos permitem vincular a atividade a nenhum grupo de atacantes conhecido, nem afirmar com certeza que o mesmo operador está por trás das duas campanhas." O artefato em que se apoia são os metadados de compilação Go dentro dos implantes, que contêm hashes de controle de versão, horários de commit e um sinalizador de cópia de trabalho suja — "uma impressão digital exclusiva para uma compilação específica." Com base nisso, as amostras se dividem em dois grupos, e dentro de cada grupo os payloads Windows e Linux compartilham metadados idênticos, o que significa que vieram da mesma cópia de trabalho.
Os grupos não estão conectados. Eles "não compartilham uma infraestrutura C2 comum", e versões diferentes do CyberStrikeAI estavam em execução nos dois conjuntos de servidores de controle. A Kaspersky apresenta duas razões pelas quais a atribuição é difícil aqui: o framework está disponível publicamente, então diferentes operadores poderiam ter criado payloads de forma independente sob condições semelhantes, e os próprios comandos são gerados por modelo, o que infla sua variedade enquanto elimina os hábitos individuais dos quais a atribuição comportamental depende.
O que resta é sugestivo, e não conclusivo. Alguns scripts traziam comentários em chinês, os atacantes usaram o serviço chinês dnslog[.]cn para confirmar o acesso à internet a partir dos hosts das vítimas, e a maioria das reinicializações dos servidores de controlo — recuperáveis porque o certificado TLS autoassinado é regenerado em memória a cada arranque, pelo que o seu campo not_before regista a hora da reinicialização — ocorreu dentro do horário comercial UTC+8. O próprio CyberStrikeAI foi desenvolvido dentro da comunidade chinesa de cibersegurança. O comunicado de imprensa da Kaspersky traça a linha com clareza: estes artefactos "não estabelecem a identidade ou a localização dos atacantes", e a empresa "não conseguiu atribuir a atividade a um grupo de ameaças conhecido nem confirmar que o mesmo operador controlava toda a infraestrutura identificada". Um operador falante de chinês é uma inferência, não uma constatação.
Por que a Kaspersky diz que isto não é uma emergência de deteção
A conclusão do relatório contesta a ideia de que um LLM na kill chain exige uma nova classe de defesa. Como o modelo reside no servidor do atacante, ele “não deixou vestígios 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 por hosts)”. O que os defensores veem, em vez disso, é uma intrusão com características humanas: os mesmos utilitários, as mesmas sequências, as mesmas entradas de log de eventos. O veredicto da Kaspersky é que “a introdução da IA na cadeia de ataque ainda não apresenta desafios fundamentalmente novos para a detecção”, que “regras clássicas e bem ajustadas de correlação e análise comportamental são suficientes” e que a novidade “não está nos métodos em si, mas na velocidade e facilidade com que foram executados”.
As detecções publicadas seguem essa lógica em vez de criar novas. O Kaspersky Anti Targeted Attack atribui o veredito de rede Backdoor.CyberStrikeAI.HTTP.C&C ao tráfego do implante; uma regra de detecção de anomalias de rede chamada "Scanning domain records via LDAP queries" detecta o reconhecimento de domínio; o Kaspersky SIEM traz mais de 100 regras que cobrem as técnicas do relatório, incluindo DCSync, Golden Ticket, Kerberoasting e Impacket WMIExec; e os implantes são classificados como HEUR:HackTool.Win64.CyberStrike.gen e HEUR:HackTool.Linux.CyberStrike.gen. A orientação da Kaspersky aos clientes é convencional — detecção e resposta em endpoints, detecção de rede, inteligência de ameaças e monitoramento fora do horário de expediente ou por meio de um serviço gerenciado.
A declaração de Nazarov no comunicado de imprensa é o mesmo argumento em uma frase: os atacantes "usaram um agente de IA baseado no CyberStrikeAI para executar uma cadeia de ataque completa e adaptar seus próximos passos dentro de redes comprometidas", mas "o framework ainda dependia de técnicas e procedimentos familiares, incluindo descoberta, dumping de credenciais, movimento lateral e coleta e exfiltração".
O que está estabelecido, e o que não está

Dito sem rodeios: o mecanismo está documentado a um nível que permitiria a um defensor caçá-lo amanhã — linhagem de processos a partir do sqlservr.exe, uma tarefa agendada chamada SystemUpdate, acesso ao LSASS por meio da comsvcs.dll, DCSync a partir de uma máquina que não seja controlador de domínio, o cabeçalho HTTP X-Implant-Token e os endereços C2 listados pela Kaspersky. A campanha em torno desse mecanismo não está documentada. A Kaspersky não publicou nenhuma lista de vítimas, nenhum detalhamento por país, nenhuma estimativa de volume de dados e nenhum ator. Tudo o que um leitor poderia querer saber sobre quem foi prejudicado e quão gravemente limita-se ao setor e à região.
Dois detalhes merecem destaque para quem consultar o relatório esperando mais. Primeiro, a Kaspersky descreve o ataque como "uma das primeiras descrições públicas de um comprometimento envolvendo um LLM em ambiente real", e não como a primeira — uma ressalva que limita a afirmação ao que a equipe conseguiu encontrar em relatórios públicos. Segundo, o relatório observa que a versão do implante não acompanha a do servidor, que configurações e chaves de listener sobrevivem a atualizações do operador e que a data de compilação de uma amostra fornece apenas a data mais antiga possível de implantação, não a duração de um comprometimento. O número de 3 a 4 dias é uma medição de um incidente reconstruído, não um limite para quanto tempo qualquer uma dessas intrusões durou antes de alguém perceber.
