Blog

After installing KB5014754 addressing a Certificate Services vulnerability (CVE-2022-26923 discovered by security researcher Oliver Lyak nicknamed “Certifried“), at some point in time the patch will go from detection mode to enforcement mode. This happens November 14, 2023 unless you actively disable this (which you shouldn’t)

So are you good to go, or will problems arise right before the month of endless “Last Christmas” replays on the radio?

Let’s use data from multiple sources to find events that are flagged, and see what templates are generating them, so we can figure out to fix problems.

First we’ll extract events from the Azure Sentinel Log by running this query:

Event
| where EventID == 39
| extend XMLFields=tostring(parse_xml(EventData).DataItem.EventData.Data)
| extend UserName=extractjson("$[0]['#text']", XMLFields)
| extend Subject=extractjson("$[1]['#text']", XMLFields)
| extend Issuer=extractjson("$[2]['#text']", XMLFields)
| extend Serial=extractjson("$[3]['#text']", XMLFields)
| extend Thumbprint=extractjson("$[4]['#text']", XMLFields)
| project UserName, Subject, Issuer, Serial, Thumbprint
| summarize count() by UserName, Issuer, Serial, Thumbprint
| sort by count_ desc

Here’s a screenshot of this process – I’ve chosen a custom time range going back 3 months just to make sure I’m not missing anything. Your output is a list of serial numbers, thumbprints and the count of times the certificate has been used to authenticate in the time range selected. The issuing CA is also available, and we’ll need this shortly.

Press the “Export” button in Azure Sentinel Log and chose “CSV All Columns” to save the data to the local disk.

Next, we need to get data from the issuing CA’s. In order to be clever and not use Remote Desktop, I used the PKITools module for PowerShell – first install it with this command:

Install-Module PKITools

You will need to map the name of your CA to a computer name, and dump each of them. You should be able to run it on all of them without parameters, but due to Kerberos issues I had to run each of them manually:

Get-IssuedCertificate -CALocation SERVERNAME\Your-CA-Name | Export-CSV -Path C:\adcs\issued-by-my-CA.csv

For some reason some of the template names did not resolve for me, so I ran a LDAP query to get those from the AD mapping the OID to the name:

Get-ADObject -LDAPFilter '(objectclass=pkicertificatetemplate)' -Searchbase 'cn=configuration,dc=domain,dc=local' -Property Name,msPKI-Cert-Template-OID | Export-CSV -Path C:\adcs\templatenames.csv

Next up is mapping the violations to the issued certificates, and just like everyone else I assume that Excel is excellent for this. Unforunately that is not the case, so after waiting 10 minutes for Excel not to complete loading 96K lines of CSV I thought bad things about Excel, and remembered that I need to use KNIME which is both fast and open source.

You can find KNIME here: https://www.knime.com/

I downloaded the pre-release version 5.0 as a ZIP file, and decompressed this in a local folder. After running KNIME.EXE you get a GUI and it lets you do all sorts of data manipulation. I switched to the old UI layout and ended up with this:

The red arrows point to data inputs and the green ones to the results you can get from this. You can download a copy of the workflow from here: Cert Analysis.knwf – you might run into issues with date formats, but give it a try.

So what can we see with this? In my case this was the stacked area chart:

What you see here are certificates that has been presented to the DCs in the custom period you chose while exporting Sentinel data. This is mapped to the certificate ISSUANCE date and the template that it originated from. I interpret the graph like this:

It’s now April 2023 (week 15). In the last three months the DCs have seen certificates originating from three templates that has been a problem, with the most different ones being in the period between April 2022 and June 2022. Since the patches have been installed in June 2022 and the certificate validty period is 1 year for the two computer and user templates, this matches up perfectly fine.

The trouble is different with the Client-Auth-NDES template, which has certificates going back to 2021 and they’re not dropping off recently. Notably even recently issued certificates also have this problem, so we’re still issuing new templates that are not strongly mapped to the account. It would be likely to assume that these certificates have a lifetime of 2 years.

The pie chart “Certificate Requester” shows quite clearly that the majority of certificates without strong mapping issues is requested by one service account, while the rest is bundled together in the “others” category (every account with 3 requests or less end up there, so these are regular users or machines requesting on behalf of themselves).

So now we have a clear indication that 1) we have a problem and 2) we know both the template and 3) who requests the certificates.

Now comes the hard part … getting the template / issuance workflow fixed and then forcing new certs out.