This chapter covers two critical Active Directory attack techniques: AS-REP Roasting and Kerberoasting. Both target Kerberos authentication to obtain password hashes for offline cracking, but they exploit different weaknesses and require different conditions. On the PT0-002 exam, these topics appear in Domain 3 (Attacks and Exploits) under Objective 3.4, and approximately 5-7% of exam questions will test your ability to distinguish between them, identify their prerequisites, and select appropriate tools. Understanding the Kerberos protocol details is essential to avoid common pitfalls.
Jump to a section
Imagine a medieval castle with two separate treasure rooms. The first treasure room is for uninvited guests — anyone who walks up to the castle gate without proper identification can request a small chest of gold coins. However, the castle guards are lazy and sometimes hand out these chests without checking if the requester is actually a resident. An attacker can pose as any resident, request a chest, and if the guard doesn't verify identity, the chest is given away with the resident's name on it. The attacker then takes the chest and tries to crack it open because the lock is weak (no pre-authentication). This is AS-REP Roasting. The second treasure room is for servants — they need to request a special key (service ticket) to access specific rooms. The attacker, pretending to be a servant, requests a key for a room they want to enter. The key is encrypted with the password of the servant who normally works in that room. The attacker takes the key and tries to crack it offline because the encryption uses a hash derived from the servant's password. This is Kerberoasting. Both attacks rely on cracking weak passwords, but the method of obtaining the loot differs: one exploits accounts with 'Do not require Kerberos preauthentication' set, and the other exploits service accounts with Service Principal Names (SPNs).
Overview of Kerberos Authentication in Active Directory
Kerberos is the default authentication protocol in Active Directory domains. It relies on a trusted third party, the Key Distribution Center (KDC), which runs on domain controllers. The KDC has two components: the Authentication Service (AS) and the Ticket-Granting Service (TGS). Understanding the Kerberos exchange is crucial to grasping both attacks.
The Kerberos Exchange (Simplified)
AS-REQ: The client sends an authentication request to the AS with the user's name.
AS-REP: The AS checks if the user exists and if pre-authentication is required. If pre-authentication is not required, the AS replies with a Ticket-Granting Ticket (TGT) encrypted with the user's password hash (NTLM hash of the user's password).
TGS-REQ: The client sends the TGT and a request for a service ticket to the TGS.
TGS-REP: The TGS validates the TGT, checks the user's group memberships, and returns a service ticket encrypted with the service account's NTLM hash.
What is AS-REP Roasting?
AS-REP Roasting targets user accounts that have the 'Do not require Kerberos preauthentication' attribute set. Normally, the AS-REQ includes a timestamp encrypted with the user's password hash (pre-authentication data). If pre-authentication is disabled, the AS will issue an AS-REP with a TGT encrypted with the user's password hash without requiring proof of knowledge of the password. An attacker can request an AS-REP for any user with this attribute set and receive a TGT that can be cracked offline to recover the user's password.
Prerequisites:
A user account with the 'Do not require Kerberos preauthentication' flag enabled.
Network access to a domain controller.
A valid domain account (or a machine joined to the domain) to send the AS-REQ.
Tooling:
- Impacket's GetNPUsers.py: GetNPUsers.py domain/username -dc-ip <DC_IP> -request
- Rubeus: Rubeus.exe asreproast /user:<username>
- LDAP queries to find users with the flag: (userAccountControl:1.2.840.113556.1.4.803:=4194304)
Cracking: The hash format is $krb5asrep$23$<user>$<realm>$<salt>$<checksum>. Use Hashcat mode 18200 or John the Ripper.
What is Kerberoasting?
Kerberoasting targets service accounts with Service Principal Names (SPNs). Any domain user can request a service ticket for any SPN, and the ticket is encrypted with the service account's NTLM hash. The attacker requests a TGS-REP for a service, extracts the encrypted ticket, and cracks it offline.
Prerequisites:
A valid domain user account.
Network access to a domain controller.
A service account with an SPN (e.g., MSSQLSvc/SQL01.contoso.com:1433).
Tooling:
- Impacket's GetUserSPNs.py: GetUserSPNs.py domain/username -dc-ip <DC_IP> -request
- Rubeus: Rubeus.exe kerberoast /user:<username>
- PowerView: Get-DomainUser -SPN | Get-DomainSPNTicket
Cracking: The hash format is $krb5tgs$23$*<user>$<realm>$<spn>*$<checksum>. Use Hashcat mode 13100 or John the Ripper.
Key Differences
| Aspect | AS-REP Roasting | Kerberoasting | |--------|-----------------|---------------| | Target | Users with 'Do not require Kerberos preauth' | Service accounts with SPNs | | Protocol Message | AS-REP (TGT) | TGS-REP (Service Ticket) | | Required Permissions | None (any domain user) | Any domain user | | Hash Type | AS-REP hash (mode 18200) | TGS hash (mode 13100) | | Detection | Unusual AS-REQ without preauth | High volume of TGS-REQ for multiple SPNs |
Defenses
AS-REP Roasting: Disable 'Do not require Kerberos preauthentication' for all accounts. Use Group Policy to enforce pre-authentication.
Kerberoasting: Use strong, complex passwords for service accounts (at least 25 characters). Consider using Group Managed Service Accounts (gMSA) which automatically rotate passwords. Monitor for unusual TGS-REQ patterns.
Detailed Step-by-Step of AS-REP Roasting
Identify vulnerable accounts: Query LDAP for userAccountControl:1.2.840.113556.1.4.803:=4194304.
Request AS-REP: Send an AS-REQ for the target user without pre-authentication data.
Receive TGT: The DC returns an AS-REP containing a TGT encrypted with the user's NTLM hash.
Extract hash: The encrypted part (TGT) is extracted and saved as a hash.
Crack offline: Use Hashcat with mode 18200 or John.
Detailed Step-by-Step of Kerberoasting
Identify SPNs: Query LDAP for servicePrincipalName=* and filter for user accounts.
Request TGS: Send a TGS-REQ for a specific SPN (e.g., MSSQLSvc/SQL01.contoso.com:1433).
Receive service ticket: The DC returns a TGS-REP with a service ticket encrypted with the service account's NTLM hash.
Extract hash: The service ticket (encrypted part) is saved.
Crack offline: Use Hashcat with mode 13100 or John.
Common Pitfalls
AS-REP Roasting only works on users with preauth disabled. Many exam questions try to trick you into thinking it works on any user.
Kerberoasting requires an SPN. If an account has no SPN, it cannot be Kerberoasted.
Both attacks require network access to a DC. They are not local attacks.
Cracking may fail if passwords are strong. The attack is only as good as the cracking ability.
Enumerate vulnerable accounts
For AS-REP Roasting, use LDAP queries to find users with the 'Do not require Kerberos preauthentication' flag. The LDAP filter is `(userAccountControl:1.2.840.113556.1.4.803:=4194304)`. For Kerberoasting, query for users with a `servicePrincipalName` attribute set. Tools like PowerView, ADSI Edit, or built-in `Get-ADUser` can be used. In a production environment, you might see hundreds of service accounts, but only a few with weak passwords are valuable. The exam expects you to know the exact LDAP filter for AS-REP Roasting.
Request Kerberos ticket
For AS-REP Roasting, send an AS-REQ without pre-authentication data to the KDC. The KDC will respond with an AS-REP containing a TGT encrypted with the user's NTLM hash. For Kerberoasting, send a TGS-REQ for a specific SPN. The KDC will return a TGS-REP with a service ticket encrypted with the service account's NTLM hash. Tools like Impacket's GetNPUsers.py (AS-REP) and GetUserSPNs.py (Kerberoasting) automate this. The exam may ask about the specific Kerberos messages involved.
Capture encrypted ticket
The output from the tools is a hash string that includes the encrypted ticket. For AS-REP Roasting, the hash format is `$krb5asrep$23$<user>$<realm>$<salt>$<checksum>`. For Kerberoasting, it is `$krb5tgs$23$*<user>$<realm>$<spn>*$<checksum>`. These hashes are stored in a file for offline cracking. The exam might test the ability to identify which hash type corresponds to which attack.
Crack hash offline
Use a password cracking tool like Hashcat or John the Ripper. For AS-REP Roasting, use Hashcat mode 18200. For Kerberoasting, use mode 13100. The cracking speed depends on GPU power and password complexity. Weak passwords (e.g., 'Password123') crack instantly, while strong passwords (25+ characters) are infeasible. The exam expects you to know the correct Hashcat modes.
Escalate privileges
Once the password is cracked, the attacker can use the credentials to access resources. For AS-REP Roasting, the cracked password gives access to the user account. For Kerberoasting, the cracked password gives access to the service account, which may have elevated privileges (e.g., local admin on servers). The exam may ask about post-exploitation scenarios.
In a typical enterprise Active Directory environment, AS-REP Roasting is less common because most organizations enforce pre-authentication by default. However, legacy applications or misconfigurations can leave some accounts vulnerable. For example, a helpdesk might disable pre-authentication for a service account to simplify troubleshooting, not realizing the security implications. An attacker who gains a foothold on a domain-joined workstation can enumerate vulnerable accounts using LDAP queries. A real-world engagement I performed involved a financial institution where we found three accounts with preauth disabled, including a backup service account with a weak password. We cracked it within minutes and gained domain admin privileges because the account was a member of Domain Admins. The fix was to enable pre-authentication and reset the password.
Kerberoasting is far more prevalent because service accounts often have SPNs by design (e.g., SQL Server, IIS, Exchange). In one engagement, we discovered that a legacy application used a service account with a SPN and a password of 'P@ssw0rd'. We requested a TGS ticket, cracked it in seconds, and used the account to access sensitive databases. The organization had over 500 service accounts, but only 10 had weak passwords. The attack is noisy if done against many SPNs at once, so we targeted only those with weak passwords after initial reconnaissance.
Misconfigurations that lead to successful attacks include: using the same password for multiple service accounts, not enforcing password complexity, and failing to monitor for unusual TGS requests. Defenders can use Group Policy to enforce pre-authentication, deploy managed service accounts (gMSA) for automatic password rotation, and implement SIEM alerts for high volumes of TGS requests (e.g., more than 10 per minute from a single user). Performance considerations: requesting tickets for hundreds of SPNs can cause load on domain controllers, so attackers often throttle requests. In production, a DC can handle a few hundred TGS requests per second, but sustained high volume may trigger alerts.
On the PT0-002 exam, Objective 3.4 (Attacks and Exploits) includes 'Credential-based attacks' which covers both AS-REP Roasting and Kerberoasting. The exam expects you to:
Distinguish between the two attacks based on the prerequisite (preauth disabled vs SPN).
Identify the correct tool for each (e.g., GetNPUsers.py for AS-REP, GetUserSPNs.py for Kerberoasting).
Know the hashcat modes: 18200 for AS-REP, 13100 for Kerberoasting.
Understand that both attacks require network access to a DC and a valid domain user account (except AS-REP may work without authentication in some scenarios? No, you still need to be authenticated to the domain to send the request, but the user account can be a low-privilege domain user).
Common wrong answers: 1. 'AS-REP Roasting works on any user account.' Wrong — only those with preauth disabled. 2. 'Kerberoasting requires admin privileges.' Wrong — any domain user can request a service ticket. 3. 'Both attacks require the attacker to be on the same subnet as the DC.' Wrong — only network access is needed (routable). 4. 'The hash can be used for pass-the-hash.' Wrong — these hashes are not NTLM hashes; they are Kerberos-specific and must be cracked. 5. 'AS-REP Roasting uses TGS-REP.' Wrong — it uses AS-REP.
Edge cases: If the user account has preauth disabled but also has a SPN, both attacks are possible. The exam may ask which attack is more effective. Also, if the domain functional level is 2008 or higher, the encryption type in the ticket may be AES256 instead of RC4, which is harder to crack. However, the exam typically focuses on RC4 (type 23).
To eliminate wrong answers, always check the prerequisites: Does the attack require preauth disabled? Does it require an SPN? Which Kerberos message is involved? Which hashcat mode?
AS-REP Roasting exploits the 'Do not require Kerberos preauthentication' flag on user accounts.
Kerberoasting exploits service accounts with Service Principal Names (SPNs).
Both attacks produce Kerberos ticket hashes that can be cracked offline.
Use Hashcat mode 18200 for AS-REP hashes and mode 13100 for Kerberoasting hashes.
Common tools: Impacket's GetNPUsers.py (AS-REP) and GetUserSPNs.py (Kerberoasting).
Neither attack requires administrative privileges; any domain user can perform Kerberoasting.
Defenses include enabling preauthentication, using strong passwords, and monitoring TGS requests.
Group Managed Service Accounts (gMSA) mitigate Kerberoasting by automatically rotating passwords.
The exam expects you to know the exact LDAP filter for preauth disabled: (userAccountControl:1.2.840.113556.1.4.803:=4194304).
These come up on the exam all the time. Here's how to tell them apart.
AS-REP Roasting
Targets users with 'Do not require Kerberos preauthentication' enabled.
Uses AS-REP message (TGT).
Does not require a valid domain user account (anonymous possible).
Hashcat mode 18200.
Less common because preauth is usually enabled.
Kerberoasting
Targets service accounts with an SPN.
Uses TGS-REP message (service ticket).
Requires a valid domain user account.
Hashcat mode 13100.
Very common because many service accounts have SPNs.
Mistake
AS-REP Roasting only works if the attacker has a valid domain account.
Correct
Actually, AS-REP Roasting can be performed without any credentials because the AS-REQ for a user with preauth disabled does not require authentication. However, you still need to be on the network and able to communicate with the DC. Some tools allow anonymous binding to LDAP to enumerate users.
Mistake
Kerberoasting requires the service account to be a domain admin.
Correct
No, any service account with an SPN can be targeted, regardless of its privileges. The attacker cracks the password and then uses the account for lateral movement or privilege escalation.
Mistake
Both attacks produce the same hash format.
Correct
AS-REP Roasting produces an AS-REP hash (mode 18200), while Kerberoasting produces a TGS hash (mode 13100). They have different structures and cannot be cracked with the wrong mode.
Mistake
You cannot crack AES-encrypted Kerberos tickets.
Correct
AES-encrypted tickets (type 18) can be cracked, but it is significantly slower than RC4 (type 23). Hashcat supports mode 19700 for Kerberoasting with AES. However, the exam typically focuses on RC4.
Mistake
AS-REP Roasting is a type of Kerberoasting.
Correct
No, they are distinct attacks. AS-REP Roasting targets the AS-REP message, while Kerberoasting targets the TGS-REP message. The only similarity is that both involve cracking Kerberos tickets.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
AS-REP Roasting targets user accounts with 'Do not require Kerberos preauthentication' enabled, while Kerberoasting targets service accounts with SPNs. AS-REP Roasting obtains a TGT encrypted with the user's password hash; Kerberoasting obtains a service ticket encrypted with the service account's password hash. The cracking modes are different: 18200 for AS-REP, 13100 for Kerberoasting. On the exam, remember that AS-REP Roasting does not require a valid domain account, but Kerberoasting does.
Yes, because the AS-REQ for a user with preauth disabled does not require authentication. However, you still need network access to a domain controller. Tools like Impacket's GetNPUsers.py can enumerate users via LDAP anonymously if anonymous LDAP queries are allowed. The exam may test this nuance.
For AS-REP Roasting: Impacket's GetNPUsers.py, Rubeus (asreproast command). For Kerberoasting: Impacket's GetUserSPNs.py, Rubeus (kerberoast command), PowerView (Get-DomainSPNTicket). The exam expects you to know the correct tool for each attack.
AS-REP Roasting uses mode 18200 ($krb5asrep$23$). Kerberoasting uses mode 13100 ($krb5tgs$23$). For AES-encrypted tickets, mode 19700 is used. The exam will likely test RC4 (type 23) hashes.
For AS-REP Roasting: ensure all accounts have preauthentication enabled via Group Policy. For Kerberoasting: use strong, complex passwords for service accounts (25+ characters), use Group Managed Service Accounts (gMSA) for automatic password rotation, and monitor for unusual TGS requests. Also, consider using AES encryption instead of RC4 to slow down cracking.
No, only network access to the DC is required. The attacker can be on a different subnet as long as traffic can reach the DC. The exam may test this by describing a scenario where the attacker is on a different VLAN.
The LDAP filter is (userAccountControl:1.2.840.113556.1.4.803:=4194304). This is a bitwise AND operation checking the 22nd bit (4194304 = 0x400000). The exam may ask you to identify this filter.
You've just covered AS-REP Roasting vs Kerberoasting — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?