Microsoft Defender for Identity: AS-REP Roasting

Microsoft released a new detection for Microsoft Defender for Identity. The detection detects a malicious request for user accounts that do not require pre-authentication, also known as an AS-REP roasting attack. This blog post will briefly explain what an AS-REP roasting attack is and how to mitigate it.

AS-REP roasting is not a new attack. The detection by Microsoft Defender for Identity is, though. People like harmj0y and many others documented AS-REP roasting well, but since the detection is new in Microsoft Defender for Identity, I will briefly go through the attack.

Kerberos

In my previous blog post, I explained how Kerberos works but let us go over it again.

Kerberos is an authentication protocol based on tickets. The protocol is an authentication protocol developed by MIT and adopted by Microsoft since Windows 2000. Kerberos is also complicated and hard to secure.

Here is an oversimplified overview of these ticket requests:

First, the user needs to authenticate. The Authentication Service, which is part of the Key Distribution Center, handles the authentication.

Note: Within a Microsoft environment, the Key Distribution Center is the Domain Controller.

The user sends a Ticket Granting Ticket (AS-REQ) request and encrypts the timestamp in the request with the users’ password hash. The encryption of the timestamp is the pre-authentication within Active Directory. Active Directory tries to decrypt the timestamp using the users’ password hash. If the decryption works, Active Directory knows the password is correct and sends a Ticket Granting Ticket (AS-REP) back to the user.

Within Active Directory, there is an option to disable the need for pre-authentication:

When pre-authentication is disabled, there is no need to encrypt the timestamp in the Ticket Granting Ticket request, making it possible for everyone, even unauthenticated users, to request a Ticket Granting Ticket for that user.

The Ticket Granting Ticket sent back to the user is encrypted with the users’ password hash. If an attacker decrypts the ticket using a rainbow table, the attacker knows the user’s password.

Mitigation

Some non-Microsoft products require pre-authentication to be disabled. I have not seen an organization where this is needed, but if pre-authentication needs to be disabled, use a strong and generated password for the user account to be impossible for an attacker to brute-force the password. I highly recommend enabling pre-authentication for all user accounts, though.

To check which user accounts have pre-authentication disabled, use this PowerShell script:

$searcher = [adsisearcher]"(&(objectClass=user)(objectCategory=person))"
$searcher.FindAll() | ForEach-Object {
  $user = [adsi]$_.Properties.adspath[0]
  $PreAuthRequired = -not [bool]($user.userAccountControl[0] -band 0x400000)
  if($PreAuthRequired -eq $false) {
    New-Object -Type PSCustomObject -Property @{
      SamAccountName = $user.sAMAccountName[0]
    }
  }
}

Note: Run this script using a domain user. No additional module is needed to run the script.

Conclusion

Any unauthenticated user can request a Ticket Granting Ticket when pre-authentication is disabled. Even though the ticket is encrypted, an attacker can brute-force the ticket to get the users’ password. Be sure no users have pre-authentication disabled within Active Directory.

Kerberos

Related