Methods for Detecting Kerberoasting Activity

Service accounts are a lucrative target for attackers. The accounts hold elevated privileges and do not have strict password reset policies, consequently, they can be compromised and leveraged for extended periods of time without detection. Due to the architecture of active directory, once attackers have infiltrated any domain-joined computer, they are able to query the directory and its objects—sometimes even anonymously. Through this, they can then:

  • Scan the active directory for user accounts with SPN values set
  • Request service tickets from the active directory using SPN values
  • Extract service tickets to memory and save to a file
  • Brute force attack passwords offline until cracked

In this post, we’ll explore how an attacker can exploit your account’s privileges using Kerberoasting, then discuss a method of detecting these attacks using honey accounts with fake service principal names.

What is Kerberoasting?

Kerberoasting is a popular attack method used to infiltrate a network and move laterally. The attack involves requesting a Kerberos service ticket(s) for the Service Principal Name (SPN) of a targeted service account. This request uses a valid domain user’s authentication Ticket-Granting Ticket (TGT) to request one or more service tickets for a server-run target service. The domain controller then searches for the SPN in its active directory and encrypts the ticket using the service account associated with the SPN, allowing the service to validate user access. The requested Kerberos service ticket’s encryption type is RC4_HMAC_MD5, which means the service account’s NTLM password hash is used to encrypt the service ticket.

Note: No elevated rights are required to get the service tickets and no traffic is sent to the target. Service tickets can be cracked offline without sending a single packet to the target server, as we see here:

Figure 1: Cracking Service Ticket Credentials Offline

Here is a visualization of Kerberos:

Figure 2: Kerberos Overview (Image Courtesy of LabofaPenetrationTester.com)

How Kerberos Works

1. The user logs on with their username and password.

a. Their password is converted to NTLM hash. A timestamp is encrypted with the hash and sent to the KDC as an authenticator in the TGT request (AS-REQ).

b. The KDC checks user information (logon restrictions, group membership, etc.) and creates a TGT.

2. The TGT is encrypted, signed, and delivered to the user (AS-REP). Only the Kerberos service (KRBTGT) in the domain can open and read TGT data.

3. The user presents the TGT to the KDC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The KDC opens the TGT and validates PAC checksum. If the KDC can open the ticket and the checksum checks out, TGT equals valid. The data in the TGT is effectively copied to create the TGS ticket.

4. The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP).

5. The user connects to the server hosting the service on the appropriate port and presents the TGS (AP-REQ). The service opens the TGS ticket using its NTLM password hash. Unless PAC validation is required (rare), the service accepts all data in the TGS ticket with no communication to the KDC.

Solution: Creating a Kerberoast Service Account Honeypot

Step 1: Create a Fake User Account

In order to create a Kerberoast Service Account Honeypot, you first need to create a user account in the active directory and give it a fake SPN. Through this fake SPN, you’ll be able to tell from the request that access is unwarranted and therefore malicious. It’s also important to make this account look attractive by setting the “AdminCount” attribute to 1—this setting flags the account as potentially having elevated active directory rights. You can help supplement this illusion by adding the fake account to a variety of fake groups, elevating the perceived credential rights.

Figure 3: Creating Honey Account Kerberoast

Figure 4: Elevated Privilege for Fake Admin Account

Step 2: Add SPN to Account

The SPN you add needs to be unique, so it should not simply be copied from another system. SQL service accounts are pretty common; don’t reuse one that already exists.

Figure 5: Adding Service Principal Name

Note: Your service account should have a strong password. You can monitor if someone logs on with this account, however, the Kerberos TGS service ticket request is enough to know that Kerberoasting activity is occurring and to determine from which computer it is being accessed by the “client address.”

Your honeypot account should never be requested or used, as it is created with an SPN that isn’t linked to any real application that would need it. There should be no reason for anyone to ever legitimately request a Kerberos TGS service ticket since there is no actual associated service running. Therefore, if we see that someone requested a Kerberos TGS ticket, it’s very likely they’re attempting to Kerberoast your account.

Inside an Attempted Attack

An attacker gains access to the internal network and searches for accounts with SPNs and have admincount set to 1 using powershell with user-level privilege. Here is how an attacker would query the domain controller:

_Get-ADUser -Filter { (admincount -eq 1) -AND (ServicePrincipalName -like “*”)} -Property * Select SamAccountname, ServicePrincipalName_

Figure 6: Attacker Querying the Active Directory for SPNs

This shows our new honeypot account to the attacker who is interested in this account and requests an RC4 encrypted Kerberos TGS ticket for the SPN.

Figure 7: TGS Ticket Acquired

Klist command shows you that the attacker obtained the TGS ticket in memory. The attacker could now theoretically crack the service ticket offline.

Figure 8: Service Ticket Dumped and Ready for Offline Cracking

Detecting Potential Kerberoast Activity using LogRhythm Threat Lifecycle Management

To stop infiltrators in their tracks, first create a simple drag-and-drop AI Engine rule looking for the Kerberoast honey account you’ve created.

The attacker requests the service ticket for the honey account/service principal name: MSSQLSVC/honeysql1.logrhythm.com:1433

Figure 9: Attacker Requesting Honey Account Service Ticket

An alarm with High Risk of Score 100 is triggered for our kerberoast honey account.

Figure 10: Kerberoast Threat Score

LogRhythm Machine Data Intelligence (MDI) Fabric further provides us with the following information:

Figure 11: LogRhythm MDI Insight

User Origin - The end user account compromised: (joe)

User Impacted - The honey account: kerberoast

IP Address - Client IP address: 192.168.49.135

Common Event - Service ticket requested with Encryption type 0x17: RC-4 Encryption

Vendor Message ID: 4769

You can now use LogRhythm’s SmartResponse™ playbook action to contain and neutralize the threat.

Beginning with Windows Server 2008 and Windows Vista, Microsoft Windows added Kerberos AES (128 & 256) encryption, which means that most Kerberos requests will be AES encrypted with any modern Windows OS. Any Kerberos RC4 tickets requested should be the exception. LogRhythm MDI Fabric has normalized 0x17, which is the Encryption Algorithm RC4_HMAC, as shown in Figure 11 above.

Since the requesting of Kerberos TGS tickets happen all the time from users that need to access resources, you should be looking for TGS-REQ packets with RC4 encryption if a honey account is not active.

Best of luck roasting those kerberoasters!

SCADA Network Security Monitoring

Using Honey Credentials to make Pivoting Detectable

Detecting Lateral Movement From ‘Pass the Hash’ Attacks

Analyzing ICMP Traffic with Network Monitor

Using Deep Packet Analytics to Extract Specific Bytes