Atores de ameaça associados ao ransomware Aurora, também conhecido como Aur0ra, foram observados usando o Cursor, assistente de programação com IA da SpaceX, para invadir redes-alvo, segundo descobertas da CloudSEK e da Gambit Security.
As duas análises independentes se baseiam em uma infraestrutura exposta ligada ao grupo de cibercrime de língua russa, o que levou à descoberta do conjunto de ferramentas, do histórico de shell e do encryptor usados pela operação. A CloudSEK informou que o diretório aberto expôs “meses de atividade” e esteve ativo contra mais de 20 organizações em nove países entre abril e julho de 2026. Quatro dessas vítimas já foram listadas no site de vazamento de dados do grupo.
“O operador usou o Cursor, um assistente de programação agêntico, para planejar ataques em russo, enquanto excluía, sem exceção, faixas de IP da CEI [Comunidade dos Estados Independentes] e domínios de países da CEI”, observou a CloudSEK.
Os primeiros detalhes sobre o Aurora surgiram no fim de maio de 2026, quando a CYFIRMA destacou ataques voltados principalmente a sistemas Windows e o avanço técnico contínuo do grupo por meio de atualizações incrementais e expansão de recursos. Dados da Ransomware.Live listam 33 vítimas nos Estados Unidos, Alemanha, Países Baixos, Canadá e Reino Unido.
Em um caso detalhado pela Black Hills Information Security no início deste mês, o acesso inicial foi obtido por meio de um bombardeio agressivo de e-mails, seguido por ligações para funcionários de pessoas que se passavam por técnicos da central de atendimento de TI, com o objetivo de ajudá-los a lidar com o problema. O resultado foi o estabelecimento de acesso remoto por meio de uma ferramenta de código aberto chamada Xray-core.
A cadeia de ataque depois avança por movimento lateral via SMB, LDAP, WinRM, RDP e RPC, com obtenção de acesso a contas administrativas de alto privilégio. Em seguida, os invasores abusam dessas contas para evitar a detecção, apagando logs e desativando o Microsoft Defender antes de coletar e exfiltrar dados sensíveis e implantar o encryptor.
A CloudSEK disse ter identificado versões do Aurora para Windows e Linux escritas em Zig. A empresa acrescentou que o histórico de conversas recuperado do operador mostra uso intenso do Cursor para planejar várias fases do ataque, inclusive um plano completo de exploração do Active Directory Certificate Services (AD CS) escrito em russo.
“Os dois binários do encryptor, o sap.exe para Windows e o encrypt.out para Linux/ESXi, são compilações estáticas de uma única base de código em Zig, compiladas para destinos diferentes em vez de terem sido escritas duas vezes”, afirmou a empresa. “O binário para Windows até carrega dentro dele exemplos de uso da versão para Linux, um resquício do compartilhamento de uma mesma árvore de código entre as duas plataformas.”
A variante para Windows também foi equipada para dificultar a recuperação do sistema, apagando cópias de sombra de volume e desativando diretamente a Restauração do Sistema no Registro. Já a versão para Linux e ESXi tenta encerrar à força todas as máquinas virtuais do host antes de iniciar a criptografia.
Além disso, uma chave recuperada do encryptor Aurora teria dado acesso a uma negociação de resgate entre o threat actor e uma vítima não identificada, bem como a um cluster de quatro carteiras de criptomoedas com divisões variáveis entre afiliados e operadores principais. Segundo a apuração, os afiliados ficam com algo entre 54% e 79% do valor, enquanto o restante vai para os administradores.
Isso indica que a porcentagem destinada aos afiliados é definida caso a caso, dependendo do valor do resgate exigido e da receita da vítima. Os fundos ilícitos depois são lavados e convertidos em dinheiro.
A Gambit Security, que também divulgou sua análise sobre a atividade, afirmou ter observado o operador do Aurora usando o Cursor Agent, rodando o Claude Sonnet da Anthropic, para apoiar a exploração prática contra 10 alvos entre 8 de abril e 21 de maio de 2026.
“Nesses casos, o agente recebeu credenciais ou uma rota já existente dentro da organização vítima”, disse Eyal Sela, diretor de inteligência de ameaças da Gambit Security. “Depois disso, ele foi encarregado de várias atividades de exploração.”
“O agente recebeu tarefas de exploração padrão. Em alguns casos, o atacante apenas pediu que o agente alcançasse um objetivo, como ‘diga-me quais permissões o usuário tem’. Em outros, indicou qual ferramenta de exploração deveria ser usada ou instruiu o agente a seguir um plano de ataque previamente gerado. Em alguns casos, o Agent forneceu uma lista de possíveis próximos passos e o atacante apenas respondeu com um número correspondente a uma delas.”
Algumas das tarefas delegadas ao agente incluem:
- instalar um cliente VPN ou proxychains, depois configurá-lo e conectar-se à vítima com credenciais fornecidas ou um túnel SOCKS já existente
- mapear as sub-redes internas em busca de hosts com Nmap ou NetExec
- enumerar o domínio para informar quais privilégios um usuário fornecido possui, usando o coletor BloodHound do NetExec
- tentar ataques de relay de NTLM, forçando autenticação com PetitPotam, Coerce Plus e PrinterBug, e usando o ntlmrelayx do Impacket para repassar a autenticação resultante
- realizar ataques com certificados usando Certipy
“A maioria dos comandos não atingiu o objetivo declarado na primeira tentativa, o que levou a vários refinamentos e mudanças nos comandos e scripts usados em cada tarefa”, disse a Gambit. “Alguns acabaram tendo sucesso, enquanto outros falharam e devolveram apenas um relatório das tentativas ao atacante.”
Além disso, os ataques envolvendo a versão para Linux usaram um script em Python, chamado esxi_finder.py, para varrer hypervisors VMware ESXi e servidores vCenter dentro da rede da vítima.
O desenvolvimento é mais um exemplo de como agentes maliciosos estão recorrendo a ferramentas comerciais de IA para conduzir ataques cibernéticos, mesmo com os fornecedores de modelos implementando mais barreiras para evitar uso indevido. Os nomes das empresas afetadas não foram divulgados, mas a Reuters informou que elas são Christeyns, Teckentrup, Helideck Certification Agency, Bayou Title, uma distribuidora farmacêutica argentina e uma fabricante italiana.
Surge o Gryxa Toolkit
O caso também sucede a descoberta de um novo kit assistido por IA, batizado Gryxa, usado por um threat actor motivado financeiramente para executar uma operação de acesso inicial contra 324 hosts. A ReliaQuest disse que o Gryxa representa o primeiro caso observado pela empresa em que a IA foi usada para construir toda a operação, desde o toolkit até o console de onde ele é executado.
“O Gryxa transforma software legítimo de monitoramento e gerenciamento remoto (RMM) em acesso clandestino, mantém o acesso vivo por meio de vários mecanismos de persistência que operam de forma independente e depois rouba credenciais salvas em navegadores baseados em Chromium”, afirmou a empresa.
“Ele também faz escalonamento contra a proteção do endpoint quando a conexão com o ator é interrompida, desativando ou tentando desinstalar o agente de segurança. Em conjunto, esses recursos dão ao ator acesso duradouro a um host e permitem o roubo de carteiras de criptomoedas.”
As evidências indicam que o threat actor por trás da operação burlou as restrições de um agente de programação de IA ao apresentar todo o processo de desenvolvimento como uma “implantação interna autorizada”. É provável que o Gryxa seja distribuído por meio de e-mails de phishing.
Depois de executado em um host comprometido, o malware estabelece persistência com tarefas agendadas e consegue contornar as proteções de criptografia vinculada ao app do Chromium, chamadas ABE, para roubar credenciais de navegadores. As credenciais coletadas são transmitidas pelo Telegram.
Talvez o aspecto mais incomum do Gryxa seja o fato de registrar tentativas de remediação e repassá-las ao threat actor. Em especial, depois que o implant visível do RMM é removido, um componente oculto do malware coleta logs do Windows e artefatos do host e faz o upload para uma infraestrutura controlada pelo atacante.
Além disso, se o relay do ator ficar inacessível, o Gryxa tenta desativar e desinstalar agentes de proteção de endpoint, como o Microsoft Defender e outros, em cerca de 10 a 13 minutos. Assim que o relay volta a ficar acessível, o toolkit reativa o Defender.
“O componente do Gryxa apenas coletava e enviava; ele não examinava o que havia obtido”, disse a ReliaQuest. “O ator tira suas conclusões sobre qual ferramenta realizou a remoção, qual conta a executou e em que ordem, depois de receber o arquivo compactado.”
“O console do ator inclui uma tarefa pronta chamada collect-forensics, o que indica que essa é uma capacidade rotineira, e não uma resposta a um incidente específico. O Gryxa rotaciona seus arquivos de log quando eles excedem 200 KB, o que significa que a atividade recente é preservada para um analista que atue rapidamente.”
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...