Extração de senhas de contas de serviço com Kerberoasting

Em nosso post de reconhecimento LDAP, exploramos como um atacante pode realizar reconhecimento para descobrir contas de serviço para atacar em um domínio do Active Directory (AD). Agora vamos explorar uma maneira que um atacante pode usar para comprometer essas contas e explorar seus privilégios: Kerberoasting. Esta técnica é especialmente assustadora porque não requer privilégios de administrador no domínio, é muito fácil de realizar e é praticamente indetectável.

Kerberoasting: Visão Geral

Kerberoasting é um ataque que abusa de um recurso do protocolo Kerberos para colher hashes de senha para contas de usuário do Active Directory: Qualquer usuário de domínio autenticado pode solicitar tickets de serviço para uma conta especificando seu Nome Principal de Serviço (SPN), e o serviço de concessão de tickets (TGS) no controlador de domínio retornará um ticket que é criptografado usando o hash NTLM da senha da conta.

Portanto, uma vez que um adversário descobriu SPNs de conta de serviço usando uma tática como reconhecimento LDAP, ele pode coletar tickets para todas essas contas. Ao levar esses dados para fora da rede, eles podem realizar um ataque de força bruta para decifrar a senha em texto simples de cada conta de serviço — sem nenhum risco de detecção ou bloqueio de conta.

Leva apenas alguns minutos para um atacante obter acesso a um domínio, coletar tickets e iniciar o processo de cracking. A partir daí, é apenas uma questão de tempo até que eles comprometam uma ou mais contas de serviço, que podem usar para roubar ou criptografar dados sensíveis ou causar outros danos.

Os adversários concentram-se em contas de serviço por várias razões. Primeiro, essas contas muitas vezes têm privilégios muito mais extensos do que outras contas de usuário do AD, então comprometê-las concede ao atacante mais acesso. Além disso, as senhas das contas de serviço raramente mudam, então é provável que o adversário mantenha o acesso por um longo tempo. Para entender os tipos de acesso que podem ser obtidos usando Kerberoasting, olhe para a lista de SPNs do Active Directory mantida por Sean Metcalf.

Kerberoasting: Como funciona

Passo 1. Obtenha os SPNs das contas de serviço.

. Existem muitas maneiras de obter esses SPNs, incluindo:

• Consultas PowerShell e reconhecimento LDAP
• Módulo do Active Directory para PowerShell
• Script GetUserSPNs no Kerberoast toolkit
• Comando Get-NetUser do PowerSploit

Passo 2. Solicite bilhetes de serviço para SPNs de contas de serviço.

Basta executar algumas linhas de PowerShell, e um ticket de serviço será retornado e armazenado na memória do seu sistema.

      Add-Type –AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken –ArgumentList ‘MSSQLSvc/jefflab-sql02.jefflab.local:1433’
      

Etapa 3. Extraia tickets de serviço usando Mimikatz.

Mimikatz extrairá tickets locais e os salvará no disco para quebra offline. Simplesmente instale Mimikatz e emita um único comando:

Passo 4. Quebre os tickets.

Os tickets Kerberos são criptografados com a senha da conta de serviço associada ao SPN especificado na solicitação do ticket. As ferramentas Kerberoasting fornecem um script em Python para decifrar tickets e fornecer suas senhas em texto claro, executando um dicionário de hashes de senha contra eles. Pode ser necessário alguma configuração para garantir que você tenha o ambiente necessário para executar o script, mas este blog cobre esses detalhes.

Alternativamente, você pode coletar tickets Kerberos usando o script GetUserSPNs e quebrá-los com a ferramenta de recuperação de senha Hashcat.

Protegendo contra ataques de Kerberoasting

A principal mitigação para ataques de Kerberoasting é garantir que todas as contas de serviço utilizem senhas longas e complexas que sejam mais difíceis de quebrar, e trocá-las regularmente para minimizar o tempo em que a conta poderia ser utilizada por um adversário que consiga decifrar uma senha. Usar group managed service accounts é uma prática recomendada para atribuir senhas aleatórias e complexas que podem ser alteradas automaticamente.

Uma vez que os adversários quebram os tickets offline, o processo não resulta em tráfego de rede, tornando essa parte do ataque indetectável. Mas você pode identificar os passos anteriores monitorando o Active Directory com uma solução de segurança robusta. Em particular, contas de serviço são normalmente usadas dos mesmos sistemas e da mesma forma, então fique atento para detectar pedidos de autenticação anômalos. Além disso, monitore picos nos pedidos de tickets de serviço.

Por fim, especialistas em segurança também recomendam desativar a criptografia baseada em RC4. Caso contrário, mesmo que uma conta de usuário suporte criptografia AES, um atacante pode solicitar um ticket criptografado em RC4, o qual é mais fácil de decifrar do que um criado usando criptografia AES.

Kerberoasting permite que um invasor com qualquer conta de domínio padrão solicite tickets criptografados para contas de serviço e depois quebre suas senhas offline, onde nenhuma política de bloqueio se aplica e o controlador de domínio não está envolvido.

O que é Kerberoasting?

Ele tem sucesso contra contas pouco protegidas, e 76% das organizações não governam nem monitoram totalmente identidades não humanas, incluindo contas de serviço, segundo o Netwrix 2026 Data and Identity Security Report.

O ataque começa com uma lista dessas contas, que um invasor pode criar por meio de LDAP reconnaissance.

Kerberoasting é um ataque ao Active Directory (AD) que transforma um recurso normal do Kerberos em uma oportunidade para quebrar senhas. O Kerberos permite que qualquer usuário autenticado solicite um ticket de serviço de um controlador de domínio, e o ticket é criptografado com uma chave derivada da senha da conta de serviço.

Como os atacantes extraem senhas de contas de serviço com Kerberoasting

A extração ocorre em quatro etapas, e Rubeus junto com o GetUserSPNs.py do Impacket combinam as três primeiras em um único comando enquanto o Hashcat cuida da quarta.

1. Encontre as contas que possuem SPNs

2. Solicite tickets de serviço para os SPNs

Um atacante que coleta esses tickets pode tentar senhas contra eles offline até que um seja descriptografado. Os alvos são contas de usuário com service principal names (SPNs), incluindo a maioria das service accounts. O ataque não precisa de privilégios elevados para começar.

Um invasor com qualquer conta de domínio pode listar contas com SPNs por meio de uma consulta LDAP, uma consulta PowerShell ou o módulo Active Directory para PowerShell. Rubeus e GetUserSPNs.py também enumeram contas kerberoastáveis por conta própria, e Rubeus pode relatar estatísticas sobre elas sem enviar solicitações de ticket.

Um SPN nomeia uma instância de serviço em três partes, como em MSSQLSvc/jefflab-sql02.jefflab.local:1433Expand, que indica a classe do serviço, o host e a porta. A classe do serviço sugere o que uma conta comprometida pode acessar, como o acesso ao banco de dados para MSSQLSvc.

Duas linhas de PowerShell solicitam um ticket para um SPN nomeado, e o Windows o armazena na memória.

Rubeus automatiza a solicitação para cada conta kerberoastable e pode gravar os resultados em um arquivo.

Kerberos comprova a identidade e deixa a autorização para o serviço (RFC 4120), então o controlador de domínio não verifica se o solicitante pode usar o serviço antes de emitir um ticket. Qualquer usuário autenticado, portanto, recebe um ticket criptografado com uma chave derivada da senha da conta do serviço.

3. Extrair os tickets de serviço

Impacket's GetUserSPNs.py faz o mesmo com sua opção -request, que gera os tickets em um formato aceito pelo John the Ripper e Hashcat.

Quando existe uma conta com pré-autenticação Kerberos desativada, a opção /nopreauth do Rubeus solicita tickets de serviço enviando mensagens AS-REQ (Authentication Service Request) através dela.

4. Quebre os tickets

Um ticket solicitado com as linhas PowerShell acima fica na memória até que o invasor o exporte. Mimikatz lista os tickets na sessão atual e os grava em arquivos para cracking offline com um único comando.

Rubeus e GetUserSPNs.py com -request pulam esta etapa, pois geram hashes que podem ser crackeados diretamente.

Por que o tipo de criptografia do ticket importa

O cracking é executado no hardware do atacante, portanto nenhuma política de bloqueio se aplica, e o controlador de domínio não vê nada após a solicitação do ticket. O Hashcat testa as senhas contra cada ticket e recupera a senha em texto claro quando uma tentativa a descriptografa. Ele aceita o formato gerado pelo GetUserSPNs.py e possui um modo separado para cada tipo de criptografia.

Netwrix Threat Prevention bloqueia ataques DCSync, Kerberoasting e Pass-the-Hash no Active Directory em tempo real. Solicite uma demonstração.

Os tickets RC4 são quebrados mais rápido

O tipo de criptografia de um ticket, RC4 (Rivest Cipher 4) ou AES (Advanced Encryption Standard), determina a rapidez com que um atacante pode adivinhá-lo, e a Microsoft alterou seus padrões em 2026.

Os atacantes podem solicitar RC4 para contas que suportam AES

Os tickets AES atrasam a adivinhação, mas ainda caem para senhas fracas

A chave de um ticket RC4 é o hash NT LAN Manager (NTLM) da conta, um hash sem salt da senha (RFC 4757). Sem salt, a mesma senha gera a mesma chave para cada conta, e cada tentativa custa uma computação de hash.

O Rubeus solicita por padrão o tipo de criptografia mais alto suportado por cada conta, mas sua opção /usetgtdeleg solicita tickets RC4 para contas que suportam AES, e sua opção /rc4opsec ignora contas habilitadas para AES.

O GetUserSPNs.py do Impacket também solicita RC4 por padrão, a menos que -no-rc4 esteja definido. Remover RC4 dos tipos de criptografia suportados pela conta de serviço fecha esse caminho de downgrade.

Os três tipos podem ser quebrados, então o comprimento e a aleatoriedade da senha decidem o resultado.

A atualização de abril de 2026 alterou o controlador de domínio padrão

Protegendo contas de serviço contra Kerberoasting

As chaves AES vêm de uma derivação de chave salteada que executa 4.096 iterações por padrão (RFC 3962), tornando cada tentativa mais cara. A opção /aes do Rubeus mira contas habilitadas para AES e solicita seus tickets AES, e o Hashcat possui um modo separado para cada tipo de criptografia de ticket.

A alteração não afeta contas que permitem explicitamente RC4 por meio desse atributo, e um padrão de domínio definido explicitamente é respeitado conforme escrito. Essas contas ainda podem receber tickets RC4, portanto, são as primeiras a serem encontradas.

A atualização KB5073381 da Microsoft começou com eventos de auditoria em janeiro de 2026. Em 14 de abril de 2026, alterou o padrão do controlador de domínio para que contas sem um valor explícito de msDS-SupportedEncryptionTypes sejam consideradas como suportando apenas AES-SHA1, e atualizações lançadas em ou após julho de 2026 não suportam mais o valor do registro que permitia aos administradores reverter a alteração.

Cada controle limita uma parte diferente do ataque, e todos usam recursos nativos do Active Directory e do Windows.

Mover contas de serviço para contas gerenciadas

Defina senhas longas e aleatórias para o restante

Redefina senhas e aplique AES

Pesquisa da Netwrix sobre o ataque BadSuccessor, que abusa de dMSAs para escalonamento de privilégios, recomenda auditar quem possui os direitos CreateChild, WriteProperty, WriteDACL, GenericAll e WriteOwner nas unidades organizacionais antes de implantá-los.

Contas de serviço gerenciadas em grupo (gMSAs) usam senhas aleatórias de 120 caracteres que o Active Directory rotaciona, então os invasores não têm nada fraco para adivinhar. Contas de serviço gerenciadas delegadas (dMSAs) também têm o Active Directory gerenciando as credenciais.

Para contas que não podem ser movidas, MITRE ATT&CK recomenda senhas de idealmente 25 caracteres ou mais. A geração aleatória é tão importante quanto o comprimento, pois as listas de palavras para quebra são feitas a partir das senhas que as pessoas escolhem.

As chaves AES são geradas quando uma senha é definida ou alterada, portanto, uma conta cuja senha é anterior ao suporte AES não possui nenhuma até ser redefinida, e uma conta apenas AES sem elas não pode receber tickets.

Remova os SPNs que as contas não precisam

Teste cada serviço antes de restringi-lo, pois serviços que não suportam AES, incluindo alguns dispositivos não Windows, param de autenticar assim que o RC4 é removido.

Redefina a senha primeiro, depois verifique o atributo msDS-SupportedEncryptionTypes da conta para configurações explícitas de RC4 e restrinja-o a AES128 e AES256 (valor 24).

Cada SPN em uma conta de usuário torna essa conta solicitável, então liste todos e compare cada um com um serviço em execução.

Controle quem pode adicionar SPNs

Limitar privilégios da conta de serviço

Registrar solicitações de tickets de serviço

A conta krbtgt aparece nos resultados por design e não deve ser alterada. Para qualquer outro SPN que aponte para um host desativado ou um aplicativo aposentado, verifique com setspn -L <account>Expand e exclua com setspn -D <SPN> <account>Expand.

No targeted Kerberoasting, um atacante com direitos GenericAll, GenericWrite, WriteProperty ou Validated Write para Service Principal Name em uma conta adiciona um SPN, tornando a conta vulnerável ao roast. Revise as listas de controle de acesso em contas de serviço e remova esses direitos de quem não gerencia a conta. Normalmente, membros do grupo integrado Account Operators os possuem.

Ative a subcategoria Audit Kerberos Service Ticket Operations nos controladores de domínio, que registra cada solicitação como Evento ID 4769. MITRE recomenda monitorar solicitações anômalas que usam RC4, indicadas como Ticket Encryption Type 0x17, enquanto os tickets AES mostram 0x11 ou 0x12.

Roasting por uma conta sem pré-autenticação envia mensagens AS-REQ, portanto essas solicitações são registradas como Evento ID 4768, e a mesma verificação RC4 se aplica a elas.

Uma senha comprometida dá a um invasor tudo o que a conta pode fazer. Remova contas de serviço de grupos privilegiados como Domain Admins e conceda apenas os direitos que o serviço usa, sob o princípio do privilégio mínimo. Esse trabalho faz parte de um mais amplo endurecimento de segurança do Active Directory.

O repositório Kerberos-Crypto da Microsoft inclui um script Get-KerbEncryptionUsage.ps1 que lê ambos os tipos de evento, e executá-lo com -Encryption RC4 e -SearchScope AllKdcs lista solicitações RC4 em todos os controladores de domínio.

Como a Netwrix ajuda a defender contra Kerberoasting

Bloqueie tentativas de Kerberoasting em tempo real

Os produtos Netwrix adicionam três controles além das configurações nativas do Windows: bloquear o ataque, detectar o que acontece em seguida e avaliar o Active Directory para as vulnerabilidades que ele explora.

Detectar ataques baseados em identidade

Netwrix Threat Prevention impede tentativas de Kerberoasting, DCSync e Pass-the-Hash contra Active Directory antes que tenham sucesso. Isso oferece às equipes um ponto de aplicação no momento do ataque, que a revisão de logs não pode fornecer.

Avaliar a postura de segurança do Active Directory

Comece com as contas que ainda permitem RC4

Netwrix Threat Manager identifica roubo de credenciais, movimentação lateral e escalonamento de privilégios, que são ataques baseados em identidade que podem ocorrer após a quebra da senha de uma conta de serviço. Também detecta quando um SPN é adicionado a uma conta privilegiada, etapa de configuração do Kerberoasting direcionado.

Kerberoasting precisa de apenas uma senha fraca de conta de serviço, então a defesa funciona melhor como uma sequência aplicada conta por conta.

Netwrix PingCastle avalia a segurança do Active Directory e identifica configurações incorretas, caminhos de ataque e exposição de privilégios.

Contas que não podem ser convertidas em contas gerenciadas precisam de senhas longas e aleatórias para resistir a tentativas de adivinhação offline. A solicitação de ticket é a única etapa que os defensores ainda podem observar, portanto registrá-la cobre o que a higiene de senhas não pode.

Após a alteração padrão da Microsoft em abril de 2026, contas que permitem explicitamente RC4, seja na conta ou por meio de um padrão de domínio explicitamente definido, ainda podem receber tickets RC4, portanto, têm prioridade. Mova o que puder para contas gerenciadas, depois redefina o restante e restrinja-os ao AES.

Solicite uma demonstração para ver como Netwrix Threat Prevention impede tentativas de Kerberoasting contra suas contas de serviço Active Directory antes que tenham sucesso.