Depuis la sortie d’un article de recherche par SpecterOps en 2021 sur des problèmes de configuration de l’environnement AD CS, de nombreuses informations sont publiées sur les méthodes d’exploitation possibles : outils pour y parvenir, rapports d’investigations évoquant ces problèmes durant un incident... Cependant une différence de connaissance et de documentation se creuse aujourd’hui entre le monde des pentesters et celui des analystes qui leur permet d’aller compromettre un domaine en quelques minutes sans lever d’alertes.
Cet article a pour objectif d’informer les acteurs et analystes des méthodes de détection, principalement post-mortem, d’exploitations de mauvaise configuration en mettant en lumière les sources de logs existantes et ce qu’il est possible d’en obtenir.
Durant un incident, les logs sont l’élément essentiel à un analyste pour retracer le déroulé de l’attaque, du point d’entrée jusqu’aux actions menées dans le système d’information par l’attaquant.
Dans un environnement composé d’une PKI Windows, aussi appelé « l’ADCS », il en existe quelques-uns qui vont permettre à l’analyste de comprendre si l’AD CS a joué un rôle contre son gré durant l’incident.
La PKI étant une brique conséquente dans un système d’information, il est tout à fait possible de retrouver des faiblesses tant au niveau mise à jour de l’infrastructure, qui peut faire peur notamment sur le sujet de la disponibilité qu’au niveau sensibilisation des administrateurs qui peuvent, lors de la mise en place du service, avoir mal configuré certains paramètres qui sont maintenant utilisés en production depuis plusieurs années...
Comment savoir si l’attaquant a pu abuser d’un AD CS et qu’a-t-il fait avec ?
Heureusement les logs sont là, et sont encore plus nombreux s’ils sont activés !
ADCS ? Rappel des informations utiles
Active Directory Certificate Service
Pour suivre pleinement cet article et découvrir comment détecter des attaques sur l’ADCS, nous allons
commencer par rappeler l’intérêt d’un Active Directory Certificate Service dans une infrastructure.
Active Directory Certificate Service (« ADCS ») est un service de l’Active Directory (« AD ») qui vous permet de construire une infrastructure à clé publique. Avec une autorité de certification (Certification Authority, « CA »), vous pourrez gérer vos certificats numériques, de l'émission d'un certificat à sa révocation. Cette couche de sécurité offre les avantages suivants : intégrité, authentification, non-répudiation et confidentialité. Cela est possible grâce à l'utilisation de certificats et de clés, c'est pourquoi on parle souvent de « PKI » : Public Key Infrastructure (infrastructure à clé publique).
Ici, nous allons utiliser une infrastructure composée :
- D’un serveur Windows avec le rôle d’AD
- D’un serveur Windows avec le rôle Certificate Service
- De postes de travail clients, sous la dernière version de Windows
Par la suite, les clients vont faire des demandes à l’autorité de certification pour obtenir des certificats qu’ils pourront ensuite utiliser
Certificat et modèle
Le principe de certificat est au cœur du fonctionnement de l’ADCS. Un certificat numérique est un fichier signé par une autorité de certification qui contient à l’intérieur plusieurs champs permettant d’indiquer des informations comme le propriétaire du certificat, la période de validité, la clé publique… et un champ Extension qui va permettre d’attribuer des fonctionnalités au certificat. Cela passe par l’ajout de champs additionnels comme l’Extended Key Usage qui va permettre de définir ce qu’il est possible de faire avec le certificat.
On retrouve par exemple la fonctionnalité d’authentification (« Client authentication »), la signature d’exécutable (« Code signing »), le chiffrement de fichiers (« Encrypting file system »).
Afin de normaliser l’utilisation de certificats dans une infrastructure, un certificat peut être créé uniquement à partir d’un modèle de certificats qui va contenir certains champs préconfigurés par l’administrateur.
Nous pouvons par exemple créer un modèle « ConnexionPC » qui va posséder l’extension « Client authentication ». L’utilisateur qui souhaitera avoir un certificat pour se connecter devra obligatoirement demander un certificat à partir de ce modèle.
Les artefacts
Nous allons voir l’ensemble des artefacts utiles pour une investigation sur un environnement ADCS de façon à pouvoir s’y référer rapidement pour la collecte et l’analyse. Ils correspondent à un mélange artefact Windows : ruches, registres... et artefacts spécifiques au service principalement la base de données de l’autorité.
Nous retrouvons 2 sources principales contenant ces artefacts :
- Le serveur Windows où est installé le service ADCS
- Le serveur Windows Active Directory
La base de données de l’autorité de certification
La base de données de la CA est l’artefact le plus riche pour identifier des actions malveillantes lors de la génération de certificats. Il s’agit d’une base au format EDB (Extensible Storage Engine (ESE) database files (EDB)), format développé par Microsoft et utilisé dans plusieurs applications notamment Exchange Server et Active Directory.
Il est possible de l’ouvrir avec différents outils, par exemple ESEDatabaseView (NirSoft) [4] avec une interface graphique ou bien en ligne de commande avec un module de Dissect dédié, esedb [5].
A l’intérieur, plusieurs tables sont disponibles dont :
- Certificates : la table contient des informations à propos des certificats qui ont été générés. Les ID, templates utilisés, CSP et clé publiques sont disponibles ici.
- Requests : la table contient toutes les demandes de certificats incluant les échecs. On accède à l’ID, au type, aux valeurs du requestername, callername, distinguishedName…
- RequestAttributes : il s’agit d’une table contenant les attributs spécifiques utilisés lors des demandes de certificats. On retrouve dans cette table la Subject Alternative Name (SAN), CSPProvider, Cert Client Machine (ccm), Client DC name (cdc), Request Machine DNS name (rmd).
Attention, certaines valeurs sont stockées avec l’identifiant associé (1111-2222-3333), il faut donc potentiellement connaitre la correspondance pour réussir à faire le lien. Je pense par exemple aux extensions qui sont affichés avec leurs identifiants d’objets (OIDs) plus compliqué qu’un mot lisible comme « Client authentication ».
A noter qu’à partir de la table RequestAttributes, il est possible de pivoter sur la machine à l’origine de la demande de certificat grâce au champ ccm.
---
Localisation :C:\Windows\System32\CertLog\nom-CA.edb
Type : Base de données EDB
Outils : ESEDatabaseView, Dissect
---
La liste de révocation de certificats de l’autorité (CRL)
Dans le cas où un certificat est révoqué, il est ajouté à la liste de révocation (CRL) qui est publié et accessible à tous. Cette liste contient des éléments notamment le numéro de série du certificat, la date derévocation et la raison.
Il peut être intéressant de la consulter pour identifier des certificats créés temporairement qui ont été révoqués par un attaquant aprèsutilisation.
En fonction de l’environnement utilisé pour analyser le fichier, il est possible d’utiliser Certutil :
ou bien Openssl sous un environnement Linux :
---
Localisation :C:\Windows\system32\certsrv\certenroll\ma-CA.crl
Type : Liste de certificats
Outils : OpenSSL, Certutil
---
Le registre Windows
Certaines informations liées à l’ADCS sont stockées dans les registres Windows. On distingue ici deux ruches différentes avec des objets distincts :
- La ruche SYSTEM
Certains paramètres de configuration sont stockés dedans. On retrouve par exemple une entrée « Configuration » contenant les informations liées au nom de l’autorité, le nom de la machine, le chemin du dossier de logs... L’entrée associée au nom de la CA contient des informations plus applicatives. Par exemple, l’adresse du chemin de la CRL, le niveau de logs, les méthodes de signatures, des modèles de messages et autres paramètres.
- La ruche SOFTWARE
Une entrée « CertificateTemplateCache » est utilisée pour stocker un cache des objets modèles de certificats créés par l’ADCS. On retrouve dedans une sous-entrée par modèle contenant l’ensemble des paramètres de celui-ci. Par exemple son nom, l’algorithme utilisé, les utilisateurs cibles, les extensions critiques, la durée de validité...
---
Localisation : C\Windows\System32\config\
Entrée 1 :Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc
Entrée 2 :Computer\HKEY_USERS\.DEFAULT\Software\Microsoft\Cryptography\CertificateTemplateCache
Type : Ruche Windows
Outils : RegRipper [6], RegistryExplorer [7], regipy (Python) [8]
---
Les évènements Windows
Malheureusement, les évènements de l’autorité de certification ne sont pas activés par défaut sur le serveur Windows. Il est nécessaire d’aller les activer manuellement à deux endroits :
- Audit de logs de l’autorité
Dans la partie « Auditing » des propriétés de laCA, différents types d’évènements peuvent être activés :
- Accès aux objets de Certificate Service
Les accès aux objets liés à l’ADCS peuvent être audités pour les succès et les échecs. Pour cela il suffit de se rendre dans la partie de politique de sécurité (au niveau local ou global), onglet “AdvancedAudit Policy Configuration” :
C’est d’ailleurs l’occasion de regarder si d’autres categories de logs peuvent être actives pour d’autres applications ou fonctionnalités !
Après l’activation de ces logs, on peut constater l’apparition des premiers évènements Windows au sein de la visionneuse d’évènements pour le fichier SECURITY.evtx
Il existe plusieurs identifiants d’évènements recensés dans la documentation Microsoft [3] pour la sécurité de la PKI
( https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786423(v=ws.11) )
Les plus utiles en termes de criticité sont les suivants :
- 4882 : The security permissions for Certificate Services changed
- 4885 : The audit filter for Certificate Services changed
- 4886 : Certificate Services received a certificate request
o Can lead to a large number of false positives - 4887 : Certificate Services approved a certificate request and issued a certificate
- 4888 : CertificateServices denied a certificate request.
- 4890 : The certificate manager settings for Certificate Services changed
- 4891 : A configuration entry changed in Certificate Services
- 4892 : A property of Certificate Services changed
- 4896 : One or more rows have been deleted from the certificate database
- 4897 : Role separation enabled
- 4898 : Certificate Services loaded a template
- 4899 : A Certificate Services template was updated
- 4900:Certificate Services template security was updated
Nous verrons au cours de cet article qu’une détection en temps réel peut potentiellement être réalisé sur au moins une exploitation demauvaise configuration.
---
Localisation :C\Windows\System32\winevt\Logs\Security.evtx
Type : Journal d’évènements Windows
Outils : Observateur d’évènements Windows,EvtxECmd [7], Plaso [8]
---
La base de données de l’ActiveDirectory : NTDS.dit
NTDS.dit est la base de données de l’Active Directory et contient toutes les informations relatives au service et à son fonctionnement.Les modèles de certificats sont des objets AD et sont alors disponibles danscette base.
Dans l’application ADSI Edit, on peut retrouver la liste des modèles et les propriétés associés dans l’onglet « CertificateTemplates ».
La consultation d’un modèle permet d’obtenir les propriétés de celui-ci :
---
Localisation : C:\Windows\NTDS
Chemin : Services\Public KeyServices\Certificate Templates
Type : Base de données
Outils : ADSI Edit, Dissect, Python [10]
---
Comment investiguer ?
Maintenant que nous avons vu les différents types d’artefacts basiques à disposition, nous allons nous placer dans un contexte d’incident de sécurité où une exploitation de la fonctionnalité ADCS est suspectée d’avoir été utilisée.
Pour cela, nous avons activé l’audit des évènements liés à l’ADCS comme montrant ci-dessus. Aucun outil de surveillance supplémentaire n’est utilisé (syslog, …) afin de reproduire un environnement peu journalisé (mais avec un minimum quand même !).
Nous ne détaillerons pas la partie exploitation, pour cela il faut se référer à l’article dans le MISC précédent consacré aux tests offensifs, uniquement des éléments de compréhension nécessaire permettant de détecter une exploitation.
CVE-2022-26923
La vulnérabilité la plus récente affectant les fonctionnalités de l’ADCS remonte au premier semestre 2022 avec laCVE-2022-26923 [11], au score CVSS de 8.8.
Le principe de cette vulnérabilité est d’usurper l’identité d’un compte à privilège lors de la requête. Pour cela, l’attaquant va utiliser un compte d’ordinateur. Il va remplacer la valeur « dNSHostName » parcelle du compte à privilège pour réaliser la demande de certificat.
Lorsqu’il va ensuite utiliser le certificat, il devra changer à nouveau la valeur du « dNSHostName » par l’original car sinon un conflit sera provoqué : il y aura deux identités au lieu d’une.
Plusieurs événements Windows existent pour chaque étape suspecte de l’exploitation [12] mais… doivent être activés pour pouvoir les retrouver :
- Modification d’objet Active Directory
o Suppression du champ« dNSHostName » : eventID 5136
- Gestion des comptes d’ordinateur
o Création d’un compte d’ordinateur : eventID4741
o Modification du champ « SPN » du compte d’ordinateur : eventID 4742
On peut s’intéresser cependant aux générations de certificats avec un dNSHostName modifiés. En effet, lors de la demande nous avons accès à ces deux éléments :
- Le nom du compte qui réalisé la demande de certificat
- La valeur du dNSHostName
Le nom du compte correspond au champ « requester »et le champ dNSHostName correspond en fait au champ « Subject »,après les caractère « CN= ».
Il faut donc identifier une incohérence entre ces deux valeurs permettant de détecter une usurpation.
Ces informations étant stockées dans la base de données de la CA, il est possible dans un contexte d’analyse post mortem de récupérer cet artefact et d’analyser les valeurs des champs.
ESC1
ESC1 est à la première mauvaise configuration détaillée parles équipes de SpecterOps [1]. Son concept repose principalement sur l’activation du paramètre« CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT » dans un modèle de certificat.Cela signifie que lors de la demande d’un certificat à l’autorité, il est possible d’ajouter un autre nom d’utilisateur dans le champ « SubjectAlternative Name » (SAN). L’attaquant va donc pouvoir ajouter un nom d’utilisateur à haut privilège, comme l’administrateur du domaine.
On retrouve alors une incohérence entre la valeur du demandeur du certificat (réalisé par le compte utilisateur compromis) et la valeur renseignée dans le champ SAN.
Lors d’une demande de certificat, envoyé par la machine compromise au service ADCS, un évènément Windows 4886 est généré : Le service CS a reçu une demande de certificat.
Cet évènement, pratique car accessible en temps réel, ne permet cependant pas de détecter une usurpation car seul l’information du demandeur du certificat, le « requester », est disponible. Il n’est alors pas possible de le comparer à un potentiel champ SAN différent.
Une fois le certificat généré, un évènement Windows 4887 est généré : la demande est approuvée et le certificat est distribué.
Encore une fois, l’information sur le champ SAN n’est pas enregistrée dans l’évènement et ne permet pas la détection en temps réel.
La demande de certificate peut tout de même nous apprendre la SAN mais à partir de la base de données de l’autorité. Cette fois, on se place dans un contexte post-mortem où il est possible d’accéder à l’artefact de la base de données pour une investigation.
La base au format EDB va contenir deux tables intéressantes :
- Requests : contient les informations de la demande avec les informations “génériques”
- Request Attribues : contient les attributs spécifiques au modèle qu’il est possible de renseigner.
Dans le cadre de l’exploitation d’ESC1, nous pouvons retrouver come attribute le champ “SAN” :
Dans le cas de la demande de certificate #14, on retrouve une Valeur du SAN avec le nom utilisateur “Administrator”. Il suffit alors de comparer cette Valeur à la Valeur du requester dans la table“requests”.
Pour aller plus vite, on peut développer un script qui va s’occuper d’ouvrir la base et parser toutes les demandes pour détecter un pattern incohérent :
L’artefact utilisé ici étant la base de données, il est bien sur possible d’accéder à la même information de façon graphique si vous avez un accès au serveur, via l’outil certsrv pour l’administration des modèles et des certificats. Un simple clic droit sur un demande permet d’accéder aux détails :
ESC3
Au tour d’ESC3 d’être investiguée pour comprendre où récupérer des preuves d’exploitation.
Cette exploitation repose cette fois sur 2 modèles de certificats vulnérables. La récupération d’un premier certificat via un modèle permet d’utiliser celui-ci pour l’obtention d’un second certificat à travers le second modèle. Le principe du modèle est de permettre d’enrôler un certificat au nom d’un autre utilisateur.
Le contexte le plus courant est celui d’une opération réalisée par un support informatique : un utilisateur possédant un badge demande de l’aide au support concernant celui-ci. Le support va alors faire une demande de certificat mais au nom de l’utilisateur.
Après avoir identifié une combinaison de deux modèles vulnérables, on peut partir à la chasse à l’exploitation.
Première étape, consulter les évènements Windows générés autour de la date d’une possible exploitation.
Lors de la demande d’un certificat malveillant qui usurperait l’identité d’un autre utilisateur en demandant un certificat à son nom, on retrouve encore une fois les 2 évènements Windows : 4886 et 4887.
Le premier évènement ne nous apporte pas d’informations comme pour la détection d’ESC1. Par contre, la réception et distribution d’un certificat via l’évènement 4887 nous indique entre autres :
- Le requester
- Le subject
Lorsque l’attaquant fait une demande au nom d’un autre utilisateur que le compte victime déjà en sa possession, au hasard un compte administrateur, le nom usurpé est disponible dans le champ... subject.Bingo !
On voit dans l’image qu’on a bien une différence lors de l’approbation du certificat par la CA entre le champ « requester » et le « subject » avec le nom « Administrator » qui tente d’être usurpé.
Super, on peut détecter ça en temps réel, mais si jamais les logs ne sont pas activés ou qu’ils ne sont pas centralisés, comment peut-on faire ?
Notre base de données préférées « nom-CA.edb »nous sauve encore !
On retrouve la demande de certificats dans la table« Requests » et la ligne associée à la demande contient les mêmes éléments utiles que dans l’évènement 4887 :
On constate alors une incohérence entre ces deux valeurs qui laisse apparaitre l’usurpation d’identité (ou un faux positif si action légitime par l’IT ?). L’ouverture de la base via ESEDatabaseViewer semble inverser les deux valeurs mais ce n’est pas un problème ici.
Attention si l’on regarde le certificat généré, il sera au nom de l’utilisateur cible, “Administrator” dans notre cas et aucune trace de l’utilisateur à l’origine de la demande.
ESC4
Partons maintenant sur la détection de la mauvaise configuration de modèle numéro 4 : ESC4.
A la différence des deux autres présentées, ESC4 repose sur le simple fait que… le modèle de certificat est modifiable par l’attaquant. Pas de prérequis de paramètres à activer ou configurer sur une certaine valeur...non, c’est simplement le droit de modification qui a été activé pour n’importe quel utilisateur sans privilège.
L’objectif de l’attaquant ici va être une fois un modèle vulnérable identifié, le modifier de façon à lui ajouter des droits pourl’exploiter, par exemple le rendre vulnérable à ESC1.
Comme nous l’avons vu, un modèle est un objet ActiveDirectory. Il est possible de détecter une modification de l’objet au travers d’évènements Windows de détection de manipulation sur les objets, mais ils ne sont pas activés par défaut et ne concernent pas directement notre service de certificats.
On peut cependant s’appuyer sur un évènement spécifique à la modification de modèle, le 4899.
A l’intérieur, on retrouve deux champs importants :
- “Old template content” : l’ancien contenu du modèle vulnérable
- “New Template Content” : le nouveau contenu
Il est alors possible de voir la différence pour comprendre ce que l’attaquant a modifié. Attention cependant, le modèle a pu être modifié plusieurs fois et donc il est important de retracer l’ensemble des changements pour être sûr de ne rien rater.
Une des difficultés dans l’investigation de l’ESC4 est de retrouver le modèle qui a servi à l’exploitation, c’est-à-dire celui qui était modifiable au début. Heureusement, l’Active Directory peut quand même nous aider ! Si l’on regarde dans la base de données NTDIS, on retrouve l’objet du modèle avec tous ses paramètres et. Ses métadonnées. Celle qui va nous intéresser va être la date de dernière modification de l’objet, qui peut donner une information sur la date de manipulation du modèle :
Dans l’exemple de l’image, on observe une modification de l’objet à 09:24 à la suite d’un essai d’exploitation ESC4.
Il est ainsi possible, avec la nouvelle information temporelle, d’affiner les recherches sur les demandes et distribution de certificats suspects.
Conclusion
Nous avons vu les principales sources d’informations utiles à investiguer pour détecter une compromission via des modèles de certificats mal configurés et vous pouvez maintenant les ajouter ou vérifier qu’ils sont présents dans vos outils de prélèvements d’artefacts de façon à couvrir ce périmètre !
Références
[1] Recherches SpecterOps : https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
[2] Outil Certipy : https://github.com/ly4k/Certipy
[3] Documentation des évènements WindowsADCS : https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786423(v=ws.11)
[4] Outil ESEDatabaseViewer : https://www.nirsoft.net/utils/ese_database_view.html
[5] Outil Dissect : https://docs.dissect.tools/en/latest/projects/dissect.esedb/
[6] Outil RegRipper : https://github.com/keydet89/RegRipper3.0
[7] Outils d’Eric Zimmerman : Doc https://ericzimmerman.github.io/#!index.md
[8] Librairie RegiPy : https://pypi.org/project/regipy/
[9] Outil Plaso : Doc https://github.com/log2timeline/plaso
[10] Manipuler la base NTDS en Python : https://www.xmco.fr/active-directory/on-depile-le-ntds/
[11] CVE-2022-26923 : https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26923
[12] Exploitation de la CVE-2022-26923: https://www.hackthebox.com/blog/cve-2022-26923-certifried-explained
