# T1558.001 - Golden Ticket
> [!danger] Técnica de Alto Impacto
> O Golden Ticket é considerada uma das técnicas mais devastadoras de persistência em ambientes Active Directory. Um adversário com acesso ao hash KRBTGT pode forjar autenticação para **qualquer conta do domínio**, incluindo administradores, por períodos de até 10 anos - tornando a detecção extremamente desafiadora.
## Descrição
Adversários que obtêm o hash da conta **KRBTGT** podem forjar Tickets de Concessão de Ticket (TGT) do Kerberos - conhecidos como **Golden Tickets**. Esses tickets conferem ao atacante a capacidade de gerar material de autenticação para qualquer conta do Active Directory, sem interagir com controladores de domínio no momento do uso.
A técnica é uma sub-técnica de [[t1558-steal-or-forge-kerberos-tickets|T1558 - Steal or Forge Kerberos Tickets]] e representa o patamar mais elevado de comprometimento de identidade em infraestruturas Windows/AD. O KRBTGT é a conta de serviço do Key Distribution Center (KDC) do Kerberos - ela assina e criptografa **todos** os tickets Kerberos emitidos no domínio.
Para forjar um Golden Ticket, o adversário necessita de quatro elementos:
1. O **hash NTLM** (ou chave AES) da conta KRBTGT
2. O **nome do domínio** (FQDN)
3. O **SID do domínio**
4. O **nome de usuário** que desejá impersonar (qualquer conta, real ou fictícia)
Com esses elementos, o atacante usa ferramentas como [[mimikatz|Mimikatz]] ou [[s1071-rubeus|Rubeus]] para gerar um TGT completamente válido e assinado criptograficamente - sem precisar conhecer a senha real do usuário alvo, sem contato com o KDC, e com válidade configurável de anos.
A técnica pai [[t1003-os-credential-dumping|T1003 - OS Credential Dumping]] é geralmente o vetor pelo qual o hash KRBTGT é obtido, tipicamente via execução de `lsadump::dcsync` do Mimikatz contra um controlador de domínio.
## Como Funciona
O protocolo Kerberos utiliza criptografia simétrica: o KDC emite TGTs criptografados com o hash KRBTGT para autenticar usuários. Servidores de aplicação (KDC) confiam nos TGTs apresentados sem re-válidar com a fonte emissora - essa é a vulnerabilidade estrutural explorada.
**Passo a passo técnico:**
1. **Obtenção do hash KRBTGT:** O adversário com acesso privilegiado a um Domain Controller executa `lsadump::dcsync /domain:corp.local /user:krbtgt` via Mimikatz, ou extrai diretamente do processo LSASS via `sekurlsa::krbtgt`. Esse hash raramente é rotacionado - em muitos ambientes, o KRBTGT nunca teve a senha alterada desde a criação do domínio.
2. **Coleta de metadados do domínio:** O SID do domínio pode ser obtido com `whoami /user` ou via `Get-ADDomain | Select-Object DomainSID` (PowerShell). O FQDN é trivialmente disponível em qualquer máquina ingressada no domínio.
3. **Forjá do Golden Ticket:** Com [[mimikatz|Mimikatz]]:
```
kerberos::golden /user:Administrador /domain:corp.local /sid:S-1-5-21-... /krbtgt:<hash> /ticket:golden.kirbi
```
Ou com [[s1071-rubeus|Rubeus]] para variantes com chaves AES-256 (mais furtivas):
```
Rubeus.exe golden /aes256:<hash> /user:Administrador /domain:corp.local /sid:S-1-5-21-...
```
4. **Injeção e uso do ticket:** O ticket forjado é injetado na sessão atual com `kerberos::ptt golden.kirbi` (Mimikatz) ou `Rubeus.exe ptt /ticket:golden.kirbi`, permitindo acesso irrestrito a recursos de domínio.
5. **Persistência de longo prazo:** Golden Tickets podem ser configurados com válidade de 10 anos e incluir SIDs de grupos privilegiados arbitrários no campo `ExtraSIDs`, permitindo elevação de privilégio mesmo em domínios filho para pai (cross-domain escalation).
A variante com chaves **AES-256** (em vez de RC4-HMAC/NTLM) é significativamente mais difícil de detectar, pois corresponde ao comportamento legítimo de clientes Windows modernos que preferem AES no Kerberos.
## Attack Flow
```mermaid
graph TB
A[Comprometimento Inicial<br/>Acesso privilegiado ao domínio] --> B[Dump de Credenciais<br/>T1003 - OS Credential Dumping]
B --> C[Extração do Hash KRBTGT<br/>Mimikatz dcsync / LSASS dump]
C --> D[Coleta de Metadados<br/>Domain SID + FQDN]
D --> E[Forjá do Golden Ticket<br/>Mimikatz / Rubeus com hash KRBTGT]
E --> F[Injeção do Ticket<br/>Pass-the-Ticket - sessão atual]
F --> G[Acesso Universal ao Domínio<br/>Qualquer recurso / qualquer conta]
G --> H[Persistência Duradoura<br/>Ticket válido por anos]
H --> I[Movimentação Lateral<br/>T1021 - Remote Services]
H --> J[Exfiltração de Dados<br/>Acesso irrestrito a shares / DCs]
style A fill:#ff6b6b,color:#fff
style E fill:#ffd93d,color:#333
style G fill:#ff6b6b,color:#fff
style H fill:#ff6b6b,color:#fff
```
## Exemplos de Uso
### Ke3chang (APT15)
O grupo chinês [[g0004-apt15|Ke3chang]], patrocinado pelo estado, utiliza Golden Tickets como mecanismo de persistência em longo prazo após comprometer redes governamentais e diplomáticas. O grupo combina dumping de credenciais via [[t1003-os-credential-dumping|OS Credential Dumping]] com a forjá de tickets para manter acesso persistente mesmo após tentativas de remediação parcial - desde que o hash KRBTGT não sejá rotacionado duas vezes.
### Grupos de Ransomware
Operadores de ransomware como [[g0102-conti-group|Wizard Spider]] (Ryuk/Conti) e afiliados do [[lockbit|LockBit]] documentadamente utilizaram Golden Tickets para garantir persistência durante operações de ransomware de longa duração. Após a forjá do ticket, movem-se lateralmente para comprometer backups e sistemas de replicação antes de acionar a criptografia.
### Operações de Espionagem APT
Grupos como [[g0016-apt29|APT29]] (Cozy Bear) e [[g0096-apt41|APT41]] incorporam Golden Tickets em suas toolchains de persistência pós-comprometimento, frequentemente combinados com técnicas [[t1021-remote-services|Remote Services]] para propagação silenciosa.
### Demonstração em Red Team
Em avaliações de Red Team, o Golden Ticket é frequentemente o "troféu" que demonstra comprometimento completo do domínio. A capacidade de autenticar como qualquer usuário - incluindo contas de serviço de backups, sistemas de monitoramento e domínios de confiança - evidência o impacto total da técnica.
## Detecção
A detecção de Golden Tickets é desafiadora porque os tickets forjados são criptograficamente válidos. As principais abordagens de detecção focam em **anomalias no comportamento do ticket** e **eventos de log específicos**:
### Indicadores Primários
- **Evento 4769** (Windows Security Log): Solicitações de TGS com encryption type `0x17` (RC4-HMAC) para contas que deveriam usar AES - indicam possível Golden Ticket com hash RC4
- **Evento 4624**: Logon com ticket Kerberos onde o tempo de expiração do TGT excede a política máxima do domínio (padrão: 10 horas)
- **Evento 4768**: TGT emitido sem correspondência prévia de pré-autenticação AS-REQ, ou com válidade anômala
- **Discrepância de PAC**: Tickets com campos PAC (Privilege Attribute Certificaté) inconsistentes com os registros reais do Active Directory
### Regra Sigma - Detecção de Golden Ticket
```yaml
title: Kerberos Golden Ticket - Anomalia de Validade e Tipo de Criptografia
status: experimental
description: |
Detecta possível uso de Golden Ticket via anomalias em tickets Kerberos:
tipo de criptografia RC4 legado em ambiente AES-preferido, ou
tickets com válidade superior à política do domínio.
logsource:
product: windows
service: security
detection:
selection_event:
EventID: 4769
selection_rc4_anomaly:
TicketEncryptionType: '0x17'
filter_legitimate_rc4:
ServiceName|endswith:
- '