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 Defender for Identity: ADFSDump

Microsoft Defender for Identity: ADFSDump

Microsoft updated Microsoft Defender for Identity to detect the ADFSDump tool’s use, which was the initial tool used in the Solorigate campaign. This blog post will describe what the attack does, including mitigations for the attack. I created a tool to perform the attack for educational purposes.

Active Directory Federation Services Authentication

To understand the attack, we first need to look at how Active Directory Federation Services (AD FS) works. Here is an oversimplified overview of the authentication using AD FS.

Image 1: AD FS Authentication Overview
  1. The user goes to https://portal.office.com and signs in with the username user@thalpius.com;
  2. Microsoft recognises the federation and sends a 302 HTTP response code, redirecting the user to the federated AD FS server ;
  3. The user identifies itself using a password on the Web Application Proxy used by AD FS;
  4. The Web Application Proxy sends the request to AD FS;
  5. AD FS authenticates the user by checking Active Directory if the user entered the correct credentials;
  6. AD DS sends the response of the authentication back to the AD FS server;
  7. AD FS signs a token using a token-signing certificate and sends it to the Web Application proxy;
  8. The Web Authentication Proxy sends the signed token to the user;
  9. The user presents the signed token to Microsoft 365 and can log in to the service.

Suppose there is a way to sign your tokens using a private key and token-signing certificate used by AD FS. In that case, you could impersonate the AD FS server and authenticate to federated services by presenting the signed token. Step 1 to 8 is not needed, and you can submit the forged token directly to the federated service. The federated service checks the token with the public key, and with the correct signed private key, the federated service authenticates the user.

The impersonation of an AD FS server is precisely what Doug Bienstock did. Doug Bienstock created a tool to obtain the token-signing certificate and private key to generate forged security tokens. The tool to obtain the token-signing certificate and private key is called ADFSDump. Since release 2.135 of Microsoft Defender for Identity, ADFSDump gets detected.

ADFS Info

For educational purposes, I created a tool to dump the private key and certificate and get undetected by Microsoft Defender for Identity. Some key features of my tool are:

  1. The date creation of the private key helps identify which key to use;
  2. The private keys are in the correct format;
  3. Microsoft Defender for Identity does not detect the attack.
Image 2: ADFS Info

Once you have obtained the private key and token-signing certificate, use ADFSSpoof to create the forged token.

Mitigation

The service account used by AD FS contains Service Principal Names. That means the account is vulnerable to Kerberoasting. Be sure the service account includes a strong and generated password, so it is less likely an attacker can brute-force the password.

Looking at the Administrative Tier Model, consider placing AD FS in the tier 0 scope.

An obvious but important one is monitoring. As I mentioned in my top 5, monitoring is crucial in any organization. An attacker needs to go through many steps in the kill chain before the attacker can extract the details. Monitoring should detect an attacker by then.

Conclusion

In my previous blog post, I mentioned that attackers could hop from on-premises to the cloud. The attack described in this blog post is another way for an attacker to jump from on-premises to the cloud. Once the on-premises environment is compromised, the attacker has many possibilities to hop to the cloud. Even though a lot of companies are focussing on the cloud, do not forget the on-premises environment.

Microsoft Defender for Identity: Kerberoasting

Microsoft Defender for Identity: Kerberoasting

Microsoft released a new detection this month for Microsoft Defender for Identity. The detection detects “Suspected Kerberos SPN exposure,” which is an attack called Kerberoasting. This blog post will briefly explain what a Kerberoasting attack is and how to mitigate it.

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

Kerberos

To understand Kerberoasting, we first need to know how Kerberos works. 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.

For a client to access a service (a SQL server, a web server, a network share, etc.), the client needs to authenticate and request a Ticket Granting Service (TGS) ticket from the Key Distribution Center (KDC). The Key Distribution Center exists of two components: the Authentication Service (AS) and the Ticket Granting Service. Within a Microsoft environment, the Key Distribution Center is the Domain Controller. With a valid Ticket Granting Service ticket, the client can access the requested service.

Here is an oversimplified overview of these ticket requests:

Image 1: Requesting a TGT and TGS

First, the client needs to authenticate. The Authentication Service handles the authentication. The client sends a Ticket Granting Ticket (TGT) request and encrypts the timestamp in the request with the users’ password hash. Active Directory holds the password hashes of all users. If the Domain Controller can decrypt the request and validates the user authentication, the Domain Controller sents a valid Ticket Granting Ticket.

With a valid Ticket Granting Ticket, the client can now request a Ticket Granting Service ticket. This part is essential: Anyone with a valid Ticket Granting Ticket can ask for a Ticket Granting Service ticket. The Ticket Granting Service ticket is encrypted with the hash of the user’s password the service belongs to (the Service Principal Name property within Active Directory on the object).

With a valid Ticket Granting Service ticket, the client can access the requested service.

Image 2: Connecting to the service

Kerberoasting

Now that we know how Kerberos works in a nutshell, we can take a look at Kerberoasting. Remember that the Domain Controler uses the users’ password hash to encrypt the Ticket Granting Service ticket. Suppose an attacker requests a Ticket Granting Service ticket and uses a password list to brute-force the ticket, and the password is weak enough. In that case, the attacker can figure out the password by brute-forcing the ticket and obtain the password for that user. This attack is called Kerberoasting.

There is an option to enable a more robust encryption algorithm in Active Directory on the user object hence harder to brute-force:

Image 3: Kerberos AES support

Unfortunately, this option is only to support AES. If an attacker requests an RC4 (weaker encryption) encrypted ticket, the Domain Controller still sends a ticket with RC4 encryption, which is easier to brute-force than AES.

Mitigation

Since the ticket needs to be brute-forced, a strong and complex password is the best mitigation for this attack. Even if the ticket can be requested using RC4 encryption, a generated and lengthy password is hard to brute-force. Use a generated and lengthy password for all service accounts that contain a Service Principal Name.

If Microsoft Defender for Identity detects a Kerberoasting attack, reset the password for the user account, and isolate the machine where the attack takes place. Investigate for malicious activities once mitigated the attack on the endpoint.

Note: Microsoft Defender for Endpoint contains an option to isolate the device. You will be able to reconnect the device back to the network at any time. The button on the device page will change to say Release from isolation, and then you take the same steps as isolating the device.

Conclusion

Kerberoasting is an attack a lot of attackers use because it is beneficial and hard to detect. Now that Microsoft Defender for Identity detects Kerberoasting it is a good start. Hopefully, other Kerberos attacks will get detected by Microsoft Defender for Identity soon.

I have created a small C# project that requests a Ticket Granting Service ticket using KerberosSecurityTokenProvider to use for Kerberoasting. I started the project for educational purposes only, but the tool works fine and is not detected by Microsoft Defender for Identity.

Image 4: Kerberoasting an SPN

The tool can be found here.