This chapter covers Kerberoasting and AS-REP roasting, two critical attack techniques against Active Directory Kerberos authentication that appear frequently on the PT0-002 exam. These attacks target service accounts and user accounts configured without Kerberos pre-authentication, allowing attackers to obtain password hashes offline for cracking. Approximately 5-10% of exam questions touch on these topics, often in the context of post-exploitation and credential access. Understanding the underlying Kerberos protocol mechanics is essential for both performing these attacks in a penetration test and implementing effective defenses.
Jump to a section
Kerberoasting is like a library where VIP members (service accounts) have special keys to restricted rooms (service tickets). The library stores a master key list (TGS) that includes encrypted copies of all VIP keys (service account NTLM hashes) used to access rooms. An attacker, pretending to be a regular member, can request a copy of any VIP key by asking the librarian (KDC) for access to a specific room. The librarian, not knowing the attacker's intent, hands over an encrypted key (TGS ticket) that is locked with the VIP's actual key (service account password hash). The attacker cannot open the key directly but can take it offline and try to brute-force the lock by guessing the VIP's password. Once cracked, the attacker has a duplicate key and can enter the restricted room whenever they want. AS-REP roasting is similar, but instead of requesting keys for rooms, the attacker asks for the master key list itself for users who don't require pre-authentication. The librarian, for those users, hands over an encrypted copy of their key (AS-REP response) without checking identity, allowing offline brute-force. Both attacks exploit the fact that the library's key distribution system (Kerberos) uses weak or guessable passwords for service accounts and users without pre-authentication.
What Are Kerberoasting and AS-REP Roasting?
Kerberoasting and AS-REP roasting are post-exploitation attacks that target the Kerberos authentication protocol in Active Directory environments. Both attacks aim to obtain password hashes of user accounts that can be cracked offline, bypassing account lockout policies and logging mechanisms. The PT0-002 exam covers these attacks under Objective 3.4 (Exploit weaknesses in authentication systems) and expects you to understand the protocol flow, tool usage, and mitigation strategies.
Kerberoasting specifically targets service accounts that have a Service Principal Name (SPN) registered in Active Directory. Any domain user can request a Kerberos service ticket (TGS) for any SPN, and the ticket is encrypted with the service account's NTLM hash. The attacker extracts this encrypted ticket and performs offline brute-force to recover the plaintext password. AS-REP roasting targets user accounts that have the 'Do not require Kerberos pre-authentication' flag set. For these accounts, an attacker can request an authentication response (AS-REP) without providing any credentials, and the response contains encrypted data using the user's NTLM hash, which can be cracked offline.
How Kerberos Works – The Foundation
To understand these attacks, you must first understand the Kerberos ticket-granting process. Kerberos uses three main messages: - AS-REQ (Authentication Service Request): Client sends username to KDC (Key Distribution Center, which is the Domain Controller). - AS-REP (Authentication Service Reply): KDC responds with a TGT (Ticket-Granting Ticket) encrypted with the user's NTLM hash. - TGS-REQ (Ticket-Granting Service Request): Client sends TGT and requests a service ticket for a specific SPN. - TGS-REP (Ticket-Granting Service Reply): KDC sends a service ticket encrypted with the target service account's NTLM hash.
In Kerberoasting, the attacker skips the AS-REQ/AS-REP phase (they already have a valid TGT) and directly requests TGS tickets for SPNs of interest. The TGS-REP contains a service ticket that includes a portion encrypted with the service account's NTLM hash. The attacker receives this encrypted blob and can attempt to crack it offline.
Kerberoasting Step-by-Step Mechanism
Enumerate SPNs: The attacker uses tools like setspn -Q */* or PowerView's Get-NetUser -SPN to list all service accounts with SPNs. Any domain user can query this information.
Request TGS: The attacker uses a valid TGT (obtained through normal authentication, e.g., as a low-privilege user) to request a TGS for each target SPN. The KDC does not verify whether the requester has permission to access the service; it only checks that the SPN exists.
Extract Ticket: The TGS-REP contains a ticket encrypted with the service account's NTLM hash. Tools like Rubeus or Impacket's GetUserSPNs.py can extract this ticket and save it in a format suitable for cracking (e.g., John the Ripper or Hashcat format).
Offline Cracking: The attacker cracks the hash using a wordlist or brute-force. Since service account passwords are often long but may be weak (e.g., Service@123), cracking is feasible.
Key Details for the Exam:
- The TGS ticket is encrypted with the service account's NTLM hash, not the user's hash.
- The attack does not require special privileges; any authenticated domain user can request TGS for any SPN.
- The encryption type used in the ticket matters: RC4 (type 23) is easier to crack than AES (type 18). The exam may ask which encryption type is more vulnerable.
- Tools: Rubeus, Impacket, PowerView, Mimikatz (for extraction).
AS-REP Roasting Step-by-Step Mechanism
Find Users Without Pre-Authentication: The attacker enumerates users with the DONT_REQ_PREAUTH flag set. Tools like ldapsearch or PowerView can query for userAccountControl:1.2.840.113556.1.4.803:=4194304.
Request AS-REP: The attacker sends an AS-REQ for the target user without including a timestamp encrypted with the user's password hash (which is the pre-authentication requirement). The KDC, seeing the flag, responds with an AS-REP that includes encrypted data using the user's NTLM hash.
Extract Hash: The AS-REP contains a session key and other data encrypted with the user's hash. Tools like Rubeus with the /asreproast flag or Impacket's GetNPUsers.py extract this data.
Offline Cracking: Same as Kerberoasting; crack the hash offline.
Key Details:
- Only works for users with the 'Do not require Kerberos pre-authentication' flag enabled.
- No authentication required; the attacker can be unauthenticated (anonymous) or authenticated.
- The encrypted data uses the user's password hash, not a service account hash.
- Tool: Rubeus asreproast, Impacket GetNPUsers.
Differences and Comparisons
| Feature | Kerberoasting | AS-REP Roasting |
|---------|---------------|-----------------|
| Target | Service accounts with SPNs | Users with pre-auth disabled |
| Requires authentication? | Yes (valid TGT) | No (can be anonymous) |
| Hash type | Service account NTLM | User NTLM |
| Privilege required | Low (domain user) | None (anonymous) |
| Common tool | Rubeus kerberoast, GetUserSPNs.py | Rubeus asreproast, GetNPUsers.py |
Encryption Types and Cracking Difficulty
Kerberos supports multiple encryption types for tickets: - RC4-HMAC (type 23): Uses the NTLM hash directly. This is the easiest to crack because the hash is unsalted and can be fed directly to hashcat mode 13100 (for TGS) or 18200 (for AS-REP). - AES128-CTS-HMAC-SHA1 (type 17) and AES256-CTS-HMAC-SHA1 (type 18): More computationally expensive to crack. However, tools like hashcat support these modes (19700 for Kerberoast AES, 19600 for AS-REP AES). - DES (type 1): Obsolete but still possible; easily crackable.
The exam may ask which encryption type is most vulnerable to offline cracking. The answer is RC4 because it uses the unsalted NTLM hash, which can be cracked quickly with tools like hashcat using mode 13100.
Mitigation Strategies
Use Strong Service Account Passwords: At least 25 characters with complexity. This makes cracking infeasible.
Use Managed Service Accounts (gMSA): gMSAs have automatically rotated, complex passwords that are not known to any user.
Disable RC4 Encryption: If all systems support AES, disable RC4 in Kerberos. This forces tickets to use AES, which is harder to crack. However, this can cause compatibility issues.
Monitor for TGS Requests: Anomalous requests for many TGS tickets from a single user can indicate Kerberoasting. Enable logging for Kerberos service ticket operations (Event ID 4769).
Set 'Do not require pre-authentication' Only When Necessary: This flag should be set only for specific use cases (e.g., some Linux services). Regularly audit for such accounts.
Use Group Managed Service Accounts (gMSA) for Services: gMSAs automatically rotate passwords and are not tied to a user account.
Common Tools and Commands
Rubeus (Windows):
- Kerberoast: Rubeus kerberoast /outfile:hashes.txt
- AS-REP roast: Rubeus asreproast /outfile:asrephashes.txt
Impacket (Linux):
- Kerberoast: GetUserSPNs.py domain/user:password -dc-ip 10.0.0.1 -request
- AS-REP roast: GetNPUsers.py domain/ -dc-ip 10.0.0.1 -request -format hashcat
PowerView:
- Find SPNs: Get-NetUser -SPN
- Find users with pre-auth disabled: Get-NetUser -PreauthNotRequired
Exam Relevance
The PT0-002 exam expects you to:
Identify the attack based on a scenario (e.g., "An attacker requests service tickets for multiple SPNs" -> Kerberoasting).
Know which encryption type is most vulnerable (RC4).
Recommend mitigations (use gMSA, strong passwords, disable RC4).
Understand that Kerberoasting requires valid domain credentials, while AS-REP roasting does not.
Recognize that both attacks are post-exploitation and often used after gaining initial access.
Summary of Key Numbers and Defaults
Kerberos uses UDP/TCP port 88.
Default Kerberos encryption type in modern Windows is AES256, but RC4 is often still supported for backward compatibility.
The 'Do not require pre-authentication' flag corresponds to bit 11 in userAccountControl (value 4194304).
Service tickets have a default lifetime of 10 hours (configurable).
TGT lifetime is typically 10 hours with a renewal limit of 7 days.
This deep understanding of the protocol mechanics will help you answer scenario-based questions correctly and avoid common pitfalls.
Enumerate SPNs or Pre-Auth Users
The attacker first identifies potential targets. For Kerberoasting, they enumerate all service accounts with SPNs using tools like `setspn -Q */*` or PowerView's `Get-NetUser -SPN`. For AS-REP roasting, they query for users with the 'Do not require Kerberos pre-authentication' flag set, often using LDAP filters like `(&(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))`. This enumeration does not require special privileges; any domain user can perform these queries. The attacker notes the usernames and SPNs for later use.
Obtain TGT for Kerberoasting
Kerberoasting requires a valid TGT. The attacker authenticates to the domain using compromised credentials (e.g., low-privilege user). This step is not needed for AS-REP roasting because the attacker does not need to authenticate. The TGT is obtained by sending an AS-REQ with the user's password hash and receiving an AS-REP containing the TGT encrypted with that hash. The attacker caches this TGT to use in subsequent TGS requests.
Request Service Tickets (TGS)
For Kerberoasting, the attacker uses the TGT to request TGS tickets for each target SPN. They send a TGS-REQ to the KDC specifying the SPN. The KDC looks up the service account associated with that SPN, generates a service ticket encrypted with the service account's NTLM hash, and sends it back in a TGS-REP. The attacker does not need any permissions on the target service; the KDC will issue the ticket as long as the SPN exists. For AS-REP roasting, the attacker sends an AS-REQ for the target user without pre-authentication data. The KDC responds with an AS-REP containing encrypted data using the user's NTLM hash.
Extract Encrypted Hashes
The attacker extracts the encrypted portion of the TGS ticket (for Kerberoasting) or the AS-REP (for AS-REP roasting). Tools like Rubeus and Impacket automate this extraction and output the data in a format compatible with hashcat or John the Ripper. For Kerberoasting, the extracted hash format is typically `$krb5tgs$23$*user$realm$spn*$...` for RC4 or `$krb5tgs$18$...` for AES. For AS-REP roasting, the format is `$krb5asrep$23$user@realm:...`. The attacker saves these to a file for offline cracking.
Offline Brute-Force Cracking
The attacker uses a password cracking tool like hashcat or John the Ripper to crack the extracted hashes. For RC4 hashes, hashcat mode 13100 (Kerberoast) or 18200 (AS-REP) is used. The attacker supplies a wordlist (e.g., rockyou.txt) and may use rules to generate variations. Since service account passwords are often weak, cracking can succeed quickly. The attacker then uses the cracked passwords to escalate privileges or access additional resources. The offline nature of this step means no account lockouts occur, and no logs are generated on the domain controller.
In enterprise environments, Kerberoasting is a common post-exploitation technique used by red teams and attackers after gaining initial foothold. Consider a scenario where a penetration tester has compromised a workstation as a low-privilege domain user. Using PowerView, they enumerate all SPNs and find a SQL Server service account with a weak password. They request a TGS ticket for the SQL service, extract the RC4-encrypted hash, and crack it offline to reveal the password 'SQL@dmin2020'. With this password, they can log into the SQL server and access sensitive databases. This attack is particularly dangerous because the service account often has elevated privileges.
AS-REP roasting is less common but equally dangerous when misconfigurations exist. For example, a help desk might disable pre-authentication for a user account to troubleshoot authentication issues, then forget to re-enable it. An attacker scanning for such accounts finds one and, without any credentials, obtains the user's hash. If the user's password is weak, the attacker gains access to that user's resources. In one engagement, a tester found a domain admin account with pre-auth disabled due to legacy application requirements. The AS-REP hash was cracked to reveal 'P@ssw0rd', granting full domain compromise.
Mitigation in production involves several layers. First, enforce strong password policies for service accounts (e.g., 25+ characters). Second, use Group Managed Service Accounts (gMSAs) which have 120-character random passwords that rotate automatically. Third, disable RC4 encryption in the domain if possible, forcing AES encryption that is harder to crack. Fourth, monitor for Event ID 4769 (Kerberos service ticket request) with anomalous patterns, such as a user requesting tickets for many different SPNs in a short time. Finally, regularly audit for accounts with pre-authentication disabled and ensure they are justified.
Performance considerations: Requesting many TGS tickets can cause load on domain controllers, but typically not enough to alert. However, in large environments with thousands of SPNs, the enumeration step can be noisy. Tools like Rubeus have options to throttle requests. The cracking step is computationally intensive; using GPU acceleration with hashcat can crack RC4 hashes at billions of attempts per second. For AES hashes, cracking is significantly slower, making strong passwords effective.
Misconfiguration pitfalls include: leaving RC4 enabled for compatibility, using weak passwords for service accounts (e.g., same as the machine name), and not rotating passwords regularly. Additionally, some administrators mistakenly believe that disabling pre-authentication is harmless because the user still needs to know the password to use the account. However, AS-REP roasting proves that the hash can be obtained without knowledge of the password, making offline cracking possible.
The PT0-002 exam tests Kerberoasting and AS-REP roasting under Objective 3.4 (Exploit weaknesses in authentication systems). You should expect scenario-based questions where you must identify the attack, the required privileges, the encryption type vulnerability, and appropriate mitigations.
Common Wrong Answers and Why: 1. 'Kerberoasting requires no authentication' – This is false. Kerberoasting requires a valid TGT, meaning the attacker must have authenticated as a domain user. AS-REP roasting does not require authentication. Candidates often confuse the two. 2. 'AS-REP roasting targets service accounts' – False. AS-REP roasting targets user accounts with pre-authentication disabled. Service accounts are targeted by Kerberoasting. 3. 'The attack can be prevented by disabling Kerberos' – Not practical. Mitigations involve strong passwords, gMSAs, disabling RC4, and monitoring. 4. 'Only domain admins can request TGS tickets' – False. Any authenticated user can request a TGS for any SPN.
Specific Numbers and Terms to Memorize: - RC4 encryption type is type 23; AES128 is type 17; AES256 is type 18. - Hashcat mode 13100 for Kerberoast RC4; mode 18200 for AS-REP RC4. - The userAccountControl bit for 'Do not require pre-authentication' is 4194304 (bit 11). - Default Kerberos ticket lifetime: TGT 10 hours, service ticket 10 hours. - Port 88 (UDP/TCP) for Kerberos.
Edge Cases the Exam Loves: - If the domain is configured to only use AES encryption, Kerberoasting is still possible but the hash is AES-encrypted, which is more difficult to crack. The attack is still valid. - If the service account password is extremely complex (e.g., 64 random characters), cracking is infeasible, but the attack still occurs. - For AS-REP roasting, if the user account has pre-authentication disabled but also has a smart card requirement, the AS-REP may still be obtainable, but the hash might be different.
How to Eliminate Wrong Answers: Focus on the mechanism: Kerberoasting requires a TGT (authentication); AS-REP does not. The hash is from the service account for Kerberoasting, from the user for AS-REP. If a question mentions 'service ticket', it's Kerberoasting; if it mentions 'authentication request', it's AS-REP. Mitigation questions should point to strong passwords, gMSAs, disabling RC4, and monitoring logs (Event 4769).
Kerberoasting requires a valid TGT (authenticated user) to request service tickets; AS-REP roasting does not require authentication.
The TGS ticket is encrypted with the service account's NTLM hash; the AS-REP is encrypted with the user's NTLM hash.
RC4 encryption (type 23) is most vulnerable because it uses unsalted NTLM hash; AES (type 17/18) is more resistant.
Hashcat mode 13100 for Kerberoast RC4; mode 18200 for AS-REP RC4.
The 'Do not require pre-authentication' flag corresponds to userAccountControl value 4194304.
Mitigation: Use gMSAs, strong passwords (25+ chars), disable RC4, monitor Event ID 4769.
Both attacks are post-exploitation and often used to escalate privileges after initial access.
Any domain user can enumerate SPNs and users with pre-auth disabled; no special privileges needed.
Offline cracking avoids account lockout and does not generate failed logon events.
Kerberos uses port 88 (UDP/TCP) and default ticket lifetime of 10 hours.
These come up on the exam all the time. Here's how to tell them apart.
Kerberoasting
Targets service accounts with SPNs
Requires valid domain credentials (TGT)
Requests TGS tickets for specific SPNs
Encrypted with service account NTLM hash
Common tool: Rubeus kerberoast
AS-REP Roasting
Targets user accounts with pre-auth disabled
Does not require any credentials (anonymous)
Requests AS-REP without pre-authentication
Encrypted with user NTLM hash
Common tool: Rubeus asreproast
Mistake
Kerberoasting requires domain admin privileges.
Correct
Any authenticated domain user can request TGS tickets for any SPN. The attack is a privilege escalation vector, not a requirement.
Mistake
AS-REP roasting requires the attacker to know the user's password.
Correct
AS-REP roasting does not require any credentials. The attacker sends an AS-REQ without pre-authentication and receives encrypted data that can be cracked offline.
Mistake
Disabling RC4 encryption completely prevents Kerberoasting.
Correct
Disabling RC4 forces the use of AES encryption, which makes cracking more difficult but does not prevent the attack. The attacker can still obtain the encrypted ticket and attempt to crack it.
Mistake
Service account passwords are automatically strong and rotated.
Correct
Many organizations set service account passwords manually and rarely change them. They are often weak or stored in scripts. gMSAs are the only way to ensure automatic rotation and strong passwords.
Mistake
Kerberoasting and AS-REP roasting generate alerts on the domain controller.
Correct
These attacks do not generate failed logon events because the attacker already has a valid TGT (Kerberoasting) or uses the pre-auth bypass (AS-REP). However, Event ID 4769 (Kerberos service ticket request) can be monitored for unusual volumes.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Kerberoasting targets service accounts by requesting TGS tickets encrypted with the service account's NTLM hash. It requires valid domain credentials (a TGT). AS-REP roasting targets user accounts with pre-authentication disabled, obtaining an AS-REP encrypted with the user's NTLM hash without any credentials. The main difference is the target and the authentication requirement.
No, Kerberoasting requires a valid TGT, which means the attacker must authenticate as a domain user first. However, the user can be low-privileged. AS-REP roasting does not require authentication.
RC4-HMAC (type 23) is most vulnerable because it uses the unsalted NTLM hash, which can be cracked quickly with hashcat. AES encryption (type 17/18) is more resistant but still crackable with enough resources.
Enable logging for Kerberos service ticket requests (Event ID 4769). Look for a single user requesting tickets for many different SPNs in a short period. Also monitor for use of tools like Rubeus or Impacket via process creation logs.
Ensure that no user accounts have the 'Do not require Kerberos pre-authentication' flag set unless absolutely necessary. Regularly audit for such accounts. Additionally, enforce strong password policies to make cracking infeasible.
No, it only forces the use of AES encryption, which is more difficult to crack but still possible. The attack itself still works; the attacker obtains the encrypted ticket and attempts to crack it.
Common tools include Rubeus (Windows), Impacket's GetUserSPNs.py (Linux), and PowerView (PowerShell). These tools automate the extraction of TGS tickets and formatting for cracking.
You've just covered Kerberoasting and AS-REP Roasting — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?