Kerberoasting e Ataques Golden Ticket

Para compreender os ataques Kerberoasting e Golden Ticket, é necessário ter uma visão clara da emissão de tickets de serviço do Kerberos. Quando um cliente deseja acessar um serviço (por exemplo, um servidor SQL), ele apresenta seu Ticket Granting Ticket (TGT) ao Ticket Granting Service (TGS) do controlador de domínio. O TGS emite um Service Ticket criptografado com o hash da senha da conta de serviço. O cliente apresenta esse ticket ao serviço, que o descriptografa com seu próprio hash para verificar sua autenticidade. Isso significa que os tickets de serviço são criptografados com a credencial do serviço-alvo — um detalhe fundamental explorado pelo Kerberoasting.

Kerberoasting é um ataque que explora o fato de que qualquer usuário de domínio autenticado pode solicitar um ticket de serviço Kerberos para qualquer serviço registrado com um SPN (Service Principal Name). O invasor solicita tickets de serviço para contas com SPNs, captura os blocos de dados criptografados dos tickets e tenta quebrar a senha da conta de serviço offline — sem qualquer interação adicional com o Active Directory e sem risco de bloqueio da conta. As contas de serviço frequentemente têm senhas fracas, senhas antigas definidas antes dos requisitos modernos de complexidade ou senhas que nunca expiram, o que as torna altamente vulneráveis à quebra offline.

Os hashes dos tickets de serviço capturados pelo Kerberoasting são criptografados por padrão com RC4-HMAC (hash NTLM) (por motivos de compatibilidade), que é mais rápido de quebrar do que tickets Kerberos AES-256. O invasor fornece os hashes $krb5tgs$23$ capturados ao Hashcat ou ao John the Ripper para realizar ataques offline de dicionário e força bruta. Listas de palavras comuns, como RockYou, combinadas com conjuntos de regras, podem quebrar a maioria das senhas fracas de contas de serviço em minutos ou horas usando hardware de GPU para consumidores. Depois de quebrada a senha, o invasor obtém a senha em texto simples da conta de serviço, que pode ser usada para autenticar-se diretamente.

As medidas de mitigação contra Kerberoasting abrangem três áreas: força da senha — as contas de serviço devem ter senhas longas e aleatórias (25 ou mais caracteres), resistentes à quebra offline mesmo com clusters de GPU; Group Managed Service Accounts (gMSA) — o Windows gerencia automaticamente as senhas de gMSA (valores aleatórios de 240 caracteres, alternados a cada 30 dias), tornando o Kerberoasting inviável do ponto de vista computacional; criptografia somente AES — configure as contas de serviço para exigir tickets AES-256 (msDS-SupportedEncryptionTypes), cuja quebra é exponencialmente mais lenta que a de RC4; e detecção — gere alertas para volumes incomuns de solicitações TGS (Event ID 4769) para contas de serviço provenientes de estações de trabalho não padrão.

A conta KRBTGT é uma conta especial integrada do Active Directory cuja hash de senha é usada para assinar e criptografar todos os TGTs do Kerberos no domínio. O controlador de domínio usa o hash KRBTGT para criar TGTs e validar TGTs recebidos. Isso torna o hash KRBTGT a credencial mais valiosa de um ambiente Active Directory — quem a possuir poderá criar tickets Kerberos arbitrários e totalmente válidos para qualquer usuário, inclusive usuários inexistentes, com qualquer associação a grupos e por qualquer duração. A senha KRBTGT normalmente nunca foi alterada em muitas organizações, pois o processo de alteração exige uma coordenação cuidadosa.

Um ataque Golden Ticket cria um TGT Kerberos falsificado e totalmente válido usando o hash da senha da conta KRBTGT comprometida. O invasor usa o comando kerberos::golden do Mimikatz para gerar um TGT para qualquer usuário (geralmente uma conta falsa semelhante à de Administrador), com qualquer associação a grupos (normalmente incluindo Domain Admins) e qualquer período de validade (comumente definido como 10 anos). Esse ticket falsificado é indistinguível de um ticket legítimo para o controlador de domínio, pois é criptograficamente válido — foi assinado com o hash KRBTGT real. Um Golden Ticket proporciona controle completo, persistente e ilimitado sobre o domínio.

Os Golden Tickets são particularmente perigosos porque continuam válidos mesmo depois que o ataque original é descoberto e eliminado. Alterar a senha do usuário-alvo não adianta — o ticket foi falsificado, não foi baseado nas credenciais reais do usuário. A única medida de correção é alterar a senha KRBTGT duas vezes (uma vez para invalidar os tickets existentes e outra porque há duas chaves KRBTGT a qualquer momento para fins de alternância). No entanto, as alterações da senha KRBTGT exigem uma coordenação cuidadosa: se forem feitas de maneira incorreta, elas interromperão a autenticação Kerberos em todo o domínio. Muitas organizações relutam em realizar essa correção, deixando os Golden Tickets válidos indefinidamente.

Um Silver Ticket é semelhante a um Golden Ticket, mas tem escopo mais limitado. Ele usa o hash da conta do serviço-alvo (em vez do KRBTGT) para falsificar um ticket de serviço somente para esse serviço específico. Por exemplo, com o hash da conta de serviço de um servidor SQL, o invasor pode falsificar um ticket de serviço que lhe conceda qualquer acesso a esse servidor SQL. Os Silver Tickets são mais difíceis de detectar do que os Golden Tickets porque ignoram completamente o controlador de domínio — o ticket falsificado vai diretamente do invasor para o serviço, sem contato com o KDC. A mitigação exige proteger os hashes das contas de serviço e monitorar padrões de acesso anômalos em serviços sensíveis.

Os invasores obtêm o hash KRBTGT usando o ataque DCSync, que abusa do protocolo legítimo de replicação de domínio do Active Directory. O Directory Replication Service (DRS) permite que os controladores de domínio sincronizem dados do AD, incluindo hashes de senhas, entre si. Um invasor com privilégios DCSync (normalmente Domain Admin, Enterprise Admin ou qualquer conta com permissões Replicating Directory Changes All) pode personificar um controlador de domínio e solicitar a replicação do hash de qualquer conta. O comando lsadump::dcsync do Mimikatz realiza esse ataque inteiramente pela rede — nenhum código precisa ser executado no próprio DC.

Detectar o uso de Golden Tickets é difícil, mas possível, observando anomalias nos metadados dos tickets Kerberos: tickets com períodos de validade excepcionalmente longos (tickets reais têm um período de validade de TGT de 10 horas; Golden Tickets geralmente são configurados para 10 anos); Event ID 4769 em que o tipo de criptografia do ticket é RC4 (0x17), quando AES-256 (0x12) é o padrão do domínio; nomes de contas nos tickets que não existem no AD; e ausência do Event ID 4768 (solicitação de TGT) antes do Event ID 4769 (solicitação de ticket de serviço) — Golden Tickets ignoram a fase de solicitação do TGT, pois o próprio TGT é falsificado. Uma regra do Microsoft Sentinel ou do Defender for Identity pode sinalizar esses padrões automaticamente.

Uma defesa em camadas contra ataques Kerberos inclui: usar gMSA para todas as contas de serviço, tornando o Kerberoasting inviável; habilitar criptografia somente AES para todas as contas, especialmente as contas de serviço de alto valor, para maximizar a dificuldade de quebra; restringir os privilégios DCSync — auditar as contas com permissões de replicação e remover as que não deveriam tê-las; habilitar o Microsoft Defender for Identity (anteriormente ATA), que fornece detecção de ameaças com reconhecimento de Kerberos, incluindo alertas em tempo real para Golden Ticket, Kerberoasting e DCSync; e implementar um modelo de administração em camadas para que, mesmo se uma conta da Camada 2 for comprometida, ela não possa ser usada para alcançar credenciais no nível do DC.

Teste sua compreensão dos conceitos do CompTIA Security+ (SY0-701) apresentados nesta lição.

Nesta lição, você aprendeu: Kerberoasting solicita tickets de serviço para contas registradas em SPNs e os quebra offline — sendo combatido por gMSA, senhas fortes e criptografia somente AES; os ataques Golden Ticket usam o hash KRBTGT para falsificar TGTs ilimitados, fornecendo controle persistente do domínio até que a senha KRBTGT seja redefinida duas vezes; e os ataques DCSync replicam o hash KRBTGT pela rede sem executar código no DC — exigindo uma auditoria rigorosa dos privilégios DCSync. A seguir, exploraremos a estrutura MITRE ATT&CK para mapear técnicas de invasores a defesas.