Le dilemme de l'intrus est l'envers du dilemme du défenseur, qui explique les défis de la défense de la cybersécurité. Si la défense de l'Active Directory (AD) contre toutes les techniques d'attaque possibles est un défi pour les défenseurs, les attaquants ont un problème différent : une fois qu'ils sont entrés, ils doivent éviter de se faire prendre.
Les attaquants peuvent n'avoir besoin que d'une seule faiblesse pour obtenir l'accès, mais il est beaucoup plus difficile de rester indétecté. Ils doivent maintenir leur accès, se déplacer latéralement, élever leurs privilèges et atteindre leurs objectifs sans déclencher d'alarmes ni se faire enfermer.
Et si nous pouvions tourner le dilemme de cet intrus à notre avantage ?
Comment transformer une attaque en une défense AD pratique
Comprendre comment les mauvais acteurs recherchent et utilisent les vulnérabilités est essentiel pour la défense de l'AD. Pour illustrer la valeur de ces connaissances, nous allons nous pencher sur une méthode courante d'attaque de l'identité qui exploite les mauvaises configurations des certificats.
Les attaques contre les services de certificats Active Directory (AD CS) ont fait l'objet d'une attention particulière après la publication par SpecterOps d'une recherche sur la façon dont les configurations erronées dans AD CS peuvent être exploitées pour l'escalade des privilèges et la persistance. Son rapport Certified Pre-Owned1 décrit plusieurs techniques, notamment ESC1, ESC4 et Golden Certificates, qui permettent aux attaquants d'abuser de l'authentification basée sur les certificats pour compromettre des comptes privilégiés. Depuis la publication de cette étude, les acteurs de la menace et les "red teams" ont de plus en plus utilisé cestechniques2, faisant d'AD CS une cible de grande valeur.
C'est là que les défenseurs peuvent renverser la situation. Lorsque vous mettez en place un pot de miel - comme un modèle de certificat leurre qui semble vulnérable - les attaquants sont obligés de faire un choix. Ils peuvent soit tenter d'exploiter ce qui ressemble à une mauvaise configuration, risquant ainsi de s'exposer, soit l'ignorer et chercher un autre moyen d'escalader les privilèges.
Imaginons qu'un attaquant recherchant des modèles de certificats mal configurés en trouve un pour lequel il dispose de droits de modification. Il peut tenter d'activer la fonction Supply in Request ce qui leur permettrait de spécifier une identité privilégiée dans une demande de certificat.
Le piège est tendu.
AVERTISSEMENT : Le fait de déployer un modèle d'autorité de certification leurre et de le rendre intentionnellement vulnérable à des attaques telles que ESC1 et ESC4 élargit la surface d'attaque. Cependant, avec les bons mécanismes de sécurité en place pour détecter ces menaces et y remédier, cette approche peut s'avérer efficace.
Création d'un piège à miel avec un modèle de certificat leurre : Exemple 1
La figure 1 montre ce qu'un pirate trouve lorsqu'il utilise un outil comme Certify3 pour rechercher des modèles de certificats exploitables.
Ce certificat, CiscoSSLVPNprend en charge l'authentification du client et permet aux ordinateurs du domaine de s'inscrire. Mais comme msPKI-Certificate-Name-Flag n'est pas réglé sur ENROLLEE_SUPPLIES_OBJECTl'attaque ESC1 ne fonctionnera pas.
Lorsque l'attaquant consulte les attributs AD du fichier CiscoSSLVPN certificat (Figure 2), ils constatent que le msPKI-Certificate-Name-Flag est fixée à 134217728ce qui correspond à SUBJECT_ALT_REQUIRE_DNS. Cela signifie que le Supply in Request n'est pas activée.
CiscoSSLVPN les attributs du modèle de certificat, avec msPKI-Certificate-Name-Flag fixé à 134217728, indiquant SUBJECT_ALT_REQUIRE_DNS.Étant donné que dans cet exemple, nous avons accordé aux ordinateurs de domaine le contrôle total sur ce modèle d'autorité de certification, notre attaquant pourrait tirer parti des avantages suivants msDs-MachineAccountQuota (Figure 3), qui est fixé à 10 par défaut, pour créer un nouvel objet ordinateur, s'authentifier en tant que compte de l'ordinateur, puis modifier le modèle d'autorité de certification.
TestPC) en s'appuyant sur msDs-MachineAccountQuotaqui est fixé à 10 par défaut dans AD.Ensuite, l'attaquant s'authentifie en tant que compte de l'ordinateur et modifie le modèle de l'autorité de certification pour le rendre vulnérable à l'ESC1(figure 4).
TestPC$ en modifiant le compte de la machine msPKI-Certificate-Name-Flag sur le CiscoSSLVPN pour le rendre vulnérable à l'ESC1.Notre attaquant vérifie maintenant les attributs AD du modèle CA modifié. Il constate que l'attribut msPKI-Certificate-Name-Flag a changé (Figure 5), qui reflète la modification qui la rend exploitable.
CiscoSSLVPN où le modèle de certificat msPKI-Certificate-Name-Flag a changé, ce qui le rend vulnérable à l'ESC1.Du côté de la défense AD : Dans Directory Services Protector DSPvous pouvez maintenant voir une entrée enregistrant le changement AD sur le modèle de l'autorité de certification leurre(Figure 6), mettant en évidence l'attribut spécifique qui a été modifié.
CiscoSSLVPN où le modèle de certificat msPKI-Certificate-Name-Flag a été modifiée, ce qui permet de poursuivre les recherches sur le compte responsable de l'action.La DSP indique également qui a modifié le modèle d'autorité de certification(figure 7), ce qui vous permet d'enquêter sur le compte responsable de la modification et de détecter toute autre activité suspecte.
CiscoSSLVPN a été modifié par le modèle de certificat TestPC$ compte informatique.Création d'un piège à miel avec un modèle de certificat leurre : Exemple 2
Les WebServer est couramment utilisé pour émettre des certificats SSL/TLS pour Windows Server Update Services (WSUS), Active Directory Federation Services (ADFS), Internet Information Services (IIS), les serveurs web et les répartiteurs de charge. Il garantit une communication cryptée sur HTTP. Par défaut, il est configuré avec Supply in Requestmais comme l'utilisation étendue de la clé (EKU) est fixée à Server AuthenticationESC1 ne peut pas être exploité (Figure 8).
WebServer modèle de certificat, montrant que Supply in Request (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) est activé, mais l'EKU est réglé sur Server Authentication.Pour mettre en place notre piège, vous pouvez commencer par dupliquer le fichier WebServer et lui donner un nom réaliste pour qu'il paraisse légitime. Ensuite, modifiez la DACL pour la faire ressembler à une configuration légitime en autorisant un faux compte d'ordinateur, tel que WSUS-2016pour s'inscrire.
Dans le même temps, le modèle est intentionnellement mal configuré en accordant des droits d'écriture aux utilisateurs authentifiés(figure 9), ce qui crée une possibilité d'exploitation.
WSUS-2016$) a des permissions d'inscription, et les utilisateurs authentifiés ont été mal configurés avec des permissions d'écriture, ce qui rend le modèle vulnérable à l'exploitation.Figure 10 montre à quoi ressemble la reconnaissance pour un attaquant qui identifie des modèles d'AC exploitables, où les utilisateurs authentifiés ont des droits d'écriture sur le leurre. WSUSSSLCert modèle.
WSUSSSLCert modèle de certificat, où les utilisateurs authentifiés ont WriteProperty ce qui leur permet de modifier des attributs tels que EKU.Notre attaquant examine maintenant les valeurs actuelles des attributs AD de ce modèle d'autorité de certification, en se concentrant plus particulièrement sur l'attribut msPKI-Certificate-Application-Policy qui définit l'utilisation autorisée du certificat (Figure 11).
WSUSSSLCert modèle de certificat, en mettant en évidence le msPKI-Certificate-Application-Policy valeur. L'identificateur d'objet 1.3.6.1.5.5.7.3.1 correspond à l'authentification du serveur.Maintenant, ils modifient ce modèle d'autorité de certification pour le rendre exploitable par l'ESC1, puis vérifient comment le modèle d'autorité de certification est exploité par l'ESC1. msPKI-Certificate-Application-Policy les changements de valeur (Figure 12).
WSUSSSLCert où le modèle de certificat msPKI-Certificate-Application-Policy a été remplacé par 1.3.6.1.5.5.7.3.2en activant l'authentification du client. Cette modification rend le modèle vulnérable à l'ESC1.En tant que Figure 13 les spectacles, les msPKI-Certificate-Application-Policy a été mis à jour avec un identifiant d'objet différent, correspondant désormais à l'authentification du client.
WSUSSSLCert où le modèle de certificat msPKI-Certificate-Application-Policy a été modifié en 1.3.6.1.5.5.7.3.2en activant l'authentification du client. Maintenant, le modèle n'est pas seulement vulnérable, il est aussi exploitable pour ESC1.La dernière étape de notre attaquant consiste à accorder des autorisations d'inscription sur le modèle d'autorité de certification, ce qui lui permet de l'exploiter(figure 14).
WSUSSSLCert à l'aide de PowerView.Du côté de la défense AD : Dans DSP, il y a maintenant une entrée dans le journal des changements AD indiquant que quelqu'un a modifié cet attribut AD spécifique sur le modèle CA(Figure 15).
WSUSSSLCert où le modèle de certificat msPKI-Certificate-Application-Policy a été modifiée, passant de l'authentification du serveur à l'authentification du client.Une autre entrée sera enregistrée dans la DSP , indiquant que l'attribut Security Descriptor a été modifié sur le modèle de l'AC leurre(figure 16).
WSUSSSLCert Modèle CA.La clé des leurres dans la défense AD : Créer une règle de notification dans DSP
Dans la DSP, vous pouvez créer une règle de notification pour les modèles de certificats leurres(Figure 17) afin que toute modification apportée à ces derniers déclenche une alerte.
WSUSSSLCert est configuré pour déclencher une alerte chaque fois qu'une modification est apportée au modèle de certificat msPKI-Certificate-Application-Policy attribut.Lorsque quelqu'un modifie cet attribut AD sur le modèle d'autorité de certification leurre, la DSP envoie une notification par courrier électronique contenant des détails sur l'auteur de la modification, le contrôleur de domaine sur lequel elle s'est produite et d'autres informations pertinentes(figure 18).
Aperçu de Semperis
Pour les organisations qui utilisent ADCS, la mise en place de pièges à miel peut être un moyen précieux de détecter les attaquants avant qu'ils ne puissent escalader leurs privilèges. Les erreurs de configuration de l'ADCS sont de plus en plus souvent exploitées dans des attaques réelles, comme le souligne le rapport de Mandiant4 sur les tactiques de post-exploitation d'Ivanti. En déployant des modèles de certificats leurres qui semblent vulnérables mais sont étroitement surveillés, les défenseurs AD peuvent inciter les attaquants à se dévoiler au moment où ils tentent de l'exploiter.
En savoir plus sur la défense proactive d'Active Directory
- Les dix principales erreurs de configuration de la NSA en matière de cybersécurité : Une perspective Active Directory
- Cyber résilience 101 : Conseils pour la défense AD
- Qu'est-ce que la sécurité de l'Active Directory ?
- Meilleures pratiques en matière de renforcement d’Active Directory
Références
