Microsoft July patch adds new fields to Windows Security events: what does it mean for a SOC/DFIR team?
Those working in an operational cybersecurity team know how important Windows events are when it comes to knowing what’s happening (or what happened) inside an Active Directory domain. The Security channel on Domain Controllers provides several domain authentication-related events, including the following three that we will talk about in this short article:
- 4768: A Kerberos authentication ticket (TGT) was requested
- 4769: A Kerberos service ticket was requested
- 4770: A Kerberos service ticket was renewed
For the past few months, we’ve expressed to Microsoft several shortcomings regarding Active Directory events. One of them is the need to uniquely identify a Kerberos ticket, and we’ll see why it was important.
The need
Imagine an investigation that starts with a suspicious AD event, let’s say a Kerberoasting alert. What you’d typically have exposed in the suspicious 4769 event, as a starting point, is the user that made the TGS request, and the source IP of that request.
What if there are also legitimate user activities coming from that IP, which could be for instance a know equipment performing SNAT before reaching the DC? How will you segregate between legitimate and malicious AD activities?
However, if we could uniquely identify the TGT that was presented to perform any further actions (such as requesting a TGS), we would be able to segregate activities correctly.
Another scenario would simply be that the two sessions (legitimate and malicious) are indeed from the same asset. An example is given below where we have an exposed service using AD credentials (VPN appliance, web service…) that got completely compromised. The attacker could decide to directly open a new session from the same machine and, from the DC’s perspective, we will also not be able to segregate legitimate from malicious actions.
The solution
In its latest patch, Microsoft released new fields for Windows events 4768, 4769, and 4770 from the Security channel. Those fields, present in the Ticket information section of the event are the following:
- Present in 4769 & 4770: Request ticket hash
- Present in 4768, 4769 & 4770: Response ticket hash
As their name suggests, the first one is the unique identifier of the Kerberos ticket presented to the DC to perform the action related to the event (i.e. getting a TGS for a 4769, or renew a TGS for a 4770).
The second one is the unique identifier of the ticket issued by the DC which can either be a TGT (4768) or a TGS (4769 & 4770) depending on the related event.
How can we use them?
Response
The first direct application is during an investigation. The same way you can pivot between process IDs to find the whole process tree of a suspicious process, you will be able to find the Kerberos ticket tree and answer key questions that can arise in IR, such as: what are the other actions performed during a suspicious session?
In the following example, let’s take back our example of a Kerberoasting alert. Being able to draw the whole ticket tree allows us to show all the other actions that the attacker did during its malicious session, which shows other potential impactful actions that might need further investigation.
Detection
There are also detection use cases that you can build which will be more or less feasible depending on your own perimeter.
First one is about a new opportunity to detect forged TGTs (aka. golden tickets). The idea is simple: since you have a fingerprint of all TGTs issued by your DCs, if you ever see a fingerprint you don’t know that was presented to get a TGS ticket, then it must be forged.
Challenges are multiple, that’s why it’s more or less feasible:
- Since those are new fields introduced by Microsoft, are they reliable (see the next paragraph and logon GUIDs)?
- What is the lifetime of TGTs in my environment? Do I have several environments where the lifetimes differ?
- To have a complete list of TGT fingerprints, we should not only look at 4768 events, but also at 4769 events for the krbtgt service, and at 4770 events for TGS ticket renewals for krbtgt
A draft of that search would be something like this, with a TGT default lifetime of 10 hours. I am using Splunk Query Language.
EventCode=4769 earliest=-1h
NOT [ search EventCode=4768 earliest=-11h
| table Response_ticket_hash
| dedup Response_ticket_hash
| rename Response_ticket_hash as Request_ticket_hash ]
NOT [ search EventCode=4769 Service_Name=krbtgt* earliest=-11h
| table Response_ticket_hash
| dedup Response_ticket_hash
| rename Response_ticket_hash as Request_ticket_hash ]
NOT [ search EventCode=4770 Service_Name=krbtgt* earliest=-11h
| table Response_ticket_hash
| dedup Response_ticket_hash
| rename Response_ticket_hash as Request_ticket_hash ]There is still an open window in this query which could allow an attacker to still use a forged TGT to get a TGS undetected. I’ll let the reader find the flaw!
The second use case example is a new opportunity to detect Pass-The-Ticket scenarios. Instead of requesting a new ticket, an attacker could choose to steal an existing ticket and re-use it, potentially from another asset. To detect this, we can simply look at the different source IPs used by a given ticket during its lifetime.
Challenges are also multiple:
- Again, what about SNAT?
- What about people’s laptops being assigned multiple IPs in the lifetime of a ticket (e.g. if they’re moving within a building)?
And I guess again that the replies will depend on your own environment. An example of workaround would be to simply restrict this search to service accounts, which are still often targeted by attackers.
What’s the difference with logon GUIDs?
Some of you might already use the logon GUID field to perform some of the pivots described in this article. As described by Microsoft’s documentation, logon GUIDs can technically allow linking 4769 with authentication events.
Practically, it is known that it is often not possible to do so, as explained for instance in the Windows events bible here. I encourage you to do your own testing if you’re not convinced yourself though.
However, the 4624 event is extremely important per se as it gives important information regarding the session level itself (elevated token or not, etc.) whereas the 4768 event gives information at the ticket level. In other words, if you’re able to correlate a 4624 event, it’s always useful.
Conclusion
Microsoft made a huge improvement that will help both detection & response teams in case of Active Directory attack scenarios, and I hope those few hints on how those new fields can be useful will kickstart your own ideas.
Don’t hesitate to check out my previous article here dealing with building, attacking and responding to an Amazon EKS cluster incident.
