Kerberoasting e ataques a credenciais de AD: deteccao e defesa

O Kerberoasting é uma das técnicas mais comuns que os defensores observam contra o Active Directory (AD) e, ainda assim, permanece amplamente mal compreendida pelas equipes responsáveis por detê-la. Este artigo adota um ponto de vista estritamente defensivo: explicamos o que é a técnica, como funciona o protocolo Kerberos subjacente, por que certas contas ficam expostas e, sobretudo, como as equipes azuis a detectam, a mitigam e se endurecem contra ela. O objetivo é entender para defender. Você não encontrará aqui instruções operacionais de ataque, apenas a telemetria, os controles e as listas de verificação que um engenheiro de detecção ou administrador de AD precisa para elevar o custo do ataque e reduzir a janela em que ele pode ter sucesso.

O que é o Kerberoasting

O Kerberoasting é uma técnica de acesso a credenciais que abusa de um recurso legítimo do Kerberos: qualquer usuário de domínio autenticado pode solicitar um ticket de serviço para uma conta de serviço que tenha um Service Principal Name (SPN) registrado. Parte desse ticket é cifrada com uma chave derivada da senha da conta de serviço. Como a solicitação em si é comportamento normal do protocolo, gera pouco ruído, e como a quebra posterior da senha ocorre offline, o controlador de domínio (DC) nunca vê as tentativas de adivinhação. O risco concentra-se, portanto, nas senhas fracas de contas de serviço e no cifrado legado. Da perspectiva do defensor, a técnica é mais bem entendida como um descompasso entre um antigo recurso de conveniência e o hardware moderno de quebra de senha. Está classificada no MITRE ATT&CK como T1558.003, dentro da tática de Acesso a Credenciais.

Como funciona a autenticação Kerberos

Para se defender da técnica, você precisa de um modelo mental funcional do Kerberos. Quando um usuário faz login, recebe um Ticket-Granting Ticket (TGT) do Key Distribution Center (KDC), que roda no controlador de domínio. Quando esse usuário quer depois acessar um serviço — um SQL Server, um pool de aplicação web, um compartilhamento de arquivos — apresenta o TGT e solicita um ticket de serviço (TGS) para o SPN específico. O KDC devolve um TGS cuja porção de serviço é cifrada com a chave de longo prazo da conta dona do SPN. Legitimamente, o cliente encaminha esse ticket ao serviço de destino, que o decifra para validar a solicitação. A suposição de projeto é que apenas o serviço (que conhece a própria senha) pode ler a porção cifrada. Essa suposição quebra quando a senha da conta é fraca o bastante para ser recuperada offline, porque qualquer um que obtenha o ticket pode tentar derivar a chave. Esse fluxo indica exatamente onde posicionar sua telemetria: no KDC, nos eventos de solicitação de ticket.

Como o ataque funciona em alto nível

Em alto nível, a técnica tem três etapas conceituais que um defensor deve reconhecer. Primeira, a enumeração: identificar quais contas têm SPNs registrados, já que só essas são alvo. Segunda, a solicitação de tickets: obter tickets TGS para esses SPNs por meio de chamadas de protocolo comuns e autenticadas, que parecem acesso normal a serviços. Terceira, a recuperação offline: levar a porção cifrada inteiramente para fora da rede e tentar recuperar a senha no hardware do próprio adversário, sem mais contato com seu domínio. A percepção crucial para a equipe azul é que apenas as duas primeiras etapas são visíveis para você — a terceira acontece fora da rede. Por isso a prevenção (senhas fortes, cifrado moderno, contas gerenciadas) importa tanto quanto a detecção: uma vez que um ticket de senha fraca deixou o ambiente, nenhum alerta consegue chamá-lo de volta.

Superfície de ataque e exposição

A superfície exposta é o conjunto de contas que carregam SPNs. Na maioria dos ambientes, isso inclui contas de serviço para bancos de dados (MSSQLSvc), servidores web, aplicações de negócio sob medida e diversos produtos de fornecedores que historicamente exigiam um usuário de domínio para executar. Duas categorias merecem escrutínio especial. A primeira são as contas de serviço privilegiadas — qualquer conta com SPN que também seja membro de Domain Admins, Enterprise Admins ou outros grupos de alto nível. São as exposições de maior valor porque recuperar a senha delas concede privilégio imediato. A segunda são as contas obsoletas: contas de serviço criadas anos atrás com uma senha escolhida por uma pessoa e que nunca foi rotacionada. Inventariar essa superfície é um projeto defensivo em si. Você deveria conseguir responder, a qualquer momento, quantas contas com SPN existem, quais são privilegiadas, quais usam cifrado legado e quando cada senha mudou pela última vez. Se não consegue responder, essa lacuna é seu primeiro achado.

Detecção: logs, Event IDs e telemetria

A detecção centra-se nos eventos de ticket de serviço Kerberos nos controladores de domínio. O sinal-chave é o Event ID 4769 ("Um ticket de serviço Kerberos foi solicitado"). Por si só, esse evento é de volume extremamente alto e benigno, então alertar de forma ingênua é inútil; a arte está no enriquecimento. Priorize eventos 4769 em que o Ticket Encryption Type seja 0x17 (RC4-HMAC) em vez de 0x12 (AES256), pois um rebaixamento para RC4 em uma conta que deveria suportar AES é um forte indicador. Correlacione por volume e diversidade: um único principal solicitando tickets de serviço para um número incomumente grande de SPNs distintos em pouco tempo é muito mais suspeito do que a contagem bruta de eventos. Observe o Event ID 4768 (TGT solicitado) para o contexto inicial de autenticação e emparelhe o 4769 com a conta solicitante, o host de origem e uma linha de base por horário. Plataformas modernas de EDR e de detecção de ameaças de identidade (por exemplo, o Microsoft Defender for Identity) trazem análises dedicadas de Kerberoasting; se você opera uma, ajuste e valide seus alertas. Por fim, considere uma conta de serviço isca (honeypot): um SPN chamariz com senha longa e aleatória sem uso legítimo, conectado para que qualquer solicitação 4769 sobre ela dispare um alerta de alta fidelidade.

Mitigação e endurecimento

É na prevenção que se vence. O controle mais eficaz é eliminar as senhas de conta de serviço escolhidas por humanos: migre para Group Managed Service Accounts (gMSA) ou Managed Service Accounts delegadas, cujas senhas são valores aleatórios de mais de 120 caracteres, rotacionados automaticamente pelo AD e desconhecidos de qualquer pessoa. Uma senha de gMSA é computacionalmente inviável de recuperar offline, o que remove a conta do risco por completo. Onde um gMSA ainda não for possível, imponha senhas longas e aleatórias (25+ caracteres) em cada conta com SPN, já que o comprimento é a alavanca direta contra a quebra offline. Desative o RC4 e exija cifrado AES para o Kerberos, tanto no nível de política de domínio quanto nos atributos de cada conta (msDS-SupportedEncryptionTypes), testando antes as dependências legadas. Aplique segmentação por níveis (tiering): nenhuma conta de serviço deveria ser ao mesmo tempo portadora de SPN e membro de um grupo altamente privilegiado — separe os papéis. Imponha um calendário de rotação para as contas manuais restantes e remova SPNs de contas que não precisam mais deles.

Ataques de credenciais de AD relacionados

O Kerberoasting raramente está sozinho; pertence a uma família de técnicas de credenciais de AD que um defensor deve tratar em conjunto. O AS-REP Roasting (T1558.004) mira contas com a pré-autenticação Kerberos desativada, produzindo material quebrável sem sequer precisar de uma conta de domínio válida — audite a flag DONT_REQ_PREAUTH e a remova onde não for estritamente necessária. As técnicas Pass-the-Ticket e Pass-the-Hash reutilizam autenticadores roubados em vez de quebrá-los, por isso importam os controles de higiene de credenciais como Credential Guard, proteção do LSASS e restrição de onde contas privilegiadas fazem login. As falsificações de Golden e Silver Ticket abusam das chaves do KRBTGT e de contas de serviço, respectivamente, mais uma razão para rotacionar o KRBTGT regularmente e proteger os segredos das contas de serviço. Enxergá-los como uma superfície conectada, e não como alertas isolados, ajuda a priorizar os controles — segredos fortes, cifrado moderno, tiering e gestão de acesso privilegiado — que reduzem vários de uma vez.

Armadilhas comuns

Vários erros recorrentes minam programas que, de resto, são bons. O primeiro é alertar sobre o volume bruto de 4769: sem enriquecimento de tipo de cifrado e diversidade, o ruído enterra o sinal e a regra é desativada em uma semana. O segundo é supor que o AES está imposto quando uma única aplicação legada força silenciosamente RC4 para a conta inteira — verifique sempre o tipo de cifrado negociado em eventos reais, não apenas na política. O terceiro é a conta de serviço privilegiada deixada no lugar porque "a aplicação precisa dela" — essa é exatamente a exposição que transforma um achado de baixa severidade em um caminho para o comprometimento do domínio. O quarto é considerar uma migração para gMSA concluída enquanto um punhado de serviços legados teimosos ainda roda sob contas manuais; é ali que o risco se concentra. O quinto é desativar a pré-autenticação para diagnosticar e esquecer de reativá-la, abrindo silenciosamente o AS-REP Roasting. Acompanhe cada um como uma tarefa de higiene permanente.

Lista de verificação do defensor

Use esta lista como revisão recorrente. Inventário: mantenha uma lista viva de todas as contas com SPN, sinalizando as privilegiadas e as de cifrado legado. Cifrado: exija AES e desative RC4 onde as dependências permitirem, verificado contra eventos 4769 reais. Contas gerenciadas: migre as contas de serviço para gMSA/dMSA; defina uma data-alvo para aposentar as manuais restantes. Senhas: para qualquer conta manual, imponha segredos aleatórios de 25+ caracteres e um calendário de rotação. Tiering: garanta que nenhuma conta com SPN tenha participação em grupos de alto nível. Detecção: implante análises enriquecidas de 4769 (tipo de cifrado + diversidade de SPN + linha de base) e valide que disparam em um teste controlado. Honeypot: levante uma conta SPN isca com alerta de alta fidelidade. Flags adjacentes: audite e remova o DONT_REQ_PREAUTH desnecessário e confirme que a rotação do KRBTGT está agendada. Resposta: documente o playbook para uma detecção confirmada — rotacionar o segredo afetado, caçar uso posterior e revisar a exposição de acesso privilegiado.

Perguntas frequentes

O Kerberoasting pode ser totalmente prevenido ou apenas detectado? Pode ser efetivamente prevenido como ameaça prática. Migrar as contas com SPN para gMSA/dMSA, ou impor senhas aleatórias muito longas com cifrado somente AES, torna a recuperação offline computacionalmente inviável. A detecção continua valiosa como defesa em profundidade e para pegar exceções mal configuradas, mas são os segredos fortes que eliminam o risco na raiz.

Por que o Event ID 4769 é tão barulhento e como o torno útil? Todo acesso normal a um serviço gera um 4769, então contagens brutas não significam nada. Ele se torna útil pelo enriquecimento: filtre solicitações RC4 (0x17) em contas capazes de AES, correlacione um único solicitante atingindo muitos SPNs distintos rapidamente, estabeleça uma linha de base por conta e reserve os alertas de alta fidelidade para os SPNs isca que nenhum processo legítimo deveria solicitar jamais.

Conclusão

O Kerberoasting persiste não por ser sofisticado, mas porque tantos ambientes ainda carregam senhas fracas de contas de serviço e cifrado RC4 legado. Para os defensores, o caminho é claro e duradouro: inventarie suas contas com SPN, mova-as para contas gerenciadas, imponha AES, separe o privilégio da identidade de serviço e construa detecção enriquecida sobre os eventos de ticket Kerberos com um honeypot como fio de tropeço. Trate-o junto com seus primos — AS-REP Roasting, falsificação de tickets e reutilização de credenciais — como uma única superfície conectada de segurança de identidade. Faça isso e você converterá um favorito confiável dos atacantes em uma técnica barulhenta quando tentada e inútil quando bem-sucedida. Entenda-a, e você poderá se defender dela.