# T1558.003 - Kerberoasting > [!info] Identificação MITRE ATT&CK > **Tática:** Credential Access · **ID:** T1558.003 · **Plataforma:** Windows · **Técnica pai:** [[t1558-steal-or-forge-kerberos-tickets|T1558 - Steal or Forge Kerberos Tickets]] ## Descrição Kerberoasting é uma técnica de pós-exploração amplamente utilizada por adversários para obter credenciais de contas de serviço do Active Directory sem precisar de privilégios elevados no domínio. A técnica abusa do protocolo de autenticação Kerberos - específicamente da fase de emissão de tickets TGS (Ticket-Granting Service) - para extrair hashes de senhas que podem ser quebrados offline. Em ambientes Windows com Active Directory, todo serviço que requer autenticação Kerberos deve estar associado a um **Service Principal Name (SPN)**. Quando um usuário autenticado solicita acesso a um serviço, o Domain Controller (DC) emite um ticket TGS criptografado com a hash NT da senha da conta de serviço associada ao SPN. Adversários que possuem um TGT válido (o que exige apenas uma conta de domínio comum, sem privilégios especiais) podem solicitar TGS tickets para qualquer SPN registrado no domínio. A parcela crítica da vulnerabilidade reside no algoritmo de criptografia: quando a conta de serviço usa criptografia RC4 (etype 23, identificado como `Kerberos 5 TGS-REP etype 23`), o ticket é criptografado com a hash NTLM da senha da conta. Essa hash pode ser extraída do ticket e submetida a ataques de [[t1110-brute-force|força bruta]] offline ou a ataques de dicionário, sem gerar alertas diretamente nos logs do Domain Controller - pois a solicitação de TGS é uma operação legítima do protocolo. Contas de serviço são alvos especialmente atrativos porque frequentemente possuem senhas que raramente são rotacionadas, às vezes configuradas com privilégios excessivos (como Domain Admin), e muitas organizações não monitoram adequadamente as solicitações de TGS em volume. Uma vez que a hash é quebrada offline, o adversário obtém a senha em texto claro e pode usá-la para [[ta0008-lateral-movement|movimentação lateral]], [[ta0004-privilege-escalation|escalação de privilégios]] e acesso a [[t1078-valid-accounts|contas válidas]] em toda a infraestrutura. > [!warning] Impacto Potencial > Em ambientes onde contas de serviço têm senhas fracas ou são membros de grupos privilegiados, um único ataque de Kerberoasting bem-sucedido pode levar à comprometimento total do domínio Active Directory. ## Como Funciona O ataque de Kerberoasting segue um fluxo técnico preciso que explora o funcionamento normal do protocolo Kerberos: **1. Reconhecimento de SPNs** O adversário, com acesso a qualquer conta de domínio válida, consulta o Active Directory para enumerar todos os SPNs registrados. Isso é feito via LDAP utilizando ferramentas como `setspn -T domain -Q */*` ou via módulos PowerShell. O objetivo é identificar contas de serviço com SPNs, especialmente aquelas que usam criptografia RC4. **2. Solicitação de Tickets TGS** Para cada SPN identificado como interessante, o adversário solicita um TGS ao Domain Controller. Esta é uma operação completamente legítima no protocolo Kerberos - qualquer conta autenticada pode solicitar TGS para qualquer SPN. Ferramentas como [[s1071-rubeus|Rubeus]] automatizam esse processo com o parâmetro `kerberoast`. **3. Extração do Hash** O TGS retornado contém a hash da senha da conta de serviço na porção criptografada do ticket. As ferramentas de Kerberoasting extraem automaticamente essa hash no formato `$krb5tgs$23$*...*` compatível com hashcat ou John the Ripper. **4. Quebra Offline da Hash** Com a hash em mãos, o adversário realiza o ataque de dicionário ou força bruta completamente offline, sem interação adicional com a rede corporativa. Hashcat com modo `-m 13100` (Kerberos 5 TGS-REP etype 23) é o método mais comum. **5. Uso das Credenciais** Com a senha em texto claro da conta de serviço, o adversário pode autenticar no domínio com privilégios equivalentes aos da conta comprometida, potencialmente escalando para Domain Admin se a conta de serviço for membro de grupos privilegiados. > [!note] Variante: AS-REP Roasting > Técnica relacionada (T1558.004) que ataca contas com pré-autenticação Kerberos desabilitada, não requerendo nem mesmo um TGT válido para iniciar o ataque. ## Attack Flow ```mermaid graph TB A["🔐 Conta de Domínio Válida<br/>(qualquer usuário autenticado)"] --> B["🔍 Enumeração de SPNs<br/>via LDAP Query ao AD"] B --> C{"SPNs encontrados<br/>com RC4 (etype 23)?"} C -->|Sim| D["📨 Solicitação de TGS<br/>para SPNs alvo"] C -->|Não - AES128/256| E["⚠️ Menor chance de sucesso<br/>Continuar com cautela"] D --> F["🎫 Domain Controller emite<br/>TGS (operação legítima)"] E --> F F --> G["📦 Extração do Hash<br/>krb5tgs 23 do ticket"] G --> H["💻 Quebra Offline<br/>Hashcat / John the Ripper"] H --> I{"Senha<br/>quebrada?"} I -->|Sim| J["🔑 Credenciais em Texto Claro<br/>da Conta de Serviço"] I -->|Não - senha forte| K["❌ Ataque falhou<br/>Tentar outra conta"] J --> L["🚀 Movimentação Lateral<br/>Escalação de Privilégios"] L --> M["🌐 Acesso a Recursos<br/>do Domínio / Domain Admin"] M --> N["📂 Exfiltração de Dados<br/>/ Persistência"] ``` ## Exemplos de Uso ### Grupos de Ameaça Documentados **[[g0102-conti-group|Wizard Spider]]** - O grupo por trás do ransomware Ryuk utilizou Kerberoasting como parte de sua cadeia de ataque pós-comprometimento inicial, frequentemente combinando com [[t1059-001-powershell|PowerShell]] e ferramentas como [[s0154-cobalt-strike|Cobalt Strike]] para movimentação lateral antes de implantar o ransomware. Em incidentes documentados contra hospitais e infraestrutura crítica, o grupo utilizou [[s1071-rubeus|Rubeus]] para extrair hashes de contas de serviço SQL e Exchange. **[[g0046-fin7|FIN7]]** - Grupo financeiramente motivado ativo contra setores de varejo, hotelaria e finanças. Incorporou Kerberoasting em sua métodologia de escalação de privilégios, frequentemente direcionado a contas de serviço associadas a sistemas de ponto de venda (POS). O grupo combinava Kerberoasting com [[t1566-phishing|spear-phishing]] para obter acesso inicial antes de escalar privilégios. **[[g0119-indrik-spider|Indrik Spider]]** - Operadores do ransomware WastedLocker e Hades. Documentados usando Kerberoasting como parte de operações de acesso inicial a ambientes corporativos, especialmente em campanhas de Big Game Hunting (BGH) contra organizações de grande porte. ### Ferramentas Comuns | Ferramenta | Comando Típico | Observação | |---|---|---| | [[s1071-rubeus\|Rubeus]] | `Rubeus.exe kerberoast /outfile:hashes.txt` | Mais completo, filtra por etype | | [[s0357-impacket\|Impacket]] | `GetUserSPNs.py domain/user -request` | Via Python, funciona remotamente | | [[s0194-powersploit\|PowerSploit]] | `Invoke-Kerberoast -OutputFormat Hashcat` | PowerShell, mais visível para EDRs | | [[s0363-empire\|Empire]] | Módulo `powershell/credentials/invoke_kerberoast` | Framework C2 completo | | [[brute-ratel-c4\|Brute Ratel C4]] | Módulo integrado de Kerberoasting | Framework adversarial moderno | | [[s0692-silenttrinity\|SILENTTRINITY]] | Módulo `kerberoast` | Baseado em IronPython | ## Detecção ### Indicadores de Comprometimento - Volume elevado de solicitações TGS em curto período de tempo (dezenas ou centenas de requisições em minutos) - Solicitações de TGS para múltiplos SPNs diferentes de uma única conta de usuário - Solicitações de TGS usando RC4 (etype 23) em ambientes que migraram para AES - Uso de ferramentas conhecidas: `Rubeus.exe`, `GetUserSPNs.py`, `Invoke-Kerberoast` - Autenticações bem-sucedidas de contas de serviço em horários ou origens incomuns após período de inatividade ### Regra de Detecção - Sigma ```yaml title: Kerberoasting - Múltiplas Solicitações TGS RC4 status: experimental description: > Detecta padrões de Kerberoasting através de múltiplas solicitações de TGS com algoritmo RC4 (etype 23) em curto período logsource: category: authentication product: windows service: security detection: selection: EventID: 4769 TicketEncryptionType: '0x17' TicketOptions: '0x40810000' filter_computer_accounts: ServiceName|endswith: ' condition: selection and not filter_computer_accounts timeframe: 5m condition_count: selection | count() by SubjectUserName > 5 level: high tags: - attack.credential_access - attack.t1558.003 falsepositives: - Ferramentas legítimas de gerenciamento que solicitam múltiplos tickets - Scanners de segurança internos ``` ### Evento Windows a Monitorar | EventID | Descrição | Campo Crítico | |---|---|---| | 4769 | Kerberos Service Ticket Request | `TicketEncryptionType: 0x17` (RC4) | | 4768 | Kerberos TGT Request | Baseline de comportamento normal | | 7045 | New Service Installed | Instalação de ferramentas como Rubeus | > [!tip] Detecção Proativa com Honeypot SPN > Crie uma conta de serviço "honeypot" com um SPN atraente (ex: `MSSQLSvc/sql-prod`) e senha forte, mas monitore qualquer solicitação de TGS para esse SPN. Qualquer requisição indica atividade de reconhecimento ou Kerberoasting em curso. ## Mitigação | ID | Mitigação | Descrição Detalhada | |---|---|---| | [[m1027-password-policies\|M1027]] | Password Policies | Implementar senhas longas (mínimo 25+ caracteres) e complexas para contas de serviço. Considerar o uso de **Group Managed Service Accounts (gMSA)** que rotacionam senhas automaticamente com 240 bits de aleatoriedade - tornando o Kerberoasting inviável na prática | | [[m1041-encrypt-sensitive-information\|M1041]] | Encrypt Sensitive Information | Configurar contas de serviço para usar **AES256** (etype 18) exclusivamente, desabilitando RC4 (etype 23). Tickets AES são computacionalmente muito mais difíceis de quebrar offline. Configurar via `Set-ADUser -KerberosEncryptionType AES256` | | [[m1026-privileged-account-management\|M1026]] | Privileged Account Management | Aplicar o **princípio do menor privilégio** rigorosamente em contas de serviço. Auditar regularmente quais SPNs possuem privilégios de Domain Admin ou similares. Remover membros desnecessários de grupos privilegiados | ### Recomendações Adicionais - **Migrar para gMSA/sMSA**: Group Managed Service Accounts gerenciam senhas automaticamente com rotação frequente e alta entropia - **Auditar SPNs regularmente**: `Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName` - **Implementar AES obrigatório**: Remover suporte a RC4 em contas de serviço via GPO (`Network Security: Configure encryption types allowed for Kerberos`) - **Monitorar solicitações TGS**: Habilitar auditoria de `Kerberos Service Ticket Operations` na política de auditoria do AD ## Contexto Brasil/LATAM O Kerberoasting tem relevância significativa no contexto brasileiro e latino-americano por razões específicas do ambiente corporativo regional: **Adoção de Active Directory**: O Brasil possui uma das maiores bases de instalação de Active Directory da América Latina, especialmente em setores de serviços financeiros, governo, saúde e manufatura. Ataques de Kerberoasting são particularmente eficazes em organizações que não implementaram gMSA ou políticas rigorosas de senha para contas de serviço. **Ransomware como Vetor Primário**: Grupos como [[g0102-conti-group|Wizard Spider]] e afiliados do [[lockbit|LockBit]] têm documentados ataques contra organizações brasileiras nos setores financeiro, saúde e governo. Kerberoasting frequentemente aparece na fase de escalação de privilégios antes do deployment do ransomware. **Déficit de Monitoramento**: Organizações brasileiras de médio porte frequentemente operam com capacidade limitada de SIEM/SOC, tornando a detecção de padrões sutis de Kerberoasting desafiadora. O ataque ocorre em canais normais do protocolo Kerberos, sem exploração de vulnerabilidades que acionariam alertas convencionais. **Campanhas Documentadas**: O CERT.br registrou incidentes em 2024 e 2025 envolvendo comprometimento de Active Directory em organizações brasileiras onde análise forense identificou uso de [[s0357-impacket|Impacket]] (GetUserSPNs.py) na fase pré-ransomware, consistente com Kerberoasting. **Setor Financeiro em Risco**: Instituições financeiras brasileiras reguladas pelo Banco Central operam sob obrigações de reporte de incidentes (Resolução BCB nº 85/2021), aumentando a pressão por controles preventivos. SPNs associados a contas de serviço SQL Server, Exchange e sistemas de core banking são alvos prioritários. > [!example] Vetor Típico em Incidentes Brasileiros > Phishing inicial → comprometimento de endpoint de usuário comum → enumeração LDAP da rede → Kerberoasting de contas de serviço SQL/Exchange → credenciais de serviço quebradas → movimentação lateral → implantação de ransomware. Este padrão foi identificado em múltiplos incidentes brasileiros documentados entre 2023 e 2025. ## Referências - [MITRE ATT&CK - T1558.003 Kerberoasting](https://attack.mitre.org/techniques/T1558/003) - [Harmj0y - Kerberoasting Without Mimikatz](https://www.harmj0y.net/blog/powershell/kerberoasting-without-mimikatz/) - [Specter Ops - Kerberoasting Revisited](https://specterops.io/blog/2022/03/10/kerberoasting-revisited/) - [Microsoft - Detecting Kerberoasting Activity](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory) - [CERT.br - Relatório de Incidentes 2024](https://www.cert.br/stats/) - [CrowdStrike - Wizard Spider Threat Actor Profile](https://www.crowdstrike.com/adversaries/wizard-spider/) - [[m1027-password-policies|M1027 - Password Policies]] - [[m1026-privileged-account-management|M1026 - Privileged Account Management]] - [[t1110-brute-force|T1110 - Brute Force]] - [[t1078-valid-accounts|T1078 - Valid Accounts]] --- *Fonte: [MITRE ATT&CK - T1558.003](https://attack.mitre.org/techniques/T1558/003) · Versão MITRE: 16.2 · Atualizado: 2026-03-25*