Detection Engineers and Threat Hunters in large enterprises are often faced with the seemingly insurmountable problem of noise – from DevOps teams, SysAdmins, DBAs, Local Administrators, Developers – the noise never ends. Often times the actions of these teams can very much resemble active threats – encoded or otherwise obfuscated PowerShell, extensive LOLBAS utilization, RDP/SSH/PsExec usage and more often contribute to making Blue Team lives a never-ending slog of allow-list editing day over day.
In such large environments it can be extremely difficult to create high-fidelity “critical” alerts without overwhelming SOC analysts – often UEBA (User and Entity Behavior Analytics) or RBA (Risk Based Alerting) are touted as the solutions to this type of problem. While these are certainly great tools to keep in mind, they can often require extensive investment in either time, money or both in order to produce a solution that meets the requirements of the organization.
Below, I propose the first of many “quick win” methodologies organizations can use to help identify extremely anomalous activity in their environment and help threat hunters cut through the noise to events that immediately require heightened scrutiny.
Kerberoasting
Kerberoasting is a well-known technique where-in abuse of the Kerberos authentication protocol is performed by attackers in order to achieve the objective of obtaining password hashes from Domain Controllers for use in offline cracking attacks, typically encrypted with a lesser-strength protocol such as RC4.
(Please see https://www.qomplx.com/qomplx-knowledge-kerberoasting-attacks-explained/ for in-depth explanation and additional resources).
Kerberos abuse can be performed in a very stealthy manner but is often fairly obvious when transforming logs in an appropriate fashion – the one real pre-requisite to detecting this from a Domain Controller Security.evtx logging perspective is ensuring your organization is forwarding Event 4768 (A Kerberos Authentication Ticket [TGT] was Requested) and 4769 (A Kerberos Service Ticket was Requested) to your SIEM platform.
These can both be enabled under the Account Logon category as ‘Kerberos Authentication Service’ and ‘Kerberos Service Ticket Operations’.
If you’re pushing these logs to a platform like Splunk, a sample query pulling out initial events of interest will look like the following;
index=windows_events EventCode IN (4769, 4768) Ticket_Encryption_Type IN ("0x1","0x3","0x17","0x18") Keywords="Audit Success" NOT Service_Name IN ("*$", "krbtgt") host IN ("DomainControllerList")
Ticket_Encryption_Type denotes the crypto algorithm utilized for the ticket in question – 0x1 is DES-CBC-CRC, 0x3 is DES-CBC-MD5, 0x17 is RC4-HMAC and 0x18 is RC4-HMAC-EXP. Other possibilities are 0x11 and 0x12, AES128* and AES256* respectively. This helps reduce events to only those that are using known weak algorithms as an attacker will typically not bother utilizing AES-encrypted tickets due to the near-impossibility (at least until quantum computing becomes widely available…).
Additionally, we are choosing to focus only on successful events and are ignoring tickets generated where the service being requested is for a standard machine account or the krbtgt account – your mileage may vary including these but I’ve had a high degree of success using this type of filtering in detecting real and simulated Kerberoasting attacks on complex enterprise networks. Finally, ensure you are primarily looking at Domain Controller Security events rather than the entire environment.
The next step in making this data useable is both binning events by time and performing some basic statistics on the data set as a whole, pivoting off of two key characteristics, as shown below.
index=windows_events EventCode IN (4769, 4768) Ticket_Encryption_Type IN ("0x1","0x3","0x17","0x18") Keywords="Audit Success" NOT Service_Name IN ("*$", "krbtgt") host IN ("DomainControllerList")
| bin _time span=1h
| stats values(Service_Name) as Unique_Services_Requested dc(Service_Name) as Total_Services_Requested by Account_Name Client_Address _time
| sort 0 - Total_Services_RequestedThese additional 3 lines will manipulate the events in a way to that makes it significantly easier for threat hunters or SOC analysts to consume – bucketing events in a per-hour fashion along with the name of the account and the network address interacting with the Kerberos protocol. It may become obvious that some allow-listing is required if your organization has particularly noisy applications or accounts used to facilitate authentication in the environment.
At this point, we’re nearly complete – this type of query could be interlaced in a dashboard with other enrichment data, used to augment user risk in an RBA framework or consumed by threat hunters as part of a daily hunt process. In order to transform this into an effective SOC alert, a final filter should be added putting a threshold on the Total_Services_Requested field, given below.
index=windows_events EventCode IN (4769, 4768) Ticket_Encryption_Type IN ("0x1","0x3","0x17","0x18") Keywords="Audit Success" NOT Service_Name IN ("*$", "krbtgt") host IN ("DomainControllerList")
| bin _time span=1h
| stats values(Service_Name) as Unique_Services_Requested dc(Service_Name) as Total_Services_Requested by Account_Name Client_Address _time
| sort 0 - Total_Services_Requested
| where Total_Services_Requested > XSimply replace ‘X’ with a number appropriate for your environment – I find that anywhere from 10-15 is high enough to remove most noise but low enough to still identify real attackers and red teamers.
This is not an ‘end all be all’ for detecting Kerberoasting as it is certainly possible for an attacker to deliberately space out their actions in order to avoid this type of attack – in that case, multiple detections or hunting queries could be built utilizing different time spans (24h vs 1h, etc) that can help to provide additional visibility into your environment. Detecting stealthy attackers is a cat and mouse game and I hope this can provide one more tool in your set for disrupting an adversaries attack-chain.
If you want to learn about how Varonis products can aid in detecting and responding to attacks against your Active Directory beyond standard SIEM capabilities, contact me on LinkedIn!
Attacker's Mindset 