AS-REP Roasting — Deteccao & Remediacao

O que é AS-REP Roasting?

AS-REP Roasting é um ataque de Active Directory contra contas que têm a pré-autenticação Kerberos desabilitada.

Quando o flag DONT_REQ_PREAUTH está habilitado em um usuário ou em uma conta de serviço, o KDC pode devolver uma AS-REP sem exigir antes a prova de que o solicitante conhece a senha. Um atacante que conhece ou adivinha um nome de conta válido pode pedir essa resposta, extrair a parte cifrada e tentar quebrá-la offline.

É isso que torna a configuração perigosa: ela transforma uma conta de domínio em alvo de cracking de senha antes de a autenticação ter sido concluída com sucesso.

A diferença operacional para Kerberoasting é importante:

Kerberoasting exige uma identidade de domínio válida para solicitar tickets de serviço.
AS-REP Roasting não exige credenciais válidas para solicitar uma AS-REP de uma conta conhecida.

Isso não significa que LDAP anônimo esteja disponível por padrão. A Microsoft desabilitou operações LDAP anônimas em controladores de domínio Active Directory por padrão desde o Windows Server 2003, exceto operações limitadas como rootDSE e bind. Descobrir nomes de usuários é um problema separado da coleta de AS-REP.

Como o fluxo Kerberos é alterado

Em uma troca AS normal do Kerberos, o cliente envia uma AS-REQ com dados de pré-autenticação, normalmente um timestamp cifrado. Esse é o passo que prova ao KDC que o cliente conhece a senha da conta.

Se DONT_REQ_PREAUTH estiver ativado, o KDC pula essa validação e devolve imediatamente uma AS-REP. A parte cifrada dessa resposta é protegida com a chave Kerberos de longo prazo da conta, derivada da senha.

Para um leitor técnico, dois pontos são centrais:

o ataque funciona porque a resposta cifrada é entregue antes de a autenticação ser concluída
essa resposta pode ser usada para cracking offline, então comprimento e qualidade da senha alteram diretamente o impacto

Não faz sentido assumir que toda conta roastable devolverá o mesmo tipo de cifragem. Em ambientes Windows modernos, tipos AES são esperados em muitos cenários; em ambientes mais antigos ainda pode aparecer RC4. O modelo correto não é “RC4 por padrão”, e sim “o material retornado depende da configuração Kerberos e dos tipos de cifragem permitidos naquele ambiente”.

O que um atacante realmente precisa

Para um AS-REP Roasting bem-sucedido bastam três coisas:

Conectividade de rede até um controlador de domínio que responda requisições Kerberos AS.
Nomes de conta candidatos.
Pelo menos uma conta com DONT_REQ_PREAUTH ativado.

É por isso que a técnica é atraente. O atacante não precisa comprometer primeiro uma sessão Windows nem roubar uma conta inicial antes de começar a coleta.

Na prática, os nomes de usuários costumam vir de:

convenções de e-mail e diretórios públicos
algum acesso prévio de baixo privilégio ao domínio
exports, scripts ou inventários antigos
enumeração AD autenticada feita por uma conta comum do domínio

LDAP anônimo é, portanto, um erro adicional, não um requisito do ataque.

A cadeia de ataque

Etapa 1 - Identificar contas roastables

Com acesso autenticado, isso pode ser consultado diretamente no AD:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

Sem credenciais, o atacante ainda pode testar nomes conhecidos enviando requisições AS e observando quais contas devolvem material aproveitável.

Etapa 2 - Solicitar respostas AS-REP

# Solicitar material AS-REP para uma lista de nomes conhecidos
impacket-GetNPUsers corp.local/ -usersfile users.txt -no-pass -dc-ip 10.10.0.1

Com uma conta de domínio válida, a enumeração pode ser mais direta:

impacket-GetNPUsers corp.local/user:password -request -dc-ip 10.10.0.1

Em um host Windows, o Rubeus faz a mesma coleta:

.\Rubeus.exe asreproast /format:hashcat /outfile:asrep_hashes.txt

Etapa 3 - Quebrar offline

A partir daí, o controlador de domínio deixa de ser parte do problema. As tentativas de senha acontecem offline, na velocidade do atacante.

Por isso senhas antigas de contas de serviço, segredos escolhidos manualmente e senhas que nunca expiram são especialmente perigosos nesse cenário.

Etapa 4 - Usar a credencial recuperada

Se a senha for recuperada, a conta pode ser usada como qualquer outra identidade comprometida:

acesso interativo, se permitido
LDAP e PowerShell para ampliar visibilidade
movimento lateral para sistemas onde a conta tenha privilégios locais ou delegados
escalada se a conta estiver ligada a grupos privilegiados, serviços, tarefas agendadas ou aplicações críticas

Uma única exceção criada para uma aplicação legacy pode, portanto, tornar-se o primeiro passo de um caminho de identidade muito maior.

Detecção

O melhor ponto de detecção continua sendo o controlador de domínio.

Event 4768 é o sinal principal

A documentação da Microsoft para Event ID 4768 torna dois campos especialmente úteis:

Pre-Authentication Type = 0 significa que a requisição de TGT ocorreu sem pré-autenticação Kerberos.
Ticket Encryption Type mostra qual tipo de cifragem Kerberos foi realmente usado.

Para AS-REP Roasting, o indicador que merece prioridade é um 4768 com Pre-Authentication Type 0.

Padrões práticos de hunting

Comece por estes casos:

eventos 4768 repetidos com Pre-Authentication Type = 0
rajadas de requisições da mesma origem contra várias contas
requisições para contas de serviço ou contas admin que não deveriam autenticar de forma interativa
picos de 4768 Result Code 0x6, que podem indicar adivinhação de nomes antes das requisições válidas
mudanças de conta que ativam DONT_REQ_PREAUTH, especialmente em identidades de serviço ou privilegiadas

Exemplo de consulta SIEM

event.code: "4768" AND
winlog.event_data.PreAuthType: "0" AND
winlog.event_data.Status: "0x0"

Se a auditoria de mudanças de diretório estiver habilitada, vale também revisar as alterações que ligam o bit de userAccountControl correspondente. Frequentemente é aí que a exceção perigosa aparece antes da exploração.

Remediation e proximos passos

1. Remover exceções de pré-autenticação sem justificativa

Set-ADAccountControl -Identity vulnerable_user -DoesNotRequirePreAuth $false

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} | ForEach-Object {
    Set-ADAccountControl -Identity $_ -DoesNotRequirePreAuth $false
}

Esse é o conserto principal. Se uma conta não precisa da exceção por uma razão técnica demonstrável, ela não deve mantê-la.

2. Rotacionar senhas depois da correção

Não basta reabilitar a pré-autenticação. Se a conta era roastable, é preciso assumir que o material pode ter sido coletado antes do ajuste.

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
    Set-ADUser -ChangePasswordAtLogon $true

Para contas de serviço, o correto é uma rotação real do segredo, não apenas a troca do flag.

3. Revisar dependências legacy

Se um time disser que a conta precisa continuar sem pré-autenticação, exija uma revisão técnica:

qual sistema realmente depende disso
se esse sistema pode ser modernizado ou isolado
se a conta pode ser reduzida ao mínimo de privilégios
se logon interativo, delegação ou grupos amplos podem ser removidos

Uma exceção de preauth em conta privilegiada ou muito reutilizada não é um pequeno compromisso de compatibilidade. É exposição offline de senha.

4. Endurecer contas que temporariamente precisem ficar em exceção

Se uma exceção precisar sobreviver por algum tempo:

imponha uma senha longa e aleatória
retire grupos privilegiados sempre que possível
restrinja direitos de logon
monitore especificamente o 4768 daquela conta
defina owner e data de revisão

5. Não confiar na obscuridade dos nomes de usuários

Mesmo com LDAP anônimo desabilitado, é preciso assumir que atacantes ainda conseguem montar listas de usuários. O controle durável é remover contas roastables e reduzir o valor das exceções que precisem permanecer.

Validacao apos a correcao

Um fechamento profissional de AS-REP Roasting se apoia em quatro verificações simples:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} retorna apenas exceções documentadas.
As senhas das contas anteriormente expostas foram rotacionadas.
Os 4768 com Pre-Authentication Type = 0 desapareceram para usuários e contas de serviço comuns.
Toda exceção remanescente tem owner, justificativa de negócio, controles compensatórios e data de revisão.

Esse passo de validacao evita um erro comum: remover o flag em uma conta visivel e deixar a mesma excecao reaparecer no proximo processo de provisionamento, na proxima migracao ou no proximo ajuste de compatibilidade. O inventario final deve registrar tambem quais contas de servico continuam com justificativa formal, qual o sistema dependente, quem aprovou a excecao e qual a data da nova revisao.

Erros frequentes do lado defensor

Os erros recorrentes costumam ser os mesmos:

assumir que LDAP anônimo é requisito do ataque
reativar a pré-autenticação mas não rotacionar a senha
manter a exceção em contas de serviço antigas com privilégios amplos
tratar a configuração como inofensiva porque a conta “não é interativa”
corrigir uma conta visível sem corrigir o processo de provisionamento que criou a exceção

Para um leitor técnico, o ponto central não é a complexidade do exploit. É a quantidade de privilégio acumulada pela conta exposta.

Referências primárias

Como o EtcSec detecta isso

O EtcSec sinaliza contas com pré-autenticação Kerberos desabilitada em todo audit AD.

O achado principal é ASREP_ROASTING_RISK: qualquer conta com DONT_REQ_PREAUTH ativado é candidata a exposição de senha.

Achados relacionados mudam a gravidade real:

PASSWORD_NEVER_EXPIRES
PASSWORD_POLICY_WEAK
WEAK_KERBEROS_POLICY

A combinação importa mais do que o flag sozinho. Uma conta roastable com senha fraca, antiga ou que nunca expira é muito mais perigosa do que uma exceção temporária fortemente controlada.

AS-REP Roasting: Coletando Hashes Sem Credenciais