Feb 05

Detecting Kerberoasting Activity

Introduction

Kerberoasting can be an effective method for extracting service account credentials from Active Directory as a regular user without sending any packets to the target system. This attack is effective since people tend to create poor passwords. The reason why this attack is successful is that most service account passwords are the same length as the domain password minimum (often 10 or 12 characters long) meaning that even brute force cracking doesn’t likely take longer than the password maximum password age (expiration). Most service accounts don’t have passwords set to expire, so it’s likely the same password will be in effect for months if not years. Furthermore, most service accounts are over-permissioned and are often members of Domain Admins providing full admin rights to Active Directory (even when the service account only needs to modify an attribute on certain object types or admin rights on specific servers).

Tim Medin presented on this at DerbyCon 2014 in his “Attacking Microsoft Kerberos Kicking the Guard Dog of Hades” presentation (slides & video) where he released the Kerberoast Python TGS cracker.

This is a topic we have covered in the past in the posts “Cracking Kerberos TGS Tickets Using Kerberoast – Exploiting Kerberos to Compromise the Active Directory Domain” & “Sneaky Persistence Active Directory Trick #18: Dropping SPNs on Admin Accounts for Later Kerberoasting.”
Also Will Schroeder, aka Will Harmjoy (@harmj0y), and I spoke at DerbyCon 2016 about how to Kerberoast to escalate privileges.

Note: This attack will not be successful when targeting services hosted by the Windows system since these services are mapped to the computer account in Active Directory which has an associated 128 character password which won’t be cracked anytime soon.

Let’s quickly cover how Kerberos authentication works before diving into how Kerberoasting works and how to detect Kerberoast type activity.

Kerberos Overview & Communication Process

Visio-KerberosComms

User logs on with username & password.

1a. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an authenticator in the authentication ticket (TGT) request (AS-REQ).
1b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) & creates Ticket-Granting Ticket (TGT).

2. The TGT is encrypted, signed, & 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 DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check out, TGT = 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 & presents the TGS (AP-REQ). The service opens the TGS ticket using its NTLM password hash.

6. If mutual authentication is required by the client (think MS15-011: the Group Policy patch from February that added UNC hardening).

Unless PAC validation is required (rare), the service accepts all data in the TGS ticket with no communication to the DC.

 

SPN Scanning for Targets

Any user authenticated to Active Directory can query for user accounts with a Service Principal Name (SPN). This enables an attacker with access to a computer on the network to identify all service accounts supporting Kerberos authentication and what they are used for. Each SPN starts with a SPN type which is the first part of the SPN. If the SPN is “MSSQLSvc/adsmsDB01.adsecurity.org:1433”, then “MSSQLSvc” is the SPN type. We can check the ADSecurity.org SPN directory and see it’s for Microsoft SQL Server. The second part (after the forward slash /) is the server name the Kerberos service is running on. The server name can be the FQDN or the short name (often both). Sometimes there’s a colon (“:”) at the end which provides additional information, such as a port number or SQL instance. Anyone can perform “SPN Scanning” in order to identify Kerberos service SPNs registered in an Active Directory forest.

Attackers are most interested in Service Accounts that are members of highly privileged groups like Domain Admins. A quick way to check for this is to enumerate all user accounts with the attribute “AdminCount” equal to ‘1’. I cover AdminCount in an earlier post (“Active Directory Recon Without Admin Rights“). This means an attacker may just ask AD for all user accounts with a SPN and with AdminCount=1.

Using the Active Directory powershell module, we can use the Get-ADUser cmdlet:
get-aduser -filter {AdminCount -eq 1} -prop * | select name,created,passwordlastset,lastlogondate

We can also use PowerView’s Get-NetUser cmdlet:
Get-NetUser -AdminCount | Select name,whencreated,pwdlastset,lastlogon

Once we have this data, we can filter further to identify the Service Accounts.

Another method to finding interesting Service Accounts is to filter based on SPN type. Some SPNs tend to have interesting permissions:

  • AGPMServer: Often has full control rights to all GPOs.
  • MSSQL/MSSQLSvc: Admin rights to SQL server(s) which often has interesting data.
  • FIMService: Often has admin rights to multiple AD forests.
  • STS: VMWare SSO service which could provide backdoor VMWare access.

Kerberoasting these SPNs could lead to attacker gaining access to the associated service account credentials, which would provide easy privilege escalation if the associated password isn’t long & complex (>25 characters) or if the associated service account isn’t configured as a Managed Service Account.

 

Kerberoasting

This attack involves requesting a Kerberos service ticket(s) (TGS) for the Service Principal Name (SPN) of the target service account (Step #3 above). This request uses a valid domain user’s authentication ticket (TGT) to request one or several service tickets for a target service running on a server.

The Domain Controller looks up the SPN in Active Directory and encrypts the ticket using the service account associated with the SPN in order for the service to validate user access. The encryption type of the requested Kerberos service ticket is RC4_HMAC_MD5 which means the service account’s NTLM password hash is used to encrypt the service ticket.

We can request RC4 encrypted Kerberos TGS service tickets by using the following PowerShell command:

$SPNName = ‘MSSQLSvc/adsmsDB01.adsecurity.org:1433’
Add-Type -AssemblyNAme System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $SPNName

Running klist shows the new Kerberos service ticket with RC4-HMAC encryption.

The next step is exporting the Kerberos ticket we just requested from memory, which can be done easily with Mimikatz (without admin rights).

Kerberoast can attempt to open the Kerberos ticket by trying different NTLM hashes and when the ticket is successfully opened, the correct service account password is discovered. The Domain Controller doesn’t track if the user ever actually connects to these resources (or even if the user has access), so a user can request hundreds of service tickets, even if they never actually connect to the service.

Note: No elevated rights are required to get the service tickets and no traffic is sent to the target.

Kerberoast-03

Note that Mimikatz is not required to extract the service ticket from memory: read Will’s post “Kerberoasting without Mimikatz”

 

Mitigating Kerberoast Attack Activity

The most effective mitigation of this attack is ensuring service account passwords are longer than 25 characters (and aren’t easily guessable)
Managed Service Accounts and Group Managed Service Accounts are a good method to ensure that service account passwords are long, complex, and change regularly. A third party product that provides password vaulting is also a solid solution for managing service account passwords. Though any 3rd party password management tool needs to be properly evaluated since the associated service account often requires Domain Admin level rights. This evaluation should also include how these credentials are managed within the solution.

 

Configuring Logging to Detect Kerberoast Activity

Before having a chance to detect Kerberoasting, it’s important to have the appropriate logging enabled.

Kerberoasting involves requesting Kerberos TGS service tickets with RC4 encryption. Domain Controllers can log Kerberos TGS service ticket requests by configuring “Audit Kerberos Service Ticket Operations” under Account Logon to log successful Kerberos TGS ticket requests.

Enabling this audit category on Domain Controllers will result in two interesting event ids being logged:
4769: A Kerberos service ticket (TGS) was requested
4770: A Kerberos service ticket was renewed

Event ID 4769 will be logged many, many times in the domain since after initial logon (and Kerberos TGT ticket request), users request Kerberos TGS service tickets to access the may services on the network (file shares, SQL, SharePoint, etc). Expect there will be around 10 to 20 Kerberos TGS requests per user every day. The 4769 event on Domain Controllers is one of the most numerous in any environment which is why it’s often not logged.

 

Detecting Potential Kerberoast Activity

I have presented and posted on potential methods to detect Kerberoasting activity in the past:

Detection is a lot tougher since requesting service tickets (Kerberos TGS tickets) happens all the time when users need to access resources.
Looking for TGS-REQ packets with RC4 encryption is probably the best method, though false positives are likely.

Monitoring for numerous Kerberos service ticket requests in Active Directory is possible by enabling Kerberos service ticket request monitoring (“Audit Kerberos Service Ticket Operations”) and searching for users with excessive 4769 events (Event Id 4769 “A Kerberos service ticket was requested”).

Here’s how to definitively detect Kerberoasting activity.

Windows added Kerberos AES (128 & 256) encryption starting with Windows Server 2008 and Windows Vista which means that most Kerberos requests will be AES encrypted with any modern Windows OS. Any Kerberos RC4 tickets requested should be the exception. There are systems that only support Kerberos RC4 by default (NetApp). Inter-forest Kerberos tickets also use RC4 unless configured for AES – ensure your forest trusts support AES and then enable AES over the trust.

So, how do we determine what encryption type was used when looking at events: 0x12, 0x17…?

Ned Pyle (@NerdPyle) posted an article on hunting down the use of Kerberos DES encryption in the AskDS Blog on TechNet and provides this handy chart:

Once all Domain Controllers are configured to log 4769 events, these events need to be filtered before sending the data into a SIEM/Splunk. Since we are only really interested in Kerberos TGS service tickets with RC4 encryption, it’s possible to filter the events. As shown above, Kerberos events with AES encryption has Ticket Encryption Type set to 0x12.
Kerberos RC4 encrypted tickets have Ticket Encryption Type set to 0x17.

These events can be filtered using the following which greatly reduces the amount of events flowing into the SIEM/Splunk:

  • Ticket Options: 0x40810000
  • Ticket Encryption: 0x17

With this information, we can start investigating potential Kerberoasting activity and reduce the number of 4769 events.

Note:
Also look for Kerberos DES encryption since this is not secure. The ticket options may be different, so just filter on 4768 & 4769 events with Ticket Encryption: 0x1 OR 0x2 OR 0x3. Starting with Windows 7 & Windows Server 2008 R2, DES encryption is disabled, but it’s still important to find systems that may be attempting (& succeeding!) to get DES Kerberos tickets

We can further reduce the number of 4769 events that flow into SIEM/Splunk:

  • Filter out requests from service accounts (ads45service@lab.adsecurity.org)
  • Filter on Audit Success
  • Filter out requests for service names with a “$” which are typically for computer accounts (or trusts or Managed Service Accounts, all accounts where Windows automatically generates a long, complex password).

In limited testing, I’ve seen 4769 event totals reduced from millions to thousands and hundreds using these filtering techniques.

Here’s a 4769 event that may potentially be from Kerberoasting activity:

Some attackers will request a bunch of RC4 TGS tickets for some or all service accounts using something similar to the following graphic.

The PowerShell script code in the graphic above is similar to PowerView functionality. The next graphic shows the results of the PowerShell script code being run.

Running klist shows the tickets are in user memory. Note that the initial krbtgt ticket is AES encrypted and others are RC4-HMAC(NT). That’s a bit unusual.

So, the tickets were requested… How to discover this activity?
Using the information regarding ticket encryption type and ticket options, we can use PowerShell to parse the DC’s event log looking for 4769 events with this info.

That looks really odd. Why would any account request several different service names (Citrix PVS, BizTalk, Business Objects, AGPM GPO management, and several SQL service accounts) within a second or two of each other?

That stands out and looks really suspicious and is very likely Kerberoasting activity. This provides great information on what users could be compromised and what activity on which computers should be scrutinized.

A single user requesting RC4 encrypted TGS tickets for several services, such as lots of SQL service principal names is suspicious and it’s worth investigating the IP (client address)  the requests came from. The same thing is true for multiple RC4 encrypted TGS requests over time for lots of service principal names. A pattern does emerge when there’s one or two accounts that request a variety or RC4 TGS tickets.

Update: Added Part 2 on How to Detect Kerberoasting Activity
Detecting Kerberoasting Activity Part 2 – Creating a Kerberoast Service Account Honeypot

If you are logging PowerShell activity, you can use my offensive PowerShell indicators to detect standard use of common PowerShell attack tools.
I cover detecting offensive PowerShell in the previous post “Detecting Offensive PowerShell Attack Tools” & “PowerShell Security: PowerShell Attack Tools, Mitigation, & Detection“. I also covered PowerShell security in my BSidesCharm & BSidesDC talks in 2016.

Specifically:

  • Deploy PowerShell v5 (or newer) and enable module logging & script block logging.
  • Send the following PowerShell log event ids to the central logging solution: 400 & 800
  • Pull the following PowerShell Operational log event ids to the central logging solution: 4100, 4103, 4104
  • Configuring system-wide transcription to send a log of all activity per user, per system to a write-only share, is incredibly valuable to catch suspicious/malicious activity that can be missed or not logged to the event logs. Even better is ingesting these transcript text files into something like Splunk for further analysis.

Note the addition of “KerberosRequestorSecurityToken” which is the PowerShell method to request Kerberos tickets.

 

Conclusion

Kerberoasting requires requesting Kerberos TGS service tickets with RC4 encryption which shouldn’t be most of the Kerberos activity on a network. Logging 4769 events on Domain Controllers, filtering these events by ticket encryption type (0x17), known service accounts (Account Name field) & computers (Service Name field) greatly reduces the number of events forwarded to the central logging and alerting system. Gathering and monitoring this data also creates a good baseline of what’s “normal” in order to more easily detect anomalous activity.

 

Kerberoasting References

 

(Visited 11,134 times, 1 visits today)