When your Enterprise PKI becomes one of your enemies (Part 4)

In the last blog post series – When your Enterprise PKI becomes one of your enemies (Part 3) we vent trough how Authentication Mechanism Assurance (AMA) works and how it can be abused together with Public Key Infrastructure (PKI) to compromise an Active Directory forest if it’s not designed the right way.

To summaries the abuse demonstrated in the post – here are the requirements (Note that the CA don’t have to be trusted in NTAuth)

1. Obtain a certificate from a certificate authority (CA) that is trusted on the KDC and being able to supply the AMA Issuance Policy OID – this can be archived by:
   • Certificate Template configured for ‘Supply in the request’ – SITR
   • Being delegated Certificate Manager on the certificate authority for one or more templates
2. The KDC must have a valid certificate
3. Being able to write to at least one user account’s altSecId (altSecurityIdentities) attribute.

Authentication Mechanism Assurance (AMA) abuse using Key Trust and KCL

Let’s demonstrate another way to abuse Authentication Mechanism Assurance (AMA) and change the requirements a bit – this is only possible against Windows Server 2016 KDCs and later.

Windows Server 2016 introduced Key Trust model to the KDC where PKINIT can be performed using a explicit key trust instead of certificate trust. They key trust model works by mapping the public key of a private/public key pair into the ‘msDS-KeyCredentialLink’ attribute of a security principal deriverad from the user or computer class, authentication can then be performed by providing the public key. This functionality was mainly added to support Windows Hello for Business (WHFB) to allow other authentication methods to be used on top of PKINIT, it’s also utilized with Entra ID – Kerberos Cloud Trust.

For more information see – 3.1.5.2.1.4 Key Trust

So what does the Key Trust model have to do with Authentication Mechanism Assurance (AMA)?

We can think of the ‘msDS-KeyCredentialLink’ as the ‘altSecurityIdentities’ attribute in the previous abuse scenario – But there is one major difference a computer account can by default write to it’s own ‘msDS-KeyCredentialLink’ attribute granted to the SELF security principal on every computer accounts default ACL – as long as the ‘msDS-KeyCredentialLink’ is empty –

This is interesting as it means there is no need to have any special access in the directory to upload the public key of our private/public key pair as long as we can become / operate in the security context of just one domain joined computer account within the entire forest – doing so would require being local administrator at one of those boxes utilizing PsExec to become SYSTEM.

Note all my demos uses ‘CertRequestTools‘ from Carl Sörqvist and in this case also Rubeus from Will Schroeder and Whisker from Elad Shamir

But first we need to obtain a certificate with the AMA Issuance Policy OID in order to abuse it – and enroll it to the machine, replace <Template> with a template in your environment configured for – Supply in the request (SITR) :

Import-Module -Name CertRequestTools
# Chrisse Issuing CA1 is trusted in NTAUTH
$CA1 = "nttest-ca-01.nttest.chrisse.com\Chrisse Issuing CA 1"  
# A0 AMA Policy OID (linked to Enterprise Admins)
$AmaExtension = New-CertificatePoliciesExtension -Oid "1.3.6.1.4.1.311.21.8.10665564.8181582.1918139.271632.11328427.90.1.402"
 
New-PrivateKey -RsaKeySize 2048 -KeyName ([Guid]::NewGuid()) `
| New-CertificateRequest `
    -Subject "CN=DEMO4" `
    -UserPrincipalName "NTTEST-CL-01.nttest.chrisse.com" `
    -OtherExtension $AmaExtension `
| Submit-CertificateRequest `
    -ConfigString $CA1 `
    -Template <Template> `
| Install-Certificate -Name My -Location LocalMachine

Now it’s time to become the machine it self and act as SYSTEM on ”NTTEST-CL-01.nttest.chrisse.com”

Psexec.exe -i -s C:\WINDOWS\system32\cmd.exe

Now we’re going to add the public key of our certificate to the ‘msDS-KeyCredentialLink’ attribute – to do this we use a tool named Whisker.

Replace <Hash> with the hash of the certificate issued previously and lunch it in the cmd instance created by Psexec.

whisker add /target:NTTEST-CL-01$ /path:<HASH>

Note that I’ve modified whisker slightly to look for a certificate by hash in the computer personal store also known as LocalMachine\MY.

Now the path is very similar to the previous abuse scenario demonstrated – we will use rubeus to perform a PKINIT with our certificate’s public key, it’s going to be matched with the key we just stored in ‘msDS-KeyCredentialLink’ of the computer account “NTTEST-CL-01.nttest.chrisse.com”

Note that I’ve modified rubeus slightly to also look for certificates by hash in the computer personal store also known as LocalMachine\MY.

rubeus asktgt /user:NTTEST-CL-01$ /certificate:<HASH> /enctype:aes256 /createnetonly:C:\Windows\System32\cmd.exe /show

We should now be authenticated as the computer account “NTTEST-CL-01.nttest.chrisse.com” and having the extra two security groups – ‘Enterprise Admins (AMA)’ and ‘Enterprise Admins’ (RID 519) as part our token thanks to the AMA Issuance Policy being present in the certificate we authenticated with.

You should now see something similar to the screen below, the cmd launched by rubeus should now have ‘Enterprise Admin’ privileges and you should be able to add a user to ‘Domain Admins’ as stated in the example.

Summary

The main difference using this path to abuse Authentication Mechanism Assurance (AMA) compared to the example demonstrated in the previous blog post is mainly two things.

1. The ability to become local administrator at any computer within the Active Directory forest instead of having write access in Active Directory to a users ‘altSecurityIdentities’ attribute.
2. For this to work the certificate authority that the certificate is issued from must be from a certificate authority that is trusted in NTAuth.

The requirement of being able to supply the AMA Issuance OID into the certificate still remains and can be achieved the same way.

• Templates published on the Certificate Authority that are configured for Supply in the request – SITR.
• Being Certificate Manager on the CA over one or more templates

One side effect of dealing with a key trust here instead of a certificate trust is that the KDC will ignore any validation errors such as CRL – that means if a certificate get issued for AMA abuse and stored in any computer accounts ‘altSecurityIdentities’ in the forest – it would NOT help if you would revoke that certificate. Pretty bad isn’t it? In order to scan your forest you must obtain the public key for any certificate issued with the AMA Issuance Policy OID from all your Certificate Authorities and start scanning every single object with contents in ‘msDS-KeyCredentialLink’ and it’s a linked multi-valued attribute.

Authentication Mechanism Assurance (AMA) is a good feature if being deployed correctly for the reasons mentioned in the beginning of this post, binding strong privileges to certificate based authentication and just in time is a good thing for sure – the question remains what can we do to prevent the abuse of Authentication Mechanism Assurance (AMA) as described and demonstrated in this blog post? It’s possible if you design your Public Key Infrastructure the right way and how it integrated with Active Directory and we’re going to cover some alternatives on how this can be mitigated in coming blog posts.