Deteccao prevencao kerberoasting começa com um fato simples: qualquer principal autenticado do Active Directory que possua um TGT válido pode solicitar tickets de serviço para SPNs, e alguns desses tickets ainda podem ser quebrados offline se a conta de serviço alvo for fraca o suficiente. A parte difícil não é entender o nome do ataque. A parte difícil é provar quais contas ligadas a SPN continuam realisticamente exploráveis no domínio, qual telemetria realmente ajuda e quais ações de remediação reduzem o risco de forma mensurável sem quebrar a produção.
O que é Kerberoasting?
Kerberoasting é o abuso do mecanismo de emissão de tickets de serviço Kerberos para obter material de ticket que depois pode ser quebrado offline contra o segredo de uma conta de serviço. A MITRE cataloga esse comportamento em T1558.003 Kerberoasting.
No Active Directory, o Kerberos usa Service Principal Names (SPNs) para associar uma instância de serviço à conta que executa esse serviço. A Microsoft documenta SPNs como o identificador que o Kerberos usa para localizar o principal alvo de um serviço. Quando um cliente solicita um ticket de serviço Kerberos para esse SPN, o ticket é gerado para a conta de serviço que o possui.
Isso não significa que toda conta com SPN tenha o mesmo nível de risco. A exposição real depende de quatro fatores:
- se a conta depende de uma senha gerida manualmente por um usuário ou de uma identidade de serviço melhor gerida;
- se o segredo da conta é antigo, previsível ou nunca foi rotacionado;
- quais tipos de criptografia Kerberos estão realmente sendo usados para emitir tickets;
- quais acessos a conta abre se suas credenciais forem recuperadas.
É por isso que Kerberoasting não é apenas um problema de Kerberos. Também é um problema de higiene de contas de serviço, de política de criptografia e, muitas vezes, de governança de privilégios.
Por que Kerberoasting ainda importa no Active Directory
Kerberoasting continua relevante porque muitos domínios ainda carregam uma longa cauda de contas de serviço legacy:
- contas de serviço apoiadas em usuários criadas há anos;
- contas com
PasswordNeverExpires; - contas cuja senha foi definida uma vez e depois esquecida;
- contas que ainda dependem de
RC4por compatibilidade; - contas que acumularam com o tempo privilégios de admin local, backup, SQL, orquestração ou direitos delegados.
Essa combinação é o que torna a técnica prática. O caminho da requisição Kerberos é legítimo. O cracking offline acontece fora do domínio. O raio de impacto depende do que essa conta de serviço permite fazer depois.
Isso também explica por que a segurança de senhas no Active Directory e as contas obsoletas e superprivilegiadas no AD importam tanto aqui. Um ticket de serviço não é o objetivo final. O objetivo é recuperar uma credencial que abra um caminho de privilégio maior.
Pré-condições para uma exposição Kerberoasting real
Uma finding de Kerberoasting merece alta prioridade quando a maioria dos pontos abaixo é verdadeira:
- a conta possui um ou mais SPNs registrados;
- a conta depende de uma senha gerida manualmente em vez de uma identidade de serviço gerida;
- a senha é antiga, raramente rotacionada ou está isenta de expiração;
RC4ainda é usado ou ainda é aceito onde tipos de criptografia mais fortes já deveriam estar presentes;- a conta tem valor real para movimento lateral ou elevação de privilégio;
- o ambiente não revisa rotineiramente o inventário de SPNs nem a ownership das contas de serviço.
A documentação da Microsoft sobre msDS-SupportedEncryptionTypes é diretamente relevante aqui. O KDC usa essa informação ao gerar um ticket de serviço para a conta. A guidance atual da Microsoft sobre Kerberos também afirma que RC4 é inseguro, está sendo retirado e deve ser auditado e remediado quando tipos de criptografia mais fortes estiverem disponíveis.
Essa é a diferença operacional entre um simples item de inventário e uma exposição Kerberoasting real. Uma conta de baixo valor com SPN, segredo longo, aleatório e rotacionado recentemente não é o mesmo problema que uma conta SQL ligada a usuário, ainda em RC4 e com acesso amplo a servidores.
Como o Kerberoasting funciona
A Microsoft documenta SPNs como a forma pela qual o Kerberos associa uma instância de serviço à conta que autentica aquele serviço. Na prática, isso significa que um principal de domínio com TGT válido pode solicitar um TGS para uma conta de serviço que possua um SPN.
A MITRE descreve Kerberoasting como a obtenção de um ticket TGS que pode ser vulnerável a força bruta. O ponto importante para defensores é que o cracking acontece offline. Depois que o material do ticket é coletado, o atacante não precisa mais de interação contínua com o domínio para testar hipóteses de senha.
Os pontos defensivos centrais são:
- o caminho da requisição é tráfego Kerberos legítimo;
- o ticket fica vinculado ao segredo da conta de serviço, e não a uma sessão interativa no host de destino;
- a explorabilidade real depende do tipo de criptografia e da força da senha;
- o impacto depende dos privilégios da conta de serviço após a recuperação da credencial.
A pergunta correta, portanto, não é “o Kerberoasting pode acontecer neste domínio?”. A pergunta correta é: “quais contas ligadas a SPN continuam quebráveis o suficiente para importar e o que elas abririam se fossem recuperadas?”
Deteccao prevencao kerberoasting: o que os defensores realmente devem revisar
A detecção de Kerberoasting deve ser construída como correlação, não como uma teoria baseada em um único evento.
Comece pelo Event ID 4769
A Microsoft documenta 4769 como o evento gerado quando o KDC emite um ticket de serviço Kerberos. Ele é registrado nos controladores de domínio. Para revisar Kerberoasting, costuma ser o evento nativo mais útil porque captura diretamente o caminho da requisição TGS.
O que observar:
- uma rajada de solicitações TGS a partir da mesma conta ou da mesma origem em curto intervalo;
- solicitações para muitos SPNs distintos que não combinam com o comportamento normal do solicitante;
TicketEncryptionType = 0x17somente quando RC4 já não deveria ser necessário naquele ambiente;- solicitações de SPN partindo de estações ou usuários que normalmente não interagem com esses serviços.
A guidance atual da Microsoft sobre remediação de RC4 recomenda explicitamente auditar o uso de RC4 nos eventos 4768 e 4769, e explica que RC4 está sendo descontinuado. Isso torna essa telemetria útil, mas somente em contexto. RC4 sozinho não prova Kerberoasting. Em alguns domínios, ainda aponta mais para um problema de compatibilidade do que para atividade hostil.
Use o Event ID 4768 como contexto de correlação
4768 documenta a emissão do TGT, e não a solicitação de ticket de serviço em que o Kerberoasting se apoia. Ele deve ser tratado como contexto de apoio, e não como detector principal.
Ele ajuda a responder perguntas como:
- qual conta obteve o TGT que antecedeu a atividade TGS incomum?
- quais sistemas de origem estão envolvidos?
- quando o esquema enriquecido do evento estiver disponível, o que os campos de chaves suportadas e fallback sugerem?
Esse contexto é útil ao investigar um cluster incomum de 4769. Ele não substitui o 4769.
Mantenha inventário contínuo de contas associadas a SPN
A qualidade da detecção melhora muito se você mantiver um inventário contínuo de:
- contas com SPN;
- idade das senhas;
PasswordNeverExpires;- se a conta é um usuário clássico ou uma identidade de serviço gerida;
- privilégios efetivos e alcance de admin local;
- postura de criptografia, quando relevante no ambiente.
Uma revisão defensiva simples de inventário já pode ser suficiente para destacar candidatos de alto risco antes mesmo que tráfego suspeito precise ser investigado.
Get-ADUser -LDAPFilter "(servicePrincipalName=*)" -Properties servicePrincipalName,pwdLastSet,PasswordNeverExpires,msDS-SupportedEncryptionTypes |
Select-Object SamAccountName,ServicePrincipalName,PasswordNeverExpires,pwdLastSet,msDS-SupportedEncryptionTypes
A ideia não é coletar todos os SPNs e entrar em pânico. A ideia é identificar quais contas combinam exposição por SPN, higiene fraca do segredo e privilégios relevantes.
Trate o baselining como obrigatório
Uma postura séria de detecção de Kerberoasting exige uma baseline dos padrões normais de tickets de serviço. Isso significa saber:
- quais hosts costumam solicitar tickets para quais serviços;
- quais contas de serviço são acessadas em volume por comportamento legítimo de aplicações;
- quais ferramentas de administração, varredura ou gestão geram legitimamente atividade TGS ampla.
Sem essa baseline, “muitos 4769” não é uma estratégia de detecção. É apenas um ponto de partida.
Prevenção e hardening
A prevenção de Kerberoasting consiste principalmente em tornar as contas de serviço ligadas a SPN maus alvos para cracking e maus alvos para escalada de privilégio.
1. Reduzir contas de serviço apoiadas em usuários sempre que possível
A Microsoft documenta group Managed Service Accounts (gMSA) como contas de domínio geridas que fornecem gestão automática de senhas e gestão simplificada de SPN, inclusive em vários servidores.
Isso não coloca uma gMSA magicamente fora do Kerberos. Mas faz dela uma opção defensiva muito melhor do que uma conta de usuário gerida manualmente cuja senha não muda há anos.
Quando a plataforma permitir, migrar serviços elegíveis de contas de serviço clássicas apoiadas em usuários para gMSA é um dos controles preventivos mais úteis que você pode aplicar.
2. Rotacionar senhas de contas de serviço legacy
A guidance da Microsoft para RC4 observa que contas antigas podem não possuir chaves AES se a senha nunca foi redefinida depois da introdução do suporte moderno a Kerberos. Isso importa porque redefinir uma senha não muda apenas o segredo: também pode atualizar o material de chaves utilizável pela conta.
Para contas de serviço legacy que ainda não podem migrar para gMSA:
- rotacione a senha;
- torne-a longa e aleatória;
- verifique depois que o serviço continua funcionando corretamente;
- documente a ownership para que a conta não volte a virar dívida técnica compartilhada.
3. Reduzir RC4 com cuidado, não às cegas
A Microsoft agora documenta explicitamente RC4 como inseguro, em retirada e algo que deve ser auditado por telemetria Kerberos. A Microsoft também documenta formas concretas de limitar ou desabilitar RC4, inclusive por política de tipos de criptografia Kerberos permitidos.
A conclusão correta não é “desative RC4 em todo lugar imediatamente”. A conclusão correta é:
- identificar onde RC4 ainda está sendo usado;
- determinar se a dependência é real ou apenas configuração herdada sem manutenção;
- mover contas e hosts elegíveis para configurações compatíveis com AES;
- monitorar falhas de autenticação durante o rollout.
A própria documentação da Microsoft alerta que desabilitar RC4 pode quebrar dependências legacy se elas não tiverem sido validadas antes. Esse caveat pertence a qualquer plano sério de hardening contra Kerberoasting.
4. Revisar os privilégios por trás da conta de serviço
A prevenção fica incompleta se você melhora apenas a senha e ignora os privilégios.
Revise se a conta de serviço possui:
- admin local em muitos servidores;
- direitos delegados no AD;
- privilégios de backup, orquestração ou deploy;
- acesso de alto valor a bancos de dados ou arquivos;
- caminhos implícitos para aninhamento perigoso de grupos AD ou desvio de acesso privilegiado em Active Directory.
Uma conta de serviço endurecida, mas superprivilegiada, ainda transforma a recuperação de um segredo em um incidente grave.
5. Limpar SPNs que não representam mais serviços reais
A Microsoft documenta setspn como a ferramenta para ler, adicionar, remover e consultar SPNs. Isso importa operacionalmente porque SPNs obsoletos ou duplicados não são apenas um problema de higiene. Eles confundem a ownership e ampliam desnecessariamente a superfície de revisão.
Se um SPN não representa mais um serviço real, remova-o. Se uma aplicação já não precisa de uma identidade apoiada em usuário, desative a conta em vez de carregá-la indefinidamente.
Validação após a remediação
Uma remediação de Kerberoasting não está concluída só porque uma senha foi rotacionada uma vez ou porque um tipo de ticket mudou em laboratório. A validação precisa provar que a exposição em produção realmente mudou.
Mantenha pelo menos um pacote mínimo de evidências como este:
| Evidência | Por que importa |
|---|---|
| Inventário atual de contas ligadas a SPN | Confirma escopo revisado e ownership |
| Postura de idade / expiração das senhas de contas de serviço | Mostra se contas legacy quebráveis foram realmente remediadas |
| Classificação entre contas geridas e contas apoiadas em usuário | Prova onde a migração para gMSA reduziu o risco de segredos manuais |
Baseline Kerberos de 4769 | Confirma a lógica de detecção após as mudanças |
| Revisão do uso de RC4 com exceções registradas | Distingue dependências legacy aceitas de deriva não governada |
| Revisão de privilégios para contas de serviço de alto valor | Mostra se o raio de impacto caiu, e não apenas o problema de senha |
As perguntas de validação devem ser concretas:
- quais contas críticas com SPN ainda dependem de senhas geridas manualmente?
- quais ainda mostram idade de senha excessiva ou isenções de expiração?
- quais serviços ainda exigem RC4 e quem aprovou essa dependência?
- quais contas ainda permitiriam movimento lateral relevante se fossem recuperadas?
- a baseline
4769do domínio melhorou materialmente após o trabalho de remediação?
Essa é a diferença entre “nós mudamos algumas senhas de contas de serviço” e “nós reduzimos de forma mensurável o risco de Kerberoasting”.
Como a EtcSec mede o risco de Kerberoasting
A EtcSec deve descrever as condições que tornam o Kerberoasting praticável, e não fingir que prova um ataque em andamento a partir de um único evento.
A finding central é KERBEROASTING_RISK, útil quando uma conta possui um SPN e ainda apresenta um ou mais traços que tornam o cracking offline materialmente mais realista.
Findings de contexto que elevam a prioridade incluem:
PASSWORD_NEVER_EXPIRESPASSWORD_POLICY_WEAKKERBEROS_RC4_FALLBACK
Em conjunto, esses checks ajudam a estruturar uma revisão repetível de:
- quais contas de serviço estão expostas;
- quais continuam fracas o suficiente para realmente importar;
- quais estão em caminhos de privilégio relevantes;
- quais ainda precisam de evidência de remediação após as mudanças.
Controles relacionados
Kerberoasting deve ser revisto junto com controles de identidade adjacentes que frequentemente ampliam o mesmo caminho de comprometimento:
- AS-REP Roasting, porque ambas as técnicas transformam material Kerberos em risco de cracking offline;
- Segurança de senhas no Active Directory, porque qualidade e rotação de senha determinam a explorabilidade;
- Contas obsoletas e superprivilegiadas no AD, porque contas esquecidas costumam carregar os SPNs mais perigosos;
- Delegação Kerberos, porque identidades de serviço costumam se sobrepor à exposição por delegação;
- Auditar a segurança do Active Directory, porque Kerberoasting é apenas um item dentro de um workflow mais amplo e orientado a evidências em AD;
- Monitoramento de Segurança AD, porque
4769só se torna útil quando a coleta de eventos e o baselining já estão em funcionamento.
Referências primárias
- MITRE ATT&CK T1558.003: Kerberoasting
- 4769(S, F): A Kerberos service ticket was requested
- 4768(S, F): A Kerberos authentication ticket (TGT) was requested
- Detect and remediate RC4 usage in Kerberos
- Kerberos authentication overview in Windows Server
- Group Managed Service Accounts overview
- Service principal names
- Setspn
- ms-DS-Supported-Encryption-Types attribute
- Audit Directory Service Access
