t1134-005-sid-history-injection

# T1134.005 - SID-History Injection ## Técnica Pai Sub-técnica de [[t1134-access-token-manipulation|T1134 - Access Token Manipulation]], que cobre o conjunto de técnicas nas quais adversários manipulam tokens de acesso do Windows para se passar por outros usuários ou elevar privilégios. ## Descrição SID-History Injection é uma técnica de escalada de privilégios e evasão de controles de acesso que explora um atributo legítimo do Active Directory (AD) projetado originalmente para facilitar migrações de domínio. O atributo `SIDHistory` de um objeto de usuário no AD permite que uma conta carregue identificadores de segurança (SIDs) históricos de domínios anteriores - preservando o acesso a recursos durante processos de consolidação de domínios. Adversários com privilégios de **Domain Administrator** (ou equivalente) exploram esse mecanismo para injetar SIDs arbitrários no histórico de um usuário controlado. Quando o usuário autentica, todos os SIDs presentes no campo `SIDHistory` são incluídos em seu **token de acesso Kerberos** (no campo `ExtraSids` do PAC - Privilege Attribute Certificaté). Do ponto de vista dos servidores de recursos, esses SIDs extras são indistinguíveis de associações de grupo legítimas. Na prática, isso significa que um adversário pode: - Injetar o SID de **Enterprise Administrators** (S-1-5-21-...-519) em uma conta comum, concedendo-lhe efetivamente o máximo de privilégios da floresta AD - Criar "backdoors" de acesso persistentes que sobrevivem a resets de senha e remoção de grupos - Mover-se lateralmente entre domínios de uma floresta com acesso privilegiado silencioso - Criar Golden Tickets ou Silver Tickets com `ExtraSids` forjados via [[mimikatz|Mimikatz]] A técnica é especialmente perigosa porque o `SIDHistory` raramente é monitorado em ambientes corporativos, e contas com SIDs injetados aparecem como usuários comuns em consultas padrão do AD. ## Como Funciona ### Pré-requisitos Para executar SID-History Injection diretamente no AD, o adversário precisa de: - Privilégios de **Domain Administrator** no domínio alvo, **OU** - Acesso direto ao banco de dados NTDS.DIT via DCSync ([[t1003-003-ntds|T1003.003]]) ou acesso físico/privilegiado ao Domain Controller ### Método 1 - Injeção direta via Mimikatz (requer acesso ao DC) O [[mimikatz|Mimikatz]] implementa o módulo `sid::patch` que patcha o processo `lsass.exe` para contornar a verificação de privilégios do sistema e permite adicionar SIDs diretamente: ``` mimikatz # privilege::debug mimikatz # sid::patch mimikatz # sid::add /sam:<usuário_alvo> /new:<SID_a_injetar> ``` Esse método requer execução direta no Domain Controller com privilégios de debug. ### Método 2 - Forjamento de PAC com Golden/Diamond Ticket Com acesso ao hash `krbtgt` (obtido via DCSync - [[t1003-dcsync|T1003 - OS Credential Dumping]]), o adversário pode criar tickets Kerberos forjados que incluem o campo `ExtraSids` com SIDs privilegiados arbitrários. O [[mimikatz|Mimikatz]] e frameworks como [[s0363-empire|Empire]] suportam criação de Golden Tickets com `ExtraSids`: ``` kerberos::golden /user:<usuário> /domain:<domínio> /sid:<SID_do_domínio> /krbtgt:<hash_krbtgt> /sids:<SID_Enterprise_Admins> /ptt ``` Esse método não modifica o AD persistentemente - o SID existe apenas no ticket em memória - mas permite acesso imediato a recursos de todos os domínios da floresta. ### Método 3 - Modificação direta do NTDS.DIT Com acesso ao arquivo `NTDS.DIT` (banco de dados do AD), é possível modificar diretamente o atributo `SIDHistory` de qualquer conta, criando backdoors persistentes. ### Mecanismo de autenticação explorado Quando uma conta com `SIDHistory` populado autentica no Kerberos: 1. O KDC (Key Distribution Center) lê o atributo `SIDHistory` do objeto de usuário 2. Os SIDs históricos são inseridos no campo `ExtraSids` do PAC (Privilege Attribute Certificaté) do ticket Kerberos 3. Servidores de recursos que recebem o ticket incluem esses SIDs extras na avaliação de autorização 4. O usuário recebe acesso como se fosse membro dos grupos correspondentes aos SIDs injetados Esse comportamento é por design - foi introduzido para migração de domínios - mas se torna um vetor de ataque quando o `SIDHistory` é populado maliciosamente. ## Attack Flow ```mermaid graph TB A["🎯 Comprometimento Inicial T1566 / T1190"] --> B["⚡ Escalada de Privilégios no Domínio AD"] B --> C{"Método de Injeção"} C --> D["🔑 DCSync Obtém hash krbtgt T1003"] C --> E["🖥️ Acesso direto ao DC Execução do Mimikatz"] D --> F["🎫 Golden Ticket com ExtraSids SID Enterprise Admins forjado"] E --> G["📝 Injeção direta no atributo SIDHistory do AD sid::patch + sid::add"] F --> H["🔓 Token de acesso com SIDs privilegiados extras"] G --> H H --> I["🌐 Movimento lateral entre domínios da floresta T1021 - Remote Services"] I --> J["🕵️ Persistência silenciosa Backdoor via conta comum com SID privilegiado"] J --> K["📤 Exfiltração / Objetivos Accesso total à floresta AD"] style A fill:#8B0000,color:#fff style D fill:#8B4513,color:#fff style H fill:#B8860B,color:#fff style J fill:#006400,color:#fff style K fill:#8B0000,color:#fff ``` ## Exemplos de Uso ### Ataques pós-comprometimento de floresta AD Em investigações de resposta a incidentes de grandes organizações, forenses revelam SID-History Injection como mecanismo de persistência de longo prazo. Após obter acesso de Domain Admin, adversários injetam SIDs privilegiados em contas de serviço aparentemente inativas - contas que raramente são auditadas e cujos atributos AD não são verificados rotineiramente. ### Mimikatz - uso em Red Teams e APTs O [[mimikatz|Mimikatz]] é a ferramenta mais utilizada para implementar SID-History Injection, tanto por grupos APT quanto em exercícios de Red Team. O módulo `sid::patch` foi documentado extensivamente em relatórios de incidentes de espionagem corporativa e governamental. ### Empire Framework O framework [[s0363-empire|Empire]] implementa módulos de PowerShell que permitem injetar SIDs via modificação do PAC sem necessitar de acesso físico ao DC, bastando ter o hash `krbtgt`. É frequentemente usado em simulações de ataque avançadas para demonstrar movimento lateral inter-domínios. ### Ataques a fusões e aquisições (M&A) Ambientes corporativos em processo de fusão - onde múltiplos domínios AD são consolidados - são particularmente vulneráveis. O mecanismo de `SIDHistory` é ativamente usado durante a migração legítima, criando jánelas de oportunidade para adversários que monitoram o processo de M&A. ## Detecção SID-History Injection é historicamente subdetectado porque o atributo `SIDHistory` não é monitorado por padrão na maioria dos ambientes. A detecção requer auditoria específica do AD e análise de tickets Kerberos. **Indicadores chave:** - Conta de usuário comum com `SIDHistory` populado (especialmente com SIDs de grupos privilegiados como Enterprise Admins S-1-5-21-...-519) - Tickets Kerberos com campo `ExtraSids` contendo SIDs não esperados para o usuário - Autenticação de conta com SIDHistory não nulo acessando recursos de domínios diferentes do seu domínio home - Uso do módulo `sid::patch` do Mimikatz detectado por EDR (manipulação de processo `lsass.exe`) - Alterações no atributo `SIDHistory` de objetos de usuário no AD (evento 4738 com campo `SIDHistory`) **Regra de detecção - modificação do atributo SIDHistory:** ```yaml title: SID-History Injection - Atributo SIDHistory Modificado no AD status: experimental logsource: category: ds_object_modification product: windows detection: selection: EventID: 4742 AttributeLDAPDisplayName: 'sIDHistory' filter_legit_migration: SubjectUserName|endswith: 'Migration Service Account' condition: selection and not filter_legit_migration level: high tags: - attack.defense_evasion - attack.privilege_escalation - attack.t1134.005 ``` **Regra de detecção - conta com SID privilegiado em ExtraSids do PAC:** ```yaml title: SID-History Injection - SID Enterprise Admins em Token de Usuário Comum status: experimental logsource: category: authentication product: windows detection: selection: EventID: 4624 LogonType: 3 filter_expected: SubjectUserSid|contains: 'S-1-5-21' kerberos_pac: ExtraSids|contains: '-519' condition: selection and kerberos_pac and not filter_expected level: critical tags: - attack.defense_evasion - attack.t1134.005 ``` **Regra de detecção - limpeza de SIDHistory (técnica de anti-forense):** ```yaml title: SID-History Injection - Remoção Suspeita de SIDHistory status: experimental logsource: category: ds_object_modification product: windows detection: selection: EventID: 4742 AttributeLDAPDisplayName: 'sIDHistory' AttributeValue: '' condition: selection level: medium tags: - attack.defense_evasion - attack.t1134.005 ``` **Consulta de auditoria recomendada (PowerShell/AD):** Para identificar contas com `SIDHistory` populado no ambiente: ```powershell Get-ADUser -Filter {SIDHistory -like "*"} -Properties SIDHistory | Select-Object Name, SamAccountName, SIDHistory ``` **Fontes de dados:** | Fonte | Eventos | Descrição | |-------|---------|-----------| | Windows Security Log | 4742, 4738 | Modificação de atributos de conta de usuário | | Windows Security Log | 4768, 4769 | Emissão de TGT/TGS Kerberos - analisar ExtraSids | | AD Audit | Modificação de `sIDHistory` | Requer Auditoria de Modificação de Objeto do DS ativa | | EDR | Mimikatz `sid::patch` | Hooking de `lsass.exe` / `lsadb.dll` | | SIEM | Correlação de eventos | Login com SIDs extras → acesso inter-domínio | ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | M1015 | [[m1015-active-directory-configuration\|M1015 - Active Directory Configuration]] | Habilitar auditoria de modificações no AD; ativar SID Filtering (Quarantine) em trusts de domínio para bloquear SIDs de domínios externos no PAC; revisar contas com `SIDHistory` não nulo periodicamente | | M1026 | Gerenciamento de contas privilegiadas | Proteger hashes `krbtgt` com Tiered Access Model; rotacionar `krbtgt` após comprometimento suspeito; implementar Privileged Access Workstations (PAWs) | | M1027 | Políticas de senha | Rotacionar o hash `krbtgt` **duas vezes** após comprometimento confirmado - tickets forjados com o hash anterior tornam-se inválidos | **Controles específicos para SID-History Injection:** 1. **SID Filtering nas trusts** - ative `Quarantine` nas trusts de domínio para bloquear `ExtraSids` de domínios externos nos tickets Kerberos; isso é crítico em ambientes multi-domínio 2. **Desabilitar SIDHistory quando não necessário** - se a organização não está em processo de migração de domínio, o atributo `SIDHistory` não deveria ser populado em nenhuma conta; criar alertas para qualquer população do campo 3. **Monitoramento contínuo do AD** - soluções como Microsoft Defender for Identity (MDI), Semperis DSP ou Varonis detectam modificações em `SIDHistory` e comportamento anômalo de tokens Kerberos 4. **Proteger o `krbtgt`** - sem o hash `krbtgt`, o adversário não pode forjar PACs com `ExtraSids`; implementar monitoramento de DCSync ([[t1003-dcsync|T1003]]) e proteger DCs com controles de acesso rígidos ## Contexto Brasil/LATAM SID-History Injection é uma técnica pós-comprometimento de alto impacto relevante para organizações brasileiras com infraestrutura Active Directory, especialmente em contextos de: **1. Grandes grupos corporativos e holding companies** Grupos empresariais brasileiros com múltiplas subsidiárias frequentemente operam ambientes AD com múltiplos domínios em relações de trust (floresta com domínios filhos por subsidiária). Esse é o ambiente ideal para SID-History Injection - um adversário que compromete um domínio filho pode injetar SIDs do domínio raiz para escalar para o nível de floresta. **2. Setores financeiro e governo** Bancos brasileiros e órgãos governamentais com ambientes AD de grande escala são alvos de grupos APT e cibercriminosos que utilizam técnicas avançadas de movement lateral. A técnica permite que um adversário que invadiu uma estação de trabalho corporativa escale para controle total do AD silenciosamente. **3. Fusões e aquisições no mercado brasileiro** O mercado brasileiro tem visto consolidações significativas em setores como financeiro, varejo e saúde. Durante processos de M&A com integração de domínios AD, o `SIDHistory` é usado legitimamente - criando jánelas onde a técnica é difícil de distinguir de atividade legítima de migração. **4. Ferramentas populares em grupos locais de cybercrime** O [[mimikatz|Mimikatz]] é amplamente utilizado por grupos de cybercrime brasileiro que operam ransomware e fraude corporativa. Incidentes de ransomware em empresas brasileiras frequentemente revelam, em análise forense, que os adversários utilizaram técnicas de token manipulation para escalar privilégios antes de implantar o payload final. **Recomendação para equipes de segurança no Brasil:** - Auditar imediatamente todos os objetos de usuário com `SIDHistory` populado no AD - Ativar auditoria de modificação de objetos do Directory Service nos Domain Controllers - Implementar alertas em tempo real para qualquer modificação do atributo `sIDHistory` - Incluir SID-History Injection em exercícios de Purple Team e avaliações de AD Security Posture ## Referências - MITRE ATT&CK - T1134.005 (Access Token Manipulation: SID-History Injection) - Microsoft - documentação de SID Filtering e SIDHistory no Active Directory - Semperis - "SIDHistory Injection: The AD backdoor you're probably ignoring" - SpecterOps / BloodHound - pesquisa sobre SID Abuse em ambientes AD complexos - Sean Metcalf (ADSecurity.org) - análise técnica de Golden Ticket com ExtraSids - Mandiant - relatório sobre técnicas de persistência em AD pós-comprometimento --- *Fonte: MITRE ATT&CK - T1134.005*