Security operations · 3 MIN READ · BRADY STOUFFER · SEP 13, 2023 · TAGS: MDR
The EventCode 39 case: some of the best threats we see arrive courtesy of clever red teams. In this story, we unravel an attack on Active Directory and how we countered it with two new detections.
Recently, a customer encountered a red team operation which included attacks against Active Directory (AD). More specifically, they exploited vulnerable configurations in AD Certificate Services (AD CS). While there were over a dozen detections in place for the activity observed during the operation, including a couple of custom SIEM detections the customer developed, none of the alerts detected the AD CS abuse. We didn’t feel great about the detection gap, so we decided to dive into the Windows event logs for traces of the AD CS abuse to see if we could help the customer better detect the activity in the future.
We scoured some amazing blogs and resources detailing a variety of attacks targeting AD CS, as well as detections that others have developed and shared with the community. We hypothesized that these techniques could be detected in the logs but, for the most part, that wasn’t the case.
Back to the drawing board.
While we were hunting for new detection opportunities, our security operations center (SOC) colleague Kyle Pellet reminded us of a previous red team operation at another customer that similarly exploited AD CS. During that investigation, we saw a very rare event in the customer’s environment: EventCode 39 in the Windows system logs for the domain controller. Unfortunately, the customer didn’t have logs and tech in place to operationalize this potential detection opportunity, so we were at a dead end. This time around, though, we were optimistic.
We first checked to see if the customer was indexing its domain controller’s system logs (this is a less common log source for security use cases than security logs). Good news: we had the logs!
We then searched for EventCode 39 during the time of the operation and, wouldn’t you know, we got hits. Bad news: there were a lot of them.
Instead of calling it quits, we confronted the challenge like curious detection engineers do. Looking closer at the 450+ events that occurred in the 30-day period, we noticed that two events related to the operation were quite unique; the Account Name of the event and the Common Name (CN) of the certificate weren’t referencing the same user like all the other events. We’d found an anomaly.
But we still weren’t done. How do we build logic to detect this case, especially since the format of the two usernames wasn’t consistent? Also, were there other anomalies that could serve as additional detection opportunities?
Tackling the first question, we were able to use a combination of Splunk’s rex, split, and mvindex commands to extract the username values from the Subject and AccountName fields so we could effectively compare them. With this logic applied, the original result set of 450+ events was reduced to just the two that were related to the red team operation. High fidelity? ✅
Suspicious certificate use—mismatched AccountName and CN
| rex field=Subject “(?P<cn>(?<=CN=).[^\s,]+)”
| eval cn = lower(mvindex(split(cn, “.”),0))
| eval acct_name = lower(rtrim(AccountName, “$”))
| where acct_name!=cn
| table _time EventCode acct_name cn Subject AccountName Computer
To answer the second question—whether there were additional detection opportunities—we stepped back and took another look at all the events for EventCode 39, at which point we noticed another anomaly: for the events related to the operation, the CN was referencing a machine name. To detect this, we again needed to extract the CN from the Subject field. With that extraction, we simply needed to search for instances where the CN ended in a dollar sign ($), indicating a machine name.
Suspicious certificate use—machine name as CN
| rex field=Subject “(?P<cn>(?<=CN=).[^\s,]+)”
| eval cn = lower(mvindex(split(cn, “.”),0))
| table _time EventCode cn Subject AccountName Computer
| search cn=*$
Okay, so, what is EventCode 39, anyway? Well, it appears to be fairly new. According to Microsoft, it was added as a new audit event in their May 10, 2022 update (KB5014754) to indicate “no strong certificate mappings could be found, and the certificate did not have the new security identifier (SID) extension that the KDC could validate.”
In the same Microsoft notice, two additional EventCodes were released: 40 and 41. Prior to this MS update, “certificate-based authentication would not account for a dollar sign ($) at the end of a machine name. This allowed related certificates to be emulated (spoofed) in various ways.”
While we didn’t observe these additional EventCodes in the environment, they’re intended to identify other certificate-related events that could indicate spoofing attempts. We haven’t yet evaluated the prevalence of these events in other environments, but we expect them to be rare and likely solid detection opportunities.
Like all detections, we suggest scoping your environment to assess volume and fidelity before deploying these in your environment.
