Auditoria de Permissões ACL DPAPI Tombstone Schema Active Directory: 3 Direitos que Ninguém Verifica

O Que É uma Auditoria de Permissões ACL DPAPI Tombstone Schema Active Directory?

Uma auditoria completa de permissões ACL DPAPI Tombstone Schema Active Directory verifica muito mais do que GenericAll e DCSync. Uma auditoria de ACL típica — seja feita manualmente com dsacls e PowerView, ou com uma ferramenta como o BloodHound — foca em uma lista conhecida: GenericAll, GenericWrite, WriteDACL, WriteOwner e os direitos de replicação por trás do DCSync. Essa lista está correta, mas não é completa. Três outros direitos adjacentes a ACL são igualmente perigosos e raramente entram em uma checklist: acesso não padrão à chave de backup de domínio do DPAPI, o direito estendido Reanimate-Tombstones e permissões não padrão no schema do AD. Eles são perigosos pelo mesmo motivo fundamental que o GenericAll — um principal fora do nível administrativo esperado pode usá-los para ler segredos, ressuscitar objetos obsoletos ou plantar um mecanismo de persistência que sobrevive à exclusão de objetos e a redefinições de senha — mas não aparecem na maior parte do conteúdo sobre abuso de ACL porque não são ACEs de objeto comuns em objetos de usuário ou computador. Este artigo aborda o que cada direito realmente concede, como é abusado e como detectá-lo e corrigi-lo, como parte de uma auditoria de segurança mais ampla do Active Directory (veja Auditar a segurança do Active Directory: o que revisar primeiro e como comprovar a remediação).

Para os caminhos mais comumente auditados, veja Abuso de ACL e DCSync: Os Caminhos Silenciosos para Domain Admin.

Direito nº 1 — Acesso Não Padrão à Chave de Backup de Domínio DPAPI

A Data Protection API (DPAPI) do Windows protege segredos em repouso — senhas de navegador salvas, perfis de Wi-Fi, credenciais RDP, certificados EFS, entradas do Credential Manager — criptografando-os com uma chave derivada da senha do usuário. Em um domínio, a chave mestra DPAPI de cada usuário também é criptografada com uma chave de backup DPAPI de todo o domínio, para que uma senha de usuário perdida ou expirada não signifique perda permanente de dados. Essa chave de backup é gerada uma única vez, na criação do domínio, e armazenada como segredos LSA BCKUPKEY_* replicados para todos os controladores de domínio (Microsoft Learn: DPAPI backup keys on AD domain controllers).

Como Atacantes Recuperam a Chave de Backup

Por padrão, recuperar a chave de backup exige direitos equivalentes a Domain Admin sobre o objeto de política LSA. Ferramentas como o Mimikatz (lsadump::backupkeys) e o SharpDPAPI a obtêm via chamadas MS-LSAD/LSARPC LsaOpenPolicy / LsaRetrievePrivateData; o DSInternals documenta o mesmo caminho de recuperação com Get-LsaBackupKey (DSInternals: Retrieving DPAPI Backup Keys from Active Directory). A pergunta da auditoria não é "a chave de backup existe" — ela sempre existe — é "quais principais, além dos Domain Admins, atualmente possuem direitos que permitem lê-la." Esse acesso costuma ser concedido indiretamente: direitos de segredo LSA delegados, uma GPO excessivamente ampla, ou uma conta de serviço adicionada a um grupo privilegiado por um motivo não relacionado.

Direito nº 2 — O Direito Estendido Reanimate-Tombstones

O Active Directory estende o modelo de ACE padrão com direitos de controle de acesso — permissões que não estão vinculadas a um atributo específico ou bit em uma máscara de acesso, mas identificadas por um GUID e verificadas contra todo o objeto. O Reanimate-Tombstones (GUID 45ec5156-db7e-47bb-b53f-dbeb2d03c40f) é um deles: ele permite que seu titular restaure um objeto excluído (tombstoned) em qualquer lugar de um naming context, e por padrão é concedido apenas na raiz do naming context a Domain Admins / Enterprise Admins (Microsoft: Reanimate-Tombstones extended right, Microsoft: Restoring Deleted Objects).

Por Que uma Concessão Delegada É um Caminho de Escalonamento de Privilégio

O caso de abuso é sutil, mas real: um objeto tombstoned ou reciclado pode reter a maioria de seus atributos originais — histórico de SID, associações a grupos, SPNs — durante o tempo de vida do tombstone (ou indefinidamente na Lixeira, se ela estiver habilitada mas não for esvaziada). Um principal ao qual foi delegado o Reanimate-Tombstones fora do nível administrativo padrão pode restaurar uma conta ou grupo privilegiado excluído, ressuscitando efetivamente um caminho de acesso que se acreditava fechado. A pesquisa da CravateRouge sobre a Lixeira do AD como superfície de escalonamento de privilégio documenta cenários concretos para isso (Have You Looked in the Trash? Unearthing Privilege Escalations from the AD Recycle Bin). O direito é fácil de passar despercebido justamente porque os auditores olham para as ACLs atuais dos objetos e esquecem de verificar os direitos estendidos delegados na raiz da partição, que é onde este vive. Para saber mais sobre como esse tipo de acesso delegado se acumula ao longo do tempo, veja Desvio acesso privilegiado Active Directory: como direitos admin voltam após auditorias.

Direito nº 3 — Permissões Não Padrão no Schema do AD

O naming context do schema define todas as classes e atributos na floresta. Por padrão, o acesso de gravação a ele é restrito ao grupo Schema Admins (mais os Enterprise Admins na raiz da floresta); isso é intencional, porque alterações de schema valem para toda a floresta e são amplamente irreversíveis — atributos e classes podem ser desativados, mas não excluídos (Semperis: NSA Top Ten Cybersecurity Misconfigurations — An AD Perspective).

Por Que o Acesso de Gravação ao Schema É um Primitivo de Persistência para Toda a Floresta

O acesso de gravação ao schema é um prêmio maior do que parece. Um atributo em particular, defaultSecurityDescriptor em um objeto classSchema, define o modelo de DACL aplicado a todo objeto futuro criado dessa classe — o que significa que um atacante com acesso de gravação ao schema pode embutir uma ACE backdoor (por exemplo, concedendo WriteDACL a uma conta de baixo privilégio) no descritor de segurança padrão da classe user ou group, de modo que toda conta ou grupo criado posteriormente herde permissões controladas pelo atacante desde o momento em que é criado. Este é um primitivo de persistência bem documentado, e também cruza fronteiras de domínio dentro de uma floresta, já que o schema vale para toda a floresta (itm8: Schema change trust attack — from child to parent), (BorderGate: Active Directory Schema Modification Attacks). Na prática, ACEs de schema não padrão costumam ser resquícios de instaladores de produtos de terceiros (Exchange, certas ferramentas de backup/gerenciamento de AD) que solicitaram direitos de schema mais amplos do que o necessário durante a instalação e nunca foram revertidos.

Detecção

Todos os três direitos precisam que as subcategorias corretas de política de auditoria estejam habilitadas nos controladores de domínio antes que gerem qualquer coisa útil no log de eventos de segurança.

A auditoria do evento 4662 para a chave de backup precisa da auditoria de Sucesso em Audit Other Object Access Events habilitada em todos os DCs — ela vem desativada por padrão (DSInternals: Detecting DPAPI Backup Key Theft). A subcategoria Directory Service Changes gera 5136 (modificado), 5137 (criado), 5138 (restaurado/undeleted), 5139 (movido) e 5141 (excluído) para qualquer objeto que tenha uma entrada de SACL correspondente (Microsoft: Event 5136 — A directory service object was modified) — mas apenas para objetos e atributos nos quais você tenha explicitamente colocado uma SACL, portanto tanto a raiz do naming context quanto o container Schema precisam ter uma adicionada manualmente (ADSI Edit → Properties → Security → Advanced → Auditing).

Outros IDs de evento que vale a pena configurar junto com esses três são abordados em Monitoramento de Seguranca AD: Os Eventos que Importam.

Correção

Corrigir a Exposição da Chave de Backup DPAPI

Não há uma forma suportada de rotacionar a chave de backup do domínio (Microsoft Learn: DPAPI backup keys on AD domain controllers), portanto trate o acesso a ela com o mesmo rigor que o krbtgt. Revise regularmente os direitos de segredo LSA delegados e a associação a grupos privilegiados; se a chave for confirmada como comprometida, a própria orientação de recuperação da Microsoft é limitada o suficiente para que um plano completo de recuperação de floresta/domínio já devesse existir antes de você precisar dele (SANS: Critical Confusion — Microsoft's Domain Compromise Recovery Guidance).

Corrigir a Delegação do Reanimate-Tombstones

Enumere as ACEs em cada raiz de naming context para o GUID do direito de controle de acesso 45ec5156-db7e-47bb-b53f-dbeb2d03c40f (dsacls ou Get-ObjectAcl -ResolveGUIDs do PowerView). Remova qualquer concessão fora de Domain Admins/Enterprise Admins e exija um ticket de mudança documentado para restaurações delegadas legítimas.

Corrigir Permissões Não Padrão no Schema

Execute dsacls contra CN=Schema,CN=Configuration,DC=<forest-root> e confirme que o acesso de gravação está limitado a Schema Admins (e Enterprise Admins na raiz da floresta). Preste atenção especial a qualquer ACE que toque defaultSecurityDescriptor nos objetos classSchema de user, group ou computer — esse é o alvo de maior valor para um backdoor de persistência.

Adicionar SACLs para Detecção de Drift no Futuro

Adicione SACLs na raiz do naming context e no container Schema conforme descrito em Detecção acima, para que futuros desvios apareçam no log de segurança em vez de serem descobertos apenas na próxima auditoria manual. Para uma base de hardening mais ampla além desses três direitos, veja Endurecimento Active Directory: o que bloquear primeiro e como validar e Quais são as configurações incorretas de segurança do Active Directory mais comuns?.

Como a EtcSec Detecta Isso

A EtcSec verifica todos os três durante cada auditoria do Active Directory: DPAPI_KEY_NON_DEFAULT_ACCESS sinaliza principais que detêm direitos sobre a chave de backup do domínio fora do nível administrativo esperado, REANIMATE_TOMBSTONES_RIGHT sinaliza concessões não padrão do direito de controle de acesso na raiz do naming context, e SCHEMA_NON_STANDARD_PERMISSIONS sinaliza ACEs no naming context do schema fora de Schema Admins/Enterprise Admins. Essas verificações ficam ao lado da mais conhecida ACL_GENERICALL, de modo que a mesma passagem de auditoria cobre tanto os caminhos conhecidos de abuso de ACL quanto os que a maioria das ferramentas ignora.