Injeção de SIDHistory: Escalada de Privilégios SID Conhecida no Domain Admin

O Que É a Injeção de SIDHistory? Escalada de Privilégios via SID Conhecida Explicada

A injeção de SIDHistory com uma SID conhecida é uma técnica de persistência e escalada de privilégios no Active Directory na qual um atacante grava uma SID privilegiada conhecida — como o sufixo RID 512 (Domain Admins) ou RID 519 (Enterprise Admins) da SID do domínio — no atributo sIDHistory de uma conta sem privilégios. O MITRE ATT&CK cataloga isso como a subtécnica T1134.005 — Access Token Manipulation: SID-History Injection.

Como toda SID armazenada em sIDHistory é copiada para o PAC (Privilege Attribute Certificate) Kerberos da conta e, por sua vez, para o seu token de acesso no logon, a conta de baixo privilégio herda efetivamente direitos de Domain Admin sem nunca ser adicionada ao grupo Domain Admins. Auditorias de associação a grupos, revisões de grupos aninhados e verificações net group /domain retornam limpas — a escalada é invisível para qualquer coisa que inspecione apenas a associação a grupos.

Como Funciona: sIDHistory e SIDs Conhecidas

sIDHistory é um atributo legítimo do Active Directory, projetado para migrações entre domínios e florestas: quando uma conta migra para um novo domínio, sua SID antiga é preservada em sIDHistory, mantendo o acesso a recursos aos quais já era autorizada, sem que um administrador precise reescrever manualmente cada ACL. A função DsAddSidHistory da Microsoft e a configuração de trust EnableSIDHistory existem especificamente para suportar esse cenário de migração.

O problema é que o Windows não faz distinção entre uma SID adicionada durante uma migração legítima e uma adicionada por um atacante. No logon, o Controlador de Domínio constrói o PAC do usuário a partir de todas as SIDs associadas à conta — grupo primário, todas as associações a grupos e o conteúdo completo de sIDHistory — e esse PAC se torna o token de acesso em que todo serviço downstream confia. Essa é uma superfície de persistência fundamentalmente diferente do aninhamento perigoso de grupos, onde o privilégio pelo menos fica visível na lista de membros de um grupo — aqui, nenhuma associação a grupo jamais muda.

Contas de domínio normais, e até a maioria das ferramentas administrativas, não conseguem simplesmente Set-ADUser -Replace @{sidHistory=...} via LDAP; sIDHistory é um atributo construído/protegido. Na prática, atacantes o alcançam por meio de:

• Os módulos sid::patch e sid::add do Mimikatz, executados diretamente em um Controlador de Domínio com privilege::debug — isso exige acesso equivalente a Domain Admin/SYSTEM no próprio DC, e o sid::patch não funciona mais no Windows Server 2016 e versões posteriores.
• O Add-ADDBSidHistory do DSInternals editava o banco de dados ntds.dit offline e exigia parar o serviço NTDS — atuava diretamente sobre o banco de dados de um DC, em vez de usar a API de replicação normal. No momento da escrita, o cmdlet foi removido do módulo PowerShell DSInternals atual (sua documentação permanece apenas para referência); o equivalente mantido é Add-ADReplSidHistory, que executa a injeção online via o protocolo de replicação MS-DRSR e ainda exige direitos de replicação equivalentes a DC.
• A API legítima DsAddSidHistory, destinada à migração entre florestas, que algumas ferramentas usam de forma não intencional quando o atacante já controla privilégios equivalentes a DC.

Em todos os casos, o atacante já precisa de acesso em nível de replicação ou de Controlador de Domínio para gravar em sIDHistory — esta é uma técnica de persistência e furtividade pós-comprometimento, não um vetor de acesso inicial. O que justifica uma detecção dedicada é o que acontece depois: o privilégio injetado não é visível na associação a grupos, sobrevive a redefinições de senha e não é afetado pela remoção da conta de nenhum grupo (porque ela nunca foi membro de um).

A Cadeia de Ataque

Etapa 1 — Obter Acesso em Nível de DC ou Equivalente a Replicação

O atacante primeiro precisa de privilégios equivalentes a Domain Admin, ou acesso direto a um Controlador de Domínio — por exemplo, através de um comprometimento DCSync anterior, acesso direto ao console/RDP de um DC, ou uma cópia exfiltrada de ntds.dit. Essa etapa é o mesmo pré-requisito de um ataque DCSync ou de um Golden Ticket falsificado.

Etapa 2 — Identificar a Conta Alvo e a SID Conhecida

O atacante escolhe uma conta de baixo privilégio e baixa visibilidade (uma conta de serviço, uma conta antiga de terceirizado ou uma recém-criada) e a SID do domínio com a RID conhecida que deseja injetar:

Etapa 3 — Injetar a SID em sIDHistory

Em um DC comprometido, usando o Mimikatz:

privilege::debug
sid::patch
sid::add /sam:lowpriv-svc /new:S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-512

Historicamente, offline contra uma ntds.dit copiada, usando o DSInternals:

Add-ADDBSidHistory -SamAccountName lowpriv-svc -SidHistory S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-512 -DatabasePath .\ntds.dit

Etapa 4 — Autenticar-se como a Conta de Baixo Privilégio

No próximo logon, o DC constrói um PAC para lowpriv-svc que inclui a SID injetada de Domain Admins. Todo serviço que confia em dados de autorização Kerberos agora concede à conta acesso equivalente a Domain Admin — enquanto sua associação a grupos real continua sem mostrar nada de incomum.

🚨 Perigo: Como a SID injetada reside no próprio objeto da conta, em vez de em um ticket falsificado, ela persiste em todo logon futuro até que alguém inspecione e limpe especificamente sIDHistory — diferente de um Golden Ticket, que expira ou é invalidado por uma rotação do KRBTGT.

Detecção

Mudanças em sIDHistory são raras em um ambiente saudável fora de uma janela de migração ativa, o que as torna uma superfície de detecção de alto sinal — mas apenas se a política de auditoria correta estiver habilitada e as RIDs corretas forem verificadas.

Os Event IDs 4765/4766 exigem que a subcategoria de auditoria avançada "Audit User Account Management" esteja habilitada — ela não vem ativada por padrão em muitos ambientes, então verifique a política de auditoria antes de presumir a cobertura.

Enumere as contas existentes em busca de sIDHistory preenchida e filtre especificamente por RIDs privilegiadas conhecidas, não apenas qualquer valor histórico:

$domainSid = (Get-ADDomain).DomainSID.Value
$privilegedRids = @(512, 516, 518, 519)

Get-ADUser -Filter { SIDHistory -like '*' } -Properties SIDHistory |
    ForEach-Object {
        foreach ($sid in $_.SIDHistory) {
            $rid = ($sid.Value -split '-')[-1]
            if ($sid.Value -like "$domainSid-*" -and $privilegedRids -contains [int]$rid) {
                [PSCustomObject]@{
                    Account = $_.SamAccountName
                    InjectedSid = $sid.Value
                    RID = $rid
                }
            }
        }
    }

O Microsoft Defender for Identity oferece uma avaliação de postura de segurança para contas que carregam um valor de sIDHistory e inclui lógica de detecção comportamental ajustada para sinalizar alterações inesperadas no atributo SID History fora de atividades de migração — um controle compensatório útil onde a política de auditoria avançada apresenta lacunas.

Remediação

1. Habilite a política de auditoria avançada para gerenciamento de contas. Ative "Audit User Account Management" para que os Event IDs 4765/4766 realmente sejam gerados, e encaminhe-os ao seu SIEM com alertas para qualquer ocorrência fora de uma janela de mudança de migração conhecida.
2. Restrinja e monitore o acesso em nível de DC e equivalente a replicação. Como injetar em sIDHistory exige acesso Domain Admin/SYSTEM em um DC ou uma cópia de ntds.dit, o controle de maior impacto é o mesmo que interrompe ataques DCSync e Golden Ticket: minimize e audite contas com DS-Replication-Get-Changes-All e restrinja o logon interativo/RDP em Controladores de Domínio.
3. Audite sIDHistory em todo o domínio em um cronograma recorrente, não apenas após uma migração conhecida. Qualquer valor preenchido contendo uma RID privilegiada conhecida que não esteja vinculado a um projeto de migração documentado e delimitado no tempo deve ser tratado como um incidente crítico.
4. Limpe sIDHistory após a conclusão das migrações. Assim que as ACLs forem corrigidas para as novas SIDs, remova os valores legados de sIDHistory — uma superfície de ataque menor sem valores residuais é mais fácil de monitorar do que uma em que "alguma SID history é esperada".
5. Implante uma ferramenta de Identity Threat Detection and Response (ITDR), como o Microsoft Defender for Identity, para adicionar cobertura comportamental para alterações em sIDHistory que complementem as regras estáticas de log de auditoria.

# Remover todos os valores de sIDHistory de uma conta após a conclusão da migração/remediação
Set-ADUser -Identity lowpriv-svc -Clear sIDHistory

Como a EtcSec Detecta Isso

A auditoria de Active Directory da EtcSec distingue especificamente problemas de higiene de SID History de indicadores ativos de escalada de privilégios:

• SIDHISTORY_WELLKNOWN_SIDS (Crítico) — sinaliza qualquer conta cujo atributo sIDHistory contenha uma RID privilegiada conhecida (Domain Admins, Enterprise Admins, Schema Admins, Domain Controllers) correspondente à própria SID do domínio — o padrão específico descrito neste artigo, não a presença genérica de SID History.
• SID_HISTORY (Alto) — sinaliza qualquer conta com sIDHistory preenchida, para que o trabalho legítimo de limpeza pós-migração possa ser rastreado e concluído.
• SIDHISTORY_RECENT_CHANGES (Info) — destaca objetos cuja sIDHistory mudou recentemente, para correlacionar com janelas de migração documentadas.
• DCSYNC_CAPABLE — sinaliza o privilégio de ponto de entrada (contas não-DC com direitos de replicação) que costuma ser o pré-requisito para alcançar um DC e realizar a injeção.

Prioridades de Revisão

A injeção de SIDHistory com SIDs conhecidas deve ser tratada como um achado em nível de dominância do domínio, não como uma lacuna rotineira de higiene. Comece enumerando toda conta com sIDHistory não vazia e, em seguida, separe artefatos documentados de migração de valores inexplicados — especialmente qualquer um que corresponda a uma RID privilegiada conhecida na própria SID do domínio atual. Confirme quais Controladores de Domínio estavam acessíveis a quais administradores e contas de serviço durante a janela suspeita, já que a técnica exige acesso em nível de DC ou equivalente a replicação para ser executada. Como o privilégio injetado contorna completamente a revisão de associação a grupos, qualquer plano de remediação que audite apenas a associação a grupos vai deixá-lo passar — o próprio atributo precisa ser a fonte da verdade.

Controles Adjacentes a Revisar

A injeção de SIDHistory raramente aparece sozinha: o acesso em nível de DC que ela exige é o mesmo acesso que permite a extração de credenciais via DCSync, a falsificação de Golden Ticket e o roubo direto de ntds.dit. Ao investigar uma suspeita de injeção, revise quem detinha direitos de replicação e acesso de logon a DCs durante a janela de exposição, se o KRBTGT foi rotacionado recentemente e se outras contas privilegiadas mostram sinais de adulteração — mapear a cadeia completa com uma ferramenta de análise de grafos ajuda a visualizar esses caminhos de ataque encadeados antes que um fix isolado deixe outro caminho aberto. Uma correção que apenas limpa a sIDHistory de uma conta, sem fechar o caminho de acesso ao DC subjacente, deixa o atacante livre para injetá-la novamente — ou em uma conta diferente.

Leituras Relacionadas

Vale a pena revisar este tema junto com Ataque Golden Ticket — Deteccao & Remediacao, Abuso de ACL e DCSync: Os Caminhos Silenciosos para Domain Admin, Ataques de Confianca do Active Directory: Do Dominio Filho a Raiz, Contas Privilegiadas Active Directory: Protected Users, Delegação e Lacunas em Contas de Serviço, Aninhamento Perigoso de Grupos AD: Caminhos para Domain Admin e Monitoramento de Seguranca AD: Os Eventos que Importam.

• Ataque Golden Ticket — Deteccao & Remediacao
• Abuso de ACL e DCSync: Os Caminhos Silenciosos para Domain Admin
• Ataques de Confianca do Active Directory: Do Dominio Filho a Raiz
• Contas Privilegiadas Active Directory: Protected Users, Delegação e Lacunas em Contas de Serviço
• Aninhamento Perigoso de Grupos AD: Caminhos para Domain Admin
• Monitoramento de Seguranca AD: Os Eventos que Importam
• Caminhos de Ataque AD: Ma Configuracoes em Cadeia

Checklist de Validação

Antes de encerrar a revisão, execute novamente a enumeração de RIDs privilegiadas conhecidas em sIDHistory contra a produção e confirme que não restam ocorrências inexplicadas. Verifique se a política de auditoria avançada está habilitada em todo Controlador de Domínio, de modo que os Event IDs 4765/4766 sejam realmente gerados, não apenas teoricamente disponíveis. Confirme que os direitos de replicação e o acesso de logon a DCs foram restringidos às contas que genuinamente precisam deles, e registre as evidências — a saída da enumeração e o estado da política de auditoria — como a linha de base para a próxima auditoria recorrente.