Nas auditorias de Active Directory, o Kerberoasting está entre os ataques verificados sistematicamente, tamanha a eficácia, a rapidez e a discrição dessa técnica. Em poucos segundos, uma simples conta de usuário sem nenhum privilégio pode obter material suficiente para quebrar, offline e sem ruído, as senhas de contas por vezes muito poderosas. Este artigo detalha seu funcionamento, por que ela tem sucesso com tanta frequência e, sobretudo, como se proteger.
Um pouco de Kerberos e de SPN
Em um domínio Windows, a autenticação se baseia no Kerberos, um protocolo fundamentado em tickets emitidos pelo controlador de domínio. O princípio remonta aos anos 1980 (o projeto Athena do MIT), e a Microsoft o adotou como mecanismo de autenticação padrão desde o Windows 2000. Cada serviço acessível via Kerberos é identificado por um SPN, sigla de Service Principal Name, um rótulo do tipo MSSQLSvc/serveur.entreprise.local:1433 que vincula um serviço (um banco SQL, um servidor web, um compartilhamento) a uma conta de serviço no diretório.
Vale lembrar que uma conta de serviço é uma conta de usuário dedicada a executar uma aplicação. Ela costuma ter permissões elevadas e sua senha raramente é alterada, pois modificá-la pode interromper a aplicação que depende dela. É um segredo que envelhece mal.
Por que as contas de serviço atraem tanto os atacantes
Essas contas concentram todos os defeitos que um atacante procura. Foram criadas há muito tempo, muitas vezes durante a instalação de um software, com uma senha escolhida manualmente por um administrador apressado. Essa senha geralmente nunca expira, pois uma expiração significaria uma pane na aplicação. E, para completar, essas contas frequentemente acabam como membros de grupos altamente privilegiados, às vezes Admins. do Domínio, “só até a aplicação funcionar”, e depois ninguém se lembra de desfazer a alteração. Um atacante sabe disso e mira prioritariamente esses SPN.
O mecanismo do ataque
O ponto-chave cabe em uma frase: qualquer usuário autenticado do domínio pode solicitar um ticket de serviço (um TGS, de Ticket-Granting Service) para qualquer SPN. É um funcionamento perfeitamente normal do Kerberos, não uma falha. Ocorre que parte desse ticket é cifrada com uma chave derivada diretamente da senha da conta de serviço. Ao obter o ticket, obtém-se portanto uma amostra cifrada que poderá ser atacada com toda a calma.
O atacante enumera os SPN do diretório, solicita os tickets correspondentes e depois os extrai. Com o GetUserSPNs.py, da suíte Impacket, um único comando basta a partir do Linux:
GetUserSPNs.py entreprise.local/utilisateur:MotDePasse -request -outputfile tickets.txtNo Windows, a ferramenta Rubeus faz o mesmo a partir de uma estação já comprometida, e sabe mirar as contas mais interessantes:
Rubeus.exe kerberoast /outfile:tickets.txtPonto crucial: em nenhum momento o atacante precisa escrever no controlador de domínio nem testar senhas contra ele. Toda a quebra é feita depois em sua própria máquina, offline. Não há, portanto, nem conta bloqueada, nem pico de falhas de autenticação visível nos logs.
A quebra offline
Uma vez recuperados os tickets, o atacante os submete a uma ferramenta de quebra como o hashcat. O formato Kerberos TGS corresponde ao modo 13100:
hashcat -m 13100 tickets.txt dictionnaire.txt -r regles.ruleO parâmetro -r aplica um conjunto de regras que reproduz os hábitos humanos: maiúscula inicial, número no final, substituições clássicas. Contra uma senha fraca do tipo Serveur2021, o resultado sai em poucos segundos em um simples notebook equipado com uma placa de vídeo. E é aí que está todo o problema:
- as contas de serviço costumam ter senhas curtas, escolhidas por um humano há anos;
- elas quase nunca são renovadas;
- elas acumulam privilégios elevados, às vezes até a administração completa do domínio.
Uma única senha fraca quebrada, e o atacante herda diretamente as permissões da conta, sem exploit nem escalonamento de privilégios adicional. É um atalho espetacular entre “sou um usuário qualquer” e “controlo o diretório”.
RC4, o combustível discreto do ataque
Um detalhe técnico muitas vezes agrava a situação: por compatibilidade, muitos tickets ainda são cifrados com o algoritmo RC4, derivado do hash NTLM da senha. Ora, o RC4 se presta particularmente bem à quebra em massa. Ao forçar o uso de AES para as contas de serviço, a quebra se torna bem mais custosa. As ferramentas de ataque sabem disso: o Rubeus, por exemplo, solicita de bom grado tickets em RC4 quando estão disponíveis, justamente porque são mais fáceis de processar.
O que o trabalho de campo revela
Em uma missão típica, a enumeração retorna regularmente várias dezenas de SPN. Basta que um único corresponda a uma conta com senha antiga para abrir uma brecha. As contas de backup, de monitoramento ou de banco de dados aparecem com frequência, muitas vezes dotadas de privilégios elevados e protegidas por uma senha que retoma o nome do fornecedor do software seguido de um ano. O impacto para o negócio é imediato: quem controla uma conta assim controla a autenticação de toda a empresa. A BOX Oxyscan identifica justamente essas contas de serviço expostas ao Kerberoasting em todo o diretório, o que permite corrigi-las antes que um atacante as encontre.
Corrigir a falha: migrar para contas de serviço gerenciadas
Como o Kerberoasting não explora um defeito de software, mas a fraqueza de uma senha, a correção consiste em tornar essa senha impossível de quebrar. As contas de serviço gerenciadas de grupo (gMSA, de group Managed Service Accounts) atendem exatamente a essa necessidade: sua senha é gerada aleatoriamente pelo domínio, ocupa 240 bytes e é renovada automaticamente, sem nenhuma intervenção humana. Um atacante que recupere um ticket cifrado com um segredo desses pode dedicar a ele todas as placas de vídeo que quiser, não vai encontrá-lo.
Vale lembrar que esse já é o comportamento das contas de máquina (aquelas cujo nome termina com $): sua senha é aleatória e muito longa, o que as torna imunes ao Kerberoasting. O gMSA simplesmente estende esse princípio às contas que executam os serviços de aplicação.
A implementação se resume a três comandos PowerShell, no controlador de domínio. Primeiro, gera-se, uma única vez para todo o domínio, a chave raiz do serviço de distribuição de chaves (KDS):
Add-KdsRootKey -EffectiveImmediatelyApesar do nome, a opção -EffectiveImmediately só torna a chave utilizável após sua replicação em todos os controladores de domínio, com um prazo de segurança que pode chegar a dez horas. Esse prazo deve ser respeitado em produção. Em seguida, cria-se a conta gerenciada, indicando seu nome DNS e o host ou os hosts autorizados a recuperar sua senha:
New-ADServiceAccount -Name sql-service -DNSHostName sql-service.exemple.local -PrincipalsAllowedToRetrieveManagedPassword "GRP-SRV-SQL$"Depois, instala-se a conta na máquina que executará o serviço:
Install-ADServiceAccount sql-serviceResta apenas designar essa conta como identidade do serviço. No gerenciador do servidor, informa-se a conta gerenciada, reconhecível pelo sufixo $, como conta personalizada, aqui para a identidade de um pool de aplicativos do IIS:
Nem todos os softwares já sabem funcionar com um gMSA. Para esses casos residuais, a regra é dupla: uma senha de pelo menos vinte e cinco caracteres, gerada aleatoriamente e guardada em um cofre, e o respeito estrito ao menor privilégio, pois uma conta de serviço quase nunca precisa pertencer aos administradores do domínio. Além disso, força-se a criptografia AES dos tickets, muito mais custosa de quebrar do que o RC4 herdado, e monitoram-se as solicitações anormalmente numerosas de tickets de serviço, muitas vezes o primeiro sinal de uma campanha de Kerberoasting em andamento.
Conclusão
O Kerberoasting não explora um bug: explora uma senha ruim definida em uma conta poderosa demais. Por isso ele figura entre as técnicas mais rentáveis para um atacante interno, e entre as mais fáceis de negligenciar do lado da defesa. A boa notícia é que as contramedidas são conhecidas, documentadas (em especial pelo MITRE e pela ANSSI) e eficazes.
Recomendações: atribuir às contas de serviço senhas muito longas (25 caracteres ou mais) ou, melhor ainda, migrar para contas de serviço gerenciadas de grupo (gMSA), cuja senha é renovada automaticamente pelo domínio; aplicar o princípio do menor privilégio (nenhuma conta de serviço deveria ser administradora do domínio sem uma justificativa sólida), forçar a criptografia AES em vez de RC4 e monitorar as solicitações em massa de tickets TGS, muitas vezes o primeiro sinal de um ataque em andamento.
Para saber mais
- Consultoria e acompanhamento em cibersegurança Oxydian, para implementar o hardening de um diretório (gMSA, criptografia AES, menor privilégio).
- Por que as senhas corporativas caem em auditoria, o artigo dedicado à quebra offline e à higiene dos segredos.
- MITRE ATT&CK, técnica T1558.003 (Kerberoasting), descrição, detecção e medidas de mitigação.
- ANSSI, recomendações de segurança para um diretório Active Directory.
- Microsoft Learn, visão geral das contas de serviço gerenciadas de grupo (gMSA).
- hashcat, a ferramenta de referência para a quebra offline (modo 13100 para os tickets Kerberos).
- Suíte Impacket (GetUserSPNs.py), o conjunto de ferramentas open source usado para a coleta dos tickets.
