Pass-the-Ticket: Deep dive

Este post é o segundo de uma série e tem como foco mostrar quais são os tipos de ataque mais usados contra o Active Directory.

O primeiro post foi sobre ataques do tipo Pass-the-hash. Caso você não tenha lido, você pode acompanhar este post aqui.

Vimos no post anterior que o uso do NTLM deve, sempre que possível, ser desativado, pois é um protocolo não tão seguro assim, haja vista que existem protocolos melhores como o Kerberos. Mas… será que o Kerberos, por ser melhor significa necessariamente ser mais seguro? Bom isso é o que você vai descobrir hoje através do entendimento da subtécnica Pass-the Ticket.

A subtécnica Pass-the Ticket é abordado no MITRE ATT&CK framework na sessão “Use of Alternate Authentication Methods (T1550)”

1. Pass-the-Ticket (T1550.003)

O Pass-the-Ticket (PtT) é um ataque direcionado ao protocolo de autenticação Kerberos, utilizado pelo Active Directory para autenticação segura (mais segura que LM e NTLM).

Esse ataque permite que um invasor reutilize um ticket de autenticação já obtido, sem precisar conhecer as credenciais do alvo. Dessa forma, ele pode acessar serviços e sistemas na rede com os privilégios da conta comprometida, facilitando o movimento lateral e a elevação de privilégios. Para que possamos explicar como esse ataque funciona teremos de dar a definição de alguns componentes como por exemplo, TGT, TGS, SSO etc.

1.1 Kerberos Ticket Granting Ticket (TGT) e Kerberos Ticket Granting Service (TGS)

O ticket de autenticação que falei no parágrafo acima é o Kerberos Ticket Granting Ticket (TGT). O TGT é um componente crucial do protocolo Kerberos, pois é ele permite que um usuário se autentique em vários sistemas sem precisar digitar sua senha toda vez (Single SignOn).

O TGT é gerado em um Domain Controller (DC) para um usuário após autenticação do usuário em um computador/servidor. Ele inclui informações como a chave de sessão, grupos e privilégios, que são usados ​​para solicitar tickets de serviço (TGS). E é com o TGS que o usuário consegue acessar serviços específicos em sistemas de destino (Ex: Share em um File Server)

O Kerberos criptografa o TGT usando o hash de senha do usuário e emprega algoritmos de criptografia simétrica como DES ou AES (dependendo da configuração do ambiente Kerberos). Após a criptografia, o TGT é enviado para a memória do computador/servidor (guarde bem isso) onde o usuário efetuou o login.

Como falei anteriormente, o TGT permite que um usuário se autentique em vários sistemas sem precisar digitar sua senha toda vez. Essa maravilha (chamada Single Sign On) acontece, pois, quando o usuário deseja acessar um recurso em outro sistema (Exemplo um share hospedado em um File Server), ele usa o TGT para solicitar um tíquete de serviço (TGS) do DC. O TGS também é criptografado com a chave de sessão do usuário e contém uma chave de sessão criptografada que pode ser usada para autenticação no sistema de destino. O tíquete de serviço é então enviado ao computador do usuário, onde é usado para autenticação no sistema de destino.

Para maior entendimento sobre TGS, TGT e outros itens do protocolo Kerberos, recomendo fortemente a leitura da RFC 4120 The Kerberos Network Authentication Service (V5). Neste post vou me ater ao Pass-the-Hash (Pth).

Tendo um TGT de um usuário privilegiado roubado, um atacante pode solicitar um TGS do DC para um serviço específico em um sistema alvo para obter acesso aos seus recursos como se fosse esse usuário privilegiado.

2. Como o ataque funciona?

1. Comprometimento inicial do sistema
   O invasor precisa primeiro obter acesso a um sistema na rede, seja por meio de phishing, exploração de vulnerabilidades ou engenharia social.
2. Extração de tickets Kerberos
   O atacante usa ferramentas como Mimikatz para extrair tickets Kerberos armazenados na memória do sistema comprometido. Os dois principais tipos de tickets que podem ser obtidos são:
   • TGT (Ticket Granting Ticket) – usado para solicitar novos tickets de serviço.
   • TGS (Ticket Granting Service) – usado para acessar serviços específicos.
3. Uso do ticket roubado
   O invasor injeta o ticket extraído em outro sistema e o usa para se autenticar em servidores ou serviços da rede, sem precisar da senha da vítima.
4. Escalação e persistência
   Se o ticket pertencer a uma conta privilegiada, como um administrador de domínio, o invasor poderá obter controle total sobre o Active Directory.

3. Impactos do Pass-the-Ticket

• Movimento lateral facilitado: O invasor pode acessar diferentes serviços e sistemas sem precisar comprometer novas credenciais.
• Dificuldade na detecção: O ataque utiliza credenciais legítimas, evitando detecções baseadas em falhas de login.
• Comprometimento de contas privilegiadas: Se o invasor capturar um ticket de um administrador, poderá assumir o controle total do domínio.
• Persistência na rede: Como os tickets Kerberos têm uma validade temporária, o invasor pode renová-los automaticamente e manter o acesso.

4. Ferramentas e técnicas

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

Ataques Pass-the-Hash (PtH) podem ser executados utilizando várias ferramentas disponíveis. Como exemplo, usarei o Mimikatz.

4.1 Mimikatz

O uso do Mimikatz para ataques PtT consiste em quatro passos

Passo 1: Obtendo ticket Kerberos de contas válidas

Para obter lista de hashs armazenadas no Windows usando Mimikatz normalmente usa-se o módulo sekurlsa com no Mimikatz para extrair informações de autenticação da memória LSASS.

A função “tickets” deste módulo examina especificamente dados do ticket Kerberos. Em conjunto com o parâmetro “export” é possível extrair todos os tíquetes Kerberos da memória e salvá-los como arquivos .kirbi. normalmente estes arquivos ficam na mesma pasta onde o arquivo executável Mimikatz está.

Olhando o Mimikatz abaixo é possível ver que conseguimos obter o ticket da conta COMPANY\John Wick:

PS> mimikatz.exe "privilege::debug" "sekurlsa::tickets /export"

A segunda linha de comando a ser usado é para localizar a conta alvo embusca do Ticket Kerberos

No caso em questão, dir | findet “John Wick” | findstr “krbtgt”, lista todos os arquivos no diretório atual e canaliza a saída (usando pipe “|”) para o comando findstr para procurar o texto “krbtgt”.

O propósito deste comando é encontrar o(s) arquivo(s) de tíquete Kerberos relacionado(s) ao usuário “Jhon Wick”, que pode incluir a string “krbtgt” no nome do arquivo.

PS> dir | findet "John Wick" | findstr "krbtgt"
...
[0;2e3c5de]-2-2-41e10000-John.Wick@krbtgt-DOMAIN.CORP.kirbi
...

IMPORTANTE: Mimikatz não é a única ferramenta para obter tickets Kerberos. O atacante pode usar, pore exemplo, o Rubeus para gerar tráfego AS-REQ bruto (RFC-4120 – Kerberos v5) para solicitar um TGT com um nome de usuário e senha fornecidos. A vantagem desse ataque é que a senha fornecida ao Rubeus pode ser criptografada em algoritmos RC4, DES e AES, e o ataque ainda funcionaria.

Passo 2: Reutilizando o Ticket roubado

Este é o passo principal do ataque Pass-the-Ticket. Neste passo, o atacante emprega o comando kerberos com a função ptt para inserir o TGT obtido, assumindo então a identidade e as permissões do TGT roubado para acesso futuro a recursos sem conhecer as credenciais de texto simples. Com isso, o atacante utiliza recursos que, de outra forma, seriam protegidos pela autenticação Kerberos.

PS> mimikatz.exe "kerberos::ptt
E:\KRB-TGT\[0;2e3c5de]-2-2-41e10000-John.Wick@krbtgt-DOMAIN.CORP.kirbi"
* File:
'E:\KRB-TGT\[0;2e3c5de]-2-2-41e10000-Winston.Scott@krbtgt-DOMAIN.CORP.kirbi': OK

Observe que o comando acima é usado para inserir o Kerberos Ticket Granting Ticket (TGT) armazenado no arquivo .kirbi (TGT do John Wick) correspondente na sessão atual (Sessão atual é a do usuário Winston.Scott.

Para validar que a personificação foi bem sucedida, usa-se o comando kerberos com a função list.

PS> mimikatz.exe "kerberos::list"
[00000000] - 0x00000012 - aes256_hmac
 Start/End/MaxRenew: 13/01/2022 09:47:44 ; 13/01/2022 09:47:44 ; 13/01/2022 09:47:44
 Server Name : krbtgt/DOMAIN.CORP @ DOMAIN.CORP
 Client Name : John.Wick @ DOMAIN.COM
 Flags 41e10000 : name_canonicalize ; pre_authent ; initial ; renewable ; forwardable ;

Dados como início, fim e renovação do TGT serão mostrados, assim como o algoritmo de criptografia simétrica usada para criptografar o TGT (no caso em questão foi o AES 256).

IMPORTTANTE: Tenha em mente que o TGT expira após um certo período de tempo (guarde bem isso). Quando esse prazo acaba, o usuário precisará se autenticar novamente no domínio para obter um novo TGT.

Passo 3: Descobrindo o nível de privilégio do TGT roubado

Com TGT roubado e validado, o atacante precisa identificar o nível de privilégio da conta, ou seja, de forma a entender onde ele pode ser utilizado. Um TGS só pode fornecer acesso ao recurso específico para o qual foi emitido, e o atacante pode descobrir essa informação examinando o TGS.
Para usar um TGT, o atacante pode ter que executar uma fase de descoberta interna para descobrir o acesso que ele concede. Isso pode ser tão simples quanto verificar as associações de grupo do usuário e procurar por sinais claros.

Várias ferramentas podem ser empregadas para reunir informações sobre o Active Directory. No entanto, o atacante também pode usar comandos internos como “net” para reunir essas informações sem alertar os controles de segurança.

PS> net user John.Wick /domain
The request will be processed at a domain controller for domain domain.corp.
User name John
Full Name John Wick
Comment
User's comment
Country/region code 800 (System Default)
Account active Yes
Account expires Never
. . .
Local Group Memberships
Global Group memberships *File-Server-Admin *Internet-Access-Level05 *VPN *Join_Domain_Computers *Domain Users
The command completed successfully.

Passo 4: Acessando recursos com o TGT roubado

No último passo, o atacante pode empregar comandos do SO para se mover lateralmente de forma não detectável, para que possa tentar obter acesso a outros recursos. Por exemplo, o atacante pode aproveitar o utilitário de linha de comando PsExec para executar o powershell.exe em uma estação de trabalho remota.

5. Métodos de detecção para o ataque Pass-the-Hash

Abaixo, IDs de eventos conhecidos são adicionados para detectar um possível ataque Pass-the-Ticket

Event ID 4768 – A Kerberos Authentication Ticket (TGT) was requested.
Campos de descrição chave: Account Name, Service Name (sempre “krbtgt”), Service ID, Client Address

Event ID 4769 – A Kerberos Service Ticket was requested.
Campos de descrição chave: Account Name, Service Name, Client Address

Event ID 4770 – A Kerberos Service Ticket was renewed.
Campos de descrição chave: Account Name, User ID, Service Name, Service ID

🔍 Sinais de alerta nos logs:

• Eventos 4769 sem um correspondente 4768
  • Indica que um ticket de serviço foi usado sem um TGT recente, o que pode sugerir um Pass-the-Ticket Attack.
• Eventos 4769 com contas de alto privilégio inesperadas
  • Se uma conta de usuário comum está solicitando tickets de serviço para recursos administrativos, isso pode ser um sinal de escalonamento de privilégios.
• Eventos 4770 em excesso
  • Se há um número incomum de renovações de TGT, pode indicar que um atacante está mantendo persistência usando tickets roubados.
• Eventos 4624 (logons) sem um 4768 correspondente
  • Usuário se autenticando sem um novo TGT pode indicar uso de um ticket comprometido.
• Eventos 4768 ou 4769 oriundos de estações suspeitas
  • Se tickets Kerberos estão sendo emitidos para um dispositivo que normalmente não faz solicitações, pode ser uma evidência de movimentação lateral.

6. Técnicas de mitigação para o ataque Pass-the-Ticket

Para mitigar o risco de ataques pass-the-hash, as organizações podem empregar várias medidas:

6.1 Reduzir o tempo de vida dos tickets

Reduzir o tempo de vida dos tickets Kerberos é uma estratégia eficaz para dificultar ataques PtT, pois limita a janela de tempo disponível para um atacante reutilizar um ticket roubado. No entanto, essa medida deve ser aplicada com equilíbrio, pois uma configuração muito agressiva pode impactar negativamente a experiência dos usuários e a operação dos serviços.

Os valores padrão do Kerberos no Active Directory estão definidos em uma GPO padrão que se aplica aos Controladores de Domínio (Domain Controllers). Abaixo segue a configuração padrão. Aproveite e valide como está em seu ambiente.

• Ticket Granting Ticket (TGT): 10 horas
• Renovação máxima do TGT: 7 dias
• Ticket de Serviço (TGS): 10 horas

Para um ambiente com maior risco de ataques, recomenda-se* reduzir esses tempos:

• TGT: 4 a 6 horas
• Renovação máxima do TGT: 2 a 4 dias
• TGS: 4 a 6 horas

IMPORTANTE: A recomendação de redução do tempo de vida dos tickets Kerberos para ambientes de alto risco não se baseia em um único padrão, mas sim em práticas recomendadas de segurança estabelecidas por organizações especializadas em segurança cibernética, como as citadas abaixo. Agora em relação ao valor em horas e dias, os dados acima baseiam-se em um dos padrões abaixo.

Essa medida deve ser aplicada com equilíbrio, pois uma configuração muito agressiva pode impactar negativamente a experiência dos usuários e a operação dos serviços.

Organizações e padrões recomendados:

• NIST (National Institute of Standards and Technology)
  • O NIST Special Publication 800-63B – Digital Identity Guidelines enfatiza a necessidade de minimizar a exposição de credenciais e tokens de autenticação. Apesar de não definir um tempo exato para os tickets Kerberos, o documento recomenda:
  • Limitar a reutilização de credenciais temporárias
  • Usar credenciais de curta duração para minimizar o impacto de vazamentos
  • Essa diretriz está alinhada à redução do tempo de vida do TGT e TGS para reduzir o risco de ataques Pass-the-Ticket.
  • 📌 Referência: NIST SP 800-63B – Digital Identity Guidelines
• CIS (Center for Internet Security)
  • O CIS Microsoft Windows Server Security Benchmark sugere reduzir tempos de expiração de credenciais sempre que possível.
  • Evitar longos períodos de reutilização de tickets
  • Monitorar logs de autenticação Kerberos para detectar anomalias
  • A prática de reduzir o tempo do TGT para 4 a 6 horas e do TGS para 4 a 6 horas segue a recomendação do CIS de limitar o tempo de vida de autenticações reutilizáveis.
  • 📌 Referência: CIS Microsoft Windows Server Benchmark
• Microsoft Security Baselines
  • A Microsoft recomenda ajustes em tempos de vida de tickets em ambientes de alta segurança. No Microsoft Security Compliance Toolkit, há sugestões de:
  • Redução da vida útil dos tickets Kerberos em ambientes críticos
  • Habilitação de Kerberos FAST para proteger renovações de tickets
  • Os valores exatos não são prescritos, pois dependem do nível de risco e do impacto operacional, mas a Microsoft recomenda não manter os tempos padrão em redes que podem ser alvo de ataques avançados.
  • 📌 Referência: Microsoft Security Compliance Toolkit
• MIT Kerberos Documentation
  • O MIT Kerberos, que é a implementação de referência do Kerberos, recomenda tempos reduzidos para tickets em ambientes de risco elevado. O guia oficial do MIT sugere:
  • TGT: entre 2 e 8 horas
  • Renovação máxima: 1 a 7 dias
  • TGS: 1 a 8 horas
  • Esses valores são recomendados para reduzir a persistência de credenciais roubadas em ataques.
  • 📌 Referência: MIT Kerberos Documentation
• NSA (National Security Agency) – Hardening Guidance
  • A NSA publicou recomendações para segurança do Active Directory, indicando:
  • Tempo de vida curto para autenticações Kerberos
  • Monitoramento constante de renovações suspeitas
  • Uso de credenciais efêmeras sempre que possível
  • 📌 Referência: NSA Hardening Guidelines

6.1.1 Como Configurar o Tempo de Vida dos Tickets no Active Directory

A configuração dos tempos de vida dos tickets Kerberos é feita através de Políticas de Grupo (GPO) ou linha de comando no controlador de domínio.

Usando Group Policy (GPO)

Abra o Group Policy Management Console (gpmc.msc).

Edite a GPO aplicada aos Controladores de Domínio.

Vá para

Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy

Modifique as seguintes configurações:

Maximum lifetime for user ticket

Maximum lifetime for service ticket

Maximum lifetime for user ticket renewal

Reinicie os controladores de domínio para aplicar as mudanças.

Usando PowerShell

No Controlador de Domínio, execute:

Set-KerberosPolicy -MaxTicketAge 6:00:00 -MaxRenewAge 3.00:00:00 -MaxServiceAge 6:00:00

Os valores acima em horas e dias são de exemplo. Avalie sempre seu ambiente ates de qualquer mudança!

Para verificar as configurações aplicadas:

Get-KerberosPolicy

6.1.2 Considerações para Implementação

Antes de alterar os tempos de vida dos tickets, é essencial considerar:

• Impacto na experiência do usuário:
  Reduzir drasticamente o tempo de vida pode aumentar a frequência de renovações e causar desconforto para usuários que precisam autenticar-se frequentemente.
• Serviços que dependem de autenticação contínua:
  Alguns sistemas e aplicações utilizam tickets de serviço longos e podem falhar se os tickets expirarem muito rápido.
• Testes em ambiente de homologação:
  Antes de aplicar mudanças em produção, teste as novas configurações para garantir que não causem interrupções.

6.2 Monitorar logs do Kerberos

Para monitorar atividades suspeitas relacionadas ao Pass-the-Ticket (PtT) Attack, é necessário ativar a Auditoria Avançada de Segurança no Windows Server, especificamente para eventos relacionados ao Kerberos Authentication Service e Kerberos Service Ticket Operations.

6.2.1 Habilitando a Auditoria pelo Group Policy (GPO)

1. Abrir o Editor de Diretivas de Grupo
   No Controlador de Domínio, execute gpedit.msc ou gpmc.msc (caso utilize GPO para toda a organização).
2. Navegar até a configuração de auditoria
   • Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon
3. Ativar as categorias necessárias
   Para monitorar atividades Kerberos, habilite as seguintes políticas:
   • Audit Kerberos Authentication Service → Habilite Success and Failure
   • Audit Kerberos Service Ticket Operations → Habilite Success and Failure
4. Aplicar a política
   Após configurar a GPO, force sua aplicação executando:
   • gpupdate /force

6.3 Habilitar proteção contra credenciais

Ativar Windows Defender Credential Guard para evitar que tickets sejam armazenados em locais vulneráveis. O Windows Defender Credential Guard evita ataques tanto Pass-the-hash quanto Pass-the-Ticket. Ele, devido a sua importância será um tema abordado em um artigo específico.

6.4 Reiniciar máquinas regularmente

Lembra que falei que o TGT fica salvo na memória do computador/servidor? O cache de tickets Kerberos é apagado quando a máquina é reiniciada, o que pode interromper a persistência de um ataque.

Quando um usuário (inclusive uma conta privilegiada) faz logoff, o sistema operacional encerra a sessão interativa, mas não necessariamente apaga os tickets Kerberos associados à sessão. O comportamento varia conforme alguns fatores:

• Sessão Interativa (GUI ou RDP)
  • Se o usuário apenas faz logoff, o TGT associado à sessão não é mais utilizável para essa conta naquela máquina.
  • No entanto, se o atacante já extraiu o TGT antes do logoff, ele ainda pode utilizá-lo de outra máquina para realizar um ataque Pass-the-Ticket (PtT).
• Sessões Persistentes (Serviços e Agentes de Background)
  • Alguns serviços ou processos agendados executados com credenciais privilegiadas mantêm tickets Kerberos na memória, mesmo após um logoff do usuário.
  • Se um atacante já comprometeu o sistema e está executando um processo malicioso em segundo plano, um simples logoff não o removerá.
• Sessões RDP Desconectadas
  • Se um administrador apenas desconectar a sessão RDP sem fazer logoff, o TGT permanece válido e pode ser extraído por um atacante que tenha acesso ao sistema.

Diferente do logoff, um reboot força a limpeza total da memória e do cache de tickets Kerberos, incluindo:

✅ Todos os TGTs e TGSs armazenados na memória são apagados.
✅ Processos maliciosos que dependem de credenciais na memória são encerrados.
✅ Sessões persistentes que poderiam ser reutilizadas pelo atacante são eliminadas.

Isso torna a reinicialização uma medida mais eficaz do que apenas fazer logoff.

Existe Alguma Forma de Apagar o TGT Sem Reiniciar?

Sim! Se reiniciar um servidor crítico não for uma opção viável, você pode revogar e limpar manualmente os tickets Kerberos. Algumas formas de fazer isso:

Limpando os Tickets Kerberos Manualmente (Sem Logoff/Reboot)

O usuário pode executar o seguinte comando para remover manualmente todos os tickets armazenados:

klist purge

Isso faz com que qualquer ticket ativo no cache do sistema seja apagado.

📌 Observação: Esse método só funciona para a sessão ativa do usuário. Se um atacante já extraiu um ticket e está utilizando-o em outra máquina, esse comando não terá efeito sobre o ataque.

Revogando Sessões e Tickets de Forma Centralizada

Se houver suspeita de um ataque ativo, um administrador pode forçar a invalidação de TGTs e sessões usando as seguintes abordagens:

🛑 1. Reduzir o Tempo de Vida do TGT no Active Directory

Se um ataque for detectado, diminuir temporariamente o tempo de vida dos TGTs pode limitar a eficácia de um Pass-the-Ticket Attack:

Set-KerberosPolicy -MaxTicketAge 2:00:00

Isso faz com que todos os tickets expirem mais rapidamente.

🛑 2. Revogar TGTs Específicos

Se uma conta comprometida for identificada, o TGT pode ser revogado com:

klist -li 0x3e7 purge

Isso forçará a conta a obter um novo ticket.

🛑 3. Reiniciar o Serviço de Logon Kerberos

Se reiniciar o sistema não for uma opção, reiniciar o serviço Kerberos pode limpar caches sem um reboot:

Restart-Service kdc

Isso invalida os tickets ativos e obriga os usuários a se autenticarem novamente.

O Que é Mais Eficiente?

Método	Remove TGT da Memória?	Elimina Sessões Persistentes?	Mitiga Pass-the-Ticket?	Impacto Operacional
Logoff	✅ Sim (para sessão ativa)	❌ Não (se houver processos rodando)	❌ Não (se um atacante já roubou o TGT)	Baixo
klist purge	✅ Sim (para usuário específico)	❌ Não (se houver serviços ativos)	❌ Não (se o TGT já foi roubado)	Baixo
Reinício do Serviço Kerberos	✅ Sim	✅ Sim (obriga todos a refazer login)	🔶 Parcialmente (não revoga TGTs já exportados)	Médio
Reinicialização do Sistema	✅ Sim (zera tudo)	✅ Sim	✅ Sim	Alto

🔹 Melhor Estratégia

• Se possível, reiniciar o servidor ou workstation regularmente para eliminar qualquer ticket armazenado na memória.
• Se um ataque for detectado, executar klist purge e reduzir a validade dos TGTs temporariamente.
• Se houver suspeita de comprometimento grave, revogar os tickets e resetar a senha da conta comprometida.

Reiniciar o ativo é a melhor defesa contra persistência, mas quando isso não for viável, há alternativas que podem ajudar a reduzir o risco.

6.5 Aplicar o princípio do privilégio mínimo

Limitar os privilégios das contas de usuários e administradores para reduzir o impacto de um ataque.

6.6 Usar autenticação multifator (MFA)

Implementar MFA pode impedir que o invasor acesse recursos críticos apenas com um ticket.