Certificate authority


In their research papers, Will Schroeder and Lee Christensen identified 2 domain persistence techniques relying on the role of the Certificate Authority within a PKI.

  • Forging certificates with a stolen CA certificates (DPERSIST1)

  • Trusting rogue CA certificates (DPERSIST2)


Stolen CA

The Enterprise CA has a certificate and associated private key that exist on the CA server itself. (Certified_Pre-Owned.pdf)

If an attacker obtains control over a CA server, he may be able to retrieve the private key associated with the CA cert, and use that private key to generate and sign client certificates. This means he could forge (and sign) certificate to authenticate as a powerful user for example.

Extracting the DPAPI-protected CA cert private key can be done remotely from UNIX-like systems with Certipy (Python).

certipy ca -backup -ca "CA" -username "USER@domain.local" -password "PASSWORD" -dc-ip "DC-IP"

Then, forging (and signing) a certificate can be done as follows.

certipy forge -ca-pfx "CA.pfx" -upn "administrator@corp.local" -subject "CN=Administrator,CN=Users,DC=CORP,DC=LOCAL"

The certificate can then be used with Pass the Certificate.

Rogue CA

it is usually preferable for an attacker to steal the existing CA certificate instead of installing an additional rogue CA certificate (Certified_Pre-Owned.pdf)

An attacker with sufficient privileges in the domain can setup a rogue CA and make the domain's resources trust it. Once the rogue CA is trusted, the attacker can forge and sign client certificates.

In order to register the rogue CA, the self-signed CA cert must be added to the NTAuthCertificates object's cacertificate attribute, and in the RootCA directory services store.

Registering the rogue CA can be done remotely with the certutil.exe utility from Windows systems.

certutil.exe -dspublish -f "C:\Temp\CERT.crt" NTAuthCA

Once this is done, a certificate can be forged, signed and used as explained above: Stolen CA


Last updated