Certified Pre-Owned Detection Ideas
If you haven't had a chance to read the Medium article or full whitepaper about abusing Certificate Services in Microsoft Active Directory environments I highly suggest you do. You can find the Medium article HERE and the whitepaper (which is very detailed) HERE.
Quick Overview
Basically SpecterOps (some very smart people) discovered a range of ways to abuse Active Directory Certificate Services. The scope of this article is not the in-depth details of how AD CS works or how it can be abused, rather, to provide some quick wins to detect some of the activity in the whitepaper. While SpecterOps provides some guidance on how to detect the specific attacks, I will be providing actual Splunk SPL. We’ll call this article Part 1 of however many it takes as I discover more ways in which to detect these activities. When you check out the whitepaper you will notice they assign ID’s to each attack and defense/mitigation. I’ll use these to reference the actual defense technique referenced in the whitepaper to make your lives easier.
Active User Credential Theft via Certificates — PERSIST1 / NTLM Credential Theft via PKINIT — THEFT5
The goal, in the context of user credential theft, is to request a certificate for a template that allows authentication to AD as that user. This (as i understand it) is very similar to requesting a TGT ticket for a different user/service, except, the certificate will persist even after a password reset! Furthermore, using the certificate to authenticate to DC via Kerberos (request a TGT ticket) will allow the attacker to steal the user’s NTLM hash.
DETECT1
If your environment uses certificates for authentication looking for “abnormal” Windows EventCode 4886 events will likely not be fruitful. However, monitoring for failed Certificate Requests (4888) can be an opportunity for some decent low fidelity signals. To do this we’re going to want to look at our Window Event logs (typically soucetype=wineventlog) and specifically focus on EventCode=4888.
index=windows sourcetype=wineventlog source=”WinEventLog:Security” EventCode IN (4888)
| stats count by Requester,ComputerName,_time
In a typical environment this will occur normally so looking for “abnormal” things like the # of failed events or other indicators might be worth it.
In multi-domain forests a possible alert could be anytime a user/system requests a certificate in a domain that user/system is not a member of. For example, if Bob is a member of the CORPUSERS domain but requests a certificate for LABCORP’s domain that might be suspicious (depending on your environment). To do this we want to split the domain off the Requester and the Certificate Authority server (ComputerName) and compare the two.
index=windows sourcetype=wineventlog source=”WinEventLog:Security” EventCode IN (4886,4888)
| eval src_domain = upper(mvindex(split(Requester,”\\”),0))
| eval dest_domain = upper(mvindex(split(ComputerName,”.”),1))
| where !match(src_domain,dest_domain)
| stats count by Requester,ComputerName,src_domain,dest_domain
At the end of the day attackers are simply using the “features” of AD CA for malicious purposes — in reality these services are supposed to be used this way and will be hard to pick our malicious activity depending on how often certificate authentication or requests are used in your environment. (Like all detections, YMMV)
DETECT2
This detection is aimed at picking up THEFT5 in which the requested certificate is then used to request a Kerberos TGT for the user/system using the previously requested certificate as the authentication proof. In order for this part to work, the attacker would have had to have already successfully stolen a valid certificate.
For this detection we’re going to mainly focus on 2 things:
- The 4768 event MUST include Certificate information
- The 4768 event will be requesting the ticket with RC4 encryption (0x17)
You can see that the certificate information is actually filled in and the “Ticket Encryption Type” = 0x17 along with the Pre-Authentication Type=16.
index=windows sourcetype=wineventlog source=”WinEventLog:Security” TERM(EventCode=4768) EventCode=4768 Ticket_Encryption_Type=”0x17" Pre_Authentication_Type=16 Certificate_Thumbprint=”*” NOT Certificate_Thumbprint=”%*”
| stats count by user,ComputerName,Certificate_Issuer_Name,Certificate_Serial_Number,Certificate_Thumbprint,Ticket_Encryption_Type
Note — while 0x17 is for RC4 any encryption can be requested. Depending on the environment it might make sense to focus on RC4 if AES128/256 is forced by Group Policy.
This should hopefully get you started! Again, if you haven’t checked out the whitepaper or Medium articles I suggest you do. Certificates allow persistence for much longer than traditional passwords, cannot be reset so easily, and open the door for further privileges' escalation and domain persistence techniques. I’m talking about Golden Certificates!
References:
- https://posts.specterops.io/certified-pre-owned-d95910965cd2
- https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf
- https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768#table-5-kerberos-pre-authentication-types
- https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4886
- https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4888
