On June 17th Will and Lee over at SpecterOps have published their impressive and detailed research into Microsoft Active Directory Certificate Server (AD CS)(mis)configurations in a blog and whitepaper.

If you have not read the blog and whitepaper and you run an AD CS in your environment I strongly encourage you to spend some time understanding the possible issues you might have.

To a certain extent, not all of their mitigation suggestions might be an option for your organization to (immediately) implement. Do keep in mind that mitigating is always preferred over detecting and responding.

One great thing about the white paper is that they have also extensively documented detective guidance, providing all kinds op detection opportunities. To support you on the detection side, we have developed a set of rules to at least have some tripwires in place that alert you of potential abuse.

Obviously, there will be a lot of legitimate use of generating new certificates as well. Especially if you, for instance, use smart cards or have a Network Access Control (NAC) solution in place that uses the 802.1x authentication based on the device certificates. However, NAC is generally used only on workstations and not on servers so that should be relatively easy to filter.

This FalconFriday primarily focuses on the first two detection chapters of the whitepaper. Out of these chapters we chose a subset of the mentioned EventIDs to work with. There is a lot more to be gained from the whitepaper; this might be covered in a follow-up post. Expect an update / new post once we have more visibility in the CS specific EventIDs (e.g. 48XX) in production environments.

The detections for the EventIDs that we’ve covered below have been designed to be actionable and have an acceptable false positive rate in most sizeable production environments with little tuning.

4768 (S, F): A Kerberos authentication ticket (TGT) was requested.

Sub category: Audit Kerberos Authentication Service

Event description: This event is generated every time the Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT).

This event is only enabled for successful events and generates events only on domain controllers. This is sufficient for this detection.

As suggested in the whitepaper and in different discussions around the topic, this event allows you to detect the use of certificates for authentication. The detections suggest to alert if the “Cert*” fields in the event have a value. When testing this, it turned out to be infeasible in any realistic organization. Since in our view one of the most powerful attacks described is the NTLM relay attack to get machine certificates (i.e. ESC8), our detection rule tries to identify misuse of this very specific yet powerful attack path. We have the following assumptions about the attack:

1. The attacker has generated a certificate for the machine account.
2. Machine account certificates are being used for SCCM/802.1X.
3. Servers are do not use machine certs for SCCM/802.1X.

The above are fair assumptions in quite some organizations. With these assumptions in mind, we’ve built a detection rule to identify someone using machine certificates for request Kerberos TGTs (DETECT2 in the whitepaper). In order for the query to work, you need some kind of custom lookup to distinguish between servers and workstations in your environment.

Please consider: Kerberos Ticket Granting Ticket (TGT) request baselining gets tricky quite fast. For instance, when using SCCM this is quite challenging since this already relatively frequently makes these ticket requests. 1 more during an attack is often too little to stand out as an anomaly and can therefore cause blind spots.

The query can be found here.

5058 (S, F): Key file operation.

Sub category: Audit Other System Events

Event description: This event is generated when an operation (read, write, delete, and so on) was performed on a file that contains a KSP key by using a Key Storage Provider (KSP). This event generates only if one of the following KSPs were used:

• Microsoft Software Key Storage Provider.
• Microsoft Smart Card Key Storage Provider.

This event is enabled by default on (at least) Windows Server 2016+.

This event helps to identify a malicious backup of your CA key. The details are described in DETECT3 in the whitepaper.

We’re essentially looking for someone that performs a read operation of the key from the file. This usually only happens at booting of the server, restarting of the service or when generating a backup, as far as we have been able to test. Note that this one will give you some false positives. So our query is probably best used for hunting instead of a detection rule.

Link to query.

5059 (S, F): Key migration operation.

Sub category: Audit Other System Events

Event description: This event is generated when a cryptographic key is exported or imported using a Key Storage Provider (KSP). It is generated only if one of the following KSPs were used:

• Microsoft Software Key Storage Provider
• Microsoft Smart Card Key Storage Provider

The event is enabled by default on (at least) Windows Server 2016+.

Monitoring this event is again related to DETECT3 to identify malicious backups of the CA key. We’ve identified that if someone performs a backup of the key, the account registered is the user account of that user, not the machine account of the CA server. So this rule monitors for that specific use-case. This is by far the most precise rule to look for exported private keys. Zero false positives expected.

Link to the rule here.

Knowledge center

Other articles

FalconForce realizes ambitions by working closely with its customers in a methodical manner, improving their security in the digital domain.

KVK 76682307
BTW NL860745314B01