Ataque Golden Ticket — Deteccao & Remediacao

O que e um Ataque Golden Ticket?

Um ataque Golden Ticket e um Ticket Granting Ticket (TGT) Kerberos falsificado que concede a um atacante acesso ilimitado e persistente a todos os recursos de um dominio Active Directory — sem precisar da senha de nenhum usuario.

O ataque abusa da conta KRBTGT, cujo hash e usado para assinar cada TGT emitido no dominio. Se um atacante obtiver esse hash, pode fabricar TGTs validos para qualquer usuario, incluindo Administradores de Dominio, com qualquer pertenca a grupos e qualquer data de expiracao que escolher.

Isso torna o Golden Ticket uma das tecnicas de pos-exploracao mais graves em Active Directory: um unico hash roubado se traduz em controle indefinido de todo o dominio.

Como Funciona um Ataque Golden Ticket

A autenticacao Kerberos depende de um terceiro confiavel: o Key Distribution Center (KDC), executado em cada Controlador de Dominio.

O fluxo normal:

1. Um usuario se autentica no KDC e recebe um TGT, assinado com o hash do KRBTGT.
2. O usuario apresenta o TGT para solicitar Service Tickets (TGS) para recursos especificos.
3. Os servicos validam o TGS e concedem acesso.

A conta KRBTGT e a raiz de confianca de todos os TGTs do dominio. Nenhum servico valida os TGTs diretamente com o KDC no momento do uso — eles confiam na assinatura. Isso significa que um TGT falsificado, assinado com o hash real do KRBTGT, e indistinguivel de um legitimo.

A Cadeia de Ataque

Etapa 1 - Obter Domain Admin (ou equivalente)

O atacante precisa de privilegios suficientes para extrair o hash do KRBTGT. Isso normalmente significa comprometer um Controlador de Dominio ou qualquer conta com direitos DS-Replication-Get-Changes-All (DCSync).

Caminhos de escalada comuns que levam ate aqui: Kerberoasting de uma conta de servico privilegiada, abuso de ADCS ESC1/ESC8 ou exploracao de delegacao irrestrita.

Etapa 2 - Extrair o Hash do KRBTGT via DCSync

O atacante executa um ataque DCSync usando Mimikatz ou Impacket para obter o hash NTLM do KRBTGT sem tocar no disco do DC nem gerar um evento de logon:

# Mimikatz
lsadump::dcsync /domain:corp.local /user:krbtgt

# Impacket (remoto, a partir do Linux)
impacket-secretsdump -just-dc-user krbtgt corp.local/admin:[email protected]

A saida inclui o hash NTLM e o SID do dominio — ambos necessarios para falsificar o ticket.

Etapa 3 - Falsificar o Golden Ticket

Com o hash do KRBTGT e o SID do dominio, o atacante fabrica um TGT para qualquer usuario que escolher:

# Mimikatz — falsificar e injetar diretamente na sessao atual
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /krbtgt:HASH /ptt

Parametros principais:

Etapa 4 - Acesso Total ao Dominio e Persistencia

O TGT falsificado e aceito por todos os servicos do dominio. O atacante agora pode:

• Acessar qualquer compartilhamento de arquivos, sessao RDP, endpoint WMI ou servico DCOM
• Criar novas contas backdoor e adiciona-las a grupos privilegiados
• Distribuir GPOs maliciosas para todas as maquinas
• Manter persistencia indefinida — redefinir a senha de qualquer conta de usuario nao tem nenhum efeito

Deteccao

Golden Tickets sao dificeis de detectar porque TGTs falsificados se parecem com trafego Kerberos legitimo. O KDC nao e consultado no momento de uso do ticket, entao nenhum evento de autenticacao e disparado no DC quando o ticket e apresentado a um servico.

A deteccao depende de analise de anomalias em vez de correlacao direta de eventos.

Event IDs do Windows

Anomalias Comportamentais

• Duracao do ticket superior a 10 horas - o maximo padrao da Microsoft e 10 horas; tickets falsificados costumam ter duracao de anos
• Nomes de usuario inexistentes em eventos Kerberos - Golden Tickets podem ser forjados para contas que nao existem no AD
• Criptografia RC4 quando o dominio impoe apenas AES - ferramentas mais antigas usam RC4 (0x17) por padrao
• Solicitacao TGS sem AS-REQ anterior - uma solicitacao de service ticket em um DC sem a correspondente solicitacao de TGT e um forte indicador
• Incompatibilidade de SID - o SID incorporado no ticket nao corresponde a nenhuma conta real do AD

Consulta SIEM (Elastic KQL)

event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")

event.code: "4768" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
winlog.event_data.PreAuthType: "0"

Remediacao

Resposta Imediata

Rotacione a senha do KRBTGT duas vezes, com um intervalo entre as rotacoes igual a duracao maxima do ticket Kerberos (padrao: 10 horas).

• A primeira rotacao invalida todos os tickets falsificados atualmente ativos.
• A segunda rotacao remove o hash anterior da memoria do DC, impedindo o uso de tickets forjados com o hash antigo.

Use o script de reset do krbtgt mantido ativamente, que trata automaticamente as verificacoes de replicacao multi-DC:

# Baixar e executar Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1
# https://github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.md

.\Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -modeOfOperation resetModeKrbTgtProdAccountsResetOnce -targetedADforestFQDN corp.local -targetedADdomainFQDN corp.local -targetKrbTgtAccountScope allRWDCs
# Aguardar pelo menos 10 horas (duracao maxima do ticket)
.\Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -modeOfOperation resetModeKrbTgtProdAccountsResetOnce -targetedADforestFQDN corp.local -targetedADdomainFQDN corp.local -targetKrbTgtAccountScope allRWDCs

Reforco para Prevenir o Comprometimento Inicial

Verificar a Exposicao a DCSync

# Encontrar contas com direitos DCSync (contas nao-DC com permissoes de replicacao)
Get-ADObject -Filter * -Properties nTSecurityDescriptor | Where-Object {
    $_.nTSecurityDescriptor.Access | Where-Object {
        $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" -and
        $_.IdentityReference -notmatch "Domain Controllers"
    }
}

Como o EtcSec Detecta Isso

O EtcSec verifica as condicoes que tornam os ataques Golden Ticket possiveis e persistentes em seu ambiente.

A deteccao GOLDEN_TICKET_RISK sinaliza ambientes onde a senha da conta KRBTGT nao foi rotacionada recentemente — um indicador direto de que qualquer Golden Ticket forjado anteriormente ainda pode ser valido.

Verificacoes relacionadas adicionais:

• WEAK_KERBEROS_POLICY - configuracoes de duracao e renovacao de tickets Kerberos que ampliam a janela de exposicao para tickets falsificados
• KERBEROS_RC4_FALLBACK - criptografia RC4 ainda permitida no dominio, necessaria para falsificar tickets com ferramentas mais antigas e que dificulta a deteccao
• UNCONSTRAINED_DELEGATION - contas com delegacao irrestrita que podem ser usadas para capturar TGTs, um precursor comum de ataques Golden Ticket

Prioridades de Revisao

Golden Ticket: As Chaves do Seu Dominio deve ser tratado como uma exposicao real dentro do seu ambiente Active Directory, e nao como uma configuracao isolada. Comece definindo o perimetro de revisao: quais grupos privilegiados, contas de servico, ACLs, vinculos de GPO, trusts, delegacoes, templates de certificado e estacoes admin estao envolvidos, quais fluxos de negocio dependem deles, quais privilegios ficam expostos e quais excecoes de emergencia foram se acumulando ao longo do tempo. Essa etapa de definicao de escopo evita uma remediacao superficial, porque o sintoma tecnico costuma ser menor que o raio de impacto operacional. Ao documentar o caminho completo entre configuracao e privilegio, o time consegue priorizar mudancas que reduzem o risco rapidamente sem quebrar o acesso em producao. Isso tambem cria uma base defensavel para a validacao posterior e da a lideranca uma explicacao clara de por que o problema importa agora.

Controles Adjacentes a Revisar

Quando atacantes alcancam seu ambiente Active Directory, raramente param no primeiro ponto fraco. Em torno de Golden Ticket: As Chaves do Seu Dominio, eles normalmente testam se o caminho exposto pode ser encadeado com contas privilegiadas obsoletas, aninhamento de grupos inseguro, delegacao excessiva, politicas de senha fracas, caminhos de GPO com permissao de escrita e abuso de ACL herdada. Isso significa que os defensores devem revisar nao apenas a fraqueza principal, mas tambem cada dependencia proxima que transforma acesso em persistencia ou escalada de privilegios. Confirme quais identidades, roles, permissoes e suposicoes de confianca podem ser reutilizadas por um operador motivado. Se uma correcao fecha apenas um objeto e deixa caminhos de privilegio adjacentes intocados, o risco efetivo muda pouco. Uma revisao disciplinada das oportunidades de encadeamento e o que transforma este tema em um exercicio de hardening pratico, em vez de uma verificacao pontual.

Leituras Relacionadas

Revise este tema junto com Ataques Delegacao Kerberos: Nao Restrita a RBCD, Deteccao prevencao kerberoasting: como identificar e proteger contas de serviço expostas a cracking offline, Abuso de ACL e DCSync: Os Caminhos Silenciosos para Domain Admin, Ataques de Confianca do Active Directory: Do Dominio Filho a Raiz e AS-REP Roasting: Coletando Hashes Sem Credenciais. Esses artigos relacionados mostram como as mesmas fraquezas de identidade costumam se encadear em uma avaliacao real, em vez de aparecer como achados isolados.

• Ataques Delegacao Kerberos: Nao Restrita a RBCD
• Deteccao prevencao kerberoasting: como identificar e proteger contas de serviço expostas a cracking offline
• Abuso de ACL e DCSync: Os Caminhos Silenciosos para Domain Admin
• Ataques de Confianca do Active Directory: Do Dominio Filho a Raiz
• AS-REP Roasting: Coletando Hashes Sem Credenciais

Usar essas referencias mantem a discussao de remediacao focada no caminho de ataque completo, em vez de em uma unica lacuna de controle.

Lista de Verificacao de Validacao

Antes de encerrar a revisao, execute novamente as mesmas verificacoes que revelaram o problema e confirme que o caminho de risco nao existe mais sob a perspectiva do atacante. Verifique as identidades, privilegios, caminhos de heranca e controles compensatorios relevantes em producao, nao apenas em staging ou na documentacao. Registre o responsavel tecnico, a dependencia de negocio esperada e as evidencias que mostram que a nova configuracao e ao mesmo tempo mais segura e operacionalmente sustentavel. Essa etapa final de validacao e o que mantem o artigo ancorado em como as equipes realmente reduzem o risco de identidade.