TL;DR

I wrote in one of my previous posts about how control over a certificate template of any kind can be abused to get a Smartcard certificate for a domain admin. In this post, I want to write a little bit more about the persistence capabilities this approach has to offer, as well as how you can detect it. I call this approach a “golden certificate” as a tribute to Benjamin Delpys famous “golden ticket”. The lifetime will not be as long as the one of a golden ticket since certificate lifetime is subject to some boundaries as described below, However it will usually be at least a year - so pretty much time for the attacker anyway.

Credits go to the folks at sysadmins.lv, which is an excellent source on PKI related stuff and (as always) Will Schroeder for gifting us with PowerView.

Recap

Certificate templates are objects in Active Directory that are used as a form of decentralized configuration by Active Directory integrated Certificate Authorities (Active Directory Certificate Services - ADCS). Certificate templates are normally used for a certain purpose (e.g. computer certificates, S/MIME certificates,…) but that’s just how it looks for the Administrator. They are all the same kind of object and if you have write access on the object itself, you can just reconfigure a computer template or any other template to be a smartcard template that accepts arbitrary user names :-). How do we get there?

Finding vulnerable templates

You can find target accounts with PoshADCS. Just download it from Github and also don’t forget PowerView, since we rely on that. First import both into your current PowerShell session.

cat -raw PowerView.ps1 | iex
cat -raw ADCS.ps1 | iex

Then run Get-ADCSTemplateACL to query the ACLs of all certificate templates in the current domain. You can use one of the predefined filters to reduce the results since all templates have a couple of default ACEs that allow access for default groups (e.g. Domain Admins).

• -Filter AdminACEs will remove the ACEs of default administrative groups from the output.
• -Filter DefaultACEs will remove administrative ACEs like above, but will also hide other default groups (e.g. Domain Computers on a computer template).

This is useful if you are looking for permissions that have been set explicitly in your environment and grant access to custom users or groups.

Get-ADCSTemplateACL -Filter DefaultACEs

In our example below, we see that the user “John” has been granted explicit write permissions on the computer template.

If we can get hold of this users credentials, we can use these to get a smartcard certificate for a domain admin or basically any other user you would like to impersonate. The Get-SmartCardCertificate function inside PoshADCS allows us to do just that. But more on that later.

Lifetime of a Golden Certificate

The maximum certificate lifetime will be the shortest of the following:

• the validity time configured in the certificate template.

• the remaining validity period of the signing CA certificate. Simply put, a certificate issued by a CA cannot be valid longer than the CA certificate itself.

• the timerange defined in the CA configuration file (CAPolicy.inf) during installation. If not defined, this is the default value of 2 years, which means that if the CA is deployed with all default values, the Golden Certificate can usually not last longer than 2 years maximum. You can check the CA configuration using certutil on the CA server.

  certutil -getreg CA\ValidityPeriod
  certutil -getreg CA\ValidityPeriodUnits
  

Getting a Golden Certificate

man Get-SmartcardCertificate

• Identity is the samAccountName of the target user
• TemplateName is the CN of the template we will abuse (= the one you have write permissions on)
• NoSmartCard instructs the script not to use the Smartcard CSP and make the certificate exportable. The resulting certificate will be stored in the normal user certificate store. This is useful if you have no ability to get a Smartcard on the host you request the certificate on. Just export it from the store and import it back on a smartcard on a host you control. It’s also useful if you just want to prove that the attack would succeed without messing around with Smartcards.

We will run Get-SmartcardCertificate mit the NoSmartCard switch to get an exportable certificate for the user “Chuck Norris” (who obviously is a domain admin).

Get-SmartcardCertificate -Identity norris -Template CorpComputer -NoSmartcard

Defending against Golden Certificates

Like Golden Tickets, you can’t really prevent these things once an attacker has the appropriate permissions to do so. But you can detect and respond as soon as it happens.

• First, be aware that your CA Admins (or any other user who can change a certificate template) are equivilant to Domain Admins. Therefore monitor and protect these accounts as you do with your Domain Admins.
• Second, you should monitor issued certificates and changes to certificate templates closely.

I will sum up quickly how to configure auditing on the CA but you should definitely have a look at Microsofts PKI Monitoring Guide for more details.

We start with enabling success/failure logging for “Object Access\Audit Certificate Services”. You can do this with group policy (Configuration\Windows Settings\Security Settings\Advanced Audit Policy) or locally by running

auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

After that you need to enable auditing in the “Auditing” tab of your CA. I would recommend to enable all categories but you need at least “Change CA configuration” and “Issue and manage certificate requests” to detect this attack.

In addition, you have to run the following certutil command to activate logging of template changes.

certutil –setreg policy\EditFlags +EDITF_AUDITCERTTEMPLATELOAD

Now that everything is set, you should find events of the task category Certification Services trickling into the default Security log of your CA. Rebooting the CA server once might speed this process up if you are missing events.

The event most interesting for us is A Certificate Services template was updated (4899). 4899 will be logged when a certificate template changes and contains the old as well as the new configuration. You can use this to match template updates where the new configuration contains a pKIExtendedKeyUsage attribute that matches the string 1.3.6.1.4.1.311.20.2.2 Smart Card Logon.

We will also find a Certificate Services approved a certificate request and issued a certificate (4887) for our Golden Certificate, however this event unfortunately does not hold much information for us. You can see in the screenshot below that we do not find the identity to whom the certificate was issued in the event nor the certificate template it refers to :-( :-( :-(. Therefore we cant use this event to alert on but it is still useful from a forensics perspective.

That’s it for now. Give it a try and let me know what you think!