Les équipes de réponses à incident Wavestone relèvent que 38% des attaques démarrent par une compromission d’identités (vs. 20% en 2024). Plus globalement, les attaquants exploitent fréquemment les identités on-premise pour se déplacer latéralement vers les environnements cloud (Microsoft Digital Defense Report 2025 [1]). 

Dans un contexte où l’hybridation des identités augmente une surface d’attaque déjà vaste, les entreprises doivent pouvoir en comprendre les enjeux et s’outiller efficacement. 

A travers ce nouveau panorama 2026 des outils de sécurisation Active Directory, nous vous proposons : 

1. Une cartographie actualisée des outils de sécurisation Active Directory 
2. Une lecture des grandes tendances du marché (consolidation, passage aux plateformes, hybridation cloud) 
3. Un retour d’expérience sur les difficultés d’implémentation opérationnelle et les facteurs clés de succès 

Un panorama des outils de sécurisation AD 2026 qui s’est encore enrichi 

En analysant le marché, nous avons identifié 4 cas d’usage principaux sur lesquels ces outils se positionnent : 

1. L’analyse et l’audit 
2. Le durcissement et le maintien en condition de sécurité 
3. La détection 
4. La réponse et la reconstruction 

Un recensement des éditeurs et outils proposant des fonctionnalités répondant à un ou plusieurs de ces 4 cas d’usage été effectué. Il a été réalisé avec l’objectif d’être le plus complet possible, intégrant les outils des acteurs les plus connus et utilisés du marché et ceux des acteurs moins/peu connus, les outils propriétaires et les outils open-source, les outils à large spectre de fonctionnalités et les outils proposant un panel plus limité de fonctionnalités. Tout outil pertinent a ainsi été consigné dans une liste, comportant pour chacun, diverses informations (renommée, description de l’outil et des cas d’usage couverts, hébergement…).  

Le panorama suivant recense un ensemble d’éditeurs de cette liste, sélectionnés en raison de la couverture fonctionnelle qu’ils proposent et de l’étendue de leur utilisation au sein des organisations. 

Le logo de Microsoft Entra ID est ajouté aux outils qui offrent la possibilité de l’intégrer dans leur fonctionnement en plus de la couverture de l’AD on-premise. Il s’agit d’une tendance forte sur le marché. 

1. Un marché en mouvement en pleine consolidation 

Le marché de l’Active Directory a connu un certain nombre de changements depuis 2022, avec plusieurs transactions majeures. Le but étant le plus souvent pour les éditeurs de compléter leur offre, ou de couvrir un nouveau besoin de la sécurisation Active Directory. 

On peut noter entre-autres : 

Rachat de PingCastle par Netwrix  [2] : PingCastle, reconnu pour son expertise dans l’audit de sécurité AD vient renforcer l’offre de Netwrix. Cette acquisition permet à Netwrix d’élargir son portefeuille avec un outil léger, rapide à déployer et apprécié des équipes techniques, tout en affirmant sa volonté de proposer une plateforme unifiée couvrant l’ensemble du cycle de vie de la sécurisation AD. 

Rachat de Attivo par SentinelOne  [3] : Attivo, spécialiste de la sécurité des identités et de la détection des mouvements latéraux, renforce l’offre SentinelOne en intégrant des capacités avancées de protection AD, dans une logique de plateforme unifiée alliant EDR, XDR et sécurité des identités. 

Rachat de BrainWave par Radiant Logic [4] : Radiant Logic renforce les capacités d’analyse d’identité et de gouvernance. En combinant la cartographie fine des droits de BrainWave avec la fédération d’identités de Radiant Logic, l’offre devient plus complète pour répondre aux enjeux AD. 

Intégration de Stealthbits par Netwrix  [5] : En fusionnant avec Stealthbits, Netwrix a intégré des briques historiques d’audit et de détection Active Directory (StealthAUDIT, StealthDEFEND, etc.), renforçant son offre sur la protection des identités et des données sensibles et s’orientant vers une plateforme unifiée autour de la sécurité d’AD. 

2. De l’outil spécifique à la plateforme centralisée 

En 2022, notre panorama des outils de sécurisation Active Directory mentionnait « des outils spécialisés, répondant chacun à une partie de l’équation. » [6]. En 2026, on observe l’émergence de plateformes centralisées, capables de couvrir plusieurs besoins autour d’Active Directory et, souvent, d’Entra ID. Cette dynamique est d’abord tirée par les éditeurs, qui cherchent à élargir leur proposition de valeur et à se différencier sur des plateformes complètes plutôt que par des outils spécialisés offrant des fonctionnalités spécifiques. 

Certains éditeurs construisent leurs plateformes par acquisitions successives, comme Netwrix (audit AD, protection des données, découverte de vulnérabilités, PingCastle…) ou SentinelOne (EDR/XDR renforcé par Attivo sur l’identité), tandis que d’autres enrichissent progressivement leurs offres historiques pour proposer des suites modulaires, qu’il s’agisse d’outils d’administration / surveillance comme ManageEngine ADAudit Plus ou Quest Change Auditor, qui ajoutent des briques d’audit AD, de durcissement et de détection sur l’ensemble de l’écosystème Active Directory. 

Les promesses mises en avant par les éditeurs sont claires : 

• Centralisation des données (comptes, groupes, droits, événements de sécurité) 
• Vision unifiée des chemins d’attaque entre AD et Entra ID 
• Pilotage simplifié pour les équipes sécurité, infrastructure et IAM, via des consoles et tableaux de bord consolidés 

Côté clients, les atouts sont évidents, mais la réalité peut être plus nuancée : 

• La consolidation peut réduire le nombre d’outils et simplifier les intégrations, mais elle ne supprime pas le besoin d’expertise AD ni les outils spécialisés (par exemple pour la reconstruction post-incident). 
• Les environnements restent souvent multi-éditeurs, avec un mix entre plateformes globales (XDR, CNAPP, Identity Security) et outils ciblés AD, notamment dans les grands groupes ou les organisations déjà fortement outillées. 

Dans ce contexte, l’enjeu n’est pas seulement de « choisir une plateforme », mais de composer un ensemble cohérent, en s’assurant que : 

• Le périmètre AD / Entra ID est bien couvert sur tout le cycle de vie (prévention, détection, réponse, reconstruction) 
• Les outils peuvent alimenter les processus existants (SOC, gestion de crise, PRA, IAM) 
• La dépendance à un éditeur unique est évaluée et maîtrisée. 

3. L’hybridation Cloud 

Avec l’essor d’Entra ID et des applications SaaS, l’hybridation des identités est devenue la norme : comptes et groupes AD sont synchronisés vers le cloud, les mêmes identifiants servent à accéder aux ressources on-premise et cloud. De nombreux incidents récents montrent que les attaquants exploitent ces architectures hybrides pour pivoter entre AD et Entra ID, en tirant parti de mauvaises configurations ou d’alignements trop faibles entre les deux mondes. [7] 

Cela se traduit par plusieurs besoins concrets : 

• Supervision conjointe d’AD et d’Entra ID : capacité à corréler les signaux issus de l’annuaire on-premise (changes, anomalies, tentatives de mouvement latéral) et du cloud (signaux Entra ID Protection, anomalies de connexion, accès conditionnel…).  
• Alignement des politiques de sécurité : durcissement de l’AD (configuration, délégation, comptes à privilèges) en cohérence avec les politiques d’accès conditionnel, de MFA et les exigences Zero Trust.  
• Capacités de reconstruction hybride : en cas de compromission AD, la reconstruction et la remise en service doivent intégrer les dépendances Entra ID (synchronisation, comptes de service, applications) pour éviter les effets de bord sur le cloud, et inversement. 

Les éditeurs se positionnent progressivement sur cette hybridation. Certains élargissent leurs moteurs d’audit AD pour inclure Entra ID (on-premise to cloud) et offrir une vue unifiée des vulnérabilités d’identité : Netwrix Auditor permet désormais de surveiller Entra ID en parallèle d’Active Directory avec une vue unique des menaces hybrides. Tenable Identity Exposure étend ses indicateurs d’exposition aux risques spécifiques Entra ID et Semperis Directory Services Protector corrèle les changements AD et Entra ID dans une console unique pour réduire la surface d’attaque hybride. 

D’autres outils partent du cloud (Entra ID, SaaS) et descendent vers l’AD on-premise (cloud to on-premise), dans une logique de “hybrid identity threat detection & response” : Microsoft Defender for Identity fournit un inventaire consolidé des identités AD et Entra ID et de nouvelles capacités de détection sur les composants hybrides (Entra Connect, AD FS, etc.), CrowdStrike Falcon Identity Threat Protection analyse les comptes hybrides présents à la fois dans AD et Entra ID / Azure AD. 

Une mise en œuvre opérationnelle encore perfectible 

Le marché de la sécurisation Active Directory montre une adoption croissante et structurée d’outils pointus. Dans beaucoup d’organisations, la couverture fonctionnelle est désormais correcte, voire avancée, sur les différents volets de la sécurité AD (audit, durcissement, détection, sauvegarde). 

Pour autant, la maturité technologique contraste, avec une mise en œuvre opérationnelle encore incomplète. Les plans de reprise d’activité (PRA / DRP) AD restent souvent théoriques, peu testés, ou déconnectés des outils de sauvegarde et de reconstruction déployés. Les revues régulières (revue de privilèges, de délégations, de relations d’approbations) sont encore rarement industrialisées : elles dépendent souvent de quelques experts, avec un niveau d’automatisation limité. 

L’efficacité de mise en œuvre est, de même, impactée par l’évolution constante de l’écosystème, entre plateformisation des outils et hybridation des identités. L’enjeu des prochaines années sera donc d’aligner les outils (existants et futurs) sur des processus robustes, documentés et testés : 

1. Clarifier les responsabilités entre équipes infra, IAM, sécurité et SOC, 
2. Formaliser et automatiser les contrôles récurrents (revues de droits, validation de configuration, tests de restauration). 

C’est à cette condition que les investissements dans les outils de sécurisation Active Directory, on-premise et cloud, permettront d’atteindre une résilience réelle. 

Méthodologie du panorama 

Nous identifions 4 catégories principales pour regrouper les outils : 

Analyse et audit : 

• Account and Privilege : Inventaire des comptes, groupes et droits associés pour détecter les privilèges excessifs ou non conformes. 
• AD Discovery : Exploration de la structure AD (OUs, GPOs, objets) pour déduire l’architecture, les relations et dépendances. 
• Vulnerability Discovery :  Identification des failles de sécurité (configuration, comptes obsolètes, mots de passe faibles…). 
• Attack Path Discovery : Modélisation des chemins d’attaque potentiels vers des comptes à privilèges. 

Durcissement et gestion : 

• Password Management : Gestion des politiques de mot de passe, synchronisation, audit des mots de passe (robustesse, réutilisation, compromission…). 
• Rights & Privilege Management : Délégation, contrôle des accès, gestion des rôles et des permissions. 
• GPOs Management : Création, analyse, modification des objets de stratégie de groupe. 
• Change Management : Suivi des modifications, traçabilité, gestion des changements et outils de migration. 

Surveillance : 

• Threat Detection : Détection proactive des comportements suspects, escalades de privilèges, mouvements latéraux. 
• Security Incident Detection : Identification des incidents de sécurité, alertes en temps réel, corrélation d’événements. 

Sauvegarde et Recouvrement : 

• AD Backup & Recovery : Sauvegarde partielle ou complète des objets AD, restauration rapide après sinistre. 
• Investigation & Forensics : Analyse post-incident, traçabilité des actions malveillantes, collecte de preuves. 

Pour chacun des outils ainsi classifiés, un badge (logo Microsoft Entra ID) est ajouté lorsque l’outil offre la possibilité d’intégrer Microsoft Entra ID dans son fonctionnement. 

Conclusion

Le panorama de 2026 se base sur l’analyse de 180 outils, contre 150 en 2022. Il a été construit dans une démarche similaire à celui de 2002. Il se base sur un recensement des outils du marché. Sur cette base et en lien avec les thèmes récurrents de sécurisation de l’Active Directory, une catégorisation a été établie pour en faciliter la lecture. 

La liste des outils mentionnés ne prétend pas être exhaustive, dans la mesure où la liste d’outils pouvant concourir de près ou de loin à la sécurité de l’Active Directory est vaste. Ce panorama est donc une synthèse des principaux outils existants, notamment ceux que les consultants Wavestone rencontrent le plus dans les grandes organisations (envisagés, étudiés, testés ou déployés). 

Références 

[1] Microsoft Digital Defense Report 2025 | Microsoft 

[2] Netwrix Acquires PingCastle | Netwrix 

[3] SentinelOne, Inc. – SentinelOne Completes Acquisition of Attivo Networks 

[4] Radiant Logic Signs Definitive Agreement to Acquire Brainwave GRC – Radiant Logic | Unify, Observe, and Act on ALL Identity Data 

[5] Netwrix annonce sa fusion avec Stealthbits | Netwrix 

[6] Radar des outils pour renforcer la sécurité d’Active Directory – RiskInsight 

[7] Microsoft Incident Response lessons on preventing cloud identity compromise | Microsoft Security Blog 

Cet article Panorama des outils de sécurisation Active Directory – version 2026  est apparu en premier sur RiskInsight.

La réflexion sur la bonne manière de traiter ce sujet dans les organisations se trouve à la croisée des projets de renforcement de la sécurité de l’AD et des projets de cyber-résilience.

Infrastructure et agent de sauvegarde : un point faible voire un vecteur de compromission

Nos différents états des lieux réalisés ces derniers mois nous le montrent : les stratégies de sauvegarde n’ont pas toujours évolué vers l’état de l’art.

Premier problème : les infrastructures de sauvegarde ne sont pas résilientes au risque cyber par défaut. L’authentification sur ces infrastructures de sauvegardes est par exemple très souvent liée à l’Active Directory lui-même. Par rebond, le système de sauvegarde pourrait être compromis par l’attaquant, induisant une potentielle destruction des sauvegardes… y compris celles de l’Active Directory !

Et les sauvegardes sont une cible de choix pour les attaquants. Dans plus de 20% des incidents gérés par le CERT Wavestone en 2021, les sauvegardes étaient impactées. Il convient donc d’intégrer le scénario cyber – et tout particulièrement le scénario rançongiciel – lorsque l’on pense à la résilience des sauvegardes.

Deuxième problème : les sauvegardes des Domain Controllers (DC) sont hébergées dans l’outil de sauvegarde, qui a souvent un niveau de sécurité plus faible que celui d’Active Directory. En effet, une organisation ayant déjà mené des travaux de sécurisation d’AD aura potentiellement fortement renforcé son tier 0 (l’on revient toujours au tiering !) : mise en place de postes dédiés pour l’administration, authentification multi-facteurs, filtrage réseau, matériel dédié, limitation du nombre de comptes à privilèges, etc. Cela ne sera hélas pas forcément le cas pour l’infrastructure de sauvegarde. Ces sauvegardes n’étant pas nécessairement chiffrées, un attaquant pourrait la récupérer et l’exfiltrer d’un DC en passant par l’infrastructure de sauvegarde, plus facile à compromettre. Une fois la sauvegarde exfiltrée, l’attaquant sera en mesure d’étendre encore son périmètre de compromission via une attaque de type pass the hash, après récupération des condensats ou encore une attaque par force brute, après extraction des secrets de la base ntds.dit pour récupérer des mots de passe en clair à rejouer sur des services dont l’authentification ne se base pas sur Active Directory.

Troisième problème : les méthodes traditionnelles de sauvegarde reposent sur des agents installés sur les Domain Controllers, dont les hauts privilèges servent parfois de vecteurs de compromissions. Les agents de sauvegarde nécessitent pratiquement toujours des droits d’administration sur l’actif sauvegardé, ce qui expose mécaniquement le Domain Controllers et donc les domaines Active Directory. L’on arrive donc à la situation paradoxale où la mesure de réduction de risque d’indisponibilité (installation d’un agent de sauvegarde sur un DC) devient elle-même la vulnérabilité à l’origine d’un risque pouvant devenir critique (indisponibilité de l’ensemble du système d’informations).

Sauvegarde sur média déconnecté, immuable ou dans le cloud : de multiples stratégies pour de multiples cas de figure

Pour résoudre ces deux problèmes, de multiples solutions existent et leur combinaison permet de construire une stratégie robuste. Cette stratégie doit prendre en compte le contexte de l’organisation ainsi que sa maturité en matière de cybersécurité.

Pour pallier le premier problème induit par l’agent vulnérable deux approches existent, toutes les deux viables :

1. Diminuer la probabilité d’exploitation de la vulnérabilité induite par l’agent de sauvegarde. Cela passe, au-delà des classiques sujets de maintien en condition de sécurité (mise à jour régulière, correction rapide de vulnérabilités de l’agent, etc.), par l’intégration d’un outil de sauvegarde dédié dans le tier 0, dont le niveau de sécurité aura été renforcé.
2. Se débarrasser de l’agent de sauvegarde. Comment ? En utilisant la fonction de sauvegarde native de Windows (Windows Backup), qui permet de réaliser et d’exporter une sauvegarde, que l’on pourra chiffrer et sortir du tier 0, vers un actif du tier 1, qui lui-même pourra être sauvegardé par la solution standard de sauvegarde de l’entreprise.

Pour renforcer la résilience des sauvegardes de l’Active Directory, plusieurs mesures doivent autant que possible se combiner :

1. Externaliser la sauvegarde sur média (version hors ligne). La première déclinaison peut être mise en place rapidement et à faible coût : un disque dur externe à déconnecter une fois la sauvegarde faite. Il s’agit simplement de mettre en place le processus organisationnel associé pour que l’action humaine puisse être faite sans oubli. La seconde déclinaison, pour les rares organisations qui en sont encore dotées, est de s’appuyer sur le système de sauvegarde sur bandes. Dans ce cas aussi, un point d’attention est de rigueur : la sauvegarde et l’externalisation régulière du catalogue de sauvegarde, pour ne pas perdre de temps en cas de restauration, dans le cas où celui-ci a disparu lui aussi (histoire s’inspirant de faits réels rencontrés par nos équipes de réponse à incident). Point d’attention : la sauvegarde sur bandes doit être vue comme un dernier recours pour s’assurer de conserver une copie des données, en cas de scénario catastrophe. En effet, ce format de sauvegarde ne se prête pas à la reconstruction rapide, en raison de délais incompressibles conséquents, avant même de pouvoir commencer à restaurer sur le SI de production : délai de rapatriement des bandes et délai la lecture de leur contenu.
2. Externaliser la sauvegarde en dehors du système d’information (version en ligne). Que cela soit réalisé à l’aise de scripts maison ou de solutions du marché (voir notre radar), après chiffrement robuste, une sauvegarde peut être externalisée. L’avantage des solutions du marché est qu’elles intègrent directement la partie reconstruction rapide (cf. partie suivante) d’un DC.
3. S’appuyer sur une sauvegarde complémentaire mais indépendante. Pour augmenter la disponibilité de l’infrastructure de sauvegarde, il suffit de la redonder en s’assurant qu’il n’y ait pas de risque de compromission simultanée. Pour cela, profitant de leur transition vers le cloud, de nombreuses organisations ont choisi récemment d’ajouter un DC supplémentaire, mais hébergé dans le cloud (les autres étant traditionnellement encore on-premises), bénéficiant ainsi naturellement des mécanismes de sauvegarde qui lui est propre. Du fait des mécanismes de réplication internes à AD, le DC hébergé dans le cloud sera compromis (compromission de certains comptes ou de certaines configurations d’AD) dans la même échelle de temps que ceux on-premises, mais l’étanchéité entre actifs sauvegardés et système de sauvegarde étant supposé meilleur dans le cloud, l’on aura plus de chance d’avoir une sauvegarde d’un DC encore disponible.
4. Rendre son infrastructure de sauvegarde immuable, en s’appuyant au maximum sur les solutions proposées par les éditeurs des logiciels de sauvegarde. En effet, la plupart des éditeurs proposent désormais des mécanismes d’immuabilité, qui parfois ne nécessitent pas l’achat de baies de stockage supplémentaires. En rendant les sauvegardes immuables sur leur stockage primaire, on s’assure d’un temps de reconstruction optimal puisqu’il ne sera pas nécessaire de rapatrier les sauvegardes depuis un stockage hors ligne (axe 1) ou en ligne (axe 2) avant de pouvoir commencer à restaurer. N.B.: l’axe 2 peut et doit bénéficier de ce concept (Amazon S3, Azure blob, etc.).

Enfin, dernier point de détail, connaître quel(s) DC sauvegarder et utiliser pour la restauration en cas de besoin est indispensable (DC Global Catalog, version d’OS la plus récente, etc.), tout comme la fréquence (sûrement quotidienne) et la durée de rétention (sujet beaucoup plus subjectif).

Reconstruction rapide : des capacités souvent incomplètement testées

Les tests de reconstruction sont aussi vieux que le concept de PCA/PRA. Mais là encore, l’on ne peut pas juste reposer sur ces tests annuels pour se considérer prêt, à la lumière de l’état de la menace. En effet, ces tests reposent très souvent sur des hypothèses qui ne seront pas vérifiées en cas de cyberattaque majeure : sauvegardes disponibles, confiance dans l’état du système d’information, outils collaboratifs (poste de travail, messagerie, outil de ticketing, etc.) fonctionnels, infrastructure d’accueil cible prête et disponible, etc.

De ce que l’on observe dans les organisations, les temps affichés et communiqués sur les temps de reconstruction d’un domaine AD sont souvent sous-estimés a priori. Les temps de déclenchement et d’arrêt du chronomètre sont bien souvent discutables : déclenchement au moment où l’on appui sur le bouton de démarrage de la restauration de la sauvegarde, arrêt au moment où un DC est restauré et opérationnel (procédure AD forest recovery exécutée [2]). Pour autant, l’on fait souvent fi de certains points qui peuvent difficilement être écartés pour comparer cette durée à celle du RTO :

• dépendance non satisfaite à un autre domaine indispensable (domaine présentant une ou plusieurs relation(s) d’approbation avec d’autres domaines) ;
• capacité à tenir la charge d’authentification que représentera une réouverture de service ;
• temps d’exécution des opérations de « toilettage » (changement de mot de passe en masse, désactivation de certains services ou compte, remise au propre dans les objets et les groupes, etc.) ;
• etc.

Lorsque l’infrastructure AD est paralysée par une cyberattaque majeure, sa reconstruction deviendra rapidement la priorité de la cellule de crise, en raison de la dépendance des applications et utilisateurs à celle-ci. C’est d’ailleurs un service dont le RTO est le plus faible. Dans le cas où les sauvegardes sont disponibles, se posent rapidement certaines questions qui doivent nourrir la stratégie de cyberdéfense que l’on est en train de définir (voir notre Top 10 des pièges à éviter pour une gestion de crise rançongiciel réussie) :

• Faut-il avoir une zone permettant d’accueillir la future infrastructure saine ?
• La création des utilisateurs dans Azure AD durant la crise permet-elle de rouvrir le service plus rapidem ent ?
• Dans le cas où il existe de nombreux domaines AD (cas des très grandes organisations) dans quel ordre procéder ?

Sur le volet infrastructure, d’abord, dans la vaste majorité des cas, disposer d’une zone isolée et sécurisée de reconstruction permet de gagner du temps. Celle-ci doit être disponible, prête à accueillir le nombre de VM permettant d’atteindre le niveau service considéré comme acceptable dans une telle situation et à la main (comptes avec les droits suffisants, accessibilité, etc.) de l’équipe responsable du service Active Directory uniquement. Cela pour réduire le risque de compromission mais aussi pour ne pas créer de freins (demandes à effectuer à une autre équipe) le jour où le besoin survient.

Cette zone peut-être on-premises ou dans un service cloud, dépendamment des coûts et de la posture cybersécurité de l’organisation quant à l’hébergement de DC sur un cloud (dans le cas où celui-ci est public). Cette zone dormante peut d’ailleurs être mise à profit pour accueillir les tests de restauration réguliers de l’Active Directory, pour être au plus proche d’une situation réelle. Enfin, cette infrastructure doit évidemment être dans le tier 0, si l’organisation s’appuie sur ce framework.

Sur le volet des processus, ensuite, il convient de préparer en amont plusieurs informations indispensables le jour où le besoin de reconstruire le service surviendra :

• déterminer le nombre de DC minimal ainsi que leur localisation (zone de reconstruction dans le cloud / on-premises, mais également géographiquement en cas de présence sur de multiples plaques) ;
• déterminer la méthode de réplication (réplication standard ou recours à IFM [3]) des DC permettant de minimiser le temps entre la disponibilité du premier et du dernier DC nécessaire à la réouverture du service ;
• des règles de filtrage prêtes et désactivées, qu’il suffira d’activer avant l’ouverture du service ;
• du niveau de risque acceptable pour la reconstruction (reconstruction simple et « toilettage » des objets ou méthode du pivot) ;
• (dans les organisations avec de multiples domaines servant plusieurs métiers) une séquence de reconstruction, qu’il aura fallu déterminer au-préalable avec les responsables métier, pour rouvrir le service selon les bonnes priorités.

Ici aussi, les outils de sauvegarde / restauration spécialisés AD apportent de la valeur : ils permettent d’exécuter la procédure de restauration d’une forêt AD en quelques clics et de manière automatisée. La parallélisation de ces opérations est également rendue possible, faisant de ces outils un accélérateur indéniable à considérer pour les organisations possédant de nombreuses forêts !

Sur le volet des ressources, enfin, il convient de disposer d’une organisation permettant de répondre à cette surcharge de travail ponctuelle mais très importante. Pour cela, l’automatisation des activités de reconstruction qui peuvent l’être, mais également le fait d’avoir des ressources ayant déjà pratiqué l’exercice à de multiples reprises s’avère souvent décisif.

Certaines organisations profitent des tests de Disaster Recovery (DR) pour simuler la pire situation possible pour le service Active Directory, plutôt que de simplement simuler une reprise seulement partielle. C’est indubitablement une bonne pratique.

En définitive, se poser la question de la résilience de son infrastructure Active Directory tire le sujet plus global de la résilience du système d’information, mais également celui du tiering, celui des exercices grandeur nature, à mener régulièrement. L’on pourrait même faire un pont avec le DevOps : ne rêverait-on pas de parvenir au redéploiement d’une infrastructure AD quasiment automatiquement, à l’image de ce que parviennent à faire les DevOps grâce au concept d’Infrastructure as Code ? En attendant, l’entraînement régulier reste le seul moyen d’atteindre un degré de sérénité sur ses capacités à rouvrir rapidement un service AD minimal, s’il venait à être entièrement détruit.

[1] https://www.wavestone.com/en/insight/cert-w-2022-cybersecurite-trends-analysis/

[2] https://learn.microsoft.com/fr-fr/windows-server/identity/ad-ds/manage/ad-forest-recovery-guide

[3] Install From Media : https://social.technet.microsoft.com/wiki/contents/articles/8630.active-directory-step-by-step-guide-to-install-an-additional-domain-controller-using-ifm.aspx

Cet article RECONSTRUCTION D’ACTIVE DIRECTORY : COMMENT SE DONNER LES MOYENS D’Y PARVENIR ? est apparu en premier sur RiskInsight.

Ces dernières années, il a très fréquemment été ciblé par les attaquants, puisqu’il a par exemple été compromis dans 100% des cyberattaques gérées par le CERT-Wavestone (cf. Cyberattaques en France : les ransomware toujours n^o1 – Par le CERT-Wavestone), dans l’optique d’utiliser les accès ainsi obtenus pour diffuser un logiciel malveillant (e.g. un rançongiciel) sur l’ensemble du SI ou encore d’accéder à de nombreuses informations sensibles de l’organisation et de les faire fuiter.

Pourtant son niveau de sécurité est encore largement insuffisant : 96% des tests d’intrusion réalisés par Wavestone en 2018, sur 25 systèmes d’information de grandes entreprises, ont résulté en sa compromission totale (cf. Bilan de la sécurité des sites web en France Retour sur 3 ans d’analyse de la sécurité des sites de grandes entreprises). Même si cette valeur est orientée à la baisse depuis 1 à 2 ans, elle reste aujourd’hui aux alentours de 90%.

Etant devenu une priorité absolue pour la plupart des organisations, les équipes de cybersécurité des entreprises ont lancé d’importants programmes de renforcement du niveau de sécurité de l’AD. Pour adresser ce chantier complexe, vaste d’un point de vue du périmètre et incluant de nombreux thèmes à traiter de front, notamment la mise en œuvre du tiering (cf. Livre Blanc – Sécurisation de l’Active Directory et d’Azure AD, enjeux et trajectoires de transformation – Wavestone et Microsoft), les organisations cherchent à se doter d’outils permettant de les aider dans l’exécution.

En analysant le marché, nous avons identifié 4 cas d’usage sur lesquels ces outils se positionnent :

1. L’analyse et l’audit
2. Le durcissement et le maintien en condition de sécurité
3. La détection
4. La réponse et la reconstruction

Le radar suivant recense un ensemble d’éditeurs mettant à disposition des solutions sur ces quatre cas d’usage en lien avec la sécurité d’Active Directory.

Dernière mise à jour : avril 2023

DES OUTILS SPECIALISES, REPONDANT CHACUN A UNE PARTIE DE L’EQUATION

« AUDIT » : CARTOGRAPHIER l’AD ET IDENTIFIER SES VULNERABILITES POUR STRUCTURER UN PLAN D’ACTIONS

Avant de débuter toute action de renforcement de la sécurité, il est nécessaire d’identifier le point de départ, en établissant un premier état des lieux. Pour cela, réaliser un audit outillé permet de revoir les différents éléments de configuration de l’AD : protocoles obsolètes, version d’OS obsolètes, niveau fonctionnel non à jour, politiques de mots de passe, relations d’approbations avec d’autres forêts AD, comptes à privilèges, octroi de droits pouvant conduire à des chemins de compromissions, etc.

Ces outils sont classiquement utilisés par les équipes de sécurité offensive (internes ou externes), mais l’on observe de plus en plus une utilisation récurrente de ce type d’outils par les équipes chargées du MCO de l’Active Directory et par les équipes sécurité durant le projet, pour suivre la correction mois après mois, des vulnérabilités identifiées.

Pour une identification des vulnérabilités de l’AD, l’on pourra notamment se tourner vers des outils tels que PingCastle (open source), Purple Knight (Semperis), Group3r (open source), ADAnlyzer (Cogiceo) ou encore OAADS (Microsoft). S’agissant des chemins de compromission, l’on pourra recourir à BloodHound (open source) ou AD Control Path (open source, ANSSI).

Enfin, pour les opérateurs règlementés et de la sphère publique, l’ANSSI propose le service Active Directory Security (ADS) [3], afin d’aider les opérateurs critiques à évaluer leur niveau de sécurité.

À noter que toutes les solutions d’audit ont en commun la production de rapports de sécurité sur les différents éléments revus, avec parfois un score de maturité (pouvant être basé sur les points de contrôle Active Directory mis à disposition par l’ANSSI [4]) et des indications techniques quant à la correction à appliquer. Il s’agira ensuite, pour les équipes cybersécurité, d’analyser et de mettre en perspective les différentes vulnérabilités à la lumière du contexte de l’entreprise (e.g. domaines prioritaires, adhérences avec d’autres projets en cours, trajectoire de sécurisation plus globales, etc.), d’établir un plan d’actions en identifiant au préalable les impacts associés à leur mise en œuvre, de prioriser le déploiement des actions correctrices et de s’assurer de leur caractère effectif.

« HARDEN & MANAGE » : RENFORCER LE NIVEAU DE SECURITE DE l’AD EN APPLIQUANT LES BONNES PRATIQUES

Maintenir le niveau de sécurité de l’Active Directory au quotidien n’est pas trivial. En effet, chaque jour, des changements sont apportés à différents niveaux (e.g. création de comptes, ajout de comptes à des groupes, octroi de droits à des comptes, modifications de GPO, modification de politiques de sécurité, etc.), pouvant, dans certains cas, exposer l’Active Directory plus que ce que l’on ne le pense.

D’abord, détecter de vulnérabilités sans délai et sans réaliser d’actions manuelles peut s’avérer être un accélérateur, si une gouvernance adéquate y est associée, afin de traiter les alertes remontées. Pour cela, des outils tels que Tenable.ad (Tenable), Directory Services Protector (Semperis) ou Security Compliance Toolkit (Microsoft) permettent d’offrir une visibilité en temps réel des vulnérabilités, permettant une plus grande réactivité dans la remédiation. Il est à noter que certaines organisations font le choix d’utiliser des outils d’audit qu’ils exécutent très régulièrement (i.e. plusieurs fois par mois), et identifient et traitent le delta.

De plus, un ensemble d’outils existent pour améliorer la visibilité globale, simplifier la gestion au quotidien et ainsi renforcer la sécurité ou encore permettre d’identifier des modifications de configuration menées. Par exemple, AD Audit Plus (Manage Engine) ou DatAdvantage for Directory Services (Varonis) permettent d’obtenir tous les détails concernant un changement effectué et d’être notifié si besoin, Booster for Active Directory (Brainwave) ou Privilege Assurance (QOMPLEX) améliorent la visibilité générale de l’AD. Par ailleurs, la suite d’outils de Quest, ActiveRoles For Server pour compléter la gestion des délégations, Change Auditor pour identifier les changements de configuration et GPOAdmin pour garder une bonne maitrise des GPO peuvent compléter les outils à disposition de l’équipe chargée du MCO de l’AD.

Enfin, s’agissant de l’amélioration de la gestion des comptes à privilèges, l’on peut citer Stealthbits Privileged Activity Manager (Netwrix), qui met en œuvre une solution de PAM qui permet par exemple d’implémenter du just-in-time administration (octroyer des privilèges à un compte seulement pour une opération à réaliser et non pas de manière permanente).

« MONITOR » : DETECTER LES TENTATIVES DE COMPROMISSION AVANT QU’ELLES N’ABOUTISSENT

Les configurations de sécurité maintenant activées, Active Directory est plus difficile à compromettre mais il n’en est toutefois pas à l’abris. Il est donc fondamental de le surveiller continuellement, afin d’être en mesure de détecter les premiers signes d’une attaque.

En complément des scénarios de détection mis en œuvre dans le SIEM par les équipes du SOC, reposant sur la corrélation de logs préalablement collectés, des outils spécialisés peuvent compléter le dispositif. Ces derniers récupèrent des données directement sur les Domain Controllers soit via un agent soit via un compte, puis mènent leurs propres opérations de corrélation et de détection.

Dans cette catégorie d’outils, l’on peut citer Tenable.ad (Tenable), Directory Services Protector (Semperis), Falcon Identity Threat Detection (CrowdStrike), Ranger AD & Singularity Identity (SentinelOne) ou encore DatAlert (Varonis).

« RESPOND & RECOVER » : INVESTIGUER LES COMPROMISSIONS ET RECONSTRUIRE L’ACTIVE DIRECTORY

En cas de compromission partielle ou totale de l’AD, deux actions devront être menées rapidement et en parallèle :

• l’investigation, pour comprendre comment l’attaquant a procédé et quel est le degré de confiance que l’on peut avoir dans l’AD dans son état actuel ;
• la restauration / reconstruction de l’AD, selon le cas de figure.

Afin de mener les investigations requises, et de pouvoir tenter de remonter à la source de compromission initiale, l’on peut notamment citer l’outil ADTimeline (open source, ANSSI), qui permet de retracer, via les données de réplication, les modifications qui ont été faites sur un AD.

Reconstruire entièrement son environnement AD peut prendre plusieurs jours, voire plusieurs semaines, ce qui peut entrainer de lourds impacts à l’échelle de l’organisation. Minimiser ce temps peut se révéler vital dans certains cas. Certains outils permettant de réduire ce temps de reconstruction, l’on peut notamment citer Active Directory Forest Recovery (Semperis), qui automatise les opérations de la procédure de récupération de forêt de Microsoft ou Recovery Manager for Active Directory (Veeam) qui combine sauvegarde mise à l’abris d’une compromission et restauration en cas de besoin.

Il est à noter que certaines organisations font le choix d’externaliser (après chiffrement) la sauvegarde ainsi que d’automatiser et de s’entrainer régulièrement à la reconstruction, ou encore d’héberger un des Domaine Controllers de la forêt sur une plateforme tierce pour maximiser les chances de succès de la restauration, en diversifiant les moyens de sauvegarde.

QUID D’AZURE AD ?

Dans la mesure où beaucoup d’entreprise sont aujourd’hui dans un mode hybride, il convient d’intégrer au plus tôt Azure AD dans le périmètre du chantier de sécurisation. Sur ce périmètre, certains outils peuvent être cités :

• Sur la partie « Audit» : Microsoft 365 DSC, BloudHound (incluant maintenant une partie Azure AD)
• Sur la partie « Harden & Manage » : CoreView, Idecsi, les outils Microsoft (Azure AD Access Reviews, Azure AD Entitlement Management, Azure AD Privileged Identity management, etc.)
• Sur la partie « Monitor » : Azure AD Identity Protection, Microsoft 365 DSC
• Sur la partie « Respond & Recover » : Azure AD Identity Protection, Quest On Demand Recovery

POINTS IMPORTANTS AU SUJET DU RECOURS AUX OUTILS

Le déploiement d’un outil ne permet pas, seul, de renforcer le niveau de sécurité des environnements AD. Après son acquisition, il s’agit de ne pas négliger le reste à faire : définir et mettre en place la gouvernance (processus, modèle d’organisation, comitologie, pilotage, reporting, contrôle, amélioration continue, etc.) et les ressources dotées de la bonne expertise permettant de rendre effective l’amélioration de la sécurité (traiter les alertes, corriger les vulnérabilités, mener des actions d’amélioration continue, etc.).

Aussi, un ensemble de projets connexes à mener et de processus à revoir lors de chantiers de sécurisation AD, qu’il convient de ne pas sous-estimer : patch management, inventaire, rationalisation (limitation du nombre de domaines / forêts afin de faciliter leur maintien en condition de sécurité), revue de la stratégie de sauvegarde, entrainement à la reconstruction, construction d’infrastructure de restauration / nettoyage, etc.

Enfin, lors du déploiement de ces outils, il convient de rester vigilant à ne pas exposer davantage l’Active Directory : installation d’agents sur les Domain Controllers, ouvertures de flux réseau, octroi de privilèges à des comptes ou à des comptes de services, etc.

À PROPOS DE NOTRE MÉTHODE

Le radar a été construit sur la base d’un recensement des outils du marché. Sur cette base et en lien avec les thèmes récurrents de sécurisation de l’Active Directory, une catégorisation a été établie pour en faciliter la lecture.

La liste des outils mentionnés ne prétend pas être exhaustive, dans la mesure où la liste d’outils pouvant concourir de près ou de loin à la sécurité de l’Active Directory est vaste. Ce radar est donc une synthèse des principaux outils existants, notamment ceux que les consultants Wavestone rencontrent le plus dans les organisations (envisagés, étudiés, testés voire déployés).

[1] https://docs.aws.amazon.com/whitepapers/latest/active-directory-domain-services//active-directory-domain-services.html

[2] https://www.silicon.fr/avis-expert/repenser-la-securite-dactive-directory-a-lere-du-cloud

[3] https://www.ssi.gouv.fr/actualite/le-service-active-directory-security-ads-accompagner-la-securisation-des-annuaires-active-directory-des-acteurs-critiques/

[4] https://www.cert.ssi.gouv.fr/uploads/guide-ad.html

Cet article Radar des outils pour renforcer la sécurité d’Active Directory est apparu en premier sur RiskInsight.

Dans un contexte où l’on assiste à une véritable pénurie de compétences cybersécurités, ces problématiques ne peuvent être adressées uniquement par le renforcement des effectifs du SOC. L’utilisation de nouveaux outils, basée sur 4 axes stratégiques, est indispensable pour permettre au SOC d’avoir de l’avance sur les nouvelles menaces.

Ainsi, l’extension de la détection à de nouveaux périmètres permet de protéger de nouvelles parties du SI, aujourd’hui insuffisamment sécurisées (Cloud) ; et des ressources de plus en plus prises pour cibles (attaques ransomware sur les terminaux, attaques ciblées utilisant les AD…).

Dans le même temps, l’adoption de nouvelles approches devient une nécessité pour détecter les attaques ciblées (0days, « low signal » …), dont la subtilité croissante met à mal les dispositifs de sécurité existants.

En complément de nouveaux outils de détection, une connaissance avancée des menaces et des attaquants peut venir améliorer les capacités de détection existantes, aider à la priorisation des incidents à traiter et faire gagner en efficacité lors de la réaction.

Mais les équipes SOC éprouvent déjà des difficultés à traiter les évènements générés par les outils existants. Il est donc primordial d’industrialiser et d’automatiser les interactions entre équipes et systèmes, et, lorsque c’est possible, les étapes d’analyse et de réaction !

Pendant l’été, suivez les épisodes de notre saga pour découvrir les moyens d’outiller ces 4 axes stratégiques !

Étendre la détection à de nouveaux périmètres

Une solution unique pour sécuriser tous les Cloud : CASB

Les CASB (pour Cloud Access Security Broker) adressent un périmètre du SI aujourd’hui mal desservi par les mesures de sécurité classiques : le Cloud. Par sa nature, sa protection nécessite en effet des adaptations par rapport aux SI classiques : pas ou peu de maîtrise des ressources (infrastructures, OS ou applications, selon le type d’offre), localisation à l’extérieur du SI…

Les CASB visent à centraliser et à faire appliquer les politiques de sécurité aux services situés dans le Cloud. Certains fournisseurs Cloud proposent leurs propres services de sécurisation CASB (par exemple Microsoft avec Microsoft Cloud App Security) ; mais, selon les besoins, il est parfois préférable d’utiliser des solutions tierces, même si l’ajout d’un acteur supplémentaire a un coût. En effet, le CASB visant à s’assurer du niveau de sécurité du Cloud, confier ce rôle aux fournisseurs du service à surveiller peut être contre-productif, et l’utilisation d’un « tiers de confiance » est à privilégier.

Dans tous les cas, les CASB sont des solutions variées, pouvant regrouper de très nombreux services, leurs maturités variant selon les éditeurs de solution, les fournisseurs Cloud et le type d’hébergement (IaaS, PaaS, SaaS…).

D’une part, les solutions CASB permettent d’adresser les enjeux spécifiques aux Cloud, en palliant le manque de visibilité sur ces environnements (détection du Shadow IT, statistiques d’utilisation…), et en s’assurant de leur conformité (vérification des configurations…).

D’autre part, elles participent au déploiement des mesures de sécurités classiques sur ce périmètre. En particulier, les enjeux de sécurité de la donnée (DLP et mesures de chiffrement, particulièrement appréciées par les régulateurs) et de détection des menaces (centralisation des logs Cloud pour transmission au SIEM, détection de comportements anormaux -UEBA !, voir partie dédiée-…) font parties des capacités classiques proposées par les éditeurs. En complément, certaines problématiques d’IAM peuvent aussi être adressées par ces solutions (SSO, contextualisation des accès…).

Il existe deux principaux modes de déploiement pour la mise en place de ces fonctionnalités, chacun possédant ses avantages (et inconvénients). Les solutions types proxy sont placées en coupure entre les utilisateurs et le service Cloud.

A l’opposé, dans le cas des solutions de type API, parfois appelées out-of-band, les consommateurs du service Cloud communiquent directement avec celui-ci. Pour chaque accès, le service interroge les API du CASB afin de d’évaluer les risques, et d’autoriser ou non la consommation du service. Les solutions API s’appuient cependant sur les interfaces proposées par le fournisseur Cloud pour fonctionner, ce qui peut limiter certaines possibilités.

Aujourd’hui jeunes et peu matures, les CASB restent peu déployés. Au vu de la démocratisation (déjà bien avancée) des services Cloud, les CASB ont cependant un bel avenir devant eux, et permettront aux équipes SOC d’étendre leur surveillance sur ce périmètre, voué à représenter une partie importante du SI.

Exemples d’éditeurs CASB :

Détection et réaction, le nouveau couteau suisse pour sécuriser les terminaux : EDR (Endpoint Detection and Response)

Les solutions EDR (pour Endpoint Detection and Response) viennent compléter les capacités de détection et de réaction des SOC sur les terminaux (PC, serveurs…).

Comme leur nom l’indique, les EDR participent à la détection d’attaques. Ceux-ci viennent en effet combler les faiblesses des anti-virus (et autres HIPS) s’appuyant sur des signatures d’attaques précises, et donc inadaptées pour détecter certains types d’attaques, notamment les attaques avancées (APT). Les EDR se basent donc sur d’autres méthodes de détection, les éditeurs proposant généralement une combinaison de techniques habituellement utilisées sur d’autres périmètres.

Parmi ces techniques, la détection d’exploitation de vulnérabilités connues ou de patterns d’attaque (ouverture de port suspects vers des adresses douteuses…), l’analyse de fichiers par une sandbox (émulation locale, soumission dans le Cloud…), et des approches comportementales basées sur du Machine Learning (en particulier les solutions UEBA, cf. partie dédiée) sont utilisées par bon nombre de solutions. Selon les besoins du SOC, les alertes remontées peuvent être intégrées comme sources du SIEM, ou disponibles directement depuis la console de management de la solution.

En plus de ces capacités de détection avancées, les solutions EDR apportent aussi un important gain en visibilité sur les terminaux : liste des processus et services lancés, liste de fichiers dans certains répertoires systèmes… et toute autre information permettant de faciliter l’investigation en cas d’alerte. Certaines solutions ne se limitent pas à récupérer l’état du terminal au moment de la demande, mais permettent aussi de récupérer son historique : génération de logs, récupération de fichiers supprimés…

Mais les fonctionnalités des EDR ne s’arrêtent pas aux étapes de détection et d’analyse. En effet, ces solutions permettent d’effectuer des actions de remédiation à distance, dont la complexité dépend des éditeurs : suppression ou mise en quarantaine de fichiers, arrêt de processus, mise en quarantaine réseau de postes, modification de clés de registre…

Les EDR sont donc des solutions très complètes intervenant à toutes les étapes du processus : de la détection, à l’analyse, jusqu’à la réaction. Elles n’ont cependant pas vocation à remplacer les solutions anti-virus, toujours plus efficaces pour bloquer les attaques connues ; même si l’on observe de plus en plus d’éditeurs proposant des solutions unissant les deux types de fonctionnalités.

Pour plus de détails sur les solutions EDR, vous pouvez consulter notre article dédié au sujet ici !

Exemples d’éditeurs EDR :

Protection des clés du royaume : supervision Active Directory

Les annuaires comptent parmi les composants les plus critiques du SI. En effet, ceux-ci fournissent les fonctionnalités d’authentification et d’habilitation pour la quasi-totalité des ressources du SI, aussi bien techniques que métiers, y compris les plus critiques. Il n’est donc pas étonnant que la compromission d’AD figure parmi les méthodes d’attaque les plus utilisées, car ouvrant de nombreuses portes aux attaquants.

Malgré cette criticité, et bien que les architectures AD soient bien connues et aient peu évolué depuis plusieurs années, leur sécurisation reste perfectible. Cela est en particulier dû à leur mode de fonctionnement spécifique (OU, domaines, arbres, forêts, utilisateurs…), rendant les moyens de protection et de surveillance classiques peu efficaces, en particulier lorsque toute vulnérabilité peut représenter un risque majeur pour le reste du SI.

Les solutions de surveillance AD visent à pallier ce problème en supervisant (en temps réel, ou lors d’audit) les spécificités des annuaires (configuration, état des comptes…), et en y détectant des vulnérabilités susceptibles de causer leur compromission. Pour cela, les solutions de supervision AD possèdent une connaissance très pointue du fonctionnement des AD, et tout particulièrement des enjeux de sécurité liés.

Lorsqu’une vulnérabilité est détectée, une alerte est remontée (par le biais du SIEM, ou directement dans la solution) et des conseils de remédiation peuvent être fournis afin de faciliter le travail des équipes en charge de la correction.

Les outils de supervision AD permettent par ailleurs au SOC de détecter toute modification de configuration (légitime, accidentelle ou malveillante) et de s’assurer en continu du niveau de sécurité de ces composants critiques, compliquant d’autant la tâche de nombreux attaquants.

En complément du renforcement direct du niveau de sécurité de l’AD, ces solutions peuvent aussi être utilisés pour s’assurer de la compliance vis-à-vis de normes ou de contraintes réglementaires (LPM, PCI DSS…).

Ces solutions restent assez peu répandues aujourd’hui, et leur utilisation généralement limitée à des audits ponctuels. Cependant, au vu des importants gains de sécurité associés (détection et conseils de remédiation) et de leur simplicité d’utilisation, ces solutions sont prometteuses et devraient réussir à se faire une place parmi les outils du SOC.

Exemples d’éditeurs de supervision AD :

Pour retrouver notre second article de la saga, c’est par ici.

Cet article SOAR, UEBA, CASB, EDR et autres acronymes… suivez la saga de l’été pour comprendre et choisir parmi les nouveaux outils du SOC (1/3) est apparu en premier sur RiskInsight.

Introduction aux données de réplication de l’Active Directory

• L’information modifiée n’est pas une information répliquée entre les différents contrôleurs de domaines. C’est le cas de l’ensemble des attributs de l’Active Directory qui disposent du flag FLAG_ATTR_NOT_REPLICATED[1] comme par exemple l’attribut « BadPwdCount » qui tient compte du nombre de tentatives de connexion échouées :

  

  Dans ce cas, le contrôleur de domaine effectue la modification dans sa propre base de données, mais ne transmet rien aux autres contrôleurs de domaine.

   

• L’information modifiée nécessite une réplication entre les différents contrôleurs de domaines. Dans ce cas, le contrôleur de domaine qui a reçu le changement utilise le modèle de réplication de l’Active Directory pour transmettre le changement aux autres contrôleurs du domaine. Ce modèle de réplication ne sera pas détaillé dans cet article, mais permet la diffusion des évolutions à l’ensemble des contrôleurs d’un domaine en limitant le trafic nécessaire et en assurant la gestion des collisions (en cas de changement d’un même attribut sur différents contrôleurs sur une fenêtre de temps réduite).

 

 

 

 

 

Lors du blocage d’un compte, un flag LOCKOUT[6] est positionné sur l’attribut userAccountControl d’un utilisateur. Cet attribué étant répliqué entre les différents contrôleurs de domaine, des données de réplication de type msDS-ReplAttributeMetaData sont alors générées. Il est alors possible de créer un script permettant d’identifier les comptes du domaine ayant un numéro de version important dans les données de réplication de cet attribut, ce qui pourrait annoncer un tel bruteforce :

 

Cet article Utilisation des métadonnées de réplication, quand les journaux font défaut est apparu en premier sur RiskInsight.

Kerberos est un protocole d’authentification réseau reposant sur un mécanisme de clés secrètes (chiffrement symétrique) et l’utilisation de tickets. Il fait partie intégrante des système d’exploitation Windows depuis la version Serveur 2000. Différents termes spécifiques sont utilisés pour détailler ce protocole :

• KDC (Key Distribution Center) : Le KDC est un service installé sur les contrôleurs de domaine et permettant l’obtention des différents tickets par un utilisateur.
• TGT (Ticket-Granting Ticket) : Le TGT est un ticket attribué par le KDC à un utilisateur. Ce ticket représente l’identité de l’utilisateur, et lui permet d’effectuer des demandes de TGS auprès du KDC.
• TGS (Ticket-Granting Service) : Le TGS est également un ticket attribué par le KDC pour représenter un utilisateur. Il permet à l’utilisateur de s’authentifier auprès d’un service spécifique, dont le nom est inscrit dans le ticket. Un exemple d’un tel ticket est le suivant :

Le schéma d’une authentification Kerberos classique est le suivant :

Dans la première étape, l’utilisateur envoi au contrôleur de domaine un timestamp chiffré à l’aide du hash NTLM de son mot de passe. Ayant accès à ce hash, le contrôleur de domaine, et plus précisément le KDC, peut déchiffrer l’information reçue et vérifier le timestamp, ce qui prouve l’identité de l’utilisateur. Le KDC fournit alors à l’utilisateur son TGT (étape 2).

L’utilisateur peut alors fournir le TGT préalablement récupéré pour effectuer une demande de TGS (étape 3). Le TGT étant représentatif de l’utilisateur, le KDC peut valider son identité et lui fournir un TGS pour le service demandé (étape 4).

Enfin, l’utilisateur transmet ce TGS comme preuve de son identité auprès du service (étape 5).

Dans le protocole Kerberos, ce sont donc bien les tickets qui permettent d’assurer l’identité d’un utilisateur, au même titre qu’un couple nom d’utilisateur / mot de passe le fait dans une authentification classique.

Introduction aux délégations Kerberos

Microsoft a introduit les délégations Kerberos dans l’objectif de permettre à une application de réutiliser l’identité d’un utilisateur pour accéder à une ressource hébergée sur un serveur différent. Un cas d’usage est par exemple l’accès à des documents hébergés sur un serveur dédié depuis une plateforme SharePoint :

L’utilisateur n’ayant pas d’accès direct au serveur de fichiers, il s’authentifie sur la plateforme SharePoint qui doit alors transmettre l’identité de l’utilisateur au serveur de fichiers.

Cependant, les tickets de service étant délivrés pour une application spécifique, le SharePoint ne peut transmettre directement le ticket qu’il a reçu de l’utilisateur. C’est donc pour répondre à cette problématique que Microsoft a mis en place les délégations Kerberos, qui existent sous deux formes :

• Les délégations non contraintes, apparues avec le système d’exploitation Windows Serveur 2000, et qui donnent l’autorisation à un compte de service de réutiliser l’identité de l’utilisateur sur n’importe quel service du domaine ou de la forêt.
• Les délégations contraintes, apparues avec le système d’exploitation Windows Serveur 2003, et qui permettent un meilleur contrôle en limitant les services sur lesquels un compte de service donné peut s’authentifier en tant que l’utilisateur.

Les délégations Kerberos non contraintes

Le schéma d’authentification d’un utilisateur désirant accéder à une ressource dans le cas d’une délégation Kerberos non contrainte est le suivant :

Lors de la première étape de ce schéma, l’utilisateur effectue une demande de TGT auprès du contrôleur de domaine, en lui transmettant un timestamp chiffré avec le hash NTLM de son mot de passe. Après avoir validé son identité, le contrôleur de domaine fournit un TGT à l’utilisateur (étape 2), comme il le ferait pour une authentification Kerberos classique.

Pour s’authentifier auprès de l’application SharePoint, l’utilisateur demande alors un TGS au contrôleur de domaine, en lui fournissant le TGT précédemment récupéré (étape 3). Dans le cas d’une délégation Kerberos non contrainte, le contrôleur de domaine construit le TGS de l’utilisateur à partir de son TGT, qu’il chiffre à l’aide du hash NTLM du mot de passe du compte de service utilisé par l’application SharePoint (étape 4).

L’utilisateur s’authentifie alors sur l’application SharePoint (étape 5) en transmettant le TGS que lui a fourni le contrôleur de domaine lors de l’étape précédente.

Le compte de service de l’application SharePoint peut déchiffrer ce TGS étant donné qu’il est chiffré avec son propre hash. Il récupère ainsi le TGT de l’utilisateur, qu’il peut fournir au contrôleur de domaine pour effectuer une demande de TGS pour le serveur de fichier (étape 6). Le TGT étant celui de l’utilisateur, le TGS renvoyé par le contrôleur de domaine (étape 7) représente son identité, et non celle du compte de service.

Le compte de service de l’application SharePoint peut alors transmettre ce TGS (étape 8), que le serveur de fichiers validera comme s’il provenait de l’utilisateur lui-même, donnant accès au document demandé (étape 9).  Ayant récupéré ce document, l’application SharePoint peut le fournir à l’utilisateur, pour lequel les phases d’authentification intermédiaires auront été transparentes.

Les délégations Kerberos contraintes

Dans le cas d’une délégation Kerberos contrainte, deux extensions de protocole sont utilisées pour permettre à une application de réutiliser l’identité de l’un de ses utilisateurs :

S4U2Self (Server-for-User-to-Self) qui autorise un service à obtenir un TGS pour lui-même en tant qu’un utilisateur.

S4U2Proxy (Server-for-User-to-Proxy) qui autorise un service à obtenir un TGS pour un autre service en tant qu’un utilisateur.

La cinématique d’authentification et d’accès aux ressources dans le cas d’une telle délégation est alors la suivante :

Dans la première étape de cette cinématique, l’utilisateur s’authentifie après du premier service en lui transmettant ses identifiants. L’authentification n’utilisant pas Kerberos, l’utilisateur n’a pas besoin de s’authentifier auprès du contrôleur de domaine.

Le compte de service demande alors un TGS représentant l’identité de l’utilisateur et permettant de s’authentifier auprès de son propre service (étape 2). Le compte de service possédant l’extension S4U2Self, le contrôleur de domaine accorde ce ticket (étape 3).

Ce même compte de service demande ensuite un TGS représentant l’identité de l’utilisateur et permettant de s’authentifier auprès du second service (étape 4). Après validation de l’extension S4U2Proxy, le contrôleur de domaine accorde ce TGS (étape 5)

Grâce à ce second ticket de service, le compte de service du SharePoint peut accéder aux ressources du serveur de fichier avec l’identité de l’utilisateur (étape 6). Le serveur de fichiers valide les privilèges de l’utilisateur, et transmet le document demandé au compte de service SharePoint (étape 7), qui le transmet à l’utilisateur (étape 8).

Contrairement au cas des délégations non contraintes, l’utilisation de l’extension de protocole S4U2Proxy permet de spécifier les services accessibles au compte de service SharePoint. Ainsi, même si l’utilisateur dispose des privilèges nécessaires pour accéder à un autre serveur, le compte de service ne pourra récupérer de TGS valide représentant l’identité de l’utilisateur. Dans le cas d’une délégation contrainte, cette restriction se fait à l’aide d’un paramètre du compte de service, appelé SPN pour Service Principal Name.

Il est à noter que depuis la version Serveur 2012 du système d’exploitation Windows, un troisième type de délégation Kerberos est proposée, les délégations Kerberos contraintes basées sur les ressources. Le fonctionnement de ces délégations est similaire à celui des délégations contraintes, mais la restriction est effectuée en spécifiant explicitement le compte ayant accès aux ressources.

Exploiter les délégations non contraintes

Les faiblesses induites par les délégations Kerberos non-contraintes sont connues depuis plusieurs années. Sean Metcalf a, par exemple, présenté les dangers de telles délégations à la Black Hat USA 2015. Dans la cinématique d’authentification présentée précédemment, il est en effet évident que le compte de service de l’application SharePoint peut, une fois que l’utilisateur lui a transmis un TGS contenant son TGT, accéder à l’ensemble des services pour lesquels l’utilisateur dispose de privilèges nécessaires.

L’objectif d’un attaquant est alors d’obtenir le TGT d’un administrateur du domaine, ce qui lui permet de se connecter au contrôleur de domaine avec les privilèges maximum pour changer le mot de passe du compte krbtgt afin de pouvoir forger ses propres tickets à la demande.

Pour parvenir à cela, il est d’abord nécessaire d’identifier les services qui disposent de délégations non contraintes. Pour cela, il suffit de filtrer les objets de l’Active Directory à la recherche de paramètres TrustedForDelegation valant True. Ce paramètre indique en effet la présence d’une délégation non contrainte, et est de plus accessible sans privilège particulier, par exemple à l’aide de la commande Get-ADComputer du module ActiveDirectory :

Une fois les services disposant d’une délégation Kerberos non contrainte identifiés, il est nécessaire d’obtenir des privilèges administrateur sur l’un des serveurs sur lesquels ils sont utilisés. Les méthodes de compromission classiques peuvent alors être utilisées, mais ne seront pas abordées dans cet article.

En cas d’accès au service par un administrateur du domaine, l’attaquant sera en mesure d’extraire le TGS fourni à l’aide par exemple de l’outil mimikatz et de la commande suivante :

Comme indiqué dans le scénario d’authentification, ce TGS contient le TGT de l’administrateur, que l’attaquant pourra extraire afin de réaliser une attaque Pass-The-Ticket pour se connecter au contrôleur de domaine.

Les recommandations pour protéger un domaine d’une telle attaque sont alors les suivantes :

• Utiliser des délégations Kerberos contraintes qui sont plus restrictives
• Configurer l’ensemble des comptes à privilèges avec le paramètre « Le compte est sensible et ne peut être délégué » qui empêche la réutilisation de l’identité du compte par une application possédant une délégation

Dans le cas d’un domaine au niveau fonctionnel supérieur à Windows Serveur 2012 R2, le groupe de sécurité « Utilisateurs protégés » peut être utilisé pour les comptes à privilèges étant donné que les délégations ne sont pas autorisées pour les comptes de ce groupe.

Qu’en est-il des délégations contraintes ?

L’utilisation de délégations contraintes semble être une alternative plus sécurisée. Cependant, différents éléments sont à noter concernant ce mécanisme d’authentification, comme l’a présenté Matan Hart lors de la Black Hat 2017. En effet, les deux extensions de protocole utilisées ont été pensées avec les principes suivants :

• Les deux extensions permettent à un service Kerberos d’obtenir des TGS sans même que l’utilisateur n’ait besoin de s’authentifier auprès du contrôleur de domaine.
• L’extension S4U2Self permet au service d’obtenir un TGS pour l’utilisateur sans qu’aucun mot de passe ne soit nécessaire.

De ce fait, un service qui possèderait les deux extensions pourrait obtenir un TGS pour n’importe quel autre service en se faisant passer pour un utilisateur, et ce sans nécessiter son mot de passe.

Matan Hart a publié son outil « Mystique[1] » qui permet d’identifier des configurations à risque pour les délégations. Pour cela, il liste les comptes qui disposent du paramètre TrustedToAuthForDelegation valant True, indiquant une délégation contrainte, ainsi que d’un paramètre MsDS-AllowedToDelegateTo non nul, indiquant l’utilisation d’un SPN, ce qui est obligatoire pour les comptes de délégation.

Il est également à noter que les TGS sont validés selon deux critères, le hash du mot de passe de l’utilisateur, et le SPN possédé par le compte de service qui possède la délégation contrainte. En cas de multiples SPNs associés à un même compte de service, et de mot de passe partagé entre différents comptes, les tickets pour deux services distincts seront complétement interchangeables, ce qui pourrait permettre à un service de réutiliser l’identité d’un utilisateur de manière illégitime.

Ces faiblesses ne sont pas considérées comme des vulnérabilités par Microsoft, et ne sont donc pas amenées à changer. Lors de la création d’une délégation Kerberos contrainte, il est alors nécessaire de faire attention aux points suivants pour se protéger des attaques :

• Configurer les services à l’aide de comptes de service dédiés, évitant ainsi le partage des comptes qui pourrait aboutir à des tickets interchangeables. Il est également important d’assurer une bonne complexité des mots de passe, ainsi qu’une rotation régulière.
• Configurer des SPNs uniques comme étant autorisés pour la délégation, en évitant les SPNs par défaut de Microsoft, et en spécifiant les ports utilisés.
• Comme pour les délégations non contraintes, configurer les comptes à privilèges comme étant des comptes sensibles ne pouvant être délégués.

Conclusion

L’utilisation de délégations contraintes n’est pas totalement à proscrire. Il est cependant nécessaire de bien maitriser leur configuration et les ressources auxquelles elles permettent d’accéder afin d’éviter les travers détaillés dans cet article.

Cet article Compromission d’un domaine Windows à l’aide des délégations Kerberos est apparu en premier sur RiskInsight.

Si la gestion de crise lors d’une attaque doit suivre les 4 principes clés évoqués dans notre précédent article, elle doit surtout en intégrer l’anticipation dans ses mécanismes.

Une stratégie à moyen terme basée sur l’anticipation des attaques ciblées

Dès aujourd’hui, il est nécessaire de refondre les processus de gestion de crise. Les scénarios de cybercriminalité doivent être inclus dans les procédures opérationnelles (modalités de réponse, SI spécialisé…). Les relations avec les autorités compétentes doivent être créées ou renforcées dans le but d’accélérer la phase de mobilisation de ces acteurs et de maîtriser les circuits de communication.

Une stratégie de communication claire doit être définie en fonction des acteurs évoluant dans et autour de l’organisation. Les obligations de demain (notification aux clients des fuites de données à caractère personnel…) doivent être anticipées afin de garantir le moment venu un respect des règlementations en vigueur. De ce fait, il ne sera plus possible de garder la confidentialité sur le fait qu’une crise est en cours.

Les attaques ciblées étant souvent constituées d’une somme d’incidents unitaires, il est nécessaire de revoir en parallèle les processus de gestion des incidents pour s’inscrire dans une démarche itérative, garantissant un état de veille constant, une rapidité d’intervention et une prise de recul.

À moyen terme, évaluer son attractivité et connaître ses actifs clés permettent de déterminer les informations attirantes pour des attaquants. Le secteur d’activité et le positionnement sur le marché sont des éléments déterminants. Au-delà de données internes, les relations entretenues avec certains partenaires et / ou clients peuvent augmenter l’attractivité du SI aux yeux d’attaquants. Cette évaluation doit s’inscrire dans une revue régulière des risques avec les métiers.

Enfin, il faut mettre en place des mesures avancées pour permettre une sécurisation renforcée des cibles identifiées avec les métiers en sanctuarisant les périmètres les plus sensibles (applications métiers clés, VIP / COMEX…) mais aussi les systèmes techniques clés (serveurs et postes d’administration, infrastructure à effet d’amplification comme la télédistribution ou l’Active Directory).

Des approches plus actives (demande de fermeture des sites utilisés pour l’exfiltration, honeypot …) peuvent être envisagées.

Complexifier l’attaque pour en diminuer sa rentabilité

Les attaques ciblées représentent un challenge pour les grandes organisations qui ne sont pas habituées à gérer ce type de crise silencieuse, à grande échelle, mêlant métier et SI et entraînant une perte de confiance dans ce dernier. Leur gestion nécessite de revoir les processus en place mais également de prévoir des actions pour rendre l’attaque plus difficile, faciliter leur détection et renforcer les capacités de réaction.

La mise en place de ces éléments permettra de complexifier les actions de l’attaquant et, à terme, de rendre l’attaque moins rentable ! C’est certainement une des clés de réponse face à ces nouvelles menaces.

Lire la première partie

Pour en savoir plus, lire le focus attaques ciblées, une refonte nécessaire de la gestion de crise.

Cet article Attaques ciblées : comment gérer le risque en amont ? est apparu en premier sur RiskInsight.

La cybercriminalité ne cesse de croître. Les cas concrets se multiplient.

Les retours d’expérience montrent la difficulté à gérer des crises d’un nouveau type. Ces attaques ciblées sont souvent des crises silencieuses qui atteignent directement la confidentialité des données sans remettre en cause le fonctionnement visible du SI. Ces crises sont difficiles à matérialiser, à traiter et finalement à clore de manière définitive.

Comment réagir à ces attaques ? Quelles démarches et organisations doit-on mettre en place pour se préparer au mieux ? Quelles actions de traitements doivent être mises en œuvre ?

Refondre les piliers de la gestion de crise

Une attaque ciblée n’est pas une crise SI mais bien une crise métier

En effet, si cette attaque a lieu c’est pour voler ou altérer des données métiers. Il est donc primordial d’impliquer les métiers et d’identifier les enjeux métiers actuels (contrats importants, fusion / acquisition, R&D…) afin d’anticiper les cibles de l’attaque et d’agir pro-activement. Dans le même esprit, et suivant les contextes, un support auprès d’entités étatiques peut également être recherché. Les équipes SI, malgré leur vigilance, ont un périmètre d’observation trop large pour être attentives sur tous les fronts. Identifier les cibles métiers majeures permettra de focaliser l’attention sur les périmètres sensibles.

Augmenter sa visibilité sur le système d’information

Pour analyser l’attaque et proposer des contre-mesures efficaces, il est nécessaire de détecter et de rapprocher les successions d’incidents unitaires et d’événements suspicieux. Pour cela la mobilisation des équipes d’experts « forensics » est essentielle. Ils seront à même de comprendre le fonctionnement des codes malicieux utilisés pour l’attaque et de pouvoir proposer des plans d’actions techniques pertinents. Ces ressources, encore trop rares aujourd’hui, devront être rapidement mobilisées.

L’utilisation d’outils pour capter les « signaux faibles » (analyses de journaux, sondes réseaux et détection d’intrusion) est également un vrai plus malheureusement encore peu généralisé. Notre retour d’expérience montre qu’il est possible de déployer rapidement ce type d’outil pendant une crise mais il nécessite un degré d’expertise fort pour être efficace.

S’astreindre à prendre du recul face à une multitude d’attaques silencieuses et trompeuses

Il est important de prendre régulièrement du recul, malgré la multitude d’évènements, pour comprendre la finalité de l’attaque, son évolution et définir le mode de réponse. La cellule de pilotage devra donc être séparée des opérations les plus « terrains » pour garder ce recul nécessaire.

Attention également à la logique de diversion, souvent mise en oeuvre par les attaquants (attaque en déni de services, sur d’autres serveurs peu critiques…). Il est conseillé dans ce genre de situation de rester focalisé sur les cibles potentielles définies avec les métiers et vigilants pendant les périodes d’inactivité de l’organisation (HNO, week-end, jours fériés).

Une limite souvent rencontrée dans une telle crise est la mobilisation de trop nombreux acteurs décisionnels au regard d’un faible nombre d’acteurs opérationnels en capacité à réaliser les actions. La longue durée d’une attaque (pouvant s’étaler sur plusieurs mois) nécessite la mise en place d’un rythme de gestion différent d’une crise classique. Une organisation adaptée doit être mise en place dans la durée, en prévoyant des rotations des acteurs impliqués.

Disposer d’un SI de crise parallèle et indépendant

L’expérience montre que les attaquants réussissent souvent à prendre le contrôle de l’Active Directory ou encore de la messagerie. Ils sont alors en mesure « d’écouter » les décisions prises par la cellule de crise et de les anticiper. Pour réagir efficacement durant la crise, il est donc crucial de disposer de postes de travail durcis hors des domaines d’administration classique et d’un service de messagerie spécifique. L’utilisation de services Cloud est possible. Attention cependant, les attaquants ayant pu également compromettre les messageries personnelles de tout ou partie des collaborateurs…

Admettre la perte de confiance dans le SI et la regagner

La découverte d’une intrusion majeure a souvent pour conséquence une perte de confiance en son SI vu le nombre et la criticité des serveurs compromis. Pour reprendre le contrôle de ceux-ci, il est souvent nécessaire de reconstruire des socles sains, et en particulier de réinstaller complètement l’Active Directory. À partir de ces socles sains, il sera alors possible de recréer progressivement des zones de confiance en privilégiant les fonctions les plus sensibles de l’organisation.

Les investissements liés à ces plans de reconstruction peuvent être très lourds (nos retours d’expérience montrent qu’ils dépassent fréquemment la dizaine de millions d’euros) et l’attention ne doit en aucun cas être relâchée dans ces zones assainies pour éviter une nouvelle attaque. Il faudra alors mettre en place tous les processus nécessaires pour garantir leur sécurité (administration sécurisée, analyse des journées, filtrage réseaux, gestion des accès fins…).

À suivre …

Cet article Attaques ciblées : une refonte nécessaire de la gestion de crise est apparu en premier sur RiskInsight.