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
Before diving into privilege escalation, let’s first become acquainted with Public Key Infrastructure (PKI).Moreover, 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 iis 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 as service account, it is coming as CA$ machine account.
Coming to the scenario, we can abuse service account using 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. Accounts with SPN records, granted unconstrained delegation, can impersonate users across services. AP_REQ packets contain an authenticator encrypted with the received session key, including the delegation TGT. Obtaining the AP_REQ packet and its encryption key allows retrieval of the delegation TGT, enabling unauthorized actions as the user.
Uploaded Rubeus.exe to target system, and obtain delegation TGT.
.\Rubeus.exe tgtdeleg /nowrap
After obtaining the TGT decoded it using base64 and save it to a new file ticket.kirbi.
Using Impacket’s ticketConverter converted kirbi file into ccache file format and exported it into memory to establish session as CA$ machine account without credentials.
Retrieving Certificate Authority Information
Expanding our survey, we can also retrieve Certificate Authority (CA) information. 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 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 enables timestamp signing with a valid certificate’s private key, bypassing password derivatives. However, specific Extended Key Usages (EKUs) like “Client Authentication” are necessary for PKINIT authentication. Read more about PKINIT in the link provided below. https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab
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 silver ticket using Impacket’s ticketer using 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 using ADCS and PKINIT authentication, we elevate privileges to NT AUTHORITY\SYSTEM, gaining full control of 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. Correct Active Directory permissions are crucial to prevent easy pivoted access on an internal network in case of compromise.
CertPotato stresses proactive cybersecurity, fortifying defenses against threats. Understanding certificate-based privilege escalation strengthens defenses against unauthorized access attempts.
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. Via CertPotato, we use ADCS and PKINIT to elevate privileges and assume machine control.
Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. If you are looking to improve your organization’s security posture, contact us today to discuss your security testing needs. Our team of security professionals can help you identify vulnerabilities and weaknesses in your systems and provide recommendations to remediate them.
“Join us on our journey of growth and development by signing up for our comprehensive courses.”
