AS-REP roasting
Last updated
Last updated
When authentication occurs within Kerberos, the first thing that happens is an authentication request to the domain controller so the identity trying to authenticate can be verified. That request is known as Authentication Server Request (AS-REQ.)
This process is commonly referred to as Kerberos preauthentication.
After the client's authentication is validated, the domain controller sends an Authentication Server Reply (AS-REP) to the client, containing a session key and a Ticket Granting Ticket (TGT).
The session key is encrypted using the user’s password hash so that only that user can decrypt and reuse it.
With pre-authentication, a user enters their password, which encrypts a time stamp. The Domain Controller will decrypt this to validate that the correct password was used. If successful, a TGT will be issued to the user for further authentication requests in the domain. If an account has pre-authentication disabled, an attacker can request authentication data for the affected account and retrieve an encrypted TGT from the Domain Controller. This can be subjected to an offline password attack using a tool such as Hashcat or John the Ripper.
Viewing an Account with the Do not Require Kerberos Preauthentication Option
ASREPRoasting is similar to Kerberoasting, but it involves attacking the AS-REP instead of the TGS-REP. An SPN is not required. This setting can be enumerated with PowerView or built-in tools such as the PowerShell AD module.
Now check this out! If the preauthentication process is not in place, attackers can send the AS-REQ to the domain controller on behalf of any user in the domain.
As a result, since the AS-REP contains the session keys encrypted with the user's password hash, they can obtain the password hash of any user.
(Tools like GetNPUsers from the Impacket tool suite can simplify this process.)
Attackers can then try to crack the hashes offline (using tools like Hashcat) or pass them around the network in what's known as “pass-the-hash” attacks. This is an attempt to gain unauthorized access to domain resources on behalf of those users.
By default, the AD User Account Control (UAC) setting: “Do not require Kerberos preauthentication” is disabled. This means that Kerberos preauthentication is performed for all users.
I recently supervised an internal networking penetration test where all user accounts had the "do not require Kerberos preauthentication" option enabled. The reason for this, as later stated by the client, was due to an internal application malfunction.
The administrators decided to enable this option "momentarily" while they fixed the issue. However, what was supposed to be temporary ended up lasting almost 2 years.
It's worth noting this particular misconfiguration was only identifiable due to this particular penetration test.
The attack itself can be performed with the Rubeus toolkit and other tools to obtain the ticket for the target account. If an attacker has GenericWrite or GenericAll permissions over an account, they can enable this attribute and obtain the AS-REP ticket for offline cracking to recover the account's password before disabling the attribute again. Like Kerberoasting, the success of this attack depends on the account having a relatively weak password.
With this information in hand, the Rubeus tool can be leveraged to retrieve the AS-REP in the proper format for offline hash cracking. This attack does not require any domain user context and can be done by just knowing the SAM name for the user without Kerberos pre-auth. We will see an example of this using Kerbrute later in this section. Remember, add the /nowrap flag so the ticket is not column wrapped and is retrieved in a format that we can readily feed into Hashcat.
We can then crack the hash offline using Hashcat with mode 18200.
When performing user enumeration with Kerbrute, the tool will automatically retrieve the AS-REP for any users found that do not require Kerberos pre-authentication.
With a list of valid users, we can use Get-NPUsers.py from the Impacket toolkit to hunt for all users with Kerberos pre-authentication not required. The tool will retrieve the AS-REP in Hashcat format for offline cracking for any found. We can also feed a wordlist such as jsmith.txt into the tool, it will throw errors for users that do not exist, but if it finds any valid ones without Kerberos pre-authentication, then it can be a nice way to obtain a foothold or further our access, depending on where we are in the course of our assessment. Even if we are unable to crack the AS-REP using Hashcat it is still good to report this as a finding to clients (just lower risk if we cannot crack the password) so they can assess whether or not the account requires this setting.
Hunting for Users with Kerberoast Pre-auth Not Required
Miscellaneous Misconfigurations
We have now covered a few ways that we can perform an ASREPRoasting attack from both Windows and Linux hosts and witnessed how we do not need to be on a domain-joined host to a) enumerate accounts that do not require Kerberos pre-authentication and b) perform this attack and obtain an AS-REP to crack offline to either gain a foothold in the domain or further our access.
Spotting this type of attack is easier than kerberoasting attack detection. However, it’s still complex because you need knowledge of AD and event logs to properly filter down to malicious activity.
As we mentioned in part one of this series, regular AD operations in corporate environments make it harder to detect malicious activity because there are thousands of Kerberos events going on per minute. However, if we know what to look for, we can still find this needle in the haystack.
Event ID 4768 is an event ID recorded in Security Logs on the domain controller whenever a Kerberos Authentication ticket is requested.
Depending on the Active directory size and assets, this can be well over thousands of tickets per minute by different accounts in the network.
Let's view one of the many events to understand this event’s fields.
Account Name: The user account that requested an authentication ticket from the domain controller.
Service Name: Name of the service that handled the ticket.
Ticket Encryption type: Depicts the Ticket encryption algorithm used (For example aes, RC4, etc).
Pre-Authentication Type: The status code shows whether pre-authentication was disabled or enabled for the said object (The Account Name).
We can see that the administrator user requested an authentication ticket and the service name is krbtgt. This is regular operations and whenever an account logs in to a workstation, krbtgt is a universal AD service that handles Kerberos authentications.
Now let's discuss a few of the filters or conditions that would indicate a possible attack.
In legitimate use cases for Kerberos ticket operations, the encryption type would be 0x12 or 0x11.
But if we see an encryption type “0x17” which is RC4 encryption, that would be a clue to look into this further, as an attacker may request a ticket in this encryption type because it allows them to crack the password.
Note💡: All major open-source tools, like Impacket and Rubeus, request tickets in RC4 encryption type.
User accounts request authentication tickets from domain controllers all the time; that’s the nature of how Active Directory Kerberos authentication works.
To further reduce the events to investigate, we can filter out requests from all service names other than “krbtgt”.
This is because during this attack, the attacker retrieves the authentication ticket just like a legitimate user account would, and krbtgt is a default AD Service that handles the authentication flow in Active Directory.
The major indicator that the AS-REP attack has been successful (the attacker managed to get the ticket, whether they cracked it or not is another case) is the pre-authentication type value in the resultant logs.
Note:💡A great way to threat hunt for this attack is to just look for pre-authentication type = 0, which means it is disabled. This would already remove 90 percent of the noise in the logs, leaving more granular results to go through.
SOC analysts can query the logs in SIEMs to create a filter for all the things mentioned.
With the filters discussed above we’re snooping for a 4768 event where:
Pre-Authentication Type is 0, which means it is disabled. This is a major condition to be fulfilled as without this condition, the attack can’t happen.
Service Name should always be krbtgt. This is also straightforward. As only krbtgt can perform authentication-related processes in AD.
Ticket encryption type will be 0x17 which is RC4 encryption, allowing attackers to easily crack the hash.
Here’s an example of identifying an actual event that was the result of a AS-REP attack using the detection tips above:
This event fulfills all the conditions we set which would highly indicate AS-REP Roasting activity. We can see that a domain Account “arthur.kyle” requested an authentication ticket for a user whose pre-authentication is disabled, with an encryption type of 0x17 from a workstation with IP Address 172.17.79.129.
So far we found out that the user arthur.kyle got compromised due to pre-authentication being disabled.
What we don't know is which user account was used to perform the attack.
It's important to note that while the “arthur.kyle” account is the victim here, the bad actor used another account to perform the attack.
We need to find that account, too, because it’s also been compromised! And our single AS-REP incident may expand into an incident with a wider scope as we keep more compromised assets.
We have the machine’s IP address from which the request originated. We will look for Kerberos service ticket events, as every domain user account requests those either during login/authentication or normal domain usage.
Filter for Event ID 4769 and look for events around the time of the malicious event.
We spotted an event about a minute later after the malicious event and it originated from User account of the “172.17.79.129” machine.
Now nothing in this event is malicious by itself. It’s purely a regular operation and is not a result of any attack or exploit.
But since we already found AS-REP activity in the previous section, and we know it originated from this machine, this event caught our eye.
Here we can see that happy.grunwald was the user account logged in around the time of AS-REP Roasting attack on the source machine (machine that performed the attack).
It can be safe to assume now that this user account is compromised hence expanding the scope of the incident.
Detecting AS-REP roasting with Splunk
Let's see a Splunk query for this as well
Query : Event.EventData.TicketEncryptionType="0x17" Event.System.EventID="4768" Event.EventData.PreAuthType="0" Event.EventData.ServiceName="krbtgt"
| table Event.EventData.TargetUserName,Event.EventData.IpAddress
(Please note that in Splunk query, your field name might differ a little as it depends on the configurations. For example instead of Event.System.EventID it can be “EventID” or “Windows.EventID”. It all depends on your Splunk configuration and deployment.)
In the above query, we are hunting for Event Log 4768 where the encryption type is 0x17, the authentication type is 0 (it's disabled), and the service name is krbtgt. So this fulfills our criteria.
Note💡: AS-REP Roasting is mapped to the sub-technique T1558.004 on the MITRE ATT&CK framework
The follow-up to this detection would be to:
Create a timeline of when this event was generated.
Do a forensic analysis of the machine with IP Address 172.17.79.129, and find out how the “happy.grunwald” user account got compromised.
We can use artifacts like Process Logs from Sysmon if available, prefetch, lnk files, Managed File Transfer (MFT), or registry to gain insights on what occurred around the time when AS-REP activity was noticed.
To prevent AS-REP Roasting attacks, it is crucial to start by identifying all user accounts that do not require Kerberos pre-authentication. If not requiring pre-authentication is not necessary, ensure that pre-authentication is enabled for every account.
Always implement a robust password policy with long, complex passwords that are changed regularly. If possible, enhance security by enabling 2FA on authenticated services.
