Comprendre les chemins d’attaque visant Active Directory

Cybersécurité
Active Directory ANSSI

Active Directory est le service d’annuaire LDAP le plus répandu au monde. Cela signifie que les attaquants ayant les connaissances et l’expérience requises pour exploiter des chemins d’attaque AD disposent d’un grand nombre de cibles potentielles.

Les chemins d’attaque sont au cœur des discussions en matière de cybersécurité. Mais qu’est-ce qu’un chemin d’attaque exactement ? Pourquoi Active Directory (AD) est-il particulièrement vulnérable ? Et comment les organisations peuvent-elles se protéger ?

Qu’est-ce qu’un chemin d’attaque ?

Il s’agit, comme son nom l’indique, d’un enchainement d’étapes permettant de cheminer au fur à mesure de mouvements latéraux et d’élévations de privilège.

Comme tous les systèmes IT, l’Active Directory est soumis à des vulnérabilités ainsi qu’à de potentielles configurations à risques. Chacune permet de passer d’une machine à une autre (mouvement latéral) ou d’obtenir des droits plus importants (élévation de privilèges).

Ainsi, si un acteur malveillant dispose d’un compte utilisateur sans droit particulier au début d’une cyberattaque, il va suivre un chemin de mouvements latéraux et d’élévations de privilèges successifs jusqu’à obtenir des droits suffisamment importants sur tout ou partie de l’environnement pour exfiltrer des données sensibles, diffuser une charge virale active (crypto malware par exemple), mettre en place des accès permanents monnayables (backdoors) ou toute autre activité néfaste.

Un chemin d’attaque n’est donc pas simplement une liste de vulnérabilités ou de configurations hasardeuses, mais bel et bien un enchainement logique de celles-ci permettant de prendre le contrôle d’un environnement.

Pourquoi Active Directory est-il particulièrement vulnérable ?

Des chemins d’attaques existent pour tous les systèmes de gestion des identités et des accès (IAM). En effet, prendre le contrôle d’une plateforme IAM permet de s’octroyer les pleins droits sur les systèmes et les données d’une organisation.

Pour Active Directory en particulier, le problème est encore plus important. Tout d’abord, Active Directory est le service d’annuaire LDAP le plus répandu au monde, utilisé par près de 95 % des entreprises du classement Fortune 1000. Cela signifie que les attaquants ayant les connaissances et l’expérience requises pour exploiter des chemins d’attaque AD disposent d’un grand nombre de cibles potentielles.

De plus, ils disposent d’un large éventail d’outils développés spécifiquement pour exploiter les vulnérabilités intrinsèques d’Active Directory et de Windows, tels que BloodHound, Mimikatz et Responder pour les plus connus.

Pour chaque Active Directory, il existe au minimum un chemin d’attaque exploitable. La plupart du temps, c’est beaucoup plus que cela du fait de la complexité, du manque de transparence des paramétrages de l’AD et de la dette technique accumulée au cours de ses plus de vingt années d’exploitation.

La gestion des autorisations peut être directe (pour un compte), indirecte (via une appartenance à un groupe), dérivée (via des appartenances de groupes imbriqués), explicite (directement sur l’objet concerné) ou encore héritée (depuis un objet parent de l’objet concerné), etc.

De plus, les Stratégies de Groupe (GPO) permettent d’appliquer massivement des milliers de paramètres avec différents niveaux de filtrage. Il est extrêmement compliqué, voire quasiment impossible de savoir qui a le droit de faire quoi sur un tel environnement.

La gestion des GPO elle-même est un véritable défi. Entre les liens d’application et leurs priorités, les permissions d’application, les héritages ou blocages d’héritage, les droits d’administration des objets GPO, les droits sur le partage sysvol où elles sont stockées, c’est un casse-tête permanent. Tout cet ensemble est un problème majeur de cybersécurité.

Exemple de chemin d’attaque courant

Un compte utilisateur sans droit élevé est membre d’un groupe. Ce groupe ne donne pas non plus de droit particulier, mais il est lui-même membre d’un groupe. Ce second groupe permet d’accéder en RDP sur un serveur qui n’héberge rien de sensible. Cependant, un service applicatif est démarré sur ce serveur et il utilise un compte de service membre d’un groupe à très hauts privilèges (« domain admins » par exemple).

En résumé, si un attaquant parvient à récupérer les identifiants du compte initial, il pourra se connecter en RDP sur le serveur et via des outils spécifiques tels que Mimikatz, il pourra récupérer les identifiants de session du compte de service. À ce stade, l’attaquant est devenu virtuellement administrateur du domaine.

Comment bloquer les chemins d’attaque ?

Bien entendu, on pourrait décider de corriger chaque point de configuration et chaque vulnérabilité qui composent les chemins d’attaque. Le résultat serait bien celui attendu. Cependant cela représente un travail immense d’identifications, de qualifications et de vérifications. En effet, tous les environnements et notamment toutes les applications ne supportent pas les meilleures pratiques de configuration.

Il est donc indispensable de prioriser les points à bloquer dans les chemins. Pour cela, un outil de cartographie et de gestion des chemins d’attaque est nécessaire. Un tel outil permet d’identifier les points de passage obligés des chemins. Une fois ces étapes communes à tous les chemins identifiés, des corrections devront être apportées aux paramétrages qui les composent afin de les bloquer. Cela revient à retirer en priorité le dernier barreau d’une échelle plutôt que de les retirer tous dans n’importe quel ordre. Le résultat attendu est obtenu de façon bien plus simple et rapide.

Dans l’exemple du graphique ci-dessous, le fait de bloquer la dernière étape de l’arbre de chemins rouges supprime 92 % des points de départ des chemins d’attaque en une seule action. Un point de départ étant un compte utilisateur ou une machine potentiellement compromise. Si je suis un attaquant et que j’ai compromis un compte qui se trouve tout en bas de l’arbre de chemin rouge, je ne pourrai pas accéder aux ressources sensibles.

Toujours dans cet exemple, trois actions de correction suffisent à bloquer l’ensemble des chemins d’attaque existants. Le total des trois pourcentages est supérieur à 100 %, car un objet peut être point de départ de plusieurs chemins. Le compte compromis peut être point de départ de l’arbre rouge, mais aussi point de départ de l’arbre bleu.

Autre élément essentiel : la surveillance des chemins d’attaque

Les modifications permettant de bloquer les chemins d’attaque ne sont pas toujours possibles. En effet, si ces corrections empêchent des actions malveillantes, elles peuvent, parfois, également bloquer des actions légitimes. Ceci est d’autant plus vrai que l’environnement hérite d’architectures ou d’applications anciennes. Ces dernières ne supportent pas certains paramétrages sécurisés. Dans ces cas-là, il n’y a pas d’autres solutions que de laisser les chemins ouverts.

Cependant, l’exploitation de ces chemins dans le cadre d’une cyberattaque est associée à des indicateurs de compromission (IoC). Par exemple, l’authentification de comptes de services sur d’autres machines que celles hébergeant les services concernés ou encore l’élévation de privilèges de certains de ces comptes peut être le signe d’une attaque Kerberoast.

Des réplications anormales de l’Active Directory peuvent être le signe d’une attaque DCSync, l’utilisation de tickets Kerberos ayant une durée de vie anormale peut être le signe d’une attaque Golden Ticket, etc.

Il est donc très important de pouvoir surveiller les IoC en temps réel, voire de pouvoir bloquer certaines actions sensibles avant même qu’elles aient lieu comme l’exfiltration de la base NTDS.DIT de l’AD ou encore les modifications non souhaitées de GPO. La surveillance de l’Azure AD est, bien entendu, fortement conseillée également.

Enfin, il est crucial de se rendre compte que l’identification est la gestion des chemins d’attaque n’est pas une action ponctuelle. Les environnements ne cessent d’évoluer et avec eux de nouveaux chemins d’attaque apparaissent sans cesse. Leur surveillance et leur analyse doivent être constantes pour ne pas être pris de vitesse par les attaquants qui, eux, sont en permanence à la recherche de nouveaux chemins pour compromettre les environnements IT des organisations.


Auteur
En savoir plus 
Quest Software
Regis Alix est Senior Principal Solutions Architect chez Quest Software
En savoir plus 

Livres blancs A la Une