AdminSDHolder SDProp Active Directory Backdoor: O Processo Horário para Acesso Privilegiado Permanente

O Que São AdminSDHolder e SDProp

AdminSDHolder SDProp Active Directory esconde uma técnica de backdoor para acesso privilegiado permanente: este guia detalha por completo como os atacantes a implantam, como os defensores a detectam e como corrigi-la antes que se torne um risco permanente. AdminSDHolder é um objeto contêiner que existe em CN=AdminSDHolder,CN=System,DC=<domain>,DC=<tld> em todo domínio do AD, e o SDProp — o Security Descriptor Propagator — é o processo em segundo plano que copia sua ACL para todo objeto que protege, por padrão uma vez por hora (Microsoft Learn — Appendix C: Protected Accounts and Groups in Active Directory).

O SDProp é executado a cada 60 minutos (por padrão) no controlador de domínio que detém a função PDC Emulator (PDCE). Ele compara as permissões do AdminSDHolder com as permissões das contas e grupos protegidos do domínio — e onde houver diferença, sobrescreve a ACL do objeto para corresponder exatamente à do AdminSDHolder. O intervalo é controlado pelo valor DWORD AdminSDProtectFrequency em HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters no PDCE, válido de 60 a 7200 segundos; a maioria dos ambientes nunca altera esse valor e simplesmente usa o padrão de 60 minutos.

Os seguintes grupos e contas integrados são protegidos por AdminSDHolder/SDProp em todo domínio do AD:

Dois efeitos colaterais marcam todo objeto protegido: o atributo adminCount é definido como 1, e a herança de ACL da OU pai é desativada permanentemente — até que algo a limpe explicitamente. A Microsoft projetou o SDProp para impedir que contas privilegiadas herdem silenciosamente permissões mais fracas caso alguém as mova no diretório. É o mesmo mecanismo subjacente que os atacantes já exploram em abuso de ACL e DCSync em objetos individuais — este backdoor apenas eleva o abuso um nível acima, para o objeto-modelo que alimenta todas as contas protegidas de uma só vez.

AdminSDHolder SDProp Active Directory Backdoor, Passo a Passo

A técnica não é nova — Sean Metcalf a documentou em 2015 — e ainda funciona exatamente como descrito hoje, porque explora um mecanismo intencional, não um bug (AD Security — Sneaky Active Directory Persistence #15). Diferente de outros caminhos de ataque do Active Directory que encadeiam várias configurações incorretas para chegar a Domain Admin, esta técnica precisa apenas de uma única escrita em um único objeto.

Passo 1 — Adicionar uma ACE Maliciosa ao AdminSDHolder

Um atacante que já pode escrever em CN=AdminSDHolder,CN=System,DC=... — normalmente por ser Domain Admin/Enterprise Admin, ou por ter obtido WriteDacl/GenericWrite ali através de abuso de ACL anterior — concede a uma conta de baixo privilégio ou descartável Full Control (ou GenericAll) diretamente sobre o objeto AdminSDHolder. No artigo original de Metcalf, uma conta de usuário comum recebe controle total sobre o próprio AdminSDHolder. Nada muda aparentemente nessa conta — ela continua sem ser membro de nenhum grupo privilegiado e continua parecendo irrelevante em uma revisão de rotina de associação a grupos.

Passo 2 — Esperar (ou Forçar) a Propagação pelo SDProp

No próximo ciclo — até 60 minutos depois — o SDProp copia a ACL do AdminSDHolder, incluindo a ACE maliciosa, para toda conta e grupo com adminCount=1: Domain Admins, Enterprise Admins, o objeto de usuário de todo membro existente e qualquer conta adicionada a esses grupos posteriormente. A conta descartável nunca precisa entrar para os Domain Admins; ela só precisa de direitos de modificação nos objetos que importam. O ciclo também pode ser forçado imediatamente — por um administrador testando uma mudança, ou por um atacante impaciente para confirmar que o backdoor funcionou — via Ldp.exe, definindo o atributo RunProtectAdminGroupsTask como 1 na rootDSE (Microsoft Learn — Appendix C).

Passo 3 — Continuar Usando Direitos Que Nunca Aparecem Como Associação a Grupo

Como a ACE reside no objeto-modelo, e não em uma única conta, ela retorna toda vez que o SDProp é executado — mesmo depois que um defensor percebe a permissão maliciosa no objeto de usuário de um Domain Admin e a remove ali. A menos que a correção seja aplicada ao próprio AdminSDHolder, o próximo ciclo do SDProp a reaplica silenciosamente em todos os lugares. É isso que transforma isso em persistência, e não em uma escalada de privilégio pontual: rotações de senha, desativação de contas ou a remoção da conta do atacante dos Domain Admins não fazem nada, porque a conta nunca foi membro — os direitos foram concedidos através do modelo de ACL. Isso também é o que diferencia essa técnica do aninhamento perigoso de grupos comum: o aninhamento se esconde na associação a grupos, esta técnica se esconde em uma única ACL que a maioria dos administradores nunca pensa em revisar.

Os defensores podem inventariar alvos candidatos e artefatos remanescentes dessa técnica com uma única consulta LDAP:

Get-ADObject -LDAPFilter "(&(admincount=1)(|(objectcategory=person)(objectcategory=group)))" -Properties MemberOf,Created,Modified,AdminCount

Qualquer resultado cujo MemberOf não inclua mais um grupo protegido, ou cujas permissões efetivas pareçam não relacionadas à sua função real, merece investigação adicional antes de presumir que se trata de um resíduo de limpeza legítimo.

Detecção

O mecanismo afeta apenas um objeto, então a detecção é restrita, mas confiável — desde que a política de auditoria e a SACL corretas já estejam em vigor.

Duas condições precisam ser verdadeiras antes que o evento 5136 seja disparado: a subcategoria Advanced Audit Policy → DS Access → Audit Directory Service Changes precisa estar habilitada, e uma SACL cobrindo o security descriptor (ou "Write All Properties") precisa existir no próprio objeto AdminSDHolder. Nenhuma das duas vem habilitada por padrão na maioria dos ambientes. A regra de detecção publicada pela Elastic para essa técnica específica depende de ambas as configurações estarem prontas antes de disparar — sua consulta é event.code:5136 and host.os.type:"windows" and winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*, mapeada para MITRE ATT&CK T1098 (Account Manipulation) e T1078.002 (Valid Accounts: Domain Accounts), classificada como severidade alta (Elastic — AdminSDHolder Backdoor detection rule). A regra equivalente do Splunk Security Content confirma a mesma lógica 5136/nTSecurityDescriptor e o mesmo pré-requisito de SACL (Splunk Security Content — Windows AD AdminSDHolder ACL Modified).

Auditando a ACL Diretamente

Os logs de eventos só ajudam depois que a auditoria é ativada — uma revisão pontual da ACL funciona independentemente da política de auditoria e é uma primeira verificação razoável em um ambiente que nunca ativou a auditoria de Directory Service Changes:

Get-Acl -Path "AD:\CN=AdminSDHolder,CN=System,DC=corp,DC=local" | Select-Object -ExpandProperty Access

Revise cada entrada da saída em relação à baseline conhecida na seção de remediação abaixo. Qualquer coisa que não seja um principal integrado conhecido merece ser escalada imediatamente, independentemente de o log já estar habilitado ou não.

Remediação

Resposta Imediata

1. Audite agora a ACL do AdminSDHolder. Compare seus trustees com uma baseline conhecida (Domain Admins, Enterprise Admins, Administrators, SYSTEM e qualquer conta de serviço explicitamente delegada) e remova o que for inesperado — como Metcalf colocou, "estes devem permanecer no padrão".
2. Force o SDProp a rodar novamente de imediato após a remediação, via Ldp.exe → RunProtectAdminGroupsTask=1 na rootDSE, em vez de esperar até 60 minutos para confirmar que a correção se propagou (Microsoft Learn — Appendix C).

Hardening Contínuo

3. Ative a auditoria de Directory Service Changes e defina uma SACL no AdminSDHolder para que futuras modificações gerem o evento 5136, conforme a seção de detecção acima.
4. Inventarie todo objeto com adminCount=1 usando a consulta LDAP mostrada anteriormente e reconcilie com a associação atual a grupos protegidos. Para contas confirmadas como não pertencentes mais a um grupo protegido, limpe o adminCount e reative a herança somente depois de confirmar que a associação ao grupo já foi removida — limpar o adminCount primeiro permite que o SDProp reverta a correção na próxima execução. Essas contas órfãs são o mesmo resíduo de limpeza abordado em Contas Privilegiadas Obsoletas.
5. Restrinja quem pode escrever no AdminSDHolder. Por padrão, apenas Domain Admins, Enterprise Admins e Administrators podem modificá-lo ou assumir a propriedade — mantenha assim. Qualquer GenericWrite ou WriteDacl delegado no contêiner System, ou especificamente no AdminSDHolder, é um risco permanente e deve ser tratado como Tier 0.

Como a EtcSec Detecta Isso

A auditoria de Active Directory da EtcSec verifica ADMIN_SD_HOLDER_MODIFIED para trustees inesperados ou direitos perigosos (Full Control, GenericAll, WriteDacl, WriteOwner) na ACL do objeto AdminSDHolder, ADMINSDHOLDER_BACKDOOR para o padrão específico de um principal não privilegiado com esses direitos, e ADMIN_COUNT_ORPHANED para contas ainda marcadas como adminCount=1 depois de deixarem um grupo protegido — resíduo de limpeza que tanto esconde backdoors genuínos quanto infla sua contagem de contas privilegiadas. Esse backdoor raramente aparece sozinho: é frequentemente encontrado junto a um desvio de acesso privilegiado mais amplo, por isso vale a pena executar as duas verificações juntas como parte de uma auditoria de rotina, em vez de tratá-las como achados isolados.