SOC OperationsIncident ResponseWindows ForensicsLinux ForensicsKQL Investigations

Authentication Server Response (AS-REP) Roasting

Introduction

AS-REP Roasting is a post-exploitation technique used by attackers to extract and crack password hashes for user accounts in a Kerberos authentication environment. It specifically targets user accounts that have "Do not require Kerberos preauthentication" enabled, exploiting a feature of the Kerberos protocol that allows attackers to obtain encrypted password hashes without direct interaction with the target user.

AS-REP Roasting is categorised under the Credential Access tactic in the MITRE ATT&CK framework (ID: T1558.004) and is often used to escalate privileges or move laterally within a compromised environment.

How AS-REP Roasting Works

  1. Kerberos Overview:

    • In a typical Kerberos authentication process, pre-authentication requires the client to prove its identity by encrypting a timestamp with the user's password hash and sending it to the Key Distribution Center (KDC). This mechanism prevents offline brute-force attacks against Kerberos accounts.

  2. No Preauthentication Accounts:

    • Some accounts in Active Directory may have the "Do not require Kerberos preauthentication" flag enabled. This is often done for compatibility with legacy systems or misconfiguration.

    • For these accounts, the KDC skips the preauthentication step and directly sends an encrypted AS-REP message containing the user's Ticket Granting Ticket (TGT).

  3. Attack Workflow:

    • Discovery: The attacker enumerates accounts in Active Directory to identify those with preauthentication disabled.

    • Request AS-REP: The attacker requests authentication for the target account without needing any credentials.

    • Receive AS-REP: The KDC responds with an AS-REP message encrypted using the target user's password hash.

    • Offline Hash Cracking: The attacker extracts the encrypted hash from the AS-REP message and uses tools like John the Ripper or Hashcat to perform an offline brute-force or dictionary attack to recover the plaintext password.

Why AS-REP Roasting is Effective

  • No Interaction with the Target User: Unlike techniques like phishing, AS-REP Roasting does not require user interaction, making it stealthier.

  • Offline Cracking: Once the attacker retrieves the AS-REP hash, the cracking process is entirely offline, bypassing detection systems that monitor real-time activities.

  • Weak Passwords: Environments with weak password policies are highly vulnerable as attackers can easily crack poorly secured hashes.

Detection and Mitigation

Detection:

  1. Log Monitoring:

    • Monitor Windows Security Event Logs for Kerberos authentication anomalies:

      • Event ID 4768: Kerberos Authentication Ticket Request.

      • Event ID 4771: Kerberos Pre-authentication Failed.

      • Event ID 4625: This event is generated when an account fails to log on.

      • Event ID 4738, 5136: These events are generated when a user account is changed

    • Look for multiple AS-REP requests from a single host or for rarely used accounts.

  2. Network Traffic Analysis:

    • Use tools like Zeek or Wireshark to detect Kerberos AS-REP traffic originating from unusual IP addresses or hosts.

  3. Threat Hunting:

    • Query Active Directory to identify accounts with the DONT_REQUIRE_PREAUTH attribute enabled:

      Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth

  4. Use EDR/SIEM Tools:

    • Configure detection rules for tools like Splunk, Elastic, or Microsoft Sentinel to flag unusual AS-REP requests.

Mitigation:

  1. Disable Legacy Settings:

    • Audit and disable the "Do not require Kerberos pre-authentication" setting for all accounts unless absolutely necessary.

  2. Enforce Strong Passwords:

    • Implement strong password policies and enforce multi-factor authentication (MFA) to make brute-force attacks impractical.

  3. Limit Privileges:

    • Ensure accounts with sensitive privileges do not have pre-authentication disabled.

  4. Regular Audits:

    • Periodically audit Active Directory for misconfigurations, including accounts with DONT_REQUIRE_PREAUTH enabled.

Common Tools for AS-REP Roasting

  1. Impacket (GetNPUsers.py):

    • Enumerates accounts with pre-authentication disabled and extracts AS-REP hashes.

  2. Rubeus:

    • A powerful tool for Kerberos abuse, including AS-REP Roasting.

  3. Cracking Tools:

    • Tools like John the Ripper and Hashcat are used to crack the extracted hashes offline.

AS-REP Roasting highlights how minor misconfigurations in Kerberos authentication can lead to significant security risks. By understanding how the attack works and implementing proactive detection and mitigation measures, organisations can better protect their Active Directory environments from credential theft and lateral movement threats.

KQL Dection Queries:

SecurityEvent
| where EventID == 4768  // Kerberos Authentication Ticket (AS-REP)
| extend AccountName = TargetUserName, 
         Domain = TargetDomainName,
         ClientIP = IpAddress,
         FailureCode = Status
| where FailureCode in ("0x0", "0x12")  // Success (0x0) or pre-auth not required (0x12)
| summarize RequestCount = count(), UniqueIPs = dcount(ClientIP), ClientIPs = make_set(ClientIP)
    by AccountName, Domain
| where RequestCount > 10 or UniqueIPs > 3  // Threshold: tune these values based on your environment
| extend SuspiciousActivity = case(
    RequestCount > 10 and UniqueIPs > 3, "High",
    RequestCount > 10, "Moderate",
    UniqueIPs > 3, "Moderate",
    "Low"
)
| project AccountName, Domain, RequestCount, UniqueIPs, ClientIPs, SuspiciousActivity
| sort by SuspiciousActivity desc, RequestCount desc

Explanation of the Query

  1. Filter for Event ID 4768:

    • Event ID 4768 corresponds to "Kerberos Authentication Ticket Request" in Windows Security logs.

    • This is the event generated when the KDC responds with an AS-REP.

  2. Focus on Preauthentication Disabled:

    • Pre-authentication disabled is indicated by FailureCode = 0x12.

    • The query also considers Success (0x0) to identify successful AS-REP requests that might indicate compromised accounts.

  3. Summarisation:

    • Groups data by the AccountName and Domain.

    • Tracks the total number of requests (RequestCount) and distinct client IPs (UniqueIPs).

    • Also lists all involved client IPs for further investigation.

  4. Anomalous Behavior Detection:

    • Flags accounts with more than 10 requests or requests originating from more than 3 unique IPs.

    • These thresholds (RequestCount > 10 or UniqueIPs > 3) can be adjusted based on your environment.

  5. Severity Classification:

    • Adds a SuspiciousActivity field to classify detected activity as High, Moderate, or Low based on thresholds.

  6. Presentation:

    • Displays key details such as account name, domain, request count, unique IPs, and their suspicious activity level for SOC analysts.

Adjustments for Environment

  • Tune Thresholds: Customise RequestCount > 10 and UniqueIPs > 3 based on the normal behaviour in your organisation.

  • Exclude Whitelisted Accounts/IPs: Use a lookup table or additional filters to exclude known safe accounts or IP addresses.

  • Correlate with Other Events:

    • Combine with Event ID 4625 (failed logons) or Event ID 4771 (Kerberos pre-auth failures) for better context.

Splunk Detection Queries

index=windows (sourcetype="WinEventLog:Security" OR EventCode=4768)
| eval TargetAccount=TargetUserName, ClientIP=IpAddress, FailureCode=Status
| where FailureCode="0x12"  // Preauthentication not required
| stats count AS RequestCount, values(ClientIP) AS RequestingIPs, dc(ClientIP) AS UniqueIPs, min(_time) AS FirstSeen, max(_time) AS LastSeen 
    BY TargetAccount
| eval SuspiciousScore = case(
    RequestCount > 10 AND UniqueIPs > 3, "High",
    RequestCount > 10 OR UniqueIPs > 3, "Medium",
    RequestCount <= 10 AND UniqueIPs <= 3, "Low"
)
| where SuspiciousScore IN ("High", "Medium")  // Filter only significant activity
| table TargetAccount, RequestCount, UniqueIPs, RequestingIPs, FirstSeen, LastSeen, SuspiciousScore
| sort - SuspiciousScore, -RequestCount

Query Breakdown

  1. Filter for Event ID 4768:

    • Searches for Kerberos authentication ticket requests in Windows Security logs.

    • Focuses on instances where FailureCode="0x12" (pre-authentication is not required).

  2. Extract Relevant Fields:

    • TargetUserName: The account being requested.

    • IpAddress: The source IP making the request.

  3. Aggregate Data:

    • Counts the number of requests per TargetAccount (RequestCount).

    • Identifies distinct source IPs (UniqueIPs).

    • Captures the time range of activity (FirstSeen, LastSeen).

  4. Calculate Suspicious Score:

    • Assign a "High" score if both RequestCount > 10 and UniqueIPs > 3.

    • Assign a "Medium" score if either condition is true.

    • Assigns a "Low" score for benign activity.

  5. Filter and Display:

    • Excludes low-risk activity by keeping only High and Medium scores.

    • Displays a concise table with actionable details for SOC analysts.

Customisations

  • Threshold Tuning:

    • Adjust thresholds (RequestCount > 10 and UniqueIPs > 3) based on your organisation’s baseline activity.

  • Whitelist Legitimate Accounts:

    • Add a filter to exclude known legitimate accounts (e.g., a lookup of service accounts).

    splCopyEdit| search NOT [ | inputlookup known_safe_accounts.csv ]

  • Alert Configuration:

    • Use this query as the basis for Splunk alerts, triggering notifications for SuspiciousScore = High.

Additional Recommendations

  1. Correlation with Failed Logons:

    • Combine with Event ID 4625 (failed logons) to check if attackers are also attempting brute force or password spraying.

  2. Integration with Threat Intelligence:

    • Cross-reference the ClientIP field with known malicious IPs from threat intelligence feeds.

Reference

PreviousKerberoastingNextPassword Spraying

Last updated