Back

Keberoasting Vs ASREP Roasting

kerberoasting

Demystifying AS_REP Roasting and Kerberoasting: A Guide for the Curious

Kerberos is a core part of Windows Active Directory, is often thought of as a fortress. But like any fortress, there are ways to sneak in if you know where to look. Two such sneaky methods are AS_REP Roasting and Kerberoasting.

Key Terms

  • KDC (Key Distribution Center): The big boss of the Kerberos world, handling all ticket distributions.
  • TGS (Ticket Granting Server): Part of the KDC that hands out service tickets.
  • TGT (Ticket Granting Ticket): Your golden ticket for requesting access in the Kerberos realm.
  • ST (Service Ticket): A ticket for getting into specific services.
  • SPN (Service Principal Name): The unique ID for a service.

What is AS_REP Roasting?

AS_REP Roasting is an initial compromise attack which targets Kerberos accounts with preauthentication disabled.

In a typical Kerberos authentication flow, a user sends an AS_REQ request containing an encrypted timestamp to the KDC. The KDC decrypts this timestamp to verify the user's identity before issuing a Ticket Granting Ticket (TGT).

However, if preauthentication is disabled, the user can request a TGT without sending this encrypted timestamp, making it easier for attackers to obtain encrypted data that can be cracked offline.

Imagine you’re trying to get into an exclusive club. Usually, you’d need to show ID at the door. But if the bouncer’s asleep, you can just walk right in.

AS_REP Roasting works a bit like that. If an account doesn’t require preauthentication (like a sleeping bouncer), an attacker can request data that's encrypted with the user's password hash. They then take this data home and try to crack it at their leisure.

In CRISP

  1. What it targets:
    • User accounts with preauthentication disabled
  2. How it works:
    • An attacker requests a Ticket Granting Ticket (TGT) for a user account. If preauthentication is disabled, the Key Distribution Center (KDC) sends back an encrypted response without verifying the user's identity first.
  3. Goal:
    • TThe attacker captures the encrypted response and attempts to crack it offline to reveal the user's password.

Commands to Try:

# Load PowerView if not already loaded
Import-Module .\PowerView.ps1

# Find all user accounts with an SPN set
Get-DomainUser -SPN

if the user has spn tied up to its account we can exploit

#for single users
impacket-getnpusers -dc-ip domain_ip domain_name/username:password

#if you have identified multiple usernames

impacket-getnpusers -dc-ip domain_ip domain_name/username:password -usersfile users.txt -outputfile hashes.txt

you will get an hash which may be decryptable if the password is not much strong

hashcat -m 18200 <hash_file> /opt/rockyou.txt

How to Prevent It:

Kerberoasting: Cooking Up Service Accounts

What is Kerberoasting?

Kerberoasting is usually a post-compromise attack. It requires the attacker to already have valid domain user credentials and a valid TGT that targets service accounts in Kerberos.

When a user requests access to a service, the KDC issues a service ticket (TGS_REP) encrypted with the service account's password hash. Attackers can exploit this by requesting service tickets for SPNs tied to user accounts, which often have simpler passwords compared to machine accounts.

The attacker can then extract these tickets and crack them offline to obtain the service account passwords.

Kerberoasting is like tricking a waiter into bringing you the manager’s keys. Service accounts often have simpler, human-set passwords. An attacker can request a service ticket (ST) for these accounts, get a ticket encrypted with the service account's password hash, and then crack it to discover the password.

In CRISP

  1. What it targets:
    • Service accounts with Service Principal Names (SPNs).
  2. How it works:
    • An attacker with valid domain credentials requests a service ticket for a service account. The KDC sends back a service ticket encrypted with the service account's password hash.
  3. Goal:
    • The attacker captures the service ticket and attempts to crack it offline to reveal the service account's password.

Commands to Try:

ldapsearch -x -H 'ldap://<domain_ip' -D '<BASE_DN>"' -w 'specify password' -b
"dc=active,dc=htb" -s sub "(&(objectCategory=person)(objectClass=user)(!
(useraccountcontrol:1.2.840.113556.1.4.803:=2)))"

Powesploit-Powerview.ps1

# Load PowerView if not already loaded
Import-Module .\PowerView.ps1

# Find all user accounts with an SPN set
Get-DomainUser -SPN
# for better visiblity
Get-DomainUser -SPN | select Name,SrvicepPincipalnNme

if the user has spn tied up to its account we can exploit

impacket-GetUserSPNs domain_name/username:passsword -dc-ip <ip_of_the_machine> -request

you will get an hash which may be decryptable if the password is not much strong kerberoasting to break the hash

hashcat -m 18200 <hash_file> /opt/rockyou.txt

Conclusion: Keeping Your Kerberos Fortress Secure

AS_REP Roasting and Kerberoasting show that even strong systems like Kerberos can have weaknesses. AS_REP Roasting takes advantage of accounts without preauthentication, while Kerberoasting targets service accounts with weak passwords. To defend your fortress, ensure all accounts require preauthentication and use strong, complex passwords for service accounts. Regular audits and vigilant security practices are key to staying safe.

If you’re eager to learn more, here are some great resources:

Back to top