par Bhabesh Raj Rai, Security Research
In this month’s patch Tuesday, Microsoft fixed a high severity privilege escalation
Dans le patch Tuesday de ce mois-ci, Microsoft a corrigé une vulnérabilité d’élévation de privilèges de sévérité élevée (CVE-2022-26923) dans les services de domaine AD, avec un score CVSS de 8,8, ce qui est proche du niveau critique. Cette vulnérabilité permet à un utilisateur authentifié à faible privilège d’obtenir un certificat de comptes privilégiés tels que les contrôleurs de domaine auprès des Services de Certificats AD (AD Certificate Services), permettant ainsi une élévation de privilèges.
Un jour après le patch Tuesday, Oliver Lyak, l’expert qui a découvert la vulnérabilité, a publié les détails techniques de cette dernière sur son blog. Il a également mis à jour l’outil certipy pour faciliter une exploitation simple de cette vulnérabilité.
Pour exploiter cette faille, un serveur AD CS (Active Directory Certificate Services) doit être présent dans le domaine. AD CS est la réponse de Microsoft pour l’infrastructure à clé publique (PKI). Les utilisateurs du domaine peuvent demander un certificat au serveur AD CS sur la base d’un modèle de certificat prédéfini. Ce certificat peut être utilisé à diverses fins, notamment l’authentification du client. Ainsi, les utilisateurs peuvent demander un Kerberos TGT en utilisant le certificat comme moyen d’authentification.
AD CS a des modèles de certificats distincts pour les utilisateurs et les ordinateurs et les deux peuvent être utilisés pour l’authentification du client. Dans le cas de l’authentification de l’utilisateur via un certificat, le contrôleur de domaine essaie de mapper l’UPN du certificat concernant un utilisateur alors que, dans le cas de l’authentification de l’ordinateur via un certificat, le contrôleur de domaine essaie de mapper dNSHostName à la place, car les comptes d’ordinateur n’ont pas d’UPN. Le créateur du compte d’ordinateur a le droit de modifier la valeur de la propriété dNSHostName. De plus, contrairement à UPN, dNSHostName n’a pas besoin d’être unique dans un domaine. Mais lorsque nous modifions la valeur dNSHostName, la valeur servicePrincipalName est également mise à jour pour refléter la nouvelle valeur dNSHostName. Ainsi, si nous mettons à jour la propriété dNSHostName d’un compte d’ordinateur pour refléter un contrôleur de domaine, ce dernier essaie de mettre à jour le servicePrincipalName, qui entrerait alors en conflit avec le propre servicePrincipalName du contrôleur de domaine, nous donnant ainsi une violation de contrainte indirecte.
Toutefois, le créateur du compte d’ordinateur est également autorisé à modifier le servicePrincipalName. Les nouvelles valeurs doivent être conformes au dNSHostName. Nous pouvons contourner cette vérification de contrainte si nous supprimons simplement les valeurs servicePrincipalName qui contiennent le dNSHostName. Enfin, le contrôleur de domaine nous permettra de mettre à jour le dNSHostName du compte d’ordinateur nouvellement créé vers l’un des contrôleurs de domaine. Le contrôleur de domaine n’a pas besoin de mettre à jour le servicePrincipalName, puisque nous venons de supprimer les valeurs qui contenaient la valeur dNSHostName.
Maintenant, nous pouvons demander un certificat, pour le compte d’ordinateur nouvellement créé, au serveur AD CS à l’aide du modèle Machine, et le contrôleur de domaine doit intégrer la propriété dNSHostName comme identification. Nous pouvons ensuite nous authentifier à l’aide de ce certificat auprès du contrôleur de domaine pour obtenir le hachage du compte de la machine du contrôleur de domaine. En utilisant ce hachage, nous pouvons directement utiliser l’attaque DCSync pour récupérer tous les hachages du contrôleur de domaine ou obtenir le TGT Kerberos de ce dernier.
La dernière phase de cette chaîne d’attaque ressemble beaucoup à l’attaque par relais Petitpotam où les adversaires ont relayé le hachage, précédemment obtenu, d’une entité vers un serveur AD CS et récupéré au final le certificat de cette dernière. Voyons comment nous pouvons détecter l’exploitation de cette vulnérabilité d’élévation de privilèges avec Logpoint.
Les sources de log nécessaires
- Windows AD
- Windows AD CS
- Zeek
Les administrateurs doivent s’assurer de bien avoir activé les paramètres suivants car ces derniers sont désactivés par défaut :
- La sous-catégorie d’audit des Services de Certificats (Certificate Services).
- La fonction audit «Issue and manage certificate requests” » au niveau du serveur AD CS.
Détecter l’exploitation avec Logpoint
Les analystes doivent rechercher de nouvelles créations de comptes d’ordinateur où la valeur dns_host est définie pour usurper l’un des contrôleurs de domaine. WINDOWS_DC est une liste qui doit contenir tous les FQDN des contrôleurs de domaine opérant dans votre domaine.
1norm_id=WinServer label=Computer label=Account label=Create dns_host IN WINDOWS_DC
Recherche de nouvelles créations de comptes d’ordinateur
Les analystes peuvent également rechercher des valeurs SPN impaires dans les créations de comptes d’ordinateur que les adversaires configurent pour contourner le contrôle de validation dNSHostName comme décrit précédemment.
1norm_id=WinServer label=Computer label=Account label=Create 2
service="HOST/*RestrictedKrbHost/*"
Recherche de manipulations SPN
Ensuite, recherchez une incompatibilité entre les valeurs ‘ordinateur’ et ‘dns_host’ au niveau des événements de création de compte d’ordinateur. Dans la requête ci-dessous, le nom de domaine est knowledgebase.local. Les analystes doivent remplacer cette valeur par leur propre nom de domaine avant d’utiliser cette requête.
1norm_id=WinServer label=Computer label=Account label=Create dns_host=* 2
| process eval("computer_name=rtrim(computer, '$')") 3
| process eval("dns_name=rtrim(dns_host, '.knowledgebase.local')") 4
| process compare(computer_name, dns_name) as result 5
| search result=*
Recherche d’une non-concordance entre les valeurs ‘ordinateur’ et ‘dns_host’ dans les événements de création de compte d’ordinateur
Nous conseillons aux analystes d’examiner les demandes de certificat réussies pour le modèle Machine durant la période entourant la nouvelle création du compte d’ordinateur.
1norm_id=WinServer label=Certificate label=Request label=Approve 2
attributes="CertificateTemplate:Machine"
Recherche de demandes de certificat réussies pour le modèle Machine
Nous pouvons corréler les deux événements en déclenchant une alerte lorsqu’un compte d’ordinateur nouvellement créé, qui usurpe un contrôleur de domaine, réussit à demander un certificat de modèle Machine.
1[ norm_id=WinServer label=Computer label=Account label=Create dns_host IN WINDOWS_DC ] as s1 2
followed by [ norm_id=WinServer label=Certificate label=Request label=Approve attributes="CertificateTemplate:Machine" 3
| norm on requester \<requester_account:'\S+'> ] as s2 4
within 1 hour on s1.computer=s2.requester_account 5
| rename s1.log_ts as account_creation_ts, s1.computer as computer, s1.user as user, s1.service as service, s1.dns_host as dns_host, s2.subject as certificate_subject 6
| chart count() by account_creation_ts, computer, user, service, dns_host, certificate_subject
Corrélation de la création d’un compte d’ordinateur avec une demande de certificat de modèle Machine réussie
Les adversaires peuvent utiliser directement l’attaque DCSync pour récupérer tous les hachages du contrôleur de domaine après avoir obtenu son hachage. Les analystes peuvent utiliser Zeek pour rechercher le trafic de réplication de répertoire provenant de systèmes qui ne sont pas des contrôleurs de domaine. WINDOWS_DC_IPS est une liste qui doit contenir toutes les adresses IP des contrôleurs de domaine opérant dans votre domaine.
1norm_id=Zeek event_category=dce_rpc endpoint=drsuapi 2
operation IN ["DRSGetNCChanges", "DRSReplicaSync"] -source_address IN WINDOWS_DC_IPS
Recherche d’artefacts DCSync dans les événements Zeek
Déployez les correctifs et les mitigations dès que possible
Nous conseillons aux administrateurs de lire les conseils de Microsoft (KB5014754) sur la remédiation complète de cette vulnérabilité. Nous conseillons également vivement à ces derniers de corriger tous les serveurs qui exécutent les Services de Certificats Active Directory (Active Directory Certificate Services) et les contrôleurs de domaine Windows qui assurent l’authentification basée sur les certificats avec la mise à jour du 10 mai 2022. Après la mise à jour du mois de mai, les systèmes seront en mode de compatibilité (Compatibility Mode). Si un certificat peut être fortement ou faiblement mappé concernant un utilisateur, l’authentification se produira comme prévu. Cependant, un avertissement sera loggé sauf si le certificat est plus ancien que l’utilisateur. Si le certificat est plus ancien que l’utilisateur, l’authentification échouera et une erreur sera loggée.
Après l’installation des correctifs, Microsoft a conseillé aux administrateurs de surveiller les avertissements qui pourraient apparaître après un mois ou plus. Si aucun avertissement n’est émis, Microsoft recommande fortement d’activer le Mode Application Complète (Full Enforcement Mode) sur tous les contrôleurs de domaine utilisant l’authentification basée sur les certificats. Microsoft mettra à jour tous les appareils en Mode Application Complète d’ici le 9 mai 2023.
Réponse à l’incident concernant les vrais-positifs
Les administrateurs peuvent suivre les étapes suivantes lors de la détection d’une véritable alerte positive :
- Identifier le compte utilisateur compromis.
- Identifier le contrôleur de domaine et le serveur CA concernés.
- Investiguer les traces d’attaque DCSync.
- Investiguer les créations de nouveaux utilisateurs autour de la période de persistance concernée.
Les clients peuvent exécuter leurs playbooks SOAR pour corriger les comptes d’utilisateur compromis et nettoyer les systèmes affectés.
Isoler le playbook de l’hôte dans Logpoint SOAR
Si les attaquants ont réussi à compromettre le domaine, les administrateurs doivent nettoyer et reconstruire l’intégralité de leur Active Directory à partir de zéro. Il s’agit d’une tâche compliquée et manuelle qui ne peut normalement pas être complètement automatisée. Pour reconstruire AD, les administrateurs peuvent implémenter les étapes de remédiation suivantes :
- Créer de nouveaux identifiants pour tous les comptes.
- Lancer les procédures de réinitialisation du mot de passe du compte KRBTGT.
- Vérifier les modifications apportées à la stratégie de groupe (GPO) et aux scripts d’ouverture de session.
- Mettre en place de nouveaux serveurs associés aux DC et déplacer les rôles FSMO vers ces derniers afin que les anciens DC puissent être mis hors service.
Récemment, de nombreuses vulnérabilités d’élévation de privilèges ont affecté à la fois Windows et Linux. Les acteurs malveillants utilisant des ransomwares sont généralement rapides à les mettre en œuvre pour minimiser le temps de déploiement de ces derniers. Nous conseillons aux défenseurs des entreprises d’identifier si leur environnement AD est vulnérable et d’appliquer les correctifs et mesures de mitigation nécessaires.
Les clients peuvent télécharger l’application Windows à partir du centre d’aide qui offre un contenu utile en matière de détection.
