Certificate authority
Last updated
Was this helpful?
Last updated
Was this helpful?
In , and 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)
The Enterprise CA has a certificate and associated private key that exist on the CA server itself. ()
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.
is a tools that extract the DPAPI-protected CA cert private key to forge a certificate offline for each user. It then performs attacks for each user to recover the NT and LM hashes.
Extracting the DPAPI-protected CA cert private key can be done remotely from UNIX-like systems with (Python).
Then, forging (and signing) a certificate can be done as follows.
The certificate can then be used with .
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 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.
Once this is done, a certificate can be forged, signed and used as explained above: Stolen CA
it is usually preferable for an attacker to steal the existing CA certificate instead of installing an additional rogue CA certificate ()