Golden Certificate Attack


If you compromised the ADCS server, you can compromise the whole domain. This is also a nice technique to forge certificate undercover since it doesn’t perform any request. The forge is done offline, a nice alternative to DCSYNC.


An ADCS server is a server that runs the Active Directory Certificate Services (ADCS) role. ADCS is a service provided by Microsoft Windows Server that allows administrators to manage and distribute digital certificates in a network. These certificates can be used for a variety of purposes, such as encrypting communications, authenticating users and devices, and enabling secure access to network resources.

An ADCS server is a critical asset because it plays a key role in ensuring the security of a network. Digital certificates are an essential part of modern network security, and an ADCS server is responsible for managing and distributing these certificates. This means that if an ADCS server were to be compromised or become unavailable, it could have serious consequences for the security of the network and the sensitive information it protects. For this reason, it is important to properly manage and protect an ADCS server to ensure its availability and security.

An ADCS server has to be treated like a tier 0 system. Thus, it need to be protected enough to avoid attacker compromising it.

From the Ghostpack/CertForge readme:

The security of the CA's private key is paramount. As mentioned, if the private key is not protected by a hardware solution like a TPM or a HSM, the key will be encrypted with the Data Protection API (DPAPI) and stored on disk on the CA server. If an attacker is able to compromise a CA server, they can extract the private key for any CA certificate not protected by hardware by using @gentilkiwi's Mimikatz or GhostPack's SharpDPAPI project. THEFT3 in the whitepaper describes this process for machine certificates.

Because the only key material used to sign issued certificates is the CA's private key, if an attacker steals such a key (for a certificate in NTAuthCertificates) they can forge certificates capable of domain authentication. These forged certificates can be for any principal in the domain (though the account needs to be "active" for authentication to be possible, so accounts like krbtgt will not work) and the certificates will be valid for as long as the CA certificate is valid (usually 5 years by default but can be set to be longer).

Also, as these certificates are not a product of the normal issuance process, the CA is not aware that they were created. Thus, the certificates cannot be revoked.


There is a scenario possible where if you have local administrator right on a ADCS server, you can escalate to domain admins or impersonate any users/machines in the domain. The only prerequisite is that you are allowed to export the Certificate Authority with the private key as shown below:

It can be exported either:

  • manually with the Windows Certsrv utility

  • Using Certipy backup command

Get the Backup CA

1- With the GUI

2- From command line using Certipy

Once the backup CA is obtained, it is possible to forge a certificate for anyone offline. It is also important to note that the certificate can’t be revoked. This technique is called Golden Certificate.

The certificate can be forged either with Certipy or ForgeCert. Here we will use ForgeCert to forge the certificate. It is important to note that you might need the CRL as it is described on the ForgeCert readme:

Note: the private key for ANY CA certificate in NTAuthCertificates (root or subordinate CA) can be used to forge certificates capable of authentication in the forest. If the certificate/key is from a subordinate CA, a legitimate CRL for verification of the certificate chain must be supplied.

You can skip to the ticket forging directly, sometimes the CRL is not required. But, if you have an error, you might need the CRL.

Obtain the CRL (not always required)

An easy way to get the CRL is to import the Backup CA that was just exported. To do that, just double click the .pfx on Windows and follow the wizard step and it will import the cert. Then, start certmgr.msc and go under Personal→Certificates as shown:

Double click on the Certificate that you just imported and go in the Details tab. Finally, scroll down and click on CRL Distribution Points.

In the second box below, scroll down and copy the section that start with ldap:// (take the url encoded version without the parenthesis).

It should look something like that:


Forge the Certificate

Next, we are ready to forge the certificate. Compile ForgeCert and run the following command. The command is ran offline.

This part is all offline. No need to proxy traffic or run in a beacon.

If you set a password to the new certificate, you will have to convert it without a password using Certipy since Certipy doesn’t support passing certificate with password. You can use the command cert to perform action on the cert and remove the password.

Without the CRL:

ForgeCert.exe --CaCertPath {pfx}.pfx --CaCertPassword "{optional}" --Subject "CN={user}" --SubjectAltName "{user}@{fqdn}" --NewCertPath {newcertname}.pfx --NewCertPassword "{optional}"

With the CRL:

ForgeCert.exe --CaCertPath {pfx}.pfx --CaCertPassword "{optional}" --Subject "CN={user}" --SubjectAltName "{user}@{fqdn}" --NewCertPath {newcertname}.pfx --NewCertPassword "{optional}" --CRL "ldap://{CRL}"

The next step is to authenticate with the forged certificate.

Authentication (Request NT Hash)

The last step is to auth against the domain controller and to obtain the NT hash. We will use Certipy with the following command:

certipy auth -pfx {newcert}.pfx -username {user} -domain {fqdn} -dc-ip {ip}

If everything is aligned, you should get the NT hash of the user that you generated the certificate as show below.

Last updated