ACTIVE DIRECTORY SECURITY – GOLDEN TICKET ATTACK

Um ataque de Golden Ticket está entre as técnicas de invasão mais perigosas: pode causar danos graves em ambientes Windows Active Directory, permanecer indetectável e garantir persistência por anos.

Este artigo cobre o essencial sobre golden tickets, seu funcionamento, por que são tão perigosos e como são explorados com ferramentas reais como Mimikatz, Rubeus e Kekeo.

Ao final você entenderá por que são tão difíceis de detectar e mitigar.

O que é um ataque de golden ticket do Kerberos?

Um Golden Ticket é uma credencial Kerberos forjada que permite ao atacante se autenticar como qualquer usuário de domínio (incluindo Domain Admin) por tempo arbitrário. É uma ameaça de alto impacto porque, depois de obtida, permite acesso irrestrito aos recursos do domínio. A defesa exige detecção focada, redução do risco de comprometimento do KRBTGT e práticas rígidas de gestão de privilégios.

A mecânica de um ataque Golden Ticket

Para entender a mecânica de um ataque de golden ticket, você precisa de um conhecimento básico de como a autenticação Kerberos funciona em ambientes modernos do Active Directory. 

Kerberos é um sistema de autenticação baseado em tickets que depende da passagem de tickets entre um Centro de Distribuição de Chaves (KDC), usuários e recursos de rede. 

O KDC geralmente é o Controlador de Domínio (DC) do ambiente do Active Directory, e os recursos de rede são servidores que a estação de trabalho do usuário precisa acessar.

Em uma interação típica de autenticação Kerberos, acontece o seguinte:

1. Um usuário enviará uma solicitação ao KDC para autenticação no domínio do Active Directory para uma sessão. Isso inclui um Ticket Granting Ticket (TGT) responsável por emitir os tickets de acesso aos serviços solicitados pelo usuário. 
2. O KDC verifica a identidade do usuário e responde com um TGT criptografado e uma chave de sessão. O TGT é criptografado usando a chave secreta do KDC (KRBTGT).
3. O usuário então solicita um tíquete de serviço, conhecido como tíquete de concessão de tíquete (TGS), sempre que deseja acessar um recurso de rede.
4. O KDC verifica os direitos de acesso do usuário e responde com um TGS criptografado com a chave de sessão do usuário.
5. Os usuários usam este TGS para se autenticar em um serviço e acessar o recurso de rede.
6. O serviço verifica o TGT e permite que o usuário interaja com o recurso de rede.

Agora que você sabe o que é um ataque de Golden Ticket, vamos ver como executá-lo!

Como realizar um ataque Golden Ticket

As demonstrações a seguir mostram como executar este ataque usando Mimikatz, Rubeus e Kekeo. Para acompanhar, você precisa atender aos seguintes requisitos.

Requisitos:

• O hash da senha da conta KRBTGT : você pode fazer isso usando uma das técnicas de ataque discutidas anteriormente, como despejar credenciais do Controlador de Domínio ou executar um ataque DCSync (demonstraremos isso abaixo).
• Desative o Microsoft Defender na máquina de destino para garantir que você possa executar suas ferramentas de hacking.

Depois de atender a esses requisitos, você estará pronto para começar!

Executando um ataque DCSync 

Antes de executar o ataque, você precisa ter o hash da senha da conta KRBTGT. Ele é usado para criptografar cada TGT pelo KDC e lhe dá acesso total ao ambiente do Active Directory de destino. 

Para extrair esse hash, você pode explorar o protocolo DRS do Active Directory por meio de um ataque DCSync usando uma ferramenta como o Mimikatz. 

Primeiro, você precisa ter acesso a uma conta do Active Directory no domainadmins grupo. Esse grupo de usuários privilegiados pode usar o protocolo DRS para solicitar dados de senha dos Controladores de Domínio. 

Usando esse acesso, você pode carregar o Mimikatz e executar o comando lsadump::dcsync /domain:<domain> /user:krbtgt. Basta substituir <domain>pelo nome de domínio do Active Directory que você está almejando.

Conceber tíquetes Kerberos

Com o hash do krbtgt em mãos, é possível conceder um Golden Ticket que o Kerberos reconhece como válido mesmo para um usuário inexistente, já que o hash krbtgt é sua raiz de confiança.

Abrindo o mimikatz em uma máquina Cliente.

Acima e abaixo, prints da máquina cliente com Windows 10, ingressada no domínio, logada com um usuário padrão, sem privilégios administrativos.

Pass the Ticket

Depois de abrir o mimikatz, criaremos e atribuiremos um Golden Ticket para um usuário hipotético, como o Kerberos confia no hash da conta krbtgt, o tíquete é aceito como válido.

kerberos::golden /domain:graymattertechnologies /sid:S-1-5-21-4244774991-4045775761-2758505370 /user:pinkman /krbtgt:e074415ceadab3edbbda32b901d981ed /ptt

Uma vez criado, o Golden Ticket pode ser carregado na sessão atual por meio do Mimikatz.

Acima, claramente, mostra que foi concedido poderes administrativos para o “usuário pinkman”, repare o userID: 500.

Digite o comando misc::cmd para abrir uma nova sessão com o Golden Ticket.

O comando klist serve para exibir o conteúdo cache de credenciais Kerberos, permitindo que administradores visualizem e gerenciem os tickets de autenticação de um sistema.

Na sessão atual, pinkman já está munido do Golden Ticket, executei o comando pushd \\nomedoservidor\c$ para o gran finale!

Pronto, estamos no servidor, com direitos administrativos!

Mitigações e boas práticas

• Princípio do menor privilégio: minimize contas com direitos de administração de domínio. Separe ambientes e contas administrativas (tiered admin model).
• Amarre contas privilegiadas a hosts dedicados (administrative workstations).
• Desative contas privilegiadas desnecessárias e monitore contas de serviço.

Proteção da conta KRBTGT

• Rotação da senha da conta KRBTGT: em caso de suspeita de comprometimento, altere a senha da conta KRBTGT duas vezes com intervalo apropriado para garantir que chaves antigas não continuam válidas (procedimento operacional e comunicação preventiva necessários).
• Restrinja quem pode ler atributos sensíveis no AD, limite permissão de leitura de atributos e hashes.

Monitoramento e detecção

• Logs de autenticação Kerberos centralizados no SIEM com correlações específicas (ex.: lifetimes anormais, tickets emitidos para contas inativas).
• Detecção de credential dumping nos endpoints (EDR/antimalware com regras atualizadas).
• Alertas para alterações de senha do KRBTGT e atividades administrativas incomuns.
• Integração com soluções especializadas (ex.: Microsoft Defender for Identity, serviços de monitoramento de AD) para detecção de anomalias Kerberos.
  

Referências

https://attack.mitre.org/techniques/T1558/001
https://attack.mitre.org/mitigations/M1015
https://docs.microsoft.com/pt-br/windows-server/security/windows-authentication/windows-authentication-overview

Até a próxima!