CVE-2024-37085

Falha de bypass de autenticação no ESXi (CWE-305) que afeta hosts previamente integrados ao Active Directory para gestão de usuários. Um atacante com permissão para criar objetos no AD — não necessariamente admin de domínio — pode recriar o grupo configurado como administrador do ESXi (padrão 'ESX Admins'/'ESXi Admins') depois que ele foi excluído, e qualquer membro desse novo grupo ganha acesso administrativo total ao host. Está no catálogo KEV da CISA com exploração confirmada, e o CVSS moderado (6.8) subestima o impacto real em ambientes que usam integração AD, porque o resultado final é controle completo do hypervisor.

O ESXi, quando integrado ao AD (documentado desde 2012 pela própria VMware), concede privilégios administrativos completos a qualquer usuário que seja membro de um grupo AD com um nome específico — por padrão 'ESX Admins', configurável via advanced setting. O problema é que essa checagem é feita pelo *nome* do grupo, e não por um identificador estável (como o SID) fixado no momento da configuração original. Isso significa que o vínculo entre 'esse grupo AD' e 'privilégio total no ESXi' não é amarrado a uma entidade específica do diretório, e sim a uma string.

Se o grupo original for excluído do AD — por erro operacional, rotação de credenciais, ou ação deliberada de um atacante com permissão suficiente — e um novo grupo com o mesmo nome for criado, o ESXi volta a reconhecer esse nome e concede acesso administrativo total a qualquer membro do grupo recriado, mesmo que ele tenha SID diferente do original e mesmo que nenhum dos membros tenha jamais sido autorizado a administrar o host. O atacante não precisa comprometer uma conta com privilégio administrativo pré-existente no AD; precisa apenas de permissão delegada para criar grupos com aquele nome específico em algum ponto do diretório, o que em muitos ambientes corporativos é uma permissão bem mais comum do que 'Domain Admin'.

O vetor CVSS (PR:H, UI:R) reflete que o atacante já precisa ter algum nível de privilégio no AD e que há uma etapa de interação/orquestração (a recriação do grupo e a associação de membros), mas não exige acesso prévio ao próprio ESXi ou vCenter. O impacto listado (C:H/I:H/A:H) corresponde a controle total do host: leitura, modificação e disponibilidade de todas as VMs nele hospedadas.

Pré-requisito central, e que a manchete não deixa claro: o host ESXi precisa ter sido configurado anteriormente para autenticação via Active Directory. Hosts geridos só por vCenter local ou com autenticação local não são afetados por este vetor. Segundo, o atacante precisa de permissões no AD suficientes para excluir (ou já ter sido excluído por terceiros) e recriar um grupo com o nome exato configurado como grupo de administração do ESXi — na maioria dos casos o padrão 'ESX Admins' ou 'ESXi Admins', que costuma não estar protegido com as mesmas ACLs restritivas de grupos como Domain Admins.

Na prática, isso é atrativo em cenários de pós-comprometimento de AD: um atacante que já obteve uma conta com permissão de gerenciar objetos de grupo (delegação comum em ambientes com estrutura organizacional descentralizada) pode escalar diretamente para controle de infraestrutura de virtualização, sem precisar de credenciais de vCenter, sem precisar de acesso prévio ao ESXi, e sem depender de exploração de memória ou lógica complexa — é abuso de confiança em nome de grupo, não corrupção de dados. Isso torna a exploração de baixa complexidade técnica assim que a pré-condição de AD é satisfeita.

A presença no catálogo KEV da CISA confirma exploração ativa observada; a entrada da CISA não detalha campanha ou ator específico nas informações disponíveis, e a ação recomendada pela CISA é aplicar a mitigação do fornecedor ou descontinuar o uso do produto quando não houver mitigação disponível — redação padrão da CISA para vulnerabilidades sem patch completo em todas as versões afetadas (caso do ESXi 7.0).

Para ESXi 8.0, aplicar a build ESXi80U3-24022510, que corrige a falha. Para VMware Cloud Foundation 5.x, atualizar para 5.2. Para ESXi 7.0 e VMware Cloud Foundation 4.x, o fornecedor declarou 'No Patch Planned' — não há correção definitiva planejada para esses ramos, apenas o workaround descrito no artigo de suporte KB369707 referenciado pela Broadcom.

O workaround consiste em reconfigurar o advanced setting do ESXi que define o nome do grupo AD tratado como administrativo, evitando o nome padrão previsível ('ESX Admins'/'ESXi Admins') e/ou impedindo que esse grupo, caso excluído, seja recriável por usuários não autorizados no AD (via ACL restritiva sobre a criação de grupos com aquele nome na OU relevante). O conteúdo exato dos passos está no KB369707 da Broadcom, não reproduzido nas fontes consultadas aqui — validar diretamente nesse artigo antes de aplicar.

Não funciona como mitigação: apenas monitorar login administrativo no ESXi sem alterar a configuração do grupo, porque o problema é estrutural (vínculo por nome, não por identidade estável) e persiste até a reconfiguração ou o patch. Também não é suficiente restringir apenas quem pode logar no vCenter, já que o vetor ataca diretamente a autenticação local do host ESXi via AD, contornando controles de acesso do vCenter.

Monitorar no Active Directory eventos de exclusão e recriação de grupos com o nome configurado como grupo administrativo do ESXi (padrão 'ESX Admins'/'ESXi Admins'), especialmente criação de grupo com mesmo nome pouco após exclusão, e mudanças de membership nesse grupo por contas que não são administradores de domínio ou de infraestrutura de virtualização. No lado do ESXi, revisar logs de autenticação/login administrativo (hostd, vpxa) por sessões originadas de contas AD que não constam em listas de administradores previamente conhecidas.

Não há assinatura de rede ou payload específico a procurar — a exploração ocorre inteiramente no plano de identidade/diretório, então sem auditoria de eventos de grupo no AD não há sinal confiável de tentativa. A ausência de correlação entre exclusão e recriação de grupo administrativo é o indicador mais forte disponível.