Unleashing the Potential of Certificates for Privilege Escalation
- April 1, 2024
- Active Directory
- Kunal Kumar
Maintaining proactive defences against emerging cyber threats is of the utmost importance in today’s rapidly changing cybersecurity environment, and one area that has gained more consideration recently is privilege escalation: the practice of gaining higher-level access within systems or networks has received much thought and consideration.
One technique known as CertPotato uses certificates to escalate privileges and gain control over machines. We will explore its inner workings, the role of certificate templates, and how a CertPotato attack chain can elevate privileges up to NT AUTHORITY SYSTEM. Secure your seat belts for an exciting journey into privilege escalation using certificates!
Understanding ADCS: A Key to Privilege Escalation
Exploring Public Key Infrastructure
Before diving into privilege escalation, let’s first become acquainted with Public Key Infrastructure (PKI). PKI is an infrastructure used for creating, managing, and revoking certificates and public/private keys—one such implementation in Windows is Active Directory Certificate Services (ADCS).
Introduced in Windows Server 2000, ADCS seamlessly integrates with various Microsoft services, including TLS certificates, binary signing, user authentication, and file system encryption.
Unveiling the Power of Certificate Templates
To streamline the certificate creation process in Active Directory, certificate templates come into play. These templates allow us to specify various parameters and rights associated with the certificates issued from them.
ADCS allows us to specify various parameters about our certificates, such as their validity period, who has access to enroll, and the Extended Key Usage (EKU), which determines its use. It offers several predefined templates – Machine being one – which can be requested by any machine account that belongs to the Domain Computers domain group.
Setting the Stage: Our Test Environment
To illustrate the CertPotato attack chain, let’s set the stage with a test environment. We have three machines in our setup:
- DC (10.0.2.10): The domain controller where the certificate authority is located.
- CA (10.0.2.100): An application server with the IIS service installed.
- Kali Linux (10.0.2.15): Our trusty hacking machine.
Now, imagine we have successfully uploaded a web shell onto the IIS server. By running the whoami command, we can see that the service account used is iss apppool\test, a Microsoft virtual account.
But what exactly is a service account?
Understanding Service Accounts
- Microsoft defines a service account as an explicit user account designed to provide security context for services running on Windows Server operating systems.
- Each Windows machine comes equipped with several predefined service accounts, such as LocalSystem (NT AUTHORITY SYSTEM), NetworkService (NT AUTHORITYNetwork Service), and LocalService (NT AUTHORITYLocal Service).
- These accounts have different privileges on the machine. Only the LocalSystem and NetworkService accounts use the computer account to authenticate with other machines on the internal network.
- In addition to the built-in service accounts, Windows Server 2008 R2 introduced standalone managed service accounts (sMSA), group-managed service accounts (gMSA), and virtual accounts.
- These accounts facilitate service management, with password complexity and renewal managed by Active Directory.
- Virtual accounts, in particular, are local managed service accounts used by services like IIS, Exchange, and MSSQL.
Exploiting the Situation: CertPotato Attack Chain
With our web shell running as the “iis apppool\test” account, we can leverage the CertPotato attack chain to escalate our privileges and gain control over the machine. While the popular technique of Delegate 2 Thyself by Charlie Clark uses RBCD to elevate privileges, CertPotato presents an alternative approach using ADCS. Let’s explore each step of the CertPotato attack chain.
Enumerating Remote Shares
To kickstart the attack chain, let’s enumerate a remote share from our web shell. Surprisingly, we discover that the default pool account does not attempt to authenticate but the CA$ machine account. This means that when requesting remote information, the operating system falls back to the machine account (CA$) to perform the authentication, which is a valid account within the Active Directory.
responder –I eth0
From the above response, we can see that the authentication to our responder server is not coming from a service account but from a CA$ machine account.
Coming to the scenario, we can abuse the service account using the tgtdeleg trick to obtain a useful TGT to request a certificate as the machine account.
Before that, we have to understand what TGT delegation is. So, Accounts with Service Principal Name (SPN) records, whether machine or otherwise, that have been granted unconstrained delegation rights can impersonate users to authenticate to any service on any host.
This is possible because when a user with these rights attempts to access a service or server, the AP_REQ packet sent contains an Authenticator encrypted with the session key received in the first Ticket Granting Service Response (TGS-REP) along with the Service Ticket.
Among the elements within this authenticator is a delegation Ticket Granting Ticket (TGT) with the key linked to the user seeking access with unconstrained delegation.
Therefore, if one manages to obtain the AP_REQ packet and the key used for encrypting the authenticator, one can retrieve the delegation TGT of the user and its associated session key, enabling one to perform unauthorized actions under the guise of that user.
Uploading Rubeus.exe to the target system and obtaining delegation TGT.
.\Rubeus.exe tgtdeleg /nowrap
After obtaining the TGT, decoded it using base64 and saved it to a new file ticket.kirbi.
Using Impacket’s ticketConverter converted the kirbi file into a ccache file format and exported it into memory to establish the session as CA$ machine account without credentials.
Using Impacket’s ticketConverter converted the kirbi file into a ccache file format and exported it into memory to establish the session as CA$ machine account without credentials.
Retrieving Certificate Authority Information
Expanding our survey, we can also retrieve information about the Certificate Authority (CA). This allows us to gather insights into the CA’s configuration, including the templates it supports and the certificates it has issued.
Requesting a Machine Certificate
Now, let’s use the Certipy tool to request a certificate using our machine account’s Ticket-Granting Ticket (TGT). With the TGT loaded, we can enumerate the available certificate templates and choose the “Machine” template. Alternatively, any certificate template with the EKU “Client Authentication” that our machine account can enroll in would suffice
Using certipy for requesting CA$ machine certificate.
Now, using the CA$ certificate, we can use PKINIT authentication technique to obtain the CA$ account hash.
To escalate our privileges further, we can exploit PKINIT authentication, a feature of Kerberos that supports asymmetric authentication. PKINIT allows us to sign the timestamp during pre-authentication with the private key associated with a valid certificate instead of using a password derivative.
However, PKINIT authentication requires the obtained certificate to have specific Extended Key Usages (EKUs), such as “Client Authentication” or “PKINIT Client Authentication. Read more about PKINIT here.
Leveraging PKINIT authentication and the U2U extension, we can obtain the machine account’s hash. This step marks an essential milestone in our quest for privilege escalation.
After extracting the Machine account hash, we can forge a silver ticket on the cifs service using Impacket’s ticketer, for that we need DomainSID and FQDN of domain.
Using rpcclient and crackmapexec to gather DomainSID and FQDN of domain.
After grabbing the required domain information, we can now forge a silver ticket using Impacket’s ticketer, using a machine hash of CA$.
Upgrading to NT AUTHORITY SYSTEM
After getting the silver ticket as Administrator User on CA machine, exported it into memory and now can use psexec to connect to it as NT Authority SYSTEM privileges on CA machine.
TL;DR
In conclusion, the CertPotato attack chain showcases the power of certificates in privilege escalation. By carefully exploiting ADCS and PKINIT authentication, we can elevate our privileges from a service account to NT AUTHORITYSYSTEM and gain full control over the compromised machine.
While the CertPotato attack chain presents a potent technique, it is crucial to address the vulnerabilities that allow initial access as virtual or network service accounts. Additionally, leveraging gMSA and sMSA accounts for sensitive servers can provide enhanced security. However, Active Directory permissions for these accounts must be correctly set to prevent easy pivoted access on an internal network in case of compromise.
CertPotato emphasizes the need to stay vigilant and proactive in cybersecurity, providing organizations with an effective means of fortifying their defences against potential threats. Understanding certificate-based privilege escalation techniques enables companies to strengthen their defences against malicious actors trying to gain unwarranted entry to critical systems.
Remember, cybersecurity is constantly developing; keeping abreast of developments is paramount to safeguarding digital assets. So, continue exploring, learning, and protecting yours today!
In the realm of privilege escalation, certificates hold the key to unlocking new levels of access. Through the CertPotato attack chain, we can harness the power of ADCS and PKINIT authentication to elevate our privileges and assume control over machines.
By partnering with Redfox Security, you’ll get the best security and technical skills to execute a practical and thorough penetration test. Our offensive security experts have years of experience assisting organizations in protecting their digital assets through Penetration Testing Services. To schedule a call with one of our technical specialists, call 1-800-917-0850 now.
Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. We proudly deliver robust security solutions with data-driven, research-based, and manual testing methodologies.
Join us on our journey of growth and development by signing up for our comprehensive courses.
