08 April, 2025

You Don’t Need PKINIT To Win It

You Don’t Need PKINIT To Win It
Ben Goodman
Author: Ben Goodman
Share:

Privilege Escalation using LDAP Part 1

Pass-the-certificate has become a common method used by attackers (as well as us pentesters and red teamers) to gain access or escalate privileges on an internal network.  A certificate can be attained multiple ways such as vulnerabilities in Active Directory Certificate Services (AD CS) and Shadow Credentials leveraging the msDS-KeyCredentialLink ACL attribute on a target host.   However, there are times when it doesn’t go as smoothly as it should.

Let’s say you are on a pentest, and you leveraged the commonly exploited AD CS ESC1 vulnerability.  ESC1 basically allows a non-privileged user to request a PFX certificate on behalf of any other user, typically a member of the Domain Admin AD group.  The certificate is used to authenticate to Kerberos and obtain the Ticket Granting Ticket (TGT) of that Domain Admin.  In this case you don’t get a login and password hash; instead Certipy throws an unfamiliar error.

Trying to get TGT…

Got error while trying to request TGT:  Kerberos SessionError: KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type) 

 

Oftentimes I hear of testers getting this error and either moving on to locate other attack paths or thinking something went wrong with the attack itself, particularly in the instance of created Shadow Credentials.  There is a much simpler explanation, however.  In order to login using a certificate through a valid Kerberos TGT, Public Key Cryptography for Initial Authentication (PKINIT) must be supported in AD.  Typically, this would be enabled if a client has stood up a Microsoft PKI environment but this is not always the case.  If PKINIT is not enabled, the above error will occur. 

What can be done with the certificate then?  This is where LDAP comes into play. Over the course of this series I will be providing information on tools and methods I use to leverage the LDAP protocol in pentests.  This post will cover additional functionality in Certipy, known as ldap-shell.

In my lab, a valid certificate file was attained for the Domain Admin Archmagos Steve on the MachineSpirit.local domain using the AD CS ESC1 vulnerability.  My low-privileged user, Servitor Carl, requested the vulnerable template RitesofDomainAdmin supplying the Domain Admin asteve in the subjectAltName field for impersonation purposes.  Now that we have the cert, we can authenticate using Certipy.  Under the assumption that PKINIT is not supported, I provided the -ldap-shell flag in Certipy as shown below.

The ldap-shell is a semi-interactive command shell built into Certipy that executes specific commands directly over LDAP in place of requesting a TGT.  Many escalation methods can be executed in this manner assuming your compromised user has proper permissions.  In my example below, I create a new user and add them to the Domain Admins group.

This is verified by logging into the Domain Controller checking Domain Admins membership.

Other options are available for escalation, such as simply resetting the password for asteve.  However, take caution that certain actions can cause disruptions to your client.  You don’t want to reset the password for a privileged service account and take it offline.  Other, more complex attacks, such as Resource Based Constrained Delegation, can also be performed.

A list of supported ldap-shell commands is provided below.  It should be noted that many of these commands are contingent on the logged in user’s permissions.  More information can be found by executing the help command in ldap-shell:

  • add_computer[computer] [password]
  •  rename_computer [current_name] [new_name] 
  •  add_user [new_user]  
  •  add_user_to_group [user] [group] 
  •  change_password [user] [password] 
  •  clear_rbcd [target] 
  •  disable_account [user]
  •  enable_account [user] 
  •  dump 
  •  search [query] [attributes] 
  •  get_user_groups [user] 
  •  get_group_users [group] 
  •  get_laps_password [computer] 
  •  grant_control [target] [grantee]
  •  set_dontreqpreauth [user] [true/false] 
  •  set_rbcd [target] [grantee] 
  •  start_tls 
  •  write_gpo_dacl [user] [gpoSID] 
  •  whoami 
  •  dirsync 
  •  exit 

Conclusion

Certipy’s ldap-shell provides a great workaround when PKINIT is problematic, and a Kerberos TGT can’t be requested.  Stay tuned for continuations of this series where I will dive into other tooling and methods that utilize the LDAP protocol. 

References: 

https://github.com/ly4k/Certipy

https://www.thehacker.recipes/ad/movement/adcs/certificate-templates#template-allows-san-esc1

About the Author

Ben is a security consultant with a background in IT operations and infrastructure. That experience in the trenches of IT gave Ben the solid foundation needed to pass the OSCP exam with no pen testing experience and jump straight into the field of offensive security consulting. Ben has nearly a decade of experience that has given him a well-rounded skillset and allows him to adapt on the fly with different engagement types. 

Join the Professionally Evil newsletter

Related Resources