AS-REP roasting technique explained
Learn how to enumerate Active Directory accounts and get their passwords with no access
to the domain in a special series on exploiting Active Directory (AD).
Welcome to our specialized series on exploiting Active Directory (AD) as we delve into various techniques. Each blog post explores the ins and outs of Active Directory internals and explains how they can be leveraged from an offensive cybersecurity professional’s perspective.
Do not hesitate to check out other posts from the series!
Today, we’ll dive deep into AS-REP roasting. You’ll learn how to target Active Directory accounts and extract their passwords without needing domain access. This method exploits accounts with pre-authentication disabled, allowing attackers to obtain service tickets for offline password cracking.
What is AS-REP roasting?
AS-REP roasting is an attack technique used in the context of Active Directory and Kerberos authentication, specifically targeting user accounts that have the Do not require Kerberos pre-authentication flag set.
To fully understand what AS-REP roasting is, we first need to understand what Kerberos is and how it works.
Kerberosis the most commonly used authentication protocol in Windows domains. It is used for authentication of users, computers and services. Whenever user, service, or computer accounts authenticate to another service, like accessing a file share, database, or web application, the service will need to ask the Domain Controller to verify if they are correct.
Kerberos uses tickets to grant access, starting with a request for a Ticket Granting Ticket (TGT), which serves as proof of the requester’s identity. The TGT allows users to request Ticket Granting Service (TGS) for access to specific services without having to provide their credentials each time they connect.
To obtain a Ticket Granting Ticket (TGT), a client must complete pre-authentication by sending an Authentication Service Request (AS-REQ) that includes the principal name and a timestamp, with the timestamp encrypted using the user’s password-derived key (NTLM hash).
AS-REQ is sent to Domain Controller’s Kerberos service (KDC), then it is validated and KDC replies with Kerberos AS-REP.
The KDC will create and send back a Ticket Granting Ticket (TGT), which will allow the requestor to request additional tickets to access specific services. TGT is encrypted using the krbtgt (Kerberos service account) password hash, therefore the user cannot access its contents.
Along with the TGT, a Session Key encrypted with the requestor’s password hash is sent back.
This part is the most important in AS-REP roasting, we can save the AS-REP with encrypted session key and later on attempt to crack it to get user password hash.
By combining the Do not require Kerberos pre-authentication setting with session key cracking, here’s what happens.
For accounts with this setting enabled, the pre-authentication step is skipped, which would normally verify the rightful principal for the TGT. Instead, an AS-REP response can be requested for any such account.
This response is then collected for offline cracking to reveal the account’s hash, which can then be used to attempt cracking the principal’s password.
AS-REP roasting in action
Now it’s time to put this knowledge into action. In our case study, we will use a non-AD-joined Kali Linux host to perform enumeration without relying on a compromised AD account.
To demonstrate the attack technique, we will show the most efficient way – the automated process. However, this can also be done manually by following these steps:
- Gather a list of users of your target domain
- Query pre-authentication disabled users using LDAP (e.g., PowerShell DirectoryServices, ldapsearch).
- Trigger Kerberos authentication with their usernames, for example using the runas utility.
- Intercept the AS-REP response (e.g., tcpdump, ettercap).
- Format the response into a hash format and attempt to crack it with a tool of your choice.
Note: It is good to understand the manual process; however, performing AS-REP roasting this way does not offer any significant advantages over the automated approach from an OPSEC perspective. The automation tools listed later on provide enough flexibility to customize the process for most common scenarios.
We decided to demonstrate the process using automation – describing each step mentioned above and outlining where it takes place.
In our demonstration, we will use a Python tool called NetExec which can be downloaded from the following repository: https://github.com/Pennyw0rth/NetExec/tree/main
However, other tools like Rubeus, Impacket (GetNPUser), or Mimikatz can achieve the same results.
1. Gather a list of users of your target domain
Before we even run NetExec we have to gather potentially active users in our target domain to then query them and see who has pre-authentication enabled. We can do it several different ways, using OSINT, company data breaches exposed publicly, lists and so on.
We can also use lists that contain most commonly used users and format them to the company’s potential login pattern format.
// Imagine we found user Elizabeth Swann on LinkedIn working at a company, we transform her name and surname into the most likely used format by the company like [email protected], [email protected] etc.
Once we created such a users list and formatted it to our needs, we can go ahead with our attack technique exploitation process.
As always, before using a tool, it is recommended at first to get to know it better, not to get infected if the code got compromised, sharpen our skills, learn the attack technique and how the tool is automating it.
2. Query pre-authentication disabled users using LDAP
NetExec starts AS-REP roasting in nxc/protocols/ldap.py script. It begins there as it uses at first an LDAP query to spot users with pre-auth disabled. It uses the following search_filter to do it:
search_filter = "(&(UserAccountControl:1.2.840.113556.1.4.803:=%d)(!(UserAccountControl:1.2.840.113556.1.4.803:=%d))(!(objectCategory=computer)))" % (UF_DONT_REQUIRE_PREAUTH, UF_ACCOUNTDISABLE)
Ref. https://github.com/Pennyw0rth/NetExec/blob/main/nxc/protocols/ldap.py#L885
The search initially looks for the UserAccountControl LDAP attribute with the value UF_DONT_REQUIRE_PREAUTH , where UF_ACCOUNTDISABLE is not set—meaning the account is not disabled – and the objectCategory is not “computer”, as we are not interested in computer accounts.
3/4/5. Trigger Kerberos auth, intercept AS-REP, and output the hash in a format suitable for cracking
After finding the accounts, NetExec uses the KerberosAttack class from its own module nxc.protocols.ldap.kerberos, which is implemented using Impacket – a collection of Python classes for working with network protocols.
– NetExec KerberosAttack class: https://github.com/Pennyw0rth/NetExec/blob/main/nxc/protocols/ldap/kerberos.py#L26
– Impacket: https://github.com/fortra/impacket
Using the Impacket module, NetExec interacts with the target server in order to get AS-REP messages for previously retrieved user objects.
Then, it also uses the KerberosAttack class in nxc.protocols.ldap.kerberos to format the received AS-REP messages to match the hashcat hash format that can be cracked later on.
Ref.
https://github.com/Pennyw0rth/NetExec/blob/main/nxc/protocols/ldap/kerberos.py#L258
So, once we know what tool is doing we can prepare command to run it targeting our Domain Controller.
At first we have to specify the module that we are going to use in our LDAP and our target IP.
Then, we specify the list of users that we got from reconnaisence process early on and blank password.
Then, the technique --asreproast, where to save the output output.txt, and in order to get details about the current state of the execution, we specify the --verbose flag.
IMPORTANT: In multi DC environment, it can happen that NetExec or other tooling falsely detect KDC (Key Distribution Center) IP, in such a case you have to manually put the IP address most likely of the Domain Controller you are targeting.
So finally the command is as follows:
sudo netexec ldap 10.10.10.5 -u users.txt -p '' --asreproast hashes.txt --verbose --kdc 10.10.10.5
As we can see, we got two hits. One was for our earlier mentioned user, spotted on LinkedIn elizabeth.swann. The second one was for p-np-svr2 user account, potentially misused as a service account instead of using MSA/gMSA accounts created for it.
Curious about MSA/gMSA accounts and their purpose? Let us know, we can take it further and explain them on practical examples in later blog posts! – ZenSec @ LinkedIn
Now, thanks to NetExec, all of the hashes in a format ready to be cracked by hashcat are in the output.txt file. The last piece of the puzzle that is left here is to attempt to crack them. We used hashcat module 18200 with brute-force mode using the most common leaked passwords list, with several additional passwords added by myself along the way of domain exploitation.
Hashcat list of modules: https://hashcat.net/wiki/doku.php?id=example_hashes
hashcat -m 18200 -a 0 -o cracked_hashes.txt hashes.txt /usr/share/wordlists/rockyou.txt
Congratulations! We have successfully obtained two username and password combinations ready to be used to help us in further compromise of the target domain.
Summary
In this post, we explored the AS-REP roasting technique in Active Directory, learning how to exploit accounts with Kerberos pre-authentication disabled to obtain user hashes.
We began by gathering a list of potential user accounts from the target domain. Next, we queried these users to identify those with pre-authentication disabled. After that, we used tools like NetExec to request AS-REP messages for the identified accounts, extract the user hashes, and then cracked them using Hashcat. This process allowed us to recover passwords that could potentially aid in further domain compromise.
Zensec 