Device and user-based certificates are commonly used for secure authentication for services like: MECM in HTTPS mode, Always On VPN, 802.1x for (wireless) LAN and so on. Mostly these certificates are deployed from an internal PKI and the certificate templates are somewhat outdated because everybody is afraid of touching these settings. As with any type of credentials - credential theft is also applicable for certificates and the corresponding private keys. So let’s dive in and learn the risk and how to reduce the attack surface.

Understanding cryptography providers

Before we start with the actual theft we need to know how certificates and the corresponding private keys are stored on Windows devices. Microsoft operating systems implement various cryptographic providers which can be either software or hardware based. The two most important ones are:

  • Microsoft Software Key Storage Provider
    • “Standard” provider which stores keys software based and supports CNG (Crypto-Next Generation)
  • Microsoft Platform Crypto Provider
    • Hardware based which stores keys on a TPM (trusted platform module) and supports CNG as well

When a client is requesting a new certificate from a CA he generates a key pair consisting of a private and public key with such a crpytographic provider.

Are private keys exportable?

The Allow private key to be exported flag can be set directly on the certificate template and controls if the certificate key is marked as exportable. The problem here is that based on the cryptographic provider the provider can be patched to allow exporting the key material by tools like mimikatz. This “technique” exists already for almost a decade so nothing special:

1
2
3

privilege::debug
crypto::cng
crypto::certificates /systemstore:CERT_SYSTEM_STORE_LOCAL_MACHINE /store:MY /export
  • Dont enable the Allow private key to be exported flag on certificates distributed to Windows clients or end users when not necessary (of course exceptions for separate S/MIME and Code Signing certificates exist)
  • Just because you didn’t set the flag don’t believe that you are not vulnerable to this type of credential theft {: .notice–warning}

Key Attestation

Okay, but I promised that this post will be about key based attestation. So what’s this? By leveraging hardware security features, more precisely a TPM (trusted platform module) windows supports using the “Microsoft Platform Crypto Provider” which generates and stores key pairs by within a TPM which is considered tamper proof.

To support key attestation the following prerequisites must be met:

  • Server 2012 R2 Enterprise CA or newer
  • Clients running Windows 10 (Windows 8.1 would be the minimum but I guess nobody uses this) and having a TPM present

Key attestation can be configured with multiple deployment options going as far as restricting which TPMs (based on manufacturer cert) or even specific devices based on the TPM cert. You can find more details on the oficial Microsoft Docs but I’m focusing on the basics within this post.

Configuring the certificate template

To enforce key attestation for Active Directory machines the following settings are required on the certificate template (I’d recommend duplicating your existing client or user certificate):

  • Raise the compatibility settings to at least Windows Server 2012 R2 for the CA and Windows 8.1 / Windows Server 2012 R2 for the recipient or newer (based on your environment)
    • Raise the compatibility settings
  • Select the Microsoft Platform Crypto Provider and I’d also recommend setting the request hash to SHA-256
    • Choose the appropriate crypto provider
  • Set the key attestation settings to required and select User credentials
    • Set key attestation settings

The issuance policy setting can be left default and as a result will be stamped into the issued certificate indicating that the client performed attestation. If you want to learn more about the policy extensions here’s a good article by Vadims Podāns {: .notice–info}

Theft attempt 2.0

When repeating the mimikatz steps we can see that the certificate protected by our machines TPM cannot be exported anymore:

Export cert

we can also verify the TPM KSP (key storage provider) where the private key got enrolled on a machine by using certutil:

1

certutil -csp "TPM" -key -v

Upgrading existing certificates

To replace your existing certificates with TPM attestation based ones make sure that you have certificate auto enrollment activated on your clients. Don’t edit your existing certificate template and create new ones instead. Afterwards you can add your non-key attestation templates as superseeded within the newly created templates and clients will automatically enroll the new one (don’t forget to grant auto enroll permissions).

Upgrade CA certificate template to use TPM attestation

Protecting SCEP Certificates (non Active Directory machines)

For SCEP certificate enrollment via Intune we can configure the TPM attestation settings directly within the SCEP profile settings under the key storage provider option. Because the certificates are enrolled on behalf of the NDES service account we cannot enable these on the certificate template directly.

Intune TPM Attestation KSP

Final words

Now you should be able to better protect your certificate based credentials with a smooth migration path and I recommend to protect all certificates containing the Client Authentication (1.3.6.1.5.5.7.3.2) extended key usage with TPM attestation.

And by the way, Microsoft Defender detects all the noisy mimikatz operations but the most important one to watch out for is the lsass process modification because lsass protects the cryptographic providers stores on Windows machines:

Intune TPM Attestation KSP

References