After SpectreOps released the research paper , Active Directory Certificate Services (AD CS) became one of the most favorite attack vectors for threat agents due to many reasons, including:
Using certificates for authentication has more advantages than regular username/password credentials.
Most PKI servers were misconfigured/vulnerable to at least one of the eight attacks discovered by SpectreOps (various researchers have discovered more attacks since then).
There are a plethora of advantages to using certificates and compromising the Certificate Authority (CA):
Users and machines certificates are valid for 1+ years.
Resetting a user password does not invalidate the certificate. With certificates, it doesn't matter how many times a user changes their password; the certificate will still be valid (unless expired or revoked).
Misconfigured templates allow for obtaining a certificate for any user.
Compromising the CA's private key results in forging Golden Certificates.
These advantages make certificates the preferred method for long-term persistence. While SpectreOps disclosed eight privilege escalation techniques, we will examine the first, ESC1, to demonstrate how it works. The description of ESC1 is:
Domain escalation via No Issuance Requirements + Enrollable Client Authentication/Smart Card Logon OID templates + CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT.
Attack
To begin with, we will use to scan the environment for vulnerabilities in the PKI infrastructure:
When checking the 'Vulnerable Certificate Templates' section from the output of Certify, we will see that a single template with plenty of information about it is listed. We can tell that the name of the CA in the environment is PKI.eagle.local\eagle-PKI-CA, and the vulnerable template is named UserCert. The template is vulnerable because:
All Domain users can request a certificate on this template.
Manager approval is not required (the certificate gets issued immediately after the request without approval).
The certificate can be used for 'Client Authentication' (we can use it for login/authentication).
To abuse this template, we will use Certify and pass the argument request by specifying the full name of the CA, the name of the vulnerable template, and the name of the user, for example, Administrator:
Now that we have the certificate in a usable PFX format (which Rubeus supports), we can request a Kerberos TGT for the account Administrator and authenticate with the certificate:
After successful authentication, we will be able to list the content of the C$ share on DC1:
PS C:\Users\bob\Downloads> dir \\dc1\c$
Directory: \\dc1\c$
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 10/15/2022 6:30 PM DFSReports
d----- 10/13/2022 11:23 PM Mimikatz
d----- 9/1/2022 9:49 PM PerfLogs
d-r--- 11/28/2022 10:59 AM Program Files
d----- 9/1/2022 2:02 PM Program Files (x86)
d----- 12/13/2022 11:22 AM scripts
d-r--- 8/7/2022 9:31 PM Users
d----- 11/28/2022 11:27 AM Windows
Prevention
The attack would not be possible if the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is not enabled in the certificate template. Another method to thwart this attack is to require CA certificate manager approval before issuing certificates; this will ensure that no certificates on potentially dangerous templates are issued without manual approval (which hopefully correlates that the request originated from a legit user).
Because there are many different privilege escalation techniques, it is highly advised to regularly scan the environment with Certify or other similar tools to find potential PKI issues.
Detection
When the CA generates the certificate, two events will be logged, one for the received request and one for the issued certificate, if it succeeds. Those events have the IDs of 4886 and 4887 as shown below:
Unfortunately, we can only tell that Bob requested a certificate from WS001; we cannot know if the request specified the SAN.
The CA contains a list of all issued certificates, so if we look there, we will see the request for certificate ID 36 (the one from the attack scenario above):
The general overview of the GUI tool does not display the SAN either, but we can tell that a certificate was issued via the vulnerable template. If we want to find the SAN information, we'll need to open the certificate itself:
There is also the possibility to view that programmatically: the command certutil -view will dump everything on the CA with all of the information about each certificate (this can be massive in a large environment):
With some scripting, we can automate parsing and discovery of abused vulnerable templates by threat agents.
Finally, if you recall, in the attack, we used the obtained certificate for authentication and obtained a TGT; AD will log this request with the event ID 4768, which will specifically have information about the logon attempt with a certificate:
Note that events 4886 and 4887 will be generated on the machine issuing the certificate rather than the domain controller. If GUI access is not available, we can use PSSession to interact with the PKI machine, and the Get-WinEvent cmdlet to search for the events:
C:\Users\bob\Downloads>runas /user:eagle\htb-student powershell
Enter the password for eagle\htb-student:
Attempting to start powershell as user "eagle\htb-student" ...
PS C:\WINDOWS\system32> New-PSSession PKI
Id Name ComputerName ComputerType State ConfigurationName Availability
-- ---- ------------ ------------ ----- ----------------- ------------
4 WinRM4 PKI RemoteMachine Opened Microsoft.PowerShell Available
PS C:\WINDOWS\system32> Enter-PSSession PKI
[PKI]: PS C:\Users\htb-student\Documents> Get-WINEvent -FilterHashtable @{Logname='Security'; ID='4886'}
ProviderName: Microsoft-Windows-Security-Auditing
TimeCreated Id LevelDisplayName Message
----------- -- ---------------- -------
4/13/2023 4:05:50 PM 4886 Information Certificate Services received a certificate request....
4/11/2023 1:24:02 PM 4886 Information Certificate Services received a certificate request....
4/11/2023 1:15:01 PM 4886 Information Certificate Services received a certificate request....
[PKI]: PS C:\Users\htb-student\Documents> Get-WINEvent -FilterHashtable @{Logname='Security'; ID='4887'}
ProviderName: Microsoft-Windows-Security-Auditing
TimeCreated Id LevelDisplayName Message
----------- -- ---------------- -------
4/13/2023 4:06:05 PM 4887 Information Certificate Services approved a certificate request and...
4/13/2023 4:06:02 PM 4887 Information Certificate Services approved a certificate request and...
4/11/2023 1:24:14 PM 4887 Information Certificate Services approved a certificate request and...
4/11/2023 1:24:14 PM 4887 Information Certificate Services approved a certificate request and...
4/11/2023 1:15:12 PM 4887 Information Certificate Services approved a certificate request and..
To view the full audit log of the events, we can pipe the output into Format-List , or save the events in an array and check them individually:
1) Connect to the Kali host first, then RDP to WS001 as 'bob:Slavi123' and practice the techniques shown in this section. What is the flag value located at \dc1\c$\scripts?
Answer: Pk1_Vuln3r@b!litY
2) After performing the ESC1 attack, connect to PKI (172.16.18.15) as 'htb-student:HTB_@cademy_stdnt!' and look at the logs. On what date was the very first certificate requested and issued?
Answer: 12-19-2022
The flag is present, allowing the requester to specify the SAN (therefore, any user can request a certificate as any other user in the network, including privileged ones).
Once the attack finishes, we will obtain a certificate successfully. The command generates a PEM certificate and displays it as base64. We need to convert the PEM certificate to the format by running the command mentioned in the output of Certify (when asked for the password, press Enter without providing one), however, to be on the safe side, let's first execute the below command to avoid bad formatting of the PEM file.
