Defesa contra ransomware Akira: blindando VMware e Veeam

Status do Incidente: Crítico / Em Andamento Gravidade: SEV-1 Vetores: CVE-2024-37085, Movimentação Lateral, Comprometimento de Backup

O grupo de ransomware Akira mudou a dinâmica dos ataques à infraestrutura. Não estamos mais lidando apenas com a exfiltração de dados de estações de trabalho. O alvo agora é a camada de armazenamento e virtualização: o hipervisor ESXi e o repositório de backup.

A sofisticação técnica do Akira reside na capacidade de utilizar ferramentas administrativas legítimas contra a própria infraestrutura, explorando configurações padrão de integração entre VMware e Active Directory. Se o seu ambiente de armazenamento de virtualização depende de autenticação via AD, você está operando em risco elevado.

Resumo em 30 segundos

• Vulnerabilidade crítica: A CVE-2024-37085 permite que invasores com acesso ao AD ganhem privilégios totais no ESXi recriando o grupo "ESX Admins".
• Erro de arquitetura: Servidores Veeam integrados ao domínio Windows permitem que um único comprometimento de credencial destrua a produção e os backups simultaneamente.
• A única defesa: Repositórios Linux imutáveis (Hardened Repository) com sistema de arquivos XFS desconectados do plano de controle do Windows.

A exploração da falha CVE-2024-37085 no VMware ESXi

Em julho de 2024, a Microsoft e a VMware detalharam uma vulnerabilidade lógica que se tornou a porta de entrada preferencial para grupos como o Akira. O problema não é um buffer overflow complexo, mas uma falha de design na integração de autenticação.

Por padrão, o ESXi concede privilégios administrativos totais a qualquer grupo do Active Directory chamado "ESX Admins". Se este grupo não existir no AD, mas o ESXi estiver "joinado" ao domínio, um atacante com privilégios para criar grupos no AD pode simplesmente criar um grupo com este nome e adicionar seu próprio usuário.

O hipervisor, ao sincronizar, entrega as chaves do root automaticamente.

Fig 1. O vetor de ataque privilegiado: como a falha de integração do AD entrega as chaves do reino ao Akira.

⚠️ Perigo: Muitos administradores de storage e virtualização integram o vCenter e os hosts ESXi ao domínio para facilitar o SSO (Single Sign-On). Essa conveniência é exatamente o vetor de ataque. O plano de controle do armazenamento (onde residem os VMDKs) nunca deve confiar cegamente no plano de identidade corporativo.

Uma vez dentro, o atacante não precisa de exploits adicionais. Ele já possui acesso ao sistema de arquivos VMFS e aos comandos de gerenciamento de armazenamento.

A mecânica do criptografador Linux e o desligamento das VMs

O Akira desenvolveu um binário ELF (Linux) especificamente para rodar dentro do ESXi. A execução segue um playbook rigoroso para garantir a destruição dos dados nos datastores.

Para criptografar um arquivo .vmdk (o disco virtual), o arquivo não pode estar em uso (bloqueado pelo processo VMX). O ransomware executa comandos esxcli para listar todas as máquinas virtuais em execução e forçar o desligamento imediato.

O comando típico observado nos logs de incidentes é: esxcli vm process kill --type=force --world-id=[ID]

Após o desligamento, o bloqueio de escrita no sistema de arquivos é liberado. O criptografador então percorre os volumes montados (/vmfs/volumes/), priorizando arquivos com extensões críticas: .vmdk, .vmx, .vmsd.

Em arrays de armazenamento All-Flash ou NVMe, a velocidade de criptografia é devastadora. O alto rendimento (throughput) desses dispositivos, que normalmente é uma vantagem para bancos de dados, joga contra a equipe de defesa, permitindo que terabytes de dados sejam tornados ilegíveis em questão de minutos.

O erro crítico de manter o servidor Veeam no domínio Windows

Durante a resposta a incidentes, frequentemente encontramos um cenário catastrófico: o servidor de backup Veeam Backup & Replication (VBR) está inserido no mesmo domínio do Active Directory que foi comprometido.

Se o atacante obteve credenciais de Domain Admin para explorar o ESXi, ele automaticamente possui acesso administrativo ao servidor Veeam via RDP ou execução remota de PowerShell.

O comportamento do Akira neste estágio é:

1. Acessar o console do Veeam ou usar o PowerShell do Veeam.

2. Localizar os repositórios de backup (seja SMB, iSCSI ou volumes locais ReFS).

3. Excluir os arquivos de backup ou formatar os volumes.

💡 Dica Pro: O servidor de gerenciamento de backup deve ser tratado como uma "Workgroup island" ou pertencer a um domínio de gerenciamento separado, com relação de confiança unidirecional ou nula com o domínio de produção.

Implementando repositórios imutáveis com Linux Hardened Repository

A defesa definitiva contra a exclusão ou criptografia dos backups não é depender apenas de antivírus, mas sim da arquitetura de armazenamento. O Veeam v11+ introduziu e refinou o conceito de Linux Hardened Repository (LHR).

O LHR utiliza a flag de imutabilidade do sistema de arquivos Linux (ext4 ou XFS) para impedir que qualquer usuário, inclusive o root (em condições normais de operação remota), delete ou modifique os arquivos de backup durante um período estipulado.

Fig 2. Arquitetura de Sobrevivência: Isolamento do plano de controle e imutabilidade no repositório Linux.

Requisitos de armazenamento para LHR

Para montar essa defesa, o hardware e o sistema de arquivos devem ser configurados especificamente:

1. Protocolo: O repositório deve ser um servidor físico com discos locais (DAS) ou um volume SAN mapeado via Fibre Channel/iSCSI, formatado localmente pelo Linux. Não use compartilhamentos SMB/NFS como repositório primário imutável.

2. Sistema de Arquivos XFS: Utilize XFS com suporte a Reflink. Isso é crucial para a performance de armazenamento. O Reflink permite a tecnologia Fast Clone do Veeam, onde backups sintéticos full não duplicam blocos fisicamente no disco. Isso economiza espaço drasticamente e reduz o desgaste (TBW) em SSDs.

3. Credenciais de Uso Único: O Veeam utiliza credenciais não-root para o transporte de dados. As credenciais persistentes armazenadas no servidor VBR não devem ter permissão de sudo ou root.

Ao configurar a imutabilidade para "7 dias", por exemplo, o Veeam aplica atributos estendidos aos arquivos de backup (chattr +i). Mesmo que o ransomware Akira comprometa o servidor VBR Windows e ordene a exclusão dos backups, o servidor Linux rejeitará o comando no nível do sistema de arquivos.

Plano de contenção e restauração via DataLabs

Se o pior acontecer e o ambiente de produção (VMware) for criptografado, a prioridade é restaurar o serviço sem reintroduzir a ameaça. Restaurar uma VM que contém o payload do ransomware ou o backdoor de persistência apenas reinicia o ciclo do incidente.

O recurso DataLabs (ou Virtual Labs) do Veeam permite montar os backups imutáveis diretamente do armazenamento em uma rede isolada (sandbox), sem conexão com a rede de produção.

Procedimento de restauração segura (Secure Restore)

1. Montagem Isolada: O DataLab sobe a VM a partir do repositório Linux.

2. Scan de Segurança: Ative a funcionalidade Secure Restore. O Veeam monta os discos da VM e aciona o antivírus atualizado para escanear o sistema de arquivos antes de finalizar a restauração.

3. Validação de Serviços: Verifique se o banco de dados ou aplicação sobe corretamente dentro do laboratório.

4. Migração para Produção: Apenas após a validação, mova os dados para o ambiente de produção (que deve ter sido limpo e reinstalado, preferencialmente com ESXi fora do domínio).

Previsão e Próximos Passos

A tendência observada é que ataques como o do Akira migrem cada vez mais para a camada de infraestrutura base ("bleeding down the stack"). O armazenamento não é apenas um depósito de bits passivo; é a última linha de defesa.

A blindagem exige uma mudança de mentalidade: a conveniência da administração centralizada (tudo no AD) é incompatível com a segurança moderna de dados. Isole seu plano de controle de armazenamento, adote repositórios Linux imutáveis e trate suas credenciais de backup como segredos de estado. A imutabilidade não é mais um recurso opcional ou "premium", é o requisito mínimo para a sobrevivência do negócio na era do ransomware de infraestrutura.

Perguntas Frequentes

1. O snapshot do storage (array-based) substitui o Hardened Repository? Não. Snapshots em arrays de storage (como Pure Storage, Dell PowerStore, NetApp) são excelentes para RPO curto e recuperação rápida, mas se o console de gerenciamento do storage estiver integrado ao AD comprometido, o atacante pode deletar os volumes e os snapshots. A imutabilidade do snapshot deve ser configurada com retenção bloqueada (SafeMode, SnapLock) para ser eficaz.

2. Posso usar um NAS (Synology/QNAP) como repositório imutável? Sim, desde que o dispositivo suporte imutabilidade de objeto (S3 Object Lock) ou snapshots imutáveis e não esteja exposto via SMB padrão com credenciais administrativas comuns. No entanto, um servidor Linux dedicado (físico) com XFS geralmente oferece melhor performance de reflink e controle de segurança mais granular para ambientes corporativos.

3. A falha CVE-2024-37085 afeta versões antigas do ESXi? A falha está relacionada à lógica de integração com o AD. Embora patches tenham sido lançados, a mitigação real recomendada é remover o grupo "ESX Admins" do AD ou, preferencialmente, desvincular totalmente os hosts ESXi do domínio Active Directory.

4. O que é XFS Reflink e por que ele importa para o ransomware? O Reflink permite que múltiplos arquivos compartilhem os mesmos blocos de dados no disco. Para recuperação de desastres, isso permite criar backups full sintéticos em segundos, sem mover dados. Isso acelera drasticamente as janelas de backup, garantindo que os dados estejam protegidos no repositório imutável mais rapidamente, diminuindo a janela de exposição ao ataque.

Referências & Leitura Complementar

• CVE-2024-37085 Detail: National Vulnerability Database (NVD) - "Authentication Bypass in VMware ESXi".

• Veeam Hardened Repository Guide: Veeam Backup & Replication User Guide (bp.veeam.com).

• CISA Ransomware Advisory: #StopRansomware: Akira Ransomware (Cybersecurity and Infrastructure Security Agency).

• VMware Knowledge Base: KB 81700 - "Using ESX Admins AD group with ESXi".