Microsoft Defender for Identity: AS-REP Roasting

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:

Image 1: Kerberos authentication

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:

Image 2: Kerberos preauthentication

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.

Microsoft on-premises to the cloud using Seamless Single Sign-On

Microsoft on-premises to the cloud using Seamless Single Sign-On

This blog post will demonstrate how an attacker can hop from on-premises Active Directory to Azure Active Directory or Microsoft 365 when Seamless Single Sign-On is enabled.

Seamless Single Sign-On

Azure Active Directory supports multiple authentication methods, including Seamless Single Sign-On. Seamless Single Sign-On automatically signs-in users when they are on their corporate devices connected to their corporate network. Users do not type in their username and password to sign in to their cloud-based applications. This feature provides users easy access to cloud-based applications without needing any additional on-premises components. Seamless Single Sign-On can be combined with either the Password Hash Synchronization or Pass-through Authentication sign-in methods.

Note: Seamless Single Sign-On does not apply to Active Directory Federation Services (ADFS).

When enabling Seamless Single Sign-On, Azure AD Connect creates a computer object (AZUREADSSOACC) within the on-premises Active Directory. The computer object holds multiple Service Principal Names.

Image 1: Service Principal Names for the computer object AZUREADSSOACC

Service Principal Name

The Service Principal Name ‘HTTP/autologon.microsoftazuread-sso.com’ holds a “secret” used to decrypt a Kerberos ticket when authenticating to Azure AD. If the client can present a valid Ticket Granting Service ticket, Azure AD assumes the client is on the corporate on-premises network and authenticates the user using Kerberos.

In my previous blog post about Kerberoasting, you can read that anyone with a valid Ticket Granting Ticket (any authenticated domain user) can request a Ticket Granting Service ticket. An attacker only needs to get a valid Ticket Granting Ticket and request the correct Ticket Granting Service ticket to log in to Azure AD or Microsoft 365 as that user.

Request the Ticket Granting Service ticket

I have added an option to request the Ticket Granting Service ticket using my Kerberos tool.

Image 2: Requesting a TGS using Kerberos

Extract the Ticket Granting Ticket of the user, including the HTTP Ticket Granting Service ticket, from memory and copy it to an attacker’s machine.

Access cloud applications

For Seamless Single Sign-On to work, you need to add a local policy to the attacker’s machine first.

Image 3: Local Computer Policy / User Configuration / Administrative Templates / Windows Components / Internet Explorer / Internet Control Panel / Security Page / Site to Zone Assignment List

Import the Ticket Granting Ticket and Ticket Granting Service ticket using a tool like Mimikatz and browse to https://myapps.microsoft.com to access the user’s cloud applications. You can now go to the Azure or Microsoft 365 portal to log in as the user.

Image 4: Login using Kerberos TGT and TGS on Azure / Microsoft 365 and MyApps

Conclusion

When an attacker gets hold of a Ticket Granting Ticket, the attacker can hop to cloud-based applications, including Azure and Microsoft 365. Other attack vectors make it possible for an attacker to jump from on-premises to the cloud, but they need admin privileges. With this attack, the attacker only needs to hold a valid Ticket Granting Ticket to jump to the cloud.

Microsoft Defender for Identity does not detect the Ticket Granting Service ticket request as it is an expecting request. Authenticating using Kerberos could bypass Conditional Access policies if not configured correctly.

There are other attack possibilities since the authentication creates an OAuth2 token for that user after authenticating, but more on that later.