Auditoria de ACEs Perigosas em SIDs Quebradas e Cross-Domain no Active Directory: O Abuso de ACL que a Maioria das Ferramentas Nem Consegue Resolver

Uma auditoria de ACEs perigosas em SIDs quebradas e cross-domain no Active Directory faz uma pergunta que uma revisão de ACL padrão nunca alcança: quais concessões no seu diretório são detidas por trustees que ninguém consegue nomear? Todo access control entry (ACE) em uma DACL do AD identifica seu trustee por um security identifier (SID), e as ferramentas de revisão quase sempre resolvem essa SID para um nome amigável antes de exibi-la. Mas o que acontece quando a SID não resolve a nada — e o ACE em que ela está grava controle total?

Essa é uma pergunta diferente da que uma revisão normal faz. Uma revisão normal pergunta "quais contas ativas possuem GenericAll no Tier 0?". Esta pergunta "quais concessões são detidas por trustees que meu diretório não consegue nomear?". As duas produzem achados completamente diferentes, e a segunda é rotineiramente ignorada: uma entrada cujo trustee não resolve é facilmente renderizada por um relatório como uma linha em branco, uma string bruta, ou nada.

O Que uma Auditoria de ACEs Perigosas em SIDs Quebradas e Cross-Domain no Active Directory Verifica

Uma SID não é um nome. A referência da Microsoft sobre Security Identifiers descreve a estrutura com precisão: para uma conta de domínio, "a SID de um principal de segurança é criada concatenando a SID do domínio com um relative identifier (RID) para a conta." Tudo antes do segmento final -RID é o identificador do domínio; o último segmento identifica o principal dentro desse domínio.

Essa estrutura é o que torna uma referência quebrada classificável. Pegue uma SID de trustee que não resolve a nenhum usuário, grupo, computador, unidade organizacional ou principal conhecido, e compare seu prefixo de domínio com a SID do seu próprio domínio:

A distinção importa por causa de uma garantia que a Microsoft dá explicitamente na mesma referência: "as SIDs sempre permanecem únicas. As autoridades de segurança nunca emitem a mesma SID duas vezes, e nunca reutilizam SIDs de contas excluídas." Uma SID local órfã, portanto, não pode ser readquirida criando uma nova conta com o mesmo nome — a nova conta recebe uma nova RID. Isso é genuinamente tranquilizador, e é por isso que esse caso não é um alarme de cinco estrelas.

O caso entre domínios não tem essa garantia, porque o principal pode simplesmente existir em algum lugar que você não consegue ver. Uma concessão legítima entre domínios normalmente se materializa no seu diretório como um objeto Foreign-Security-Principal — "o Security Principal de uma fonte externa." Se não existir um foreignSecurityPrincipal correspondente, você está diante de uma concessão intencional cujo objeto complementar nunca foi criado, ou de um resquício de um trust que já foi removido ou reconfigurado.

Os Direitos Que Tornam um Trustee Não Resolvível Perigoso

Nem todo ACE com um trustee quebrado importa. Os que importam carregam direitos que permitem ao titular assumir o objeto. A referência ADS_RIGHTS_ENUM da Microsoft fornece os bits exatos:

Há uma armadilha aqui que arruína silenciosamente scripts de auditoria caseiros. Os bits genéricos acima são os valores brutos do ADSI. A enumeração ActiveDirectoryRights do .NET, que o PowerShell expõe, usa os valores mapeados do directory service: GenericAll é 983551 (0xF01FF), não 0x10000000. E 0xF01FF é um composto que inclui ReadProperty (16) e ListChildren (4).

Assim, um script que escreve $ace.ActiveDirectoryRights -band 'GenericAll' e trata um resultado diferente de zero como controle total vai marcar praticamente todo ACE de leitura do diretório. O teste correto é um teste de igualdade contra a máscara completa, mais verificações separadas dos bits genéricos brutos e dos direitos de gravação padrão:

$mask = [int]$ace.ActiveDirectoryRights
$isDangerous =
    (($mask -band 0x10000000) -ne 0) -or          <# ADS_RIGHT_GENERIC_ALL   #>
    (($mask -band 0x40000000) -ne 0) -or          <# ADS_RIGHT_GENERIC_WRITE #>
    (($mask -band 0x000F01FF) -eq 0x000F01FF) -or <# controle total (mapeado) #>
    (($mask -band 0x00040000) -ne 0) -or          <# WRITE_DAC               #>
    (($mask -band 0x00080000) -ne 0)              <# WRITE_OWNER             #>

A Própria Microsoft Enviou Um Desses

A evidência mais convincente de que referências de SID quebradas são uma condição sistêmica, e não uma curiosidade, vem da própria documentação da Microsoft sobre o que o adprep /domainprep faz ao seu diretório.

A referência Active Directory domain-wide schema updates lista as operações executadas quando um controlador de domínio Windows Server 2016 é preparado. A Operação 85 é descrita como modificando o naming context do domínio "para permitir que domain\Key Admins e rootdomain\Enterprise Key Admins modifiquem o atributo msds-KeyCredentialLink." A coluna de permissões então registra o que realmente aconteceu:

(OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Key Admins)
(OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Enterprise Key Admins in root
 domain, but in nonroot domains resulted in a bogus domain-relative ACE with a
 nonresolvable -527 SID)

Leia essa última cláusula novamente. A Microsoft está documentando que, em todo domínio não raiz de uma floresta multi-domínio, essa operação deixou para trás um ACE cujo trustee é uma SID não resolvível. Enterprise Key Admins é um grupo de nível de floresta que vive na raiz da floresta; a operação construiu a SID relativa ao domínio local, produzindo uma referência -527 para um principal que esse domínio não possui.

Duas outras operações limpam essa bagunça depois — e elas não são distribuídas juntas, o que decide se o seu domínio recebeu uma correção ou as duas. A Operação 87 está na mesma tabela do Windows Server 2016 (operações 82-88, após as quais o atributo revision em CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System é definido como 15); ela exclui "o ACE que concede Full Control ao grupo Enterprise Key Admins domain-relative incorreto" e adiciona um correto. A Operação 89 está listada em uma tabela diferente — Windows Server (Semi-Annual Channel) domain-wide updates, que leva esse mesmo atributo revision a 16 — e vai além, excluindo a entrada ampla (A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;Enterprise Key Admins) e substituindo-a por (OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Enterprise Key Admins) — controle total em todo o naming context, restrito a acesso de gravação em um único atributo. Esse valor de revision é como você descobre qual das duas limpezas o seu domínio realmente recebeu.

Essas strings SDDL se decodificam pela referência ACE Strings da Microsoft: A é um ACE access-allowed, OA um específico de objeto, CI marca herança por contêiner, e RPWPCRLCLOCCDCRCWDWOSDDTSW concatena read property, write property, control access, list children, list object, create child, delete child, read control, write DAC, write owner, delete, delete tree e self-write. Isso é controle total com outro nome — incluindo os dois direitos que permitem a um titular reescrever a DACL e tomar a propriedade.

🚨 Perigo: Se a sua floresta foi preparada com a mídia original do Windows Server 2016 e as operações de limpeza posteriores nunca rodaram, um ACE -527 concedendo direitos amplos sobre todo um naming context de domínio ainda pode estar em um domínio filho, apontando para o nada.

Por Que os Dois Casos Têm Pesos Diferentes

Uma SID local órfã e uma SID entre domínios parecem idênticas em uma DACL — um trustee não resolvível —, mas merecem prioridades diferentes.

SID local órfã. Ninguém consegue exercer essa concessão através de um logon normal. Como o AD não recicla RIDs, readquirir exatamente essa SID exigiria injetá-la no sIDHistory de uma conta, e isso pressupõe o acesso privilegiado que um atacante estaria usando essa concessão para obter. É um item de limpeza e um problema de trilha de auditoria, não um caminho ativo. Deixado de lado, sobreviverá ao incidente que o criou, ampliando silenciosamente o raio de impacto de qualquer migração futura.

SID entre domínios. Esta é viva se o domínio referenciado algum dia se tornar acessível. As orientações de filtragem de SID da Microsoft afirmam o mecanismo claramente: "em algumas circunstâncias é possível que atacantes ou administradores desonestos que comprometeram um controlador de domínio em um domínio confiável usem o atributo de histórico de SID (sIDHistory) para associar SIDs a novas contas de usuário, concedendo a si mesmos direitos não autorizados." A avaliação de postura de contas do Microsoft Defender for Identity reafirma a versão em nível de floresta: "se você tem um trust de floresta sem a filtragem de SID habilitada (também chamada de quarentena), é possível injetar uma SID de outra floresta e ela será adicionada ao token do usuário quando autenticado e usada para avaliações de acesso."

Juntando essas peças, um ACE entre domínios obsoleto se torna uma concessão pré-posicionada. Um atacante que controla — ou mais tarde restabelece — o domínio referenciado não precisa modificar a sua DACL de forma alguma. A permissão já está escrita. Ele só precisa de um token carregando essa SID. Esse é o mesmo raciocínio sobre fronteiras de trust abordado em Ataques de Confiança do Active Directory e na auditoria de filtragem de SID e autenticação seletiva em trusts; a diferença é que aqui a concessão sobrevive à exclusão do trust, porque excluir um trust não limpa ACLs.

Mais Dois Direitos no Mesmo Ponto Cego

Referências de SID quebradas compartilham um ponto cego com outros dois padrões de permissão que revisões padrão ignoram por um motivo diferente: eles não são GenericAll, então auditorias baseadas em palavras-chave nunca os veem.

Self-membership em grupos. O direito de gravação validada Self-Membership, GUID bf9679c0-0de6-11d0-a285-00aa003049e2, é documentado como "Permissão de gravação validada para permitir a atualização da associação de um grupo em termos de adicionar/remover a própria conta." Seu nome de exibição no editor de ACL é Add/Remove self as member, e se aplica apenas à classe Group. Concedido em um grupo privilegiado, é uma escalada de um único passo em que nunca um terceiro grava member — o próprio principal se adiciona. A referência Dsacls da Microsoft confirma o escopo: a permissão WS é "significativa apenas em objetos de grupo e quando {ObjectType | Property} é 'member'." Esta é a família de direitos que torna o aninhamento perigoso de grupos pior do que parece.

Enterprise Key Admins sobre msDS-KeyCredentialLink. Segundo Active Directory security groups, Enterprise Key Admins carrega a RID conhecida 527, é um grupo Global em CN=Users, não tem membros padrão e é protegido pelo AdminSDHolder. O atributo que ela governa, msDS-KeyCredentialLink (schemaIdGuid 5b47d60f-6090-40b2-9f37-2a4de88f3063), "contém material de chave e informações de uso" e foi "implementado pela primeira vez no Windows Server 2016."

O acesso de gravação a esse atributo é todo o ataque Shadow Credentials. Na pesquisa original de Shadow Credentials de Elad Shamir Shadow Credentials research: "se você conseguir gravar na propriedade msDS-KeyCredentialLink de um usuário, você pode obter um TGT para esse usuário" e "você pode recuperar o hash NT desse usuário." Os pré-requisitos são um controlador de domínio Windows Server 2016, um certificado de Server Authentication nele, e o nível funcional Windows Server 2016 — e a credencial plantada "persistiria mesmo que o usuário/computador mudasse a senha." Cobrimos a técnica em si em Shadow Credentials: abuso de msDS-KeyCredentialLink.

A questão da auditoria é mais estreita do que o ataque. Enterprise Key Admins é enviado vazio. O que você está verificando é se o ACE do grupo sobre o seu naming context de domínio é o RPWP delimitado em 5b47d60f-… que a Operação 89 instala, ou a entrada de controle total não delimitada que a preparação original deixou para trás — e se o trustee realmente resolve.

Detecção

Auditar isso requer duas passagens: uma varredura pontual das DACLs existentes e auditoria de mudanças, para que novas referências quebradas sejam detectadas assim que surgirem.

Varrer as DACLs existentes em busca de trustees perigosos não resolvíveis

Solicite as SIDs brutas em vez de nomes de conta. Pedir objetos NTAccount ao .NET de antemão lança exceção exatamente nas entradas que você está procurando: SecurityIdentifier.Translate lança IdentityNotMappedException quando "algumas ou todas as referências de identidade não puderam ser traduzidas."

Import-Module ActiveDirectory

$domainSid = (Get-ADDomain).DomainSID.Value
$root      = (Get-ADRootDSE).defaultNamingContext

Get-ADObject -SearchBase $root -LDAPFilter '(objectClass=*)' -Properties nTSecurityDescriptor |
  ForEach-Object {
    $dn = $_.DistinguishedName
    $_.nTSecurityDescriptor.GetAccessRules(
        $true, $true, [System.Security.Principal.SecurityIdentifier]) |
      Where-Object { $_.AccessControlType -eq 'Allow' } |
      ForEach-Object {
        $mask = [int]$_.ActiveDirectoryRights
        $dangerous =
            (($mask -band 0x10000000) -ne 0) -or
            (($mask -band 0x40000000) -ne 0) -or
            (($mask -band 0x000F01FF) -eq 0x000F01FF) -or
            (($mask -band 0x00040000) -ne 0) -or
            (($mask -band 0x00080000) -ne 0)
        if (-not $dangerous) { return }

        $sid = $_.IdentityReference
        try {
            $null = $sid.Translate([System.Security.Principal.NTAccount])
            return
        } catch [System.Security.Principal.IdentityNotMappedException] { }

        $scope = if ($sid.Value.StartsWith("$domainSid-")) {
                     'SID local orfa'
                 } else {
                     'SID entre dominios'
                 }

        [pscustomobject]@{
            ObjectDN = $dn
            Trustee  = $sid.Value
            Rights   = $_.ActiveDirectoryRights
            Scope    = $scope
        }
      }
  } | Sort-Object Scope, ObjectDN | Format-Table -AutoSize

Execute isso primeiro contra uma única OU. Uma varredura completa do naming context lê todo security descriptor do domínio e não é algo para disparar contra um DC de produção durante o horário comercial.

Verificar os dois padrões específicos

Ambas as consultas abaixo pedem trustees SecurityIdentifier pelo mesmo motivo que a varredura: a propriedade .Access traduz para NTAccount e lança IdentityNotMappedException exatamente nos ACEs sobre os quais este artigo trata.

$root    = (Get-ADRootDSE).defaultNamingContext
$sidType = [System.Security.Principal.SecurityIdentifier]

<# Key Admins (-526) e Enterprise Key Admins (-527) no NC de domínio:
   delimitado, ou controle total? Compare pela RID, não pelo nome — em um
   domínio não raiz, o trustee bugado é precisamente aquele que não vai
   resolver para "Key Admins", então um filtro por nome perde o achado silenciosamente. #>
(Get-ADObject $root -Properties nTSecurityDescriptor).nTSecurityDescriptor.GetAccessRules(
    $true, $true, $sidType) |
  Where-Object { $_.IdentityReference.Value -match '-52[67]$' } |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

<# Concessões de self-membership em grupos: o direito de gravação validada, ou um DS_SELF não delimitado #>
$selfMembership = [guid]'bf9679c0-0de6-11d0-a285-00aa003049e2'
Get-ADGroup -Filter * -Properties nTSecurityDescriptor | ForEach-Object {
    $g = $_
    $g.nTSecurityDescriptor.GetAccessRules($true, $true, $sidType) |
      Where-Object {
        $_.AccessControlType -eq 'Allow' -and (
          $_.ObjectType -eq $selfMembership -or
          ($_.ObjectType -eq [guid]::Empty -and
           ([int]$_.ActiveDirectoryRights -band 0x8) -ne 0)
        )
      } |
      Select-Object @{n='Group';e={$g.DistinguishedName}},
                    IdentityReference, ActiveDirectoryRights
}

Um ObjectType igual a 5b47d60f-6090-40b2-9f37-2a4de88f3063 na primeira consulta é a forma delimitada e esperada. Um ObjectType vazio com uma máscara de controle total é a entrada não delimitada que deveria ter sido substituída — e um trustee -527 que você não consegue associar a um grupo Enterprise Key Admins vivo é o próprio caso não resolvível.

Capturar novos casos assim que surgem

A referência do evento 5136 da Microsoft estabelece os pré-requisitos e as regras de leitura. O evento pertence à subcategoria Audit Directory Service Changes, e "para gerar este evento, o objeto modificado deve ter uma entrada apropriada na SACL: a auditoria de ação 'Write' para atributos específicos" — apenas habilitar a subcategoria não é suficiente, a SACL precisa existir nos objetos que interessam a você.

Espere pares, não eventos isolados: "para uma operação de mudança, você tipicamente verá dois eventos 5136 para uma ação, com campos Operation Type diferentes: 'Value Deleted' e depois 'Value Added'." A própria recomendação da Microsoft é alertar sobre o evento Value Added e usar o Correlation ID para extrair o valor anterior do seu par.

Um detalhe da mesma página funciona também como um diagnóstico para todo este artigo: "o Event Viewer tenta automaticamente resolver SIDs e mostrar o nome da conta. Se a SID não puder ser resolvida, você verá os dados brutos no evento." Uma SID bruta onde você esperava um nome é o sinal — em um evento, e em um relatório de ACL.

Remediação

1. Confirme que a limpeza do adprep rodou. Em cada domínio não raiz, inspecione a DACL no NC de domínio em busca de ACEs cujo trustee termina em -527. Se encontrar uma entrada de controle total — especialmente uma que não resolve — você está diante do estado anterior às Operações 87/89. O atributo revision em CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System revela até onde a preparação chegou: 15 significa que as operações 82-88 foram concluídas, 16 significa que a Operação 89 também foi.

2. Classifique antes de excluir. Para cada trustee não resolvível, compare o prefixo de domínio com a sua SID de domínio e com as SIDs de todo domínio em que você confia. Uma SID entre domínios que corresponde a um parceiro de trust atual é provavelmente uma concessão intencional sem o seu objeto foreignSecurityPrincipal, e excluí-la vai quebrar algo. Uma que não corresponde a nenhum trust atual é uma referência obsoleta.

3. Remova por SID, não por nome. É aqui que as ferramentas resistem. A referência Dsacls da Microsoft documenta /R recebendo um trustee "como Usuário@Domínio ou como Domínio\Usuário" — uma forma de nome que, por definição, não existe para uma SID que não resolve. Use PowerShell e passe uma SecurityIdentifier diretamente para a API:

$dn  = 'DC=child,DC=corp,DC=local'
$sid = [System.Security.Principal.SecurityIdentifier]'S-1-5-21-1004336348-1177238915-682003330-527'

$acl = Get-Acl -Path "AD:\$dn"
$acl.GetAccessRules($true, $false, [System.Security.Principal.SecurityIdentifier]) |
  Where-Object { $_.IdentityReference -eq $sid } |
  ForEach-Object { $null = $acl.RemoveAccessRuleSpecific($_) }

Set-Acl -Path "AD:\$dn" -AclObject $acl

Observe o $false para regras herdadas: um ACE herdado não pode ser removido no filho, apenas no objeto que o define. Corrija o pai e deixe a herança se propagar.

4. Restaure o escopo pretendido, não apenas exclua. Onde a entrada era Enterprise Key Admins sobre o NC de domínio, o estado alvo está documentado: um ACE específico de objeto concedendo RPWP delimitado a 5b47d60f-6090-40b2-9f37-2a4de88f3063, herdável por contêiner. Excluir sem substituir remove uma permissão que o provisionamento do Windows Hello for Business espera.

5. Mantenha a filtragem de SID ativada — e não a confunda com quarentena. Um ACE entre domínios só é explorável se uma SID estrangeira conseguir chegar ao seu token de acesso, e a filtragem de SID é o que impede isso. Em um trust de floresta, a filtragem é estrutural, não opcional: o MS-PAC especifica que um trust cross-forest "não permite que SIDs locais à sua floresta atravessem um trust cross-forest", e que SIDs ForestSpecific são "filtradas para os limites de trust QuarantinedWithinForest, CrossForest, External e QuarantinedExternal." O Defender for Identity, citado acima, trata a ausência dessa filtragem como o achado. A quarentena de filtro de SID é um modo separado e mais rígido, e os avisos da Microsoft se aplicam apenas a ela: não aplicar a quarentena "a trusts dentro de uma floresta que não usa o nível funcional de floresta Windows Server 2003, porque isso remove SIDs necessárias para a replicação do Active Directory", e ela "não deve ser aplicada a trusts de floresta." Leia isso como uma instrução sobre a flag de quarentena — nunca como uma licença para desligar a filtragem de SID por completo.

6. Coloque uma SACL nos objetos que importam para você. O evento 5136 precisa dela. No mínimo: o objeto NC de domínio, CN=AdminSDHolder,CN=System, CN=Keys e todo grupo e OU do Tier 0. Auditar gravações em nTSecurityDescriptor e msDS-KeyCredentialLink transforma a próxima ocorrência em um alerta em vez de um achado descoberto um ano depois. O artigo Backdoor AdminSDHolder SDProp explica por que esse contêiner em particular merece vigilância permanente.

7. Incorpore à revisão recorrente. Trustees órfãos se acumulam a partir de operações comuns — contas de serviço desativadas, aquisições encerradas, trusts aposentados. Trate a varredura como parte da auditoria de segurança do Active Directory contínua, não como um projeto de correção único.

Como a EtcSec Detecta Isso

A EtcSec divide o problema de referências quebradas em duas verificações, precisamente porque os dois casos carregam riscos diferentes. ORPHANED_SID_DANGEROUS_ACE reporta ACEs de concessão transmitindo GenericAll, controle total, WriteDACL, WriteOwner ou GenericWrite a um trustee cujo prefixo de domínio corresponde ao domínio auditado, mas que não resolve a nenhum principal vivo — o caso de conta provavelmente excluída, classificado como High. CROSS_DOMAIN_SID_DANGEROUS_ACE reporta os mesmos direitos detidos por um trustee de um domínio inteiramente diferente, classificado como Critical, porque essa referência se torna explorável no momento em que o domínio referenciado volta a ficar acessível. Ambos excluem deliberadamente trustees administrativos embutidos e ACEs de negação, então a saída mostra a exposição real, não a forma normal do diretório.

Junto a eles, ACL_SELF_MEMBERSHIP sinaliza o direito de gravação validada Add/Remove-self-as-member em objetos de grupo — delimitado apenas a grupos, e deliberadamente excluindo controle total para não simplesmente repetir o que ACL_GENERICALL já encontrou. ENTERPRISE_KEY_ADMINS_FULL_ACCESS sinaliza o trustee -527 detendo controle total não delimitado ou acesso de gravação a msDS-KeyCredentialLink em objetos de domínio, a condição que as Operações 87 e 89 existem para corrigir. ACL_WRITEDACL e ACL_WRITEOWNER cobrem os mesmos dois direitos quando o trustee resolve, e TRUST_SID_FILTERING_DISABLED cobre o controle do lado do trust que decide se uma referência entre domínios pode algum dia alcançar um token.

Junto com as verificações mais amplas de Abuso de ACL e DCSync e a auditoria de permissões de DPAPI, tombstone e schema, essas verificações fecham a lacuna entre "quem possui direitos perigosos" e "quais direitos perigosos são detidos por principais que ninguém consegue nomear."