CVE-2018-8581

CVE-2018-8581 é a falha conhecida como 'PrivExchange': o Exchange Server pode ser coagido, via a API Exchange Web Services (EWS), a se autenticar via NTLM contra um host arbitrário controlado por um atacante que já possua uma credencial de caixa de correio válida no domínio. Como a conta de computador do Exchange normalmente tem privilégios elevados no Active Directory (herdados do grupo 'Exchange Windows Permissions'), o hash/sessão NTLM capturado pode ser retransmitido (relay) para o LDAP do domínio, permitindo escalar de um usuário de e-mail comum a controle total do Active Directory. É crítica não pelo CVSS em si, mas pelo impacto final: comprometimento de domínio a partir de uma conta de baixo privilégio.

A causa raiz está no recurso de notificações push da EWS (PushSubscription), usado por clientes de e-mail para receber callbacks sobre novos itens em uma caixa de correio. Um usuário autenticado pode registrar uma URL de callback arbitrária; o servidor Exchange então faz uma requisição HTTP a essa URL usando as credenciais da própria máquina Exchange (autenticação NTLM), sem validar adequadamente que o destino é confiável. Isso é um problema de falsificação de requisição do lado do servidor (classe próxima de CWE-918, SSRF) combinado com uso indevido de credenciais de máquina para autenticação outbound.

O atacante controla o endpoint de destino da notificação. Ao apontar essa URL para uma máquina sob seu controle, ele obtém uma tentativa de autenticação NTLM do servidor Exchange, que pode capturar e retransmitir (NTLM relay) para outro serviço do domínio — no caso mais grave, o LDAP do Controlador de Domínio.

O agravante estrutural é que, em instalações padrão de Exchange da época, a conta de computador do servidor Exchange pertence a um grupo com permissões de escrita elevadas sobre objetos do Active Directory (incluindo, em muitos casos, direitos equivalentes a DCSync). O relay do NTLM capturado para o LDAP permite ao atacante conceder a si mesmo (ou a uma conta que controle) direitos de replicação de diretório, extraindo hashes de todas as contas do domínio, inclusive Domain Admins.

O CVSS oficial (PR:N, AC:H) reflete a mecânica de rede da falha em EWS isoladamente, mas ignora a pré-condição prática mais relevante: o atacante precisa de credenciais válidas de uma caixa de correio no domínio — não é exploração anônima. A parte de alto impacto (dominância total do AD) depende da configuração de privilégios padrão do Exchange no diretório, que Microsoft e pesquisadores trataram como parte do mesmo problema, ainda que a CVE em si cubra apenas o abuso da EWS.

Pré-requisito real: o atacante precisa de uma conta de e-mail válida no Exchange (qualquer usuário do domínio com caixa de correio, sem privilégios administrativos) e a capacidade de fazer o servidor Exchange se conectar a um host controlado por ele — tipicamente na mesma rede interna ou alcançável pelo servidor. Não há necessidade de interação de outro usuário nem de acesso administrativo prévio.

O fluxo de exploração combina duas etapas: primeiro, o atacante abusa da EWS para forçar o Exchange a autenticar-se (NTLM) contra sua máquina; segundo, ele retransmite essa autenticação para o LDAP de um Controlador de Domínio, usando-a para conceder privilégios de replicação de diretório (DCSync) à conta do atacante ou a uma nova conta. A partir daí, extrai hashes de credenciais de qualquer conta do domínio, incluindo administradores, obtendo controle total do Active Directory. A complexidade técnica é moderada — exige ferramentas de relay NTLM/LDAP e conhecimento da topologia do domínio — mas não exige exploração de memória nem bypass de ASLR/DEP, é abuso de lógica de aplicação e privilégios mal configurados.

A vulnerabilidade está no catálogo KEV da CISA (adicionada em março de 2022) com exploração confirmada em ambiente real, e há PoC pública amplamente disseminada desde a divulgação original em 2018. A ação recomendada pela CISA é genérica ('aplicar atualizações conforme instruções do fornecedor'), sem prazo estendido de patch além do padrão do catálogo.

A correção primária é aplicar a atualização de segurança de novembro de 2018 da Microsoft para o Exchange Server, que restringe o comportamento de PushSubscription/EWS explorado nesta CVE. Consultar o advisory oficial da Microsoft para o número de build exato correspondente à sua versão e Cumulative Update instalada, já que patches de Exchange são cumulativos e dependem do CU base.

Como a exploração de maior impacto depende de o servidor Exchange ter privilégios excessivos no Active Directory, a mitigação estrutural recomendada por pesquisadores e pela própria Microsoft é reduzir os direitos do grupo 'Exchange Windows Permissions' sobre o objeto de domínio (removendo WriteDacl/permissões de escrita herdadas desnecessárias) e habilitar assinatura e channel binding no LDAP dos Controladores de Domínio, o que neutraliza o relay de NTLM para LDAP mesmo que a autenticação seja capturada. Sem essa segunda camada, corrigir apenas a EWS reduz a superfície de ataque mas não elimina o risco caso outro vetor de coação NTLM seja encontrado.

Não funciona como mitigação: desabilitar apenas EWS para usuários externos ou depender de firewall perimetral — a exploração típica ocorre a partir de dentro da rede, com um usuário de e-mail comum já autenticado, então controles de borda não bloqueiam o vetor.

Nos logs do IIS/EWS do Exchange, procurar por requisições de criação de PushSubscription com URLs de callback apontando para hosts externos ou fora da faixa de IPs esperada de clientes de e-mail legítimos. No tráfego de rede, monitorar conexões SMB/HTTP saindo do servidor Exchange (origem incomum para esse tipo de tráfego) em direção a hosts não catalogados, especialmente autenticações NTLM outbound iniciadas pela conta de computador do Exchange. No Active Directory, alertar sobre alterações de ACL/DACL em objetos de domínio realizadas pela conta de computador do Exchange fora de janelas de manutenção, e sobre eventos de replicação de diretório (DCSync) originados por contas que não são Controladores de Domínio legítimos. Não há assinatura única e confiável — a exploração usa protocolos e chamadas de API legítimos, então a detecção depende de correlação comportamental (linha de base de para onde o servidor Exchange normalmente se conecta) mais do que de um IOC estático.