Les 10 défauts de configuration Active Directory les plus exploités
Vous avez récemment mené un exercice de phishing visant à évaluer l’hygiène de sécurité de votre organisation et le niveau de sensibilisation de vos collaborateurs aux risques cyber.
Il est jeudi 17h30 et vous avez enfin le rapport en main. Les tests se sont déroulés pendant deux semaines sur l’ensemble de vos collaborateurs.
Vous pouvez être content du résultat, car vous constatez que les formations de sensibilisation fonctionnent. La plupart des utilisateurs ont signalé le mail malveillant au service informatique.
Cependant, un seul utilisateur a cliqué sur le lien malveillant, ce qui aurait pu mettre votre société en difficulté face à un véritable attaquant.
Dans une attaque réelle, un attaquant aurait pu accéder à votre système d’information. Mais une fois à l’intérieur, qu’aurait-il fait ? Quels sont les « quick hits » qu’un attaquant recherche pour aller plus loin et compromettre totalement un système d’information ? Quels sont les 10 défauts de configuration les plus courants que vous pourriez corriger pour complexifier la tâche d’un attaquant éventuel qui aurait réussi à accéder à votre réseau ?
Dans cet article, nous allons énumérer les principaux défauts de configuration que notre équipe de sécurité offensive rencontre le plus souvent lors des tests d’intrusion internes réalisés pour nos clients, ainsi que les mesures que vous pouvez mettre en place pour limiter l’exploitation de ces faiblesses.
Dans cet article :
Ajoutez un en-tête pour commencer à générer la table des matières
1. Le cloisonnement réseau
Que ce soit dans le cadre d’exercices de Red Teaming ou de tests d’intrusion internes, les auditeurs commencent systématiquement par collecter de l’information via des scans réseau afin d’identifier leur position et les ressources accessibles. Bien souvent, ils sont connectés à un VLAN dédié aux utilisateurs. Or, il arrive que la segmentation réseau soit incomplète ou ne reflète pas exactement ce que les administrateurs pensent avoir configuré. Résultat : tous ou une partie des utilisateurs du SI peuvent accéder à des ressources qu’ils ne devraient pas contacter, comme des interfaces d’administration de serveurs, des équipements réseau ou des serveurs de bases de données applicatives. Sans s’en rendre compte, cela augmente fortement la surface d’attaque.
Même si maintenir un cloisonnement réseau efficace est complexe dans un SI étendu, plusieurs mesures permettent de réduire fortement les risques. D’abord, il est nécessaire d’avoir une vision précise de l’ensemble des flux réseau du SI et de formaliser une matrice des flux claire, la plus détaillée possible, puis de l’appliquer fidèlement sur les équipements de cloisonnement (pare-feu). Ensuite, toute l’administration du SI doit être isolée dans un VLAN dédié, intégrant toutes les interfaces d’administration des différents équipements (serveurs, réseau, etc.). Idéalement, ce VLAN ne doit pas être routable depuis les autres VLAN.
Enfin, il est important de faire des revues régulières de la configuration pour s’assurer que ce qui est configuré sur les différents équipements de cloisonnement respecte bien la matrice.
2. La gestion des mots de passe
Un point récurrent dans les missions de notre équipe offensive est la récupération de mots de passe. Même si cela n’est pas toujours simple, récupérer des mots de passe, qu’il s’agisse de comptes utilisateurs ou de comptes de service, reste redoutablement efficace. Cela permet des mouvements latéraux, donnant accès à de nouveaux réseaux et équipements du SI, mais aussi des élévations de privilèges (mouvements verticaux) pour atteindre des ressources plus sensibles. Pour compliquer la tâche des attaquants, les organisations mettent en place des politiques de mot de passe limitant l’usage de mots de passe faibles. Mais une politique, à elle seule, n’est pas toujours suffisante. Dans plusieurs missions, nos auditeurs ont ainsi récupéré des comptes à cause de schémas de construction prévisibles lors de l’initialisation.
Par exemple, si une politique de mot de passe contraint un mot de passe à avoir au minimum 12 caractères, avec des majuscules, des minuscules, des chiffres et des caractères spéciaux, alors le mot de passe « WelcomeCorp2025! » est considéré comme robuste. Cependant, si un attaquant arrive à récupérer l’information sur la construction de ce mot de passe, peu importe le moyen (mot de passe en clair dans un share, cassage via un brute force…), à cause de la prédictibilité de sa construction, ce dernier pourrait en dériver une liste et tenter du « password spraying » sur les comptes du domaine pour voir si d’autres utilisateurs n’auraient pas conservé cette construction. Le password spraying consiste à tester un même mot de passe sur un grand nombre de comptes avec un faible volume de tentatives par compte, ce qui permet de rester sous les seuils de verrouillage et de contourner la politique de blocage.
Pour se prémunir de ce type d’attaque, il est impératif d’utiliser des mots de passe totalement aléatoires (ou des phrases de passe) lors de l’onboarding ou de la création de nouveaux comptes. De plus, la politique de mot de passe doit respecter les recommandations des autorités de sécurité (ICI pour la Suisse et ICI pour la France). Enfin, pour les organisations disposant d’un budget plus confortable, des solutions d’audit de mots de passe couplées à des wordlists personnalisées de mots de passe interdits permettent de réduire encore le risque de compromission.
Concernant les comptes d’administration, il est conseillé d’utiliser la solution LAPS de Microsoft qui gère automatiquement les mots de passe. Enfin, pour les comptes de services, il est recommandé de les remplacer par des gMSA. (Group Managed Service Account)
La complexité d’un mot de passe ne fait pas tout. Il est tout aussi important de le stocker de manière sécurisée. En effet, peu importe sa robustesse : si votre mot de passe est inscrit sur un morceau de papier visible sur votre bureau ou enregistré dans un fichier texte non protégé sur votre ordinateur, le risque qu’il soit récupéré reste le même. Il est donc essentiel, en plus d’utiliser un mot de passe aléatoire et robuste, de le conserver dans un emplacement sécurisé. Un gestionnaire de mots de passe est idéal pour cela : il permet de stocker l’ensemble de vos identifiants de manière chiffrée, et lui-même est protégé par un mot de passe maître qui doit être tout aussi solide.
3. La gestion des mises à jour
La gestion des mises à jour est l’un des points les plus complexes qu’il soit, qu’il s’agisse d’une PME de 30 utilisateurs ou d’une grande entreprise de 5 000 utilisateurs. Elle exige une connaissance précise de toutes les solutions du SI et un processus de gestion des correctifs efficace. En pratique, ce niveau de maturité est parfois atteint sur les postes de travail, mais plus rarement sur les serveurs et les applicatifs. Il n’est pas rare de rencontrer des serveurs encore sous d’anciens systèmes d’exploitation (Windows Server 2012, Windows Server 2008), avec des protocoles obsolètes (SMBv1). Ces environnements exposent des vulnérabilités connues, massivement documentées et donc plus faciles à exploiter aujourd’hui. Même sans aller jusqu’à ces cas extrêmes, des retards de plusieurs mois suffisent à exposer des serveurs à des CVE récentes activement exploitées (KEV), avec un risque de compromission élevé.
Pour limiter ces risques, il faut disposer d’une vision exhaustive des ressources du SI. Cela passe par des outils de management des serveurs et postes de travail, afin de connaître à tout moment les versions d’OS et les applications installées sur chaque machine. Cela passe également par des CMDB intégrées aux environnements DevSecOps, pour maintenir une cartographie claire des applicatifs et de leurs dépendances.
Une fois cet inventaire stabilisé, il est nécessaire de mettre en place une politique récurrente d’application des mises à jour (par exemple tous les 1 à 3 mois), avec un traitement accéléré pour les vulnérabilités de sévérité 7 ou plus, selon le niveau de risque accepté.
Dans certains cas particuliers, des serveurs ou des applicatifs ne peuvent pas être mis à jour du fait de leur fonctionnement au sein du SI. Alors, il est nécessaire de bien comprendre le risque associé et de mettre en place des sécurités périmétriques pour limiter la possible exploitation de ces éléments critiques (par exemple les isoler en les sortant de l’Active Directory, etc.).
4. Les protocoles de résolution de noms obsolètes
Depuis les débuts de l’utilisation d’Active Directory, il existe plusieurs protocoles de résolution de noms. Ces protocoles sont utilisés dès lors qu’une ressource est contactée sur le réseau pour connaître son IP. Cependant, ils ne sont pas tous utiles et certains exposent à des risques. Actuellement, dans tous les SI, si un utilisateur tente de se connecter à un serveur SMB distant, par exemple « \\smb.srv.tld\shares », une fois l’UNC (Universal Naming Convention) rentré dans l’Explorateur Windows, son poste de travail va tenter de résoudre le nom du serveur via une requête DNS pour tenter de trouver l’IP de la machine smb.srv.tld. Cependant, si le serveur DNS ne peut pas répondre car il n’a aucune entrée avec ce nom de serveur, automatiquement la machine va vérifier dans son fichier hosts en local et, en dernier recours, elle va basculer sur de plus anciens protocoles pour tenter de trouver l’IP de la ressource.
Le problème est que ces « anciens » protocoles, à savoir LLMNR, mDNS ou NBT-NS, sont des protocoles de broadcast/multicast, c’est-à-dire que, contrairement au DNS qui n’enverra des requêtes qu’au serveur DNS, ces protocoles vont tenter d’envoyer des requêtes à tout le monde sur le réseau pour tenter de résoudre le nom du serveur.
Le risque se situe ici : un attaquant qui répondrait volontairement à ce genre de requête, en se faisant passer pour le serveur, recevrait donc la tentative de connexion de l’utilisateur qui souhaitait accéder à « \\smb.srv.tld\shares ». Ainsi, il récupérerait les informations d’authentification chiffrées de l’utilisateur et pourrait essayer de casser, en local, ces informations pour récupérer le mot de passe de l’utilisateur. Si le mot de passe est trop robuste pour être cassé, cette méthode de coercition permet également de mener des attaques plus sophistiquées, comme des attaques par relais SMB (cf. 6) pour tenter d’accéder à d’autres informations et d’autres partages réseau.
La bonne pratique concernant ces protocoles est de les désactiver dans tout le SI. Ils ne doivent plus être utilisés et ne sont, a priori, plus utiles à notre époque. La désactivation de ces protocoles peut se faire au moyen de GPO poussées sur l’ensemble des machines du parc.
5. Les partages réseau
Dans un environnement Active Directory, les partages réseau font partie du cœur du fonctionnement du SI. Ils servent notamment aux serveurs pour accéder et appliquer les GPO (SYSVOL), ils permettent de stocker de façon centrale les fichiers et répertoires des utilisateurs, ils permettent également de faire de l’administration à distance. À cause de la présence importante des partages réseau, il peut être compliqué de gérer les droits d’accès de chaque utilisateur et ces répertoires peuvent élargir grandement la surface d’attaque.
Il est très courant de trouver, dans tous ces partages, des fichiers comme des scripts, des fichiers de configuration ou de simples fichiers textes, accessibles à tous en lecture et pouvant contenir des informations sensibles comme des identifiants et mots de passe, ou encore des données personnelles d’utilisateurs du SI ou de clients.
L’autre problème dans la gestion des droits est le droit d’écriture sur ces partages. Si un utilisateur malveillant a des droits d’écriture dans des répertoires largement utilisés, il pourrait piéger des binaires pour rajouter du code malveillant dedans, ou encore écrire des fichiers qui forceraient tous les utilisateurs qui accèdent à ce partage à se connecter sur une machine malveillante et ainsi pouvoir tenter des attaques par relais ou tenter de casser le mot de passe en local.
Même s’il est extrêmement complexe de gérer les droits pour tous ces partages réseau, il est important de sensibiliser les utilisateurs à ne pas mettre d’informations en clair dans les fichiers. Il est également important de faire une revue des droits de tous les partages pour s’assurer que seuls les utilisateurs qui en ont les droits et/ou le besoin puissent y accéder pour éviter à des utilisateurs l’accès à des données personnelles.
6. La signature SMB/LDAP
Comme évoqué dans le point précédent, les partages sont centraux au fonctionnement d’Active Directory. Le protocole pour accéder à ces partages est le protocole SMB (Server Message Block) et il est très largement utilisé. Lors de l’utilisation de ce protocole, les échanges entre le client et le serveur ne sont pas signés par défaut. Si un serveur accepte que le client ne signe pas ses messages SMB, alors il ne peut pas être en mesure de s’assurer que le message provient bien du client. C’est également le même problème pour le protocole LDAP (Lightweight Directory Access Protocol), qui est le protocole utilisé pour faire les requêtes sur l’ensemble des différents objets de l’annuaire Active Directory.
C’est ce problème qui permet de faire des attaques par relais. En effet, si un attaquant arrive à contraindre un utilisateur à se connecter sur la machine qu’il contrôle (cela peut être fait notamment par les biais évoqués précédemment, (cf. 4 et 5), alors il pourra, à l’aide d’outils, relayer la requête d’authentification sur un serveur qui ne vérifie pas la signature (SMB ou LDAP).
Ce dernier va alors proposer un challenge à résoudre au client. Ce challenge sera renvoyé au client par l’intermédiaire de l’attaquant. La réponse sera ensuite transmise au serveur, qui authentifiera alors la connexion relayée par l’attaquant. Le risque est relativement important, car, dans ce scénario, la coercition d’une machine n’est pas très complexe à mettre en place et permet à un attaquant, de façon transparente, d’accéder à des ressources du SI sans que le client ne se doute de rien. La bonne pratique est de forcer la signature de l’ensemble des communications SMB et LDAP pour l’ensemble du parc. Cela peut être fait via des GPO et poussé à tous les postes de travail ainsi que les serveurs.
7. Les listes de contrôle d’accès
Chaque objet dans un environnement Active Directory a, dans son Security Descriptor (structure de données propre à Windows), ce qu’on appelle une DACL (Discretionary Access Control List). Cette liste contient des entrées (ACE) donnant des droits sur ledit objet. Par exemple, si on regarde les droits du répertoire « C:\Windows », dans la liste, on doit, entre autres, trouver que le groupe Administrateur a les droits « Modify et Synchronize » alors que le groupe Utilisateur ne possède que les droits « ReadAndExecute et Synchronize ». Cela se traduit par le fait que les simples utilisateurs ne peuvent pas écrire dans ce répertoire alors que les administrateurs le peuvent.
Un autre point important à prendre en compte dans ces listes est la notion d’héritage qui permet de simplifier la configuration des ACL pour les différents objets. Si on reprend notre exemple, le répertoire « C:\Windows\System32 », qui est un sous-répertoire de Windows, va hériter des ACL (si elles sont marquées comme telles) configurées sur le répertoire parent. Cependant, dans un environnement riche et complexe en termes de groupes, d’utilisateurs ou d’objets, il peut être difficile de conserver une restriction des accès sur différents objets. Un exemple d’abus de mauvaise configuration d’une DACL est l’attaque « Shadow Credential ». Cette attaque intervient quand un attaquant arrive à compromettre un compte qui a des droits importants (GenericWrite ou GenericAll) sur l’objet LDAP msDs-KeyCredentialLink. Cet objet contient la clé publique d’un objet et peut être utilisé notamment pour s’authentifier grâce à la clé privée, souvent stockée localement. L’attaquant qui possède des droits sur l’objet peut donc générer un couple de clés et remplacer la clé publique stockée dans l’attribut « msDs-KeyCredentialLink » par sa propre clé publique, et ainsi utiliser la clé privée associée pour s’authentifier. Il est important de noter que cette attaque est un moyen de persistance très puissant, car même si le mot de passe est changé, l’authentification par certificat sera toujours possible.
Un autre exemple de mauvaise gestion des ACL est la possible récupération du compte Administrateur d’une machine configurée avec la solution LAPS (Local Administrator Password Solution). Dans certains cas, un utilisateur peut avoir des droits comme GenericAll ou AllExtendedRights sur une machine du SI. Ces droits permettent à un utilisateur de pouvoir lire le champ « ms-mcs-admpwd », contenant le mot de passe en clair du compte Administrateur local. Ce cas est également applicable pour les comptes de services de type gMSA avec l’attribut « msDS-ManagedPassword ».
Il n’y a pas vraiment de solution pour se prémunir de ce genre d’attaque. Pour limiter l’impact, il est important de factoriser les objets au sein du domaine et d’éviter de multiplier les groupes, unités d’organisation ou différents objets afin d’éviter le cas où un utilisateur aurait trop de droits sur un objet parce qu’il appartient à un groupe qui appartient à un groupe…
8. Le Kerberos Roasting
Kerberos est, depuis longtemps, un des deux protocoles d’authentification utilisés avec NTLM. Son fonctionnement est le suivant : lorsqu’un utilisateur cherche à se connecter, il va faire une requête au KDC (Key Distribution Center), qui est le serveur central dans l’architecture Kerberos (généralement, c’est un Domain Controller). Ce dernier va renvoyer ou non une clé de session qui authentifie l’utilisateur sur le réseau ainsi que le ticket d’authentification (TGT) contenant également la clé de session. Enfin, si ce dernier souhaite accéder à une ressource comme un partage réseau, il va faire la demande d’un ticket de service (TGS) à l’aide de son TGT et présenter le TGS au service en question, qui validera ou non si l’utilisateur a le droit d’accéder au service.
Cependant, ce fonctionnement comporte des points sensibles. Lors de la première requête au KDC, un utilisateur doit impérativement chiffrer la requête avec son secret. Sinon, un attaquant pourrait faire une demande de TGT (même vide) au nom d’un utilisateur, récupérer le TGT dans la réponse du KDC (ASREP Roasting), puis tenter de casser localement le mot de passe correspondant.
Un autre cas lié à Kerberos est l’utilisation de comptes avec un SPN. Le SPN (Service Principal Name) est un nom contenant souvent le nom et l’adresse IP du service et qui peut être utilisé lors de la demande d’un ticket de service. Cette demande de TGS peut être faite par n’importe quel utilisateur authentifié du domaine (Kerberoasting). Comme pour le TGT, le TGS contient des informations notamment chiffrées avec la clé du service. Ces informations peuvent donc être récupérées, et l’attaquant peut tenter de les casser localement.
Ces deux cas ne sont pas des vulnérabilités à proprement parler, étant donné que c’est le fonctionnement normal du protocole. Mais il est important de réduire la possibilité d’exploitation à travers ces « fonctionnalités ».
Pour le cas de l’ASREP Roasting, une option, active par défaut depuis Windows 2000, force la préauthentification Kerberos. Cette option doit être active pour tous les comptes du domaine et ne doit pas être retirée.
Concernant la possibilité de récupération d’informations chiffrées d’un compte avec un SPN, il faut limiter idéalement l’utilisation d’un SPN aux comptes de service ou de machine (car les mots de passe sont aléatoires et plus sécurisés), ou sinon s’assurer que le compte utilisateur a un mot de passe robuste.
9. Les certificats
Le rôle ADCS (Active Directory Certificate Services) permet d’installer une infrastructure de gestion de clés (PKI) dans un environnement Active Directory. Cependant, de nombreuses mauvaises configurations existent (ESCx), du simple mouvement latéral à l’élévation de privilèges sur le domaine. Un exemple d’attaque possible (ESC1) apparaît lorsqu’un modèle peut fournir des certificats utilisables pour l’authentification, sans validation managériale. De plus, si le certificat généré via ce modèle permet au client de choisir le Subject Alternative Name (SAN) alors il y a un problème. Même si ces prérequis semblent nombreux, ils sont loin d’être rares. Lorsqu’ils sont réunis, n’importe quel utilisateur peut demander un certificat au nom d’un administrateur de domaine et s’authentifier en son nom.
Un autre problème que l’on peut rencontrer avec les modèles de certificats (ESC4) survient lorsque les utilisateurs ont trop de droits (c’est-à-dire soit Owner, soit des droits d’écriture sur le groupe « owner » ou sur les propriétés du modèle, ou encore des droits d’écriture sur la DACL associée). Dans ce cas, l’utilisateur qui a ces droits pourra modifier le modèle et retomber dans le scénario d’attaque précédent (ESC1).
Un autre cas régulièrement rencontré lors des missions de notre équipe offensive est l’exploitation d’une attaque par relais sur l’interface web d’enrôlement de certificats. Par défaut, cette interface écoute sur le port HTTP (80) et permet d’enrôler des certificats. Donc, si un attaquant est en mesure de contraindre, via les différents moyens évoqués précédemment, un utilisateur et de relayer ces informations sur l’URL http://adcs.srv.tld/certsrv/certfnsh.asp, alors il pourra récupérer un certificat au nom de l’utilisateur et s’authentifier avec.
Dans cette section, nous n’avons donné que 3 exemples d’abus liés aux modèles de certificats, mais il en existe plus (15 à l’écriture de cet article). Il est important de vérifier précisément les droits sur les différents modèles, de limiter au maximum les usages d’authentification associés et de restreindre l’accès à l’interface web via HTTP. Hors environnements complexes, il est rarement nécessaire de disposer de plus de 2 ou 3 modèles de certificats.
10. Les trusts Active Directory
Dans la plupart des petites sociétés, Active Directory repose sur une forêt avec un seul domaine. Prenons l’exemple d’une société CyberSecure avec une forêt contenant uniquement le domaine « cybersecure.local ». Si cette société ouvre des locaux dans un autre pays, elle peut créer un domaine enfant (par exemple uk.cybersecure.local) pour exercer un contrôle plus granulaire sur sa filiale. De plus, si cette société est infogérée par un tiers, elle peut accorder des droits aux utilisateurs de la forêt de son partenaire « partenaire.infogerant.local ». Tous ces sous-domaines/forêts sont reliés via des relations de confiance ( « trusts » ).
Il peut exister des trusts unidirectionnels (entrant ou sortant) ou bidirectionnels (deux trusts unidirectionnels) entre les différents domaines/forêts. Pour les trusts unidirectionnels, le sens des accès est opposé au sens du trust. Dans notre exemple, si seule la société partenaire doit accéder au domaine « cybersecure.local », sans réciprocité, alors on parle d’un trust unidirectionnel « sortant » (outbound trust) vers le domaine « partenaire.infogerant.local ».
Par défaut, les trusts intra-forêt de type tree root et parent/child (sous-domaines) sont bidirectionnels et transitifs. Dans notre exemple, un utilisateur du sous-domaine uk.cybersecure.local pourrait donc s’authentifier et accéder à des ressources du domaine cybersecure.local.
Sachant cela, si une vulnérabilité permet à un simple utilisateur du domaine « uk.cybersecure.local » d’élever ses privilèges et de passer Domain Admin, alors le domaine parent « cybersecure.local » sera également compromis, mais pas le domaine distant « partenaire.infogerant.local ».
De plus, si un jour le domaine « partenaire.infogerant.local » est compromis et qu’un attaquant arrive à compromettre ce domaine, grâce aux trusts et à la transitivité, l’attaquant pourrait se déplacer dans les domaines « cybersecure.local » et « uk.cybersecure.local ».
Il est important de retenir qu’un domaine n’est pas une « security boundary » : au sein d’une même forêt, les administrateurs d’un domaine ne peuvent pas empêcher des administrateurs malveillants d’un autre domaine d’accéder aux données de leur domaine. Ce n’est en revanche pas le cas au niveau des forêts.
Quand les failles s’enchaînent
Pris unitairement, ces différents cas d’usage ne permettent que rarement de compromettre complètement un système d’information. Le risque devient réellement important lorsque plusieurs problèmes de sécurité existent et qu’ils peuvent être chaînés afin de construire des attaques plus complexes.
Par exemple, un attaquant, après l’envoi d’un e‑mail de phishing, pourrait commencer par effectuer un scan réseau et constater qu’il a accès à des partages réseau sur lesquel il parvient à récupérer un compte. Malheureusement, ce compte lui permet de se connecter à un serveur qui, contrairement à ce que pensent les équipes IT, reste accessible depuis les VLAN utilisateurs, et ce serveur n’est pas à jour. Une fois connecté, l’attaquant réussit à élever ses privilèges via une vulnérabilité et à obtenir un compte Administrateur du domaine. Grâce à ce compte, il pourrait ensuite rebondir vers d’autres domaines interconnectés et causer encore plus de dommages.
Vous ne pouviez pas savoir qu’un tel enchaînement d’actions était possible à partir d’un simple exercice de phishing. Désormais, vous savez quelles mesures peuvent être mises en place pour limiter les actions d’un attaquant sur le réseau, et il suffit souvent de corriger un point précis pour empêcher toute une chaîne d’attaque de se développer.
Et si vous testiez réellement votre environnement ?
Identifier les mauvaises configurations est une première étape. Encore faut-il savoir si elles peuvent réellement être exploitées et jusqu’où un attaquant pourrait aller.
Notre équipe sécurité accompagne les organisations dans l’identification de leurs chemins d’attaque grâce à des tests d’intrusion (pentests) adaptés à leur environnement. L’objectif : mettre en évidence les vulnérabilités exploitables, mesurer leur impact et vous aider à renforcer durablement votre niveau de sécurité.
Vous souhaitez évaluer la sécurité de votre Active Directory et identifier vos principaux chemins d’attaque ?
Échangez avec notre équipe sécurité !
Plus d’information à ce sujet ?
Nous sommes à votre disposition !