AS-REProasting Attack & Defense

What is AS-REProasting?

AS-RepRoasting is a cybersecurity attack targeting Active Directory environments, specifically accounts where Kerberos preauthentication is disabled. Attackers send an Authentication Server Request (AS-REQ) without the encrypted timestamp, and if preauthentication isn't required, the Domain Controller (DC) responds with an Authentication Server Reply (AS-REP) containing Ticket Granting Ticket (TGT) data. This data, often encrypted with an insecure algorithm like RC4, can be extracted and cracked offline to reveal passwords, enabling unauthorized access.

Lab Setup

Before we begin, ensure your home lab meets these requirements:

  1. Domain Controller (DC): A Windows Server configured as an AD domain controller (e.g., lab.local).

  2. Client Machine: A Windows client joined to the domain.

  3. Kali Linux Machine

  4. Ubuntu Machine (Elasticsearch & Kibana)

We also need to create a user with the "Do not require Kerberos preauthentication" property enabled.

New-ADUser -Name "victim" -UserPrincipalName victim@Main.local -SAMAccountName victim -AccountPassword (ConvertTo-SecureString "P@ssword123" -AsPlainText -Force) -Enabled $true
Set-ADAccountControl -Identity "victim" -DoesNotRequirePreAuth $true
Get-ADUser -Filter * -Properties DoesNotRequirePreAuth | Where-Object { $_.DoesNotRequirePreAuth -eq $True -and $_.Enabled -eq $True }

Audit Policies to Enable

🔹 Enable "Audit Kerberos Authentication Service"

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon

  • Event ID 4768

🔹 Enable "Audit Kerberos Service Ticket Operations"

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon

  • Event ID 4769

🔹 Enable "Audit Logon"

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff

  • Event ID 4624 → Successful logons.

  • Event ID 4625 → Failed logons.

gpupdate /force

To set up Elasticsearch and Kibana on an Ubuntu machine, refer to the following guide: Configure Elasticsearch and Kibana on Ubuntu.

Also we need to download and install Winlogbeat on the Domain Controller to forward logs to our ELK stack. For detailed setup instructions, refer to: Winlogbeat Configuration Guide.

The Attack - AS-REProasting

  • Attackers identifying accounts with preauthentication disabled, either by querying AD using PowerShell with LDAP filters or by sending AS-REQ messages and checking for responses without errors.

  • Sending an AS-REQ message without the encrypted timestamp for these accounts.

  • Receiving an AS-REP message from the DC, which contains TGT data encrypted with an insecure algorithm like RC4, making it vulnerable to offline password cracking attacks similar to Kerberoasting.

To retrieve crackable hashes, we can utilize Rubeus. This time, we will leverage the asreproast action. If no specific username is provided, Rubeus will extract hashes for all users who have Kerberos preauthentication disabled.

.\Rubeus.exe asreproast /outfile:ticket.txt

We have successfully obtained the hash for the victim user, which has been saved to ticket.exe. Next, we will attempt to crack it using Hashcat.

sudo hashcat -m 18200 -a 0 ticket.txt /usr/share/wordlists/rockyou.txt --outfile ticketcrack.txt --force

  • hashcat: The password-cracking tool.

  • -m 18200: Specifies the hash type. 18200 is the mode for Kerberos 5 AS-REP (pre-authentication) hashes.

  • -a 0: Specifies the attack mode. 0 means a straight dictionary attack.

  • ticket.txt: The file containing the Kerberos ticket hash(es) to crack.

  • /usr/share/wordlists/rockyou.txt: The wordlist (dictionary) used for cracking. rockyou.txt is a common password list.

  • --outfile ticketcrack.txt: Saves the cracked passwords to ticketcrack.txt.

  • --force: Forces Hashcat to run, even if it detects potential issues (e.g., unsupported hardware).

sudo cat ticketcrack.txt

We can also execute the attack using GetNPUsers.py from Impacket to retrieve password hashes. To facilitate this, I created a file named users.txt, which contains a list of usernames, including the target user, "victim," for use in the attack.

sudo python3 GetNPUsers.py Main.local/ -usersfile /home/fares/users.txt -format hashcat -outputfile hashes.txt

This command runs a Python script (GetNPUsers.py) from the Impacket toolkit to extract Kerberos AS-REP hashes for users in Active Directory who have pre-authentication disabled.

Defenses Against AS-RepRoasting

Defending against AS-RepRoasting requires a multi-layered approach to mitigate the risk of exploitation:

  • Enable Kerberos Preauthentication: Ensure all user accounts have preauthentication enabled by setting msDS-kerb-pre-auth-required to 1. Use PowerShell scripts to locate accounts without preauth, such as the command mentioned earlier, and enable it to prevent offline cracking. This ensures the DC can decrypt the timestamp, validating the user's credentials.

  • Implement Strong Password Policies: Enforce strong passwords (25+ characters, periodic expiration) to increase the difficulty of cracking extracted hashes.

  • Use AES Encryption: Where possible, configure Kerberos to use AES encryption instead of RC4, as RC4 is considered insecure and facilitates hash cracking.

After the attack has occurred, we will analyze key Event IDs to gain insights into the incident and understand what happened.

Event ID 4768 – Kerberos Authentication (AS-REQ)

I executed the attack using two different methods: one from a Windows machine and another from a Kali machine. As a result, in Event ID 4768, the source IP address will differ for each instance.

This event was recorded during the attack on the domain from a Windows machine that was joined to the domain and leveraged Rubeus.

Here, we observe the following indicators:

  • TicketEncryptionType: 0x17 (RC4) → A common encryption type associated with AS-REP Roasting attacks.

  • PreAuthType: 0 → Indicates logon without pre-authentication.

This event was logged during the attack on the domain from a Kali machine.

However, when executing the attack from a Kali machine, the ticket options change, while the Result code, Ticket encryption type, and Pre-authentication type remain unchanged.

Based on the insights gathered, we can develop detection rule to enhance security. Let's begin by investigating this attack using ELK.

event.code: 4768 and (winlog.event_data.TicketOptions: "0x50800000" OR winlog.event_data.TicketOptions:"0x40800010" )

Let's create a rule based on Event Code, Ticket Options, Pre-Authentication Type, and Ticket Encryption Type. While a threshold rule could be used to detect anomalies based on the number of tickets generated within a short time frame, grouped by source IP, in this case, we have a single user with Pre-Authentication disabled. Therefore, we will create a custom query rule tailored to this scenario.

event.code: 4768 and winlog.event_data.TicketOptions: ("0x50800000" OR "0x40800010" ) AND winlog.event_data.PreAuthType:"0" AND winlog.event_data.TicketEncryptionType: ("0x17" OR "0x3")

This rule means:

  • At each execution (every 1 minute), the rule analyzes data collected over the last 5 minutes (the look-back time).

  • For example, if the rule runs at 5:21 PM, it will check data from 5:16 PM to 5:21 PM. Then, at 5:22 PM, it will check data from 5:17 PM to 5:22 PM, and so forth.

Now, let's save the rule and reattempt the attack to verify if any alerts are triggered.

These rules are not the final production-ready versions. When deploying them in real-world environments, they need to be continuously tuned to minimize false positives as much as possible.

Other Mitigations.

Our attacks (Kali with Ticket Options: 0x50800000 and Rubeus with 0x40800010) succeeded due to Pre-Authentication Type: 0, indicating preauthentication was disabled for the target account (victim). Both used RC4-HMAC (0x17), producing crackable hashes because the domain controller didn’t require preauthentication validation. Ensuring this option is disabled is the most direct mitigation.

DoesNotRequirePreAuth Flag

  • False (Pre-Authentication Enabled): Safe

    • Kerberos pre-authentication is required.

    • The user must provide valid credentials (encrypted timestamp) before a Ticket Granting Ticket (TGT) is issued.

    • This prevents replay attacks and brute-force attacks, making it the secure default.

  • True (Pre-Authentication Disabled): Not Safe

    • Kerberos pre-authentication is not required.

    • An attacker can request a TGT without providing valid credentials, making the account vulnerable to:

      • Brute-force attacks: Attackers can guess passwords offline.

      • Pass-the-ticket attacks: Attackers can reuse captured tickets.

    • This should only be enabled if absolutely necessary (e.g., for compatibility with legacy systems).

Let's enable Pre-Authentication for the user account named "victim."

Set-ADAccountControl -Identity victim -DoesNotRequirePreAuth $false
Get-ADUser -Identity victim -Property DoesNotRequirePreAuth | Select-Object SamAccountName, DoesNotRequirePreAuth
Get-ADUser -Filter * -Properties DoesNotRequirePreAuth | Where-Object { $_.DoesNotRequirePreAuth -eq $True -and $_.Enabled -eq $True }

We also need to implement AES-256 encryption to replace weak ciphers and enhance security.

Set-ADUser -Identity victim -KerberosEncryptionType AES256

Now, let's examine the properties of the "victim" account following these modifications.

Get-ADUser -Identity "victim" -Properties UserPrincipalName,MemberOf,DoesNotRequirePreAuth,KerberosEncryptionType

Let's attempt the attack again to assess whether it succeeds or fails.

.\Rubeus.exe asreproast /outfile:ticket.txt
PreviousGolden Ticket Attack & DefenseNextDCSync Attack & Defense

Last updated