CVE-2025-23120: Por que ingressar seu servidor de backup no domínio é um erro fatal

O Active Directory não é seu amigo. Ele é o vetor de ataque.

Se você gerencia infraestrutura de armazenamento e backup, provavelmente dorme tranquilo acreditando que suas VLANs de gerenciamento e seus firewalls de borda são suficientes. Você está errado. Em março de 2025, a divulgação da CVE-2025-23120 (CVSS 9.9) transformou uma prática padrão de TI — ingressar servidores no domínio — em uma sentença de morte para seus dados.

Não estamos falando de uma falha obscura que exige acesso físico. Estamos falando de uma execução remota de código (RCE) que permite que qualquer usuário autenticado do domínio (sim, a conta do estagiário de vendas comprometida por phishing) execute comandos com privilégios de SYSTEM no seu servidor Veeam Backup & Replication.

Resumo em 30 segundos

• O Vetor: A CVE-2025-23120 explora uma falha de desserialização .NET no Veeam Mount Service, acessível a qualquer usuário do domínio.
• O Erro: Ingressar o servidor de backup (VBR) no domínio produtivo estende a superfície de ataque do AD diretamente para o cofre dos seus dados.
• A Solução: Isolar a infraestrutura de backup em Workgroups ou Florestas de Gerenciamento dedicadas e adotar Repositórios Linux Imutáveis.

A anatomia do desastre: .NET Remoting e a confiança cega

Para entender a gravidade, precisamos olhar para o disco e para o código. O Veeam, como muitas soluções Enterprise de Storage, depende pesadamente do framework .NET. Um de seus componentes vitais é o Mount Service, responsável por montar backups para restauração de arquivos e itens de aplicação.

Historicamente, o .NET Remoting (uma tecnologia legada, mas ainda presente) confia nos dados que recebe se a conexão for autenticada. A CVE-2025-23120 revelou que o Veeam não validava corretamente o tipo de objeto sendo desserializado.

Quando você ingressa seu servidor de backup (vamos chamá-lo de VBR-01) ao domínio CORP.LOCAL, o sistema operacional Windows concede, por padrão, permissão de conexão a membros do grupo "Domain Users".

⚠️ Perigo: O ataque não exige que o invasor seja Admin do Domínio. Ele só precisa de uma credencial válida. O invasor envia um objeto .NET malicioso ("gadget") para a porta do Mount Service. O servidor, confiando na autenticação do domínio, desserializa o objeto e executa o payload injetado na memória RAM, ignorando completamente as ACLs de disco ou permissões de compartilhamento SMB.

Fig. 1: O fluxo de execução onde a confiança no Domínio se torna o vetor de morte.

Fig. 1: O fluxo de execução onde a confiança no Domínio se torna o vetor de morte. O tráfego lateral autenticado bypassa proteções de perímetro.

O colapso da defesa baseada em patches

Você pode argumentar: "Mas eu apliquei o patch de março de 2025". Ótimo. Mas a mentalidade de Chaos Engineering nos ensina que patches são reativos. A arquitetura deve ser resiliente apesar da falha do software.

A vulnerabilidade de 2025 foi, na verdade, uma variação de falhas anteriores (como a CVE-2024-40711). Os atacantes, incluindo grupos de ransomware, perceberam que os patches da Veeam funcionavam baseados em "Blacklists" (lista negra) de classes .NET perigosas. A pesquisa da watchTowr Labs demonstrou que bastava encontrar uma nova classe não listada para contornar a correção.

Se sua estratégia de defesa é "esperar o patch da vendor", você já perdeu. A latência entre a descoberta do exploit (Day Zero) e a aplicação do patch na sua infraestrutura de storage é a janela onde seus HDDs são criptografados.

Arquitetura de "Ilha de Dados": A única defesa real

A única mitigação definitiva para a CVE-2025-23120 — e para a CVE-2026-XXXX que virá — é arquitetural. Devemos tratar o servidor de backup como uma Ilha de Resiliência.

1. O Protocolo Workgroup (Para PMEs e Home Labs)

Para ambientes menores, a regra é clara: NUNCA ingresse o servidor de backup no domínio.

• Mantenha o VBR em um Workgroup.

• Use contas locais com senhas de 30+ caracteres (geradas por cofre de senhas).

• Isso quebra a cadeia de confiança. Se o AD for comprometido, o atacante não consegue autenticar no serviço .NET Remoting do Veeam porque as credenciais do domínio CORP\User não valem nada no contexto local VBR-01\Admin.

2. Floresta de Gerenciamento (Para Enterprise)

Em datacenters com SANs complexas e arrays All-Flash, gerenciar contas locais é inviável. A solução é uma Floresta de Gerenciamento (Red Forest).

• Crie um domínio separado (ex: MGMT.LOCAL) com confiança unidirecional (One-Way Trust).

• O MGMT confia no CORP? NÃO.

• O CORP confia no MGMT? Talvez, mas idealmente não para backup.

• O servidor de backup vive no MGMT. Se o CORP cair, o MGMT permanece de pé.

3. O Repositório Imutável (Hardened Linux Repository)

O Windows é a superfície de ataque. O armazenamento real dos dados (os blocos nos discos) deve residir em um sistema operacional que não fale a língua do .NET Remoting nativamente da mesma forma.

Implemente um servidor físico com Linux (Ubuntu/RHEL), repleto de discos (seja HDD SAS 20TB ou NVMe para tiering), formatado em XFS com Reflink.

• Imutabilidade: Configure a flag +i ou use a função de imutabilidade nativa do Veeam v12+.

• Credenciais Descartáveis: O Veeam usa credenciais de uso único (Single-use credentials) para falar com o Linux. Mesmo que o servidor VBR Windows seja hackeado via CVE-2025-23120, o atacante não consegue deletar os backups no Linux porque não tem a senha root e a imutabilidade bloqueia a exclusão ( rm -rf falha).

Fig. 2: A transição necessária de 'Membro do Domínio' para 'Ilha de Resiliência'.

Fig. 2: A transição necessária de 'Membro do Domínio' para 'Ilha de Resiliência'. Note o isolamento do plano de controle e o airgap lógico.

Protocolo de terra arrasada: Quando o AD cai

Como Engenheiros do Caos, assumimos que o pior vai acontecer. O Active Directory foi dizimado. Não há DNS. Não há Kerberos. Se o seu backup depende do AD para autenticar você no console de recuperação, você criou um loop de dependência fatal.

💡 Dica Pro: Teste a recuperação "Dark Start". Desconecte os cabos de rede dos Domain Controllers. Tente logar no seu servidor de backup. Tente restaurar uma VM. Se falhar, sua estratégia de Disaster Recovery é apenas teatro.

Checklist de Sobrevivência Pós-CVE:

1. Contas "Break-Glass": Crie uma conta local no servidor de backup e guarde a senha em um envelope físico ou cofre offline.

2. DNS Hosts File: Mantenha o arquivo hosts do servidor de backup atualizado com os IPs dos hosts ESXi/Hyper-V e do Storage SAN. Sem AD, sem DNS. Você precisará resolver nomes para montar os datastores.

3. KVM/IPMI: Garanta acesso fora de banda (iDRAC/iLO) ao servidor de armazenamento físico. Se o RDP falhar (porque depende de NLA/Domínio), o console virtual é sua única salvação.

Perguntas Frequentes

P: O MFA no console do Veeam me protege dessa CVE? R: Não. A CVE-2025-23120 ataca o serviço antes da autenticação do console. O exploit ocorre na camada de rede do serviço de montagem, nível sistema operacional. O MFA do console é irrelevante para um RCE de baixo nível.

P: Posso usar firewall do Windows para bloquear o acesso? R: Pode, mas é frágil. Se você bloquear as portas usadas pelo Veeam, o backup para. Se deixar aberto apenas para "Domain Computers", e um computador do domínio for infectado, o vetor persiste. A segmentação de rede (VLANs) com regras estritas de quem pode falar com a porta 6172 (e range dinâmico) é mais eficaz, mas o isolamento do domínio é superior.

P: Isso afeta NAS domésticos (Synology/QNAP)? R: Se você usa o NAS apenas como repositório SMB/NFS, o risco está no servidor Windows que gerencia o backup. Se você roda o Veeam dentro de uma VM no NAS, as mesmas regras se aplicam. Se usa os apps nativos de backup do NAS (Hyper Backup), essa CVE específica não se aplica, mas o conceito de isolamento de credenciais sim.

Referências & Leitura Complementar

• Veeam Knowledge Base KB4724: Detalhes técnicos e patches para CVE-2025-23120 (Março 2025).

• watchTowr Labs Research: "By Executive Order: Domain-Level RCE in Veeam" - Análise técnica da desserialização .NET.

• RFC 6750: OAuth 2.0 Authorization Framework (Conceitos de tokens vs confiança implícita).

• Veeam Hardened Repository Guide: Documentação oficial sobre repositórios imutáveis Linux e XFS Reflink.