Akira testou variante em Rust com foco padrão em servidores ESXi

A variante Akira v2 foi escrita em Rust, expôs uma CLI completa para operadores e incluiu lógica multithread para criptografia, desligamento de VMs e execução voltada por padrão a hipervisores ESXi bare metal.

Componente	Variante Akira v2, ransomware escrito em Rust com capacidade de atingir servidores hipervisores ESXi bare metal e ambientes Linux.
Vetor	Execução local do binário por operador ou afiliado com argumentos de linha de comando; a amostra interpreta flags por uma CLI construída com seahorse e ajusta comportamento por parâmetros como --stopvm e --path.
Impacto	Criptografia de arquivos e VMs, tentativa de desligamento de máquinas virtuais ESXi e geração de nota de resgate, com execução multithread para acelerar a operação.
Prioridade	Caçar execução incomum de binários Rust em servidores ESXi/Linux, uso de comandos vim-cmd encadeados por shell e invocações de ransomware com flags operacionais.
Artefatos	Nomes e construções observáveis incluem Akira v2, default_action, lock, lock_closure, seahorse, indicatif, available_parallelism, --stopvm e --path.
Mitigação	Restringir acesso administrativo a hosts ESXi, monitorar execução de processos de shell que chamem vim-cmd, validar backups fora do alcance do hipervisor e revisar telemetria de linha de comando em Linux.

Resumo técnico

A variante experimental Akira v2 representa uma tentativa de levar o ransomware Akira para uma base escrita em Rust, com suporte multiplataforma e foco operacional em servidores ESXi bare metal. O comportamento descrito aponta para um binário com interface de linha de comando completa, lógica de preparação de execução, coleta de arquivos-alvo, criação de múltiplas threads e rotina final de criptografia. A escolha de Rust não muda apenas a implementação: ela também aumenta o custo de análise reversa, porque a combinação de biblioteca padrão, crates de terceiros e otimizações de compilação em modo de produção gera funções grandes, com muito código de suporte incorporado diretamente ao fluxo de controle.

A amostra foi associada a uma fase de experimentação ocorrida no início de 2024, quando afiliados do ecossistema Akira promoveram a variante como uma nova versão chamada Akira v2. A funcionalidade descrita indica capacidade de atingir ESXi por padrão, mas não limita o binário a esse alvo. O mesmo programa também contém elementos suficientes para operar como ransomware Linux de propósito geral quando parâmetros específicos alteram o caminho de execução. Para equipes de defesa, o ponto central é tratar a amostra como uma ferramenta orientada por operador: o risco não está apenas na rotina criptográfica, mas no conjunto de opções que permite escolher caminhos, desligar VMs, definir paralelismo e acompanhar o andamento da operação.

O fluxo de alto nível é dividido entre parsing de argumentos, seleção de comportamento em default_action, coleta de arquivos e chamada de lock, que atua como invólucro para lançar threads responsáveis pela lógica de criptografia em lock_closure. Essa separação ajuda a explicar por que a superfície de detecção precisa considerar tanto eventos de sistema quanto sinais de execução do próprio binário. A rotina de criptografia pode ser o resultado final, mas os estágios anteriores deixam rastros: argumentos de processo, chamadas de shell, enumeração de VMs, cálculo de paralelismo, mensagens de progresso e criação de threads.

Fluxo técnico

A execução começa com a coleta de argumentos por std::env::args, seguida de conversão para uma estrutura de iteração em memória. A análise descreve como essa área depende do sistema operacional: em Linux, strings de sistema seguem uma representação próxima de um vetor com comprimento, buffer e capacidade; em Windows, aparece a codificação interna WTF8, com campo adicional para indicar conhecimento de UTF-8. Esse detalhe é importante para engenharia reversa, porque o binário não apresenta uma sequência simples de chamadas legíveis. A representação dos argumentos e o código gerado pelo compilador aparecem misturados a estruturas da biblioteca padrão, o que complica a delimitação entre lógica do autor e infraestrutura gerada automaticamente.

A presença da crate seahorse explica a existência de uma função chamada default_action e de uma CLI mais elaborada do que seria esperado em uma amostra minimalista. O ransomware inicializa uma aplicação de linha de comando, registra flags e usa essas opções para controlar comportamento. Esse modelo reforça a hipótese de uso por afiliados ou operadores humanos, já que parâmetros como número de threads, caminho de ataque e ações contra VMs tornam a execução adaptável ao ambiente invadido. A interface não é apenas conveniência de desenvolvimento; ela vira parte da capacidade operacional, pois permite mudar escopo e intensidade sem recompilar a ferramenta.

Um dos pontos mais relevantes é o uso de available_parallelism para determinar paralelismo quando o operador não fornece um valor explícito. A chamada aparentemente simples resulta em grande volume de código de biblioteca incorporado em default_action, incluindo lógica relacionada a cotas de CPU em cgroup, variantes de controle de grupos Linux e contagem de CPUs por funções como CPU_COUNT. Em modo Release, essas camadas podem ser inlinadas profundamente, fazendo com que blocos de assembly pareçam código manual complexo quando, na prática, são desdobramentos da biblioteca padrão e de chamadas auxiliares. Para analistas, isso muda a estratégia: antes de atribuir intenção ao autor, é necessário separar otimização de compilador, crate externa e lógica realmente específica do ransomware.

A variante também usa indicatif para apresentar barras de progresso, spinners e mensagens de estado ao operador. O conteúdo operacional citado inclui etapas como destruição de backups, geração de chave simétrica de sessão, criptografia de VM e escrita de nota de resgate. Esses textos indicam que o malware foi pensado para exibir progresso durante a execução, algo compatível com operações manuais em ambientes de servidor. O uso de uma biblioteca de experiência de terminal não reduz o impacto técnico; ele mostra que a operação foi organizada para acompanhar tarefas longas e paralelas, especialmente quando há grande volume de arquivos ou máquinas virtuais no escopo.

Superfície afetada

A superfície principal descrita é formada por servidores ESXi bare metal e, de forma mais ampla, sistemas Linux onde o binário possa ser executado com permissões suficientes para acessar arquivos de interesse. O comportamento padrão voltado a ESXi é evidenciado pela semântica do parâmetro --path: sem específicação de outro comportamento, a amostra tenta agir sobre VMs ESXi. Essa escolha operacional aumenta o risco em ambientes virtualizados, porque um único host pode concentrar múltiplas cargas críticas e volumes associados. A criptografia nesse nível pode afetar disponibilidade de várias máquinas ao mesmo tempo, mesmo sem necessidade de comprometer cada convidado individualmente.

A flag --stopvm adiciona uma etapa de impacto direto sobre a disponibilidade. Quando definida, o malware cria um novo processo que executa um encadeamento de comandos para listar VMs e desligá-las por vim-cmd. O comando observado é vim-cmd vmsvc/getallvms | tail -n +2 | awk '{system("vim-cmd vmsvc/power.off " $1)}'. Em termos defensivos, esse artefato é valioso porque combina utilitário nativo de administração ESXi, pipeline de shell e desligamento programático de VMs. A presença desse padrão em histórico de processos, auditoria de shell ou logs de execução deve ser tratada como evento crítico quando não fizer parte de manutenção autorizada.

Embora o foco padrão seja ESXi, a amostra não deve ser tratada como exclusiva de hipervisores. O próprio desenho de CLI, as rotinas de coleta de arquivos e a lógica multithread indicam capacidade de atuação em Linux comum quando orientada por parâmetros. Isso amplia a superfície para servidores de arquivos, hosts de aplicação, sistemas com volumes montados e ambientes onde operadores tenham obtido acesso interativo ou execução remota prévia. O material analisado não descreve o mecanismo de intrusão inicial, exploração de vulnerabilidade, credenciais usadas ou infraestrutura de comando e controle; portanto, a análise defensiva deve concentrar-se na execução pós-comprometimento e nos sinais locais do binário.

A versão foi descrita como uma experiência promovida por afiliados durante um período do início de 2024, não como uma substituição comprovada de todas as variantes anteriores do ecossistema Akira. Essa distinção importa para priorização: a ameaça é tecnicamente relevante pela combinação de Rust, ESXi e CLI operacional, mas a presença da variante em um ambiente específico deve ser confirmada por artefatos de execução, nomes de funções, argumentos, comportamento de processo e efeitos em arquivos ou VMs.

• Servidores ESXi bare metal com acesso administrativo ou execução de comandos locais pelo operador.
• Hosts Linux onde o binário consiga enumerar caminhos, iniciar threads e acessar arquivos-alvo.
• Ambientes virtualizados em que comandos vim-cmd possam listar e desligar VMs a partir do hipervisor.
• Rotinas de backup acessíveis pelo mesmo contexto de execução do ransomware.

Hunting e telemetria

A telemetria mais útil está na linha de comando e na árvore de processos. O uso de seahorse cria uma CLI com flags específicas, então registros de EDR, auditd, syslog, histórico de shell e coleta forense de processos devem ser revisados em busca de invocações com --stopvm, --path e parâmetros relacionados a número de threads. Mesmo que o nome do binário tenha sido alterado, a combinação de execução em diretórios temporários ou administrativos, argumentos de operação em massa e acesso simultâneo a muitos arquivos pode indicar atividade compatível com ransomware.

Em ESXi, a busca deve priorizar comandos que chamem vim-cmd vmsvc/getallvms e vim-cmd vmsvc/power.off em sequência ou dentro de pipelines de shell. O padrão com tail e awk sugere automação para ignorar cabeçalho da listagem e desligar cada VM enumerada. Esses comandos podem existir em rotinas legítimas de manutenção, mas a execução próxima a criação de arquivos de nota de resgate, alterações em muitos arquivos de VM, atividade intensa de escrita e processos desconhecidos deve elevar a severidade. A correlação temporal é essencial: desligamento de VMs seguido de criptografia de arquivos do datastore é muito mais forte do que um comando isolado em janela de administração planejada.

Para análise reversa e triagem de amostras, a presença de Rust em modo Release exige cuidado com falsos caminhos. Blocos enormes dentro de default_action podem representar código inlinado de available_parallelism, quota, quota_v1, quota_v2, CPU_COUNT e count_ones, não necessariamente uma rotina maliciosa escrita manualmente. O hunting estático deve procurar strings e símbolos comportamentais quando disponíveis, incluindo seahorse, indicatif, default_action, lock, lock_closure, mensagens de progresso, nomes de flags e referências a comandos ESXi. A ausência de linhas de fonte em informações de depuração também é coerente com compilação otimizada, mas sozinha não prova malícia.

No endpoint, sinais de criação de muitas threads, varredura de diretórios, escrita de nota de resgate e abertura sequencial de arquivos devem ser avaliados junto com contexto de privilégio. Em servidores de virtualização, a coleta deve incluir histórico de tarefas do host, eventos de desligamento de VMs, alterações em datastores e qualquer execução de shell por contas administrativas. Em Linux, auditd pode registrar execve com argumentos, enquanto EDRs podem capturar cadeia pai-filho, hash do binário e diretório de execução. O material analisado não fornece hashes, domínios ou IPs; portanto, regras baseadas apenas em IoCs de rede não são apropriadas para está variante com os dados disponíveis.

• Processos com flags --stopvm ou --path executados em hosts Linux ou ESXi.
• Sequência de comandos envolvendo vim-cmd vmsvc/getallvms e vim-cmd vmsvc/power.off.
• Criação de múltiplas threads por binário desconhecido antes de alto volume de escrita em arquivos.
• Strings ou símbolos relacionados a seahorse, indicatif, default_action, lock e lock_closure em amostras suspeitas.
• Mensagens de terminal associadas a geração de chave de sessão, criptografia de VM, escrita de nota de resgate ou destruição de backups.

Mitigação

A resposta deve começar pela redução do alcance operacional no hipervisor. Contas capazes de executar vim-cmd, desligar VMs e acessar datastores precisam ser limitadas, monitoradas e separadas de credenciais usadas por sistemas comuns. Acesso administrativo ao ESXi deve exigir autenticação forte, origem de rede controlada e registro centralizado. Como a variante depende de execução local com parâmetros, impedir ou detectar shells administrativos inesperados no host é uma medida de alto valor. Também é importante revisar automações legítimas que usam pipelines com vim-cmd, para que exceções sejam documentadas e desvios sejam visíveis.

Em contenção, a descoberta de sinais compatíveis com Akira v2 em um host de virtualização deve levar ao isolamento do servidor, preservação de logs e bloqueio de novas sessões administrativas. Desligar o host sem coleta mínima pode destruir evidências voláteis; por outro lado, manter o sistema exposto durante criptografia ativa aumenta o dano. A decisão operacional deve priorizar interromper processos suspeitos, desconectar acesso de rede do operador e proteger volumes ainda não afetados. Backups devem ser verificados a partir de ambiente separado, porque a própria amostra exibe mensagens relacionadas à destruição de backups, e qualquer cópia acessível pelo mesmo contexto de privilégio pode estar no escopo.

A validação pós-incidente deve confirmar se VMs foram desligadas por atividade autorizada ou pelo encadeamento de comandos descrito, quais datastores sofreram escrita anômala e se houve execução com parâmetros de caminho. A análise do binário, quando recuperado, deve distinguir código de biblioteca inlinado de funcionalidade maliciosa real. Isso evita gastar tempo em blocos derivados de available_parallelism e direciona a investigação para flags, coleta de arquivos, criação de threads e rotina de criptografia. A ausência de IoCs de rede no material não elimina risco; apenas indica que a detecção primária, neste caso, deve ser comportamental e baseada em host.

A prevenção também passa por arquitetura de backup. Cópias imutáveis, armazenamento fora do domínio administrativo do hipervisor, testes de restauração e segregação de credenciais reduzem o impacto de uma execução bem-sucedida. Em ambientes Linux, controles de aplicação podem impedir execução de binários desconhecidos em diretórios de escrita comum. Em ESXi, a linha de defesa mais prática é combinar endurecimento de acesso, logs centralizados, alertas para vim-cmd sensível e revisão contínua de contas com permissão para manipular VMs em massa.

• Criar alertas para vim-cmd vmsvc/getallvms seguido de vim-cmd vmsvc/power.off fora de janelas autorizadas.
• Restringir contas administrativas de ESXi e registrar origem, horário e comando de sessões privilegiadas.
• Bloquear execução de binários desconhecidos em servidores Linux críticos por controle de aplicação quando viável.
• Manter backups imutáveis ou isolados do mesmo contexto de credencial usado para administrar hipervisores.
• Preservar linha de comando, árvore de processos, eventos de VM e cópia do binário antes de limpeza completa.