Huy Kha | Architecte principal de l'identité et de la sécurité

L'escalade des privilèges dans Active Directory (AD) permet aux cyber-attaquants d'élargir l'accès à l'environnement et de compromettre potentiellement des réseaux entiers - sans être détectés. L'Enterprise CA Security Configuration (ESC1) est une méthode d'attaque qui a gagné en popularité parce qu'elle permet à des acteurs malveillants d'obtenir un accès privilégié par le biais d'un outil qui est en fait conçu pour faciliter la vie des administrateurs : les modèles de certificats.

Qu'est-ce qu'une attaque ESC1 ?

Les modèles de certificats permettent de simplifier l'administration des autorités de certification (AC) des services de certificats Active Directory (AD CS) en fournissant un ensemble préconfiguré de règles et de paramètres qui sont appliqués aux demandes de certificats entrantes. Ils permettent aux administrateurs de rationaliser la gestion des certificats et d'assurer la cohérence de l'application des politiques de certification.

Toutefois, les modèles de certificats peuvent être utilisés à mauvais escient.

Dans une attaque ESC1, un attaquant exploite un modèle de certificat d'autorité de certification d'entreprise mal configuré dans AD CS pour demander un certificat pour un compte à privilèges élevés (par exemple, Admin de domaine). Il utilise ensuite ce certificat pour agir en tant que ce compte, obtenant ainsi un contrôle non autorisé.

Comment fonctionne une attaque ESC1 ?

Pour réaliser une attaque ESC1, un acteur malveillant a besoin qu'AD CS soit en cours d'exécution et qu'il ait l'autorisation de s'inscrire dans un modèle de certificat mal configuré.

L'attaquant recherche une configuration de modèle de certificat vulnérable(figure 1) avec :

  • Le paramètre "Supply in Request" est coché, ce qui permet à l'attaquant de demander un certificat pour n'importe quel compte.
  • Utilisation étendue des clés (EKU) des extensions telles que Client Authentication, PKINIT Client Authentication, Smart Card Logon, Any Purpose-ou pas d'EKU (par exemple SubCA)
Figure 1. Modèle de certificat vulnérable permettant à un pirate d'usurper l'identité de tous les utilisateurs du domaine.

Lorsque ces conditions sont réunies, l'attaquant peut demander un certificat pour n'importe quel compte du domaine(figure 2) et l'utiliser pour se faire passer pour ce compte.

Figure 2. Demande de certificat au nom d'un compte spécifié

Comment se défendre contre une attaque ESC1 ?

Si votre organisation dispose de modèles de certificats autorisant les Subject Alternative Names (SAN) et prenant en charge les Client Authentication EKU, ils pourraient être vulnérables à une attaque ESC1.

Pour vous en prémunir, suivez ces quelques conseils pratiques :

  • Vérifier les modèles de certificats : Passez en revue tous vos modèles de certificats et identifiez ceux qui autorisent les SAN et comportent des extensions EKU telles que :
    • Client Authentication (1.3.6.1.5.5.7.3.2)
    • PKINIT Client Authentication (1.3.6.1.5.2.3.4)
    • Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2)
    • Any Purpose (OID 2.5.29.37.0)
    • Ou des modèles sans EKU (tels que SubCA)
  • Limiter les personnes autorisées à s'inscrire : Veillez à ce que seuls les utilisateurs ou les groupes qui ont réellement besoin d'un accès puissent s'inscrire pour obtenir des certificats avec ces modèles. Le fait de restreindre l'accès permet de minimiser le nombre de personnes qui peuvent exploiter les modèles.
  • Nécessite l'approbation du gestionnaire de l'AC : Pour tous les modèles de certificats qui autorisent le SAN et prennent en charge le Client AuthenticationActivez l'approbation du gestionnaire de certificats de l'autorité de certification. Cela signifie que quelqu'un doit approuver chaque demande avant qu'un certificat ne soit émis.
  • Désactiver les modèles inutilisés : Si certains modèles de certificats ne sont pas utilisés, désactivez-les ou modifiez-les pour supprimer les configurations à risque. Par exemple, désactivez le paramètre Fournir dans la demande pour que les utilisateurs ne puissent pas demander de certificats pour d'autres comptes.

Les défenseurs peuvent utiliser le Purple Knight pour identifier les modèles de certificats non sécurisés et prendre des mesures pour y remédier(figure 3).

Figure 3. Outil Purple Knight montrant les modèles de certificats vulnérables

Les défenseurs peuvent également utiliser Invoke-Locksmith1 (Figure 4) pour identifier rapidement les modèles de certificats non sécurisés et prendre des mesures pour les corriger. Le script PowerShell Locksmith comprend une option de remédiation automatique, mais il est important de tout tester et de tout examiner avant de mettre en œuvre des mesures de remédiation.

L'une des grandes caractéristiques de la Invoke-Locksmith est qu'il comprend également Invoke-RevertLocksmithqui permet à une organisation de revenir facilement sur toute modification si elle constate un impact négatif. Cela offre une sécurité supplémentaire lors de l'ajustement des modèles de certificats.

Figure 4. Remédiation aux modèles de certificats vulnérables avec Invoke-Locksmith

Comment détecter les attaques ESC1

Dans un environnement de grande entreprise, la détection des demandes malveillantes de modèles de certificats vulnérables peut s'avérer difficile. Si les ID d'événement 4886 et 4887 permettent de savoir quel utilisateur a demandé un certificat, ils ne révèlent pas la valeur qu'un attaquant a spécifiée dans l'ID d'événement 4886 et 4887. subjectAltName pour se faire passer pour un compte spécifique.

D'un point de vue médico-légal, toutes les demandes de certificat sont enregistrées (Figure 5) et peuvent être consultés dans l'interface utilisateur de l'autorité de certification sous Issued Certificates. Cette section montre quand une demande de certificat inclut des valeurs telles que celles de la section subjectAltNameainsi que d'autres informations importantes telles que l'auteur de la demande, le modèle de certificat utilisé, l'EKU et les horodatages correspondants. Ces journaux sont utiles pour enquêter sur les demandes de certificat suspectes et en retrouver la trace.

Figure 5. Certificats émis par le serveur de l'autorité de certification

Profils des acteurs de la menace

Les acteurs suivants ont mené des attaques ESC1 dans la nature :

  • UNC53302
  • APT293

Outils ESC1

Les outils publics d'abus de certificats Active Directory suivants peuvent être utilisés pour effectuer une attaque ESC1 :

  • Certifier
  • Certipy

Aperçu des menaces

Tactique ATT&CK : escalade des privilèges

Le 4 avril 2024, Google Cloud a publié un rapport décrivant comment l'acteur de la menace UNC5330 a exploité les vulnérabilités CVE-2024-21893 et CVE-2024-21887 dans Ivanti Connect Secure pour infiltrer le réseau d'une victime. Il a utilisé un compte de liaison LDAP pour exploiter un modèle de certificat Windows vulnérable, en créant un objet informatique et en se faisant passer pour un administrateur de domaine.4

Le 28 avril 2022, Mandiant a signalé qu'APT29 a exploité des modèles de certificats mal configurés pour se faire passer pour des utilisateurs administrateurs. En abusant de ces mauvaises configurations dans AD CS, l'attaquant a pu demander des certificats en tant qu'utilisateurs à faibles privilèges et spécifier des comptes à hauts privilèges dans le champ Subject Alternative Name (SAN). Cela lui a permis de s'authentifier en tant que ces utilisateurs à haut privilège.5

Aperçu de Semperis

AD CS doit être traité comme un actif de niveau 0, car il contrôle directement la sécurité de l'ensemble de votre environnement Active Directory. La compromission d'AD CS pourrait permettre à des attaquants d'émettre des certificats leur permettant d'usurper l'identité de comptes à privilèges élevés, de contourner les contrôles de sécurité et d'obtenir un accès complet à des systèmes sensibles.

En savoir plus sur l'escalade des privilèges dans AD

Notes de fin d'ouvrage

  1. https://github.com/jakehildreth/Locksmith/tree/main
  2. https://malpedia.caad.fkie.fraunhofer.de/actor/unc5330
  3. https://malpedia.caad.fkie.fraunhofer.de/actor/apt29
  4. https://cloud.google.com/blog/topics/threat-intelligence/ivanti-post-exploitation-lateral-movement
  5. https://cloud.google.com/blog/topics/threat-intelligence/tracking-apt29-phishing-campaigns