{"id":67,"date":"2025-03-12T05:55:11","date_gmt":"2025-03-12T05:55:11","guid":{"rendered":"http:\/\/racrx.io\/?p=67"},"modified":"2025-03-15T00:31:07","modified_gmt":"2025-03-15T00:31:07","slug":"as-rep-roasting-explained","status":"publish","type":"post","link":"https:\/\/racrx.io\/?p=67","title":{"rendered":"AS-REP Roasting Explained"},"content":{"rendered":"\n

AS-REP Roasting is a post-exploitation attack technique that targets user accounts in Active Directory (AD) that have the “Do not require Kerberos preauthentication” setting enabled. This allows an attacker to request and retrieve AS-REP (Authentication Server Response) messages, which contain an encrypted NTLM hash of the user\u2019s password, and crack them offline.<\/p>\n\n\n\n

\n\n\n\n

1. The Kerberos Authentication Process<\/strong><\/h2>\n\n\n\n

In a standard Kerberos authentication flow, the client requests a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC). This process involves:<\/p>\n\n\n\n

    \n
  1. The client sends an Authentication Service Request (AS-REQ).<\/li>\n\n\n\n
  2. The KDC responds with an Authentication Server Response (AS-REP), containing an encrypted TGT.<\/li>\n\n\n\n
  3. The encryption key for the AS-REP is derived from the user\u2019s NTLM hash.<\/li>\n<\/ol>\n\n\n\n

    Normally, Kerberos preauthentication is required, meaning the AS-REQ must be encrypted using the user\u2019s password-derived key to prove their identity before getting an AS-REP.<\/p>\n\n\n\n

    However, when the “Do not require Kerberos preauthentication” setting is enabled on an account, anyone can request an AS-REP without needing prior knowledge of the user’s password.<\/p>\n\n\n\n

    \n\n\n\n

    2. Attack Execution: AS-REP Roasting<\/strong><\/h2>\n\n\n\n

    To perform AS-REP roasting<\/strong>, an attacker follows these steps:<\/p>\n\n\n\n

    Step 1: Enumerate User Accounts Without Preauthentication<\/strong><\/h3>\n\n\n\n

    The attacker first identifies accounts that have preauthentication disabled. This can be done using PowerShell:<\/p>\n\n\n\n

    Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth
    <\/code><\/pre>\n\n\n\n
    PowerView<\/strong>:<\/p>\n\n\n\n
    Get-DomainUser -PreauthNotRequired
    <\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Step 2: Request an AS-REP Ticket for a Target User<\/strong><\/h3>\n\n\n\n
    The attacker requests an AS-REP for a vulnerable user using Impacket’s GetNPUsers.py<\/strong>:<\/p>\n\n\n\n
    python3 GetNPUsers.py domain.local\/ -usersfile users.txt -format hashcat -output hashes.txt
    <\/code><\/pre>\n\n\n\n
    Since preauthentication is disabled, the KDC directly responds with an AS-REP message containing an encrypted NTLM hash of the user’s password.<\/p>\n\n\n\n
    \n\n\n\n
    Step 3: Extract and Save the AS-REP Hash<\/strong><\/h3>\n\n\n\n
    The AS-REP response contains an encrypted NTLM hash, which follows the Kerberos 5 AS-REP etype 23 format. The extracted hash looks like this:<\/p>\n\n\n\n
    $krb5asrep$23$user@DOMAIN:HASH
    <\/code><\/pre>\n\n\n\n
    This is then saved to a file (e.g., hashes.txt<\/code>) for offline cracking.<\/p>\n\n\n\n
    \n\n\n\n
    Step 4: Crack the Hash Offline<\/strong><\/h3>\n\n\n\n
    The attacker attempts to recover the user’s password by brute-forcing the AS-REP hash using Hashcat<\/strong>:<\/p>\n\n\n\n
    hashcat -m 18200 hashes.txt \/path\/to\/wordlist.txt --force
    <\/code><\/pre>\n\n\n\n
    If the user\u2019s password is weak, Hashcat will recover it.<\/p>\n\n\n\n
    \n\n\n\n
    3. Impact of AS-REP Roasting<\/strong><\/h2>\n\n\n\n