Escalada de Privilégios Exchange WriteDacl Domínio Active Directory: Como uma Instalação de Dez Anos Ainda Concede Domain Admin

O Que É a Escalada de Privilégios Exchange WriteDacl Domínio Active Directory

As más configurações de escalada de privilégios Exchange WriteDacl domínio Active Directory estão entre os padrões mais consequentes que permanecem intocados em ambientes que instalaram o Exchange Server on-premises em algum momento da última década. Quando o Exchange Server 2013, 2016 ou 2019 é configurado com o modelo padrão de permissões compartilhadas (shared permissions) da Microsoft, o grupo de segurança Exchange Windows Permissions recebe o direito WriteDacl — o direito de modificar a lista de controle de acesso discricionário (DACL) — diretamente no objeto de domínio, na raiz do Active Directory. Essa única entrada de controle de acesso (ACE), a poucos elos de distância em uma cadeia curta, é suficiente para conceder a um atacante acesso equivalente a Domain Admin em toda a floresta, não apenas na organização Exchange.

O grupo Exchange Trusted Subsystem — a identidade de serviço que cada servidor Exchange usa para agir no AD em nome dos usuários finais por meio do modelo de Controle de Acesso Baseado em Função (RBAC) do Exchange — está ele próprio aninhado dentro de Exchange Windows Permissions por padrão (Microsoft Learn, "Split permissions in Exchange Server"). Qualquer pessoa que consiga adicionar uma conta a Exchange Trusted Subsystem, ou que comprometa diretamente um servidor Exchange, herda o direito WriteDacl no objeto de domínio.

Por Que Isso Não É "Apenas" a CVE-2019-1166

Não se trata de uma única CVE corrigível por patch: a própria documentação da Microsoft sobre permissões divididas descreve isso como um padrão arquitetural do modelo de permissões compartilhadas, não como uma vulnerabilidade com uma versão corretiva. Essa distinção importa, porque textos de catálogo sobre esse achado às vezes são erroneamente associados à CVE-2019-1166 — uma CVE real, mas que trata de um bypass do NTLM Message Integrity Check (MIC) sem relação com este caso ("Drop the MIC 2", descoberto pela Preempt Research Team e corrigido pela Microsoft na Patch Tuesday de outubro de 2019, segundo o aviso da Praetorian). Esse patch, e sua contraparte de junho de 2019, a CVE-2019-1040, reforçaram as defesas contra NTLM relay de forma geral; nenhum dos dois tocou na ACE WriteDacl que o Exchange deixa no objeto de domínio. Organizações que instalaram ambos sem nunca adotar permissões divididas continuam expostas hoje, e um controlador de domínio totalmente corrigido (patched) não indica nada sobre se essa ACE ainda está lá — veja nossa análise mais ampla sobre abuso de ACL e caminhos DCSync até Domain Admin para entender como essas concessões de acesso se somam a outras más configurações do Active Directory.

Como Funciona: de Exchange Windows Permissions a DCSync

A Cadeia de Privilégios Padrão

A cadeia que vai de uma identidade Exchange com privilégios excessivos (ou simplesmente comprometida) até o comprometimento total do domínio é curta:

1. Exchange Windows Permissions possui uma ACE WriteDacl no objeto de domínio.
2. Exchange Trusted Subsystem é membro de Exchange Windows Permissions por padrão.
3. Os membros do grupo de função RBAC Organization Management podem modificar a associação de outros grupos de segurança do Exchange, incluindo Exchange Trusted Subsystem (ADSecurity.org, "Mitigating Exchange Permission Paths to Domain Admins in Active Directory"; Trimarc Security).
4. Qualquer pessoa nessa cadeia — ou quem comprometer diretamente a conta de computador de um servidor Exchange — pode usar o direito WriteDacl para gravar uma nova ACE no objeto de domínio concedendo DS-Replication-Get-Changes e DS-Replication-Get-Changes-All, os dois direitos estendidos dos quais o DCSync depende.
5. A partir daí, uma solicitação de replicação extrai todos os hashes de senha do domínio, incluindo o krbtgt. Esse é o mesmo abuso de direitos de replicação que abordamos em nosso guia de auditoria de permissões ACL, DPAPI, tombstone e schema — o Exchange é simplesmente a fonte mais comum dessa concessão, não a única.

# Enumeração somente leitura: Exchange Windows Permissions (ou um grupo aninhado)
# ainda possui WriteDacl no objeto de domínio?
dsacls "DC=corp,DC=local" | Select-String "Exchange Windows Permissions|WRITE DAC"

A Amplificação PrivExchange de 2019

Em janeiro de 2019, o pesquisador Dirk-jan Mollema mostrou que o comportamento padrão nem sequer exigia um ponto de apoio prévio em um grupo do Exchange. O recurso PushSubscription do Exchange podia ser abusado para forçar a própria conta de computador de um servidor Exchange a se autenticar, via HTTP, em um endpoint controlado pelo atacante. Como o NTLM sobre HTTP não define o flag de assinatura obrigatória por padrão, essa autenticação podia ser retransmitida (relay) para o LDAP e combinada com o direito WriteDacl do servidor para conceder ao atacante privilégios de DCSync — acionável por qualquer usuário com caixa de correio (dirkjanm.io, "Abusing Exchange: one API call away from Domain Admin"). As atualizações cumulativas do Exchange de fevereiro de 2019 da Microsoft trataram isso em duas frentes: a KB4490060 alterou o contrato de autenticação das Push Notifications do Exchange Web Services para que as assinaturas deixassem de transmitir credenciais que pudessem ser coagidas a uma autenticação de saída, e a KB4490059 documentou como reduzir as permissões padrão do Exchange no Active Directory daí em diante — mas nem essa correção, nem os patches posteriores do bypass do NTLM MIC, removem uma ACE já gravada em um objeto de domínio anos antes.

Uma variante comum no mundo real agrava ainda mais isso: organizações que migraram caixas de correio para o Exchange Online frequentemente mantêm um servidor Exchange on-premises apenas para gerenciamento de atributos do AD, porque as orientações híbridas da Microsoft historicamente desaconselham remover totalmente o último servidor on-premises. Esse servidor mantido, e os grupos do AD por trás dele, continuam carregando a mesma concessão de WriteDacl indefinidamente — é exatamente assim que uma instalação com dez anos acaba concedendo Domain Admin em um ambiente onde ninguém mais considera o Exchange como estando "dentro do escopo", muito depois de as próprias caixas de correio terem migrado para a nuvem.

Detecção

A auditoria de Directory Service Access e Directory Service Changes não está habilitada por padrão nos controladores de domínio, e mesmo quando está, o Event ID 4662 só é disparado para objetos que possuem uma SACL correspondente. Ambas as lacunas precisam ser fechadas antes que qualquer um dos indicadores a seguir realmente apareça em seus logs (Altered Security, "A primer on DCSync attack and detection"). Nosso guia de monitoramento do Active Directory sobre os Event IDs que importam aborda os pré-requisitos de política de auditoria para todos eles em mais profundidade.

Detecção Baseada em Logs

Enumeração Proativa

Como a própria ACE pode ter anos e permanecer silenciosa — ela não gera um novo evento apenas por existir —, o monitoramento de logs de eventos deve ser combinado com enumeração proativa periódica: dsacls ou Get-Acl "AD:\<domain DN>" contra o objeto de domínio, ou uma coleta do BloodHound verificada especificamente quanto a uma aresta (edge) WriteDacl que chega ao nó de domínio. Trate isso da mesma forma que trataria o desvio de acesso privilegiado: uma auditoria pontual só prova que a ACE não estava presente no dia em que você verificou, não que ela permanece ausente depois disso.

Remediação

Controles Compensatórios Imediatos

1. Enumerar. Execute dsacls ou Get-Acl contra o objeto de domínio e verifique se Exchange Windows Permissions / Exchange Trusted Subsystem possui WriteDACL; faça a verificação cruzada com uma coleta do BloodHound para a mesma aresta.
2. Reduza o raio de impacto imediato caso uma migração completa para permissões divididas ainda não seja viável: remova Exchange Trusted Subsystem de Exchange Windows Permissions e exija um processo controlado por mudança e registrado em log para qualquer adição futura a Organization Management, Exchange Windows Permissions ou Exchange Trusted Subsystem (Trimarc Security).

A Correção Permanente

3. Adote o modelo de permissões divididas da Microsoft. As permissões RBAC divididas são o padrão recomendado pela Microsoft; as permissões divididas do Active Directory garantem separação total entre a administração do Exchange e do AD. Ambas exigem executar novamente o Setup com /PrepareAD /ActiveDirectorySplitPermissions:true, além de /PrepareAllDomains (ou um /PrepareDomain por domínio) em florestas multi-domínio (Microsoft Learn, "Split permissions in Exchange Server"). É isso que de fato remove as ACEs de Exchange Windows Permissions do objeto de domínio — não um patch de segurança do Windows ou do Exchange.
4. Desative de forma limpa. Se o Exchange já foi migrado para fora do ambiente local ou desativado, confirme que a ACE do objeto de domínio foi removida como parte desse processo. O deprovisionamento do Exchange não remove automaticamente, de forma retroativa, uma concessão anterior de WriteDacl — é exatamente assim que uma instalação com dez anos continua concedendo Domain Admin muito depois de o último servidor Exchange ter sido desligado.
5. Verifique. Execute novamente a enumeração do passo 1 após a remediação e confirme que os direitos DS-Replication-Get-Changes(-All) no objeto de domínio estão limitados apenas a controladores de domínio e contas de replicação explicitamente autorizadas. Incorpore essa verificação a um fluxo de auditoria recorrente em vez de uma limpeza pontual, já que reativar as permissões compartilhadas ou readicionar Exchange Trusted Subsystem a Exchange Windows Permissions restaura silenciosamente a ACE, sem nenhum sinal de alerta óbvio.

Como a EtcSec Detecta Isso

A auditoria de Active Directory da EtcSec sinaliza esse padrão diretamente por meio da verificação Exchange Privilege Escalation Risk (EXCHANGE_PRIV_ESC_PATH), que inspeciona a ACL do objeto de domínio em busca da concessão WriteDacl de Exchange Windows Permissions e rastreia o aninhamento de grupos até essa origem. Ela é correlacionada com as verificações mais amplas ACL WriteDACL (ACL_WRITEDACL) e DS-Replication-Get-Changes Rights (DCSync) (ACL_DS_REPLICATION_GET_CHANGES), além do rollup geral DCSync Capable (DCSYNC_CAPABLE), de modo que um caminho de ataque completo de Exchange para DCSync surge como um único achado priorizado, em vez de quatro entradas de ACL desconectadas, seja ele originado de um servidor Exchange ativo ou de um resquício de dez anos que ninguém se lembrou de desativar.