Active Directory and Entra ID (formerly known as Azure AD) have their own password policies to prevent users from using weak and insecure passwords. While these policies can be combined, the level of protection achieved through this approach is still limited.
Dans cet article, nous allons nous intéresser à une mauvaise pratique encore très présente au sein des équipes d'administration et des annuaires Active Directory : le stockage de mots de passe dans l'attribut "description" des objets utilisateurs.
Nous allons voir en quoi cette pratique est dangereuse pour le domaine et pourquoi son existence et ses impacts sont souvent méconnus. Également, nous nous intéresserons de façon très pratique à la manière dont attaquants et défenseurs peuvent détecter et exploiter cette faille au sein d'un Active Directory.
Enfin, nous verrons quelles sont les bonnes pratiques et les difficultés de détection, aussi bien lors de l'introduction de la vulnérabilité dans l'Active Directory que lors de son exploitation par un attaquant.
II. Mot de passe dans l'attribut description : quels risques ?
Lorsque l'on administre un système d'information et un domaine, nous avons accès à des outils, interfaces et serveurs auquel personne d'autres n'a accès dans l'entreprise. Ainsi, il est aisé de croire que nous seul avons accès aux différentes informations que nous manipulons : ce n'est pas tout à fait vrai.
Au sein de l'Active Directory, tous les objets ont de nombreux attributs, techniques et métier. Le "dn", "sAMAccountName", les attributs relatifs aux groupes, aux mots de passe, etc. L'attribut "description" en fait partie, il s'agit d'un simple champ texte permettant d'indiquer des informations sur l'objet créé :
Exemple de description d'un objet utilisateur dans l'Active Directory.
Plutôt pratique lorsque l'on souhaite, par exemple, se rappeler pour quel service ce compte a été créé, quel est le nom complet du propriétaire lorsque l'on crée des objets non nominatifs ("XR-23-OP"), etc.
Lorsque l'on combine ces deux constats, les administrateurs peuvent penser que la description peut aussi permettre de stocker les mots de passe des comptes dont ils ne se serviront pas tous les jours ou que plusieurs membres de l'équipe sont susceptibles de manipuler (comptes "communs" ou de services par exemple). Dès lors, quoi de plus pratique que d'établir une convention implicite : "si tu cherches le mot de passe de ce compte, il est dans sa description AD" ?
Cependant, il est souvent oublié que la quasi-totalité des attributs de tous les objets sont lisibles par tous les comptes authentifiés de l'Active Directory (utilisateurs, ordinateurs, etc.). C'est ainsi que fonctionne l'Active Directory et il en va de son bon fonctionnement. Si vous avez déjà parcouru mon cours sur BloodHound, vous verrez que cela permet d'aller très loin dans la découverte d'un domaine et même d'y découvrir des chemins d'attaque complets.
Pour l'attribut "description" par exemple, il pourrait très bien être utilisé par une application de tchat interne se reposant sur l'annuaire pour afficher la description de l'utilisateur avec lequel vous discutez. Il faut donc bien que cet attribut soit accessible en lecture.
Cette mauvaise pratique, très commune d'après mon expérience en tant qu'auditeur cybersécurité et pentester, est souvent exploitée par les attaquants ayant déjà un accès authentifié au domaine afin de compromettre rapidement d'autres comptes. Ce type d'attaque dispose même d'un TTP dans le framework MITRE ATT&CK, qui référence les principales techniques d'attaque (T1552 - Unsecured Credentials) :
TTP T1552 du framework MITRE ATT&CK
III. Point de vue de l'attaquant
A. Depuis Linux
À présent, nous allons voir comment un attaquant disposant d'un accès authentifié au domaine (mode opératoire "boite grise"), peut récupérer les descriptions des objets utilisateurs du domaine depuis un poste Linux. De nombreux outils offensifs ont été développés, notamment en Python et bash, pour les OS Linux.
Utilisation de ldapsearch
L'outil le plus simple pour commencer est bien sur "ldapsearch", un client plutôt classique et légitime pour discuter avec le service LDAP :
Ici, nous obtenons rapidement toutes les descriptions de tous les utilisateurs C'est un début (plutôt verbeux), cherchons maintenant des mots de passe.
D'après mon expérience, certains caractères sont spécifiques à la présence de mots de passe et rarement présents dans des descriptions textuelles simples, c'est notamment le cas du ":" et du "=". C'est aussi le cas de certains mots comme "mdp", "pass" ou "mot de passe".
Nous pouvons ajouter des filtres, bien que ce soit quelque peu fastidieux via "ldapsearch" :
Nous utilisons ici le module "user-desc" de "netexec", celui-ci va tout d'abord nous ressortir toutes les descriptions des objets utilisateurs contenant le mot de "pass".
Utilisation de netexec pour extraire les descriptions des objets utilisateurs.
Comme vous pouvez le voir dans la dernière ligne de la sortie, "netexec" va également sauvegarder toutes les descriptions des utilisateurs dans un fichier de log, dans lequel nous pourrons faire nos propres recherches, exemple :
Récupération d'un mot de passe dans le fichier de log créé par "netexec".
Utilisation de Cypher
Enfin, si vous avez utilisé "SharpHound.exe" pour extraire les données de l'Active Directory et que vous les avez importées dans BloodHound, voici une requête "Cypher" à utiliser dans la base "Neo4j" pour avoir une recherche équivalente à celles faites précédemment :
MATCH (u:User) WHERE u.description CONTAINS "=" OR u.description CONTAINS ":" OR u.description CONTAINS "mdp" OR u.description CONTAINS "pass" OR u.description CONTAINS "mot de passe" RETURN u.samaccountname,u.description
Voici un exemple de résultat obtenu :
Recherche et visualisation des mots de passe dans l'attribut "description" depuis neo4j.
Si vous souhaitez apprendre à utiliser BloodHound, n'hésitez pas à consulter mon cours sur le sujet :
Nous allons à présent voir comment récupérer ces informations en tant qu'attaquant sur un poste Windows, intégré ou non au domaine : la différence n'est pas très importante lorsque l'on dispose d'un compte de domaine valide.
Utilisons pour cela "PowerView" de la suite PowerSploit, un ensemble de scripts PowerShell offensifs (un peu l'équivalent de la librairie "impacket" sous Linux) :
Nous venons de voir que sous Linux comme sous Windows, la récupération des descriptions des objets de l'Active Directory est triviale et même réalisable avec des outils natifs et non "offensifs" ("ldapsearch"). Il faut également savoir que si votre Active Directory est affecté par certaines mauvaises configurations, ces informations peuvent aussi être récupérées sans authentification, par exemple, en cas d'accès anonyme autorisé au service LDAP de l'Active Directory.
IV. Point de vue du défenseur
A. Identifier les mots de passe dans les descriptions
Si vous êtes en charge de l'administration du domaine et avez accès au contrôleur de domaine. La première bonne pratique est déjà de constater si des mots de passe sont présents dans la description de vos objets. Vous pouvez ouvrir la console "Utilisateurs et ordinateurs Active Directory" et trouver la description des objets dans l'affichage central :
VIsualisation des attributs descriptsion des objets d'un OU sur le contrôleur de domaine.
Pour trouver et modifier la description d'un objet, il faut faire un clic droit "Propriétés" sur l'objet en question, puis se rendre sur "Général" :
Accès à l'attribut "description" d'un objet utilisateur au sein de l'Active Directory.
Vous pouvez faire la même opération en PowerShell avec la cmdlet "Get-ADUser", issue du module "Active Directory". Une première requête va nous afficher toutes les descriptions utilisateurs non vides :
Application de filtres de recherche sur le contenu des descriptions utilisateur avec "get-ADUser".
Il s'agit là déjà d'une bonne base de recherche. Si vous souhaitez aller plus loin et être sûr qu'aucun mot de passe n'est présent, il faudra parcourir les données affichées manuellement.
Nous nous limitons aux utilisateurs ici, mais cela vaut peut-être également le coup de chercher dans les descriptions d'autres types d'objets ? Également, maintenant que vous avez ces quelques commandes sous la main, pourquoi ne pas planifier un contrôle régulier du contenu des attributs "description" des objets de l'Active Directory ? Afin de mettre en place cette sécurisation dans la durée.
B. Correctif et bonnes pratiques de sécurité
Nous allons à présent voir comment corriger cette faiblesse si vous la découvrez sur votre domaine. Dans un premier temps, il convient de savoir s'il est légitime de stocker ce mot de passe, doit-il être utilisé par plusieurs personnes (cas d'un compte de service) ? Si c'est le cas, il est recommandé de stocker ce mot de passe dans un coffre-fort numérique, partagé avec votre équipe si besoin est. Ensuite, la correction en elle-même est plutôt simple : Modifier la description.
Via l'interface graphique, il suffit de faire un clic droit "Propriétés" et de modifié la valeur de l'attribut "description", tel que montré plus haut :
Modification de la description d'un utilisateur.
Il est également possible de le faire via PowerShell, en utilisant la CmdLet "Set-ADUser" du module "Active Directory" :
Set-ADUser Topdesk -Description $null
Vous pourrez immédiatement contrôler le résultat de "Set-ADUser" avec la CmdLet "Get-ADUser" :
Modification via "Set-ADUser", puis contrôle de la description d'un utilisateur en PowerShell.
Pour être très pointilleux, vous pouvez même remplacer le contenu de la description par "Description supprimée par XXX le XX/XX/XXXX". Ainsi, il n'y aura pas de mauvaise surprise pour votre collègue qui a l'habitude de récupérer ce mot de passe à cet endroit, et il pourra venir vous demander où est ce fameux mot de passe à présent :).
Évoquons à présent les bonnes pratiques concernant le stockage des mots de passe :
Les mots de passe ne doivent jamais être stockés de manière non sécurisée (chiffrée) et sur des supports, physiques ou numériques, accessibles à tous (même chiffrés).
Lorsque le besoin de partager des mots de passe est présent (cas pour un compte de service, susceptibles d'être géré par plusieurs personnes), il est recommandé d'utiliser des coffres-forts de mots de passe. KeePass est une bonne option, mais peut être limité en ce qui concerne le partage d'information, son usage est d'ordinaire plutôt personnel. Des solutions existent pour le partage de mot de passe, on peut notamment citer le projet Bitwarden qui permet de gérer les permissions et journaliser les accès aux mots de passe (vous pouvez auto-héberger Bitwarden).
Lorsqu'il s'agit de mots de passe de compte utilisateur (dans le sens utilisateur humain du système d'information) : l'administrateur n'a pas à le connaitre, ce mot de passe n'a donc rien à faire dans un attribut quel qu'il soit.
La bonne pratique d'assignation des mots de passe utilisateur consiste à paramétrer un mot de passe (aléatoire et différent à chaque utilisateur) à un compte, et de cocher la case "L'utilisateur doit changer ce mot de passe à la prochaine ouverture de session". L'utilisateur pourra alors paramétrer un mot de passe qui lui est propre ensuite.
Activation de l'option imposant à l'utilisateur de changer son mot de passe à la première connexion.
Si le besoin d'invoquer un argument d'autorité se fait sentir, nous pouvons toujours rappeler la directive n°11 du guide d'hygiène informatique de l'ANSSI :
Directive n°11 du guide d'hygiène de l'ANSSI sur la protection des mots de passe.
Il est également recommandé de changer les mots de passe des comptes concernés. En effet, les mots de passe ayant été exposés "publiquement" par le passé, n'importe qui peut les avoir récupérés et donc continuer de les utiliser. Sans parler de la présence de cette information dans d'éventuels backups de la base NTDS, export des données de l'AD (BloodHound, PingCastle), etc.
Enfin, il convient également sensibiliser et former les administrateurs aux bonnes pratiques de sécurité et risques liés au stockage non sécurisé des mots de passe :
Identifiant de la remédiation dans le framework MITRE ATT&CK : M1017 - User Training
Directive n°1 du guide d'hygiène de l'ANSSI : Former les équipes opérationnelles à la sécurité des systèmes d’information
Les simulations de cyberattaques, telles que les tests d'intrusion ou les opérations Red Team, offrent également une opportunité de mettre en lumière de manière très factuelle les mauvaises pratiques en matière de sécurité. Elles permettent de mesurer concrètement l'impact de ces pratiques sur la sécurité du système d'information et, par extension, sur la résilience de l'entreprise. Cela permet aussi parfois de bousculer certaines certitudes en incitant à une ouverture d'esprit et à une révision des positions figées.
C. Possibilité de détection de l'attaque
Nous allons à présent nous intéresser aux possibilités de détection de l'exploitation de cette vulnérabilité ou de son introduction au sein de l'Active Directory via les journaux d'évènements. Concernant la détection, et sur un Active Directory disposant des règles d'audit par défaut, les choses se compliquent quelque peu.
Pour étudier les évènements produits lors de la récupération des descriptions, j'effectue 10 fois de suite une récupération de la description des 2500 utilisateurs de mon Active Directory depuis un poste Linux, histoire de générer un beau volume de requêtes :
Exécution d'une boucle de 10 itérations récupérant la description des utilisateurs de l'Active Directory.
Voici le volume de logs produits durant le temps de l'attaque, que je visualise dans ElasticSearch :
Vue d'ensemble des journaux d'évènements générés durant l'opération.
59 évènements, ce qui est plutôt faible au regard du nombre d'éléments récupérés et en sachant que mon Active Directory est dans un lab vide, et non dans un vrai SI avec de l'activité. Si j'interroge ELK sur les top évènements générés, voici ce qu'il en ressort :
Pour faire simple : aucun évènement n'est journalisé mis à part l'ouverture et la fermeture d'une session. Autrement dit, cette opération passe totalement inaperçue.
Autre point potentiellement intéressant, nous pouvons tenter de voir si les journaux d'évènement peuvent nous aider à détecter l'introduction de la vulnérabilité sur le domaine par un administrateur. Autrement dit, pouvons-nous avoir un évènement/une alerte lorsqu'un utilisateur est créé ou modifié avec une description contenant des caractères/mots caractéristiques d'un mot de passe ?
Lors de la création d'un utilisateur, l'eventID 4720 A user account was created est journalisé, voici son contenu (vue ElasticSearch) :
Contenu de l'event 4720 suite à la création d'un nouvel utilisateur.
Lors de la modification d'un utilisateur existant et de l'insertion d'un mot de passe dans sa description, l'eventID 4738 A user account was changed est journalisé, voici son contenu (vue ElasticSearch):
Contenu de l'event 4738 suite à la modification de la description d'un utilisateur existant.
Vous ne voyez pas l'attribut description ? C'est normal, il n'est pas journalisé. Autrement dit, nous sommes à nouveau dans le noir et il est impossible de mettre en place une règle de détection basée sur le contenu du champ "description".
Nous venons de voir que l'objectif de détection parait difficile à atteindre, tant lors d'une "exploitation" (récupération des attributs) et que lors de l'introduction de la vulnérabilité sur le domaine. La seule option qu'il nous reste est donc la réalisation d'audits réguliers, manuels ou scriptés, permettant de chercher des mots de passe dans l'attribut "description" des utilisateurs.
Pour répondre à ce besoin, je vous propose un script PowerShell qui peut être utilisé dans le cadre d'une tâche planifiée déclenchée par un évènement 4738 :
Ce script va, lors de sa première exécution, créer une "archive" : un fichier XML contenant les GUID des utilisateurs et le hash de leur description. Lors des exécutions suivantes, les utilisateurs et descriptions seront récupérés auprès de l'Active Directory, comparés à l'archive créée précédemment et les différences de hash découverts (donc, une modification de la description) entrainerons une journalisation du login utilisateur ainsi que de sa description.
Si l'utilisateur n'existait pas dans l'archive précédente (cas d'une création), sa description sera journalisée également. Enfin, une nouvelle archive sera créée et remplacera la précédente, prête pour la prochaine analyse. Le script créera un évènement ID 1000 dans le journal "Application" :
Journalisation d'une description modifiée dans un évènement 10000.
Voici par exemple une requête KQL (pour ElasticSearch) permettant de chercher quelques mots de clés dans les "event.code 10000" :
event.code:10000 and (winlog.event_data.param2: *pass* or winlog.event_data.param2: *mot de passe* or winlog.event_data.param2: *pwd*)
Et enfin un exemple de détection d'un mot de passe dans une description grâce aux évènements créés par ce script dans ElasticSearch :
Détection d'un mot de passe dans une description via ELK et d'un event.code 10000.
Identifiant de la remédiation dans le framework MITRE ATT&CK : M1047 - Audit
Si vous connaissez d'autres options, eventID ou moyens de détection concernant cette faiblesse et son exploitation, n'hésitez pas à le signaler dans les commentaires de cet article !
V. Conclusion
Nous avons dans cet article fait le tour de la question concernant la présence de mots de passe dans l'attribut "description" des utilisateurs du domaine. Nous avons notamment vu pourquoi cette faiblesse pouvait être présente sur un domaine, comment elle pouvait être exploitée et corrigée. Également, nous avons vu que la détection de l'attaque en question n'est pas aisée, contrairement au contrôle de sa présence au sein de l'Active Directory. Cela va donc dans le sens d'un contrôle régulier de cet attribut et de la sensibilisation des administrateurs sur les bonnes pratiques de stockage des mots de passe.
N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !
Dans ce tutoriel, nous allons avoir comment configurer l'authentification LDAP de GLPI pour pouvoir se connecter à l'application GLPI à partir des comptes utilisateurs présents dans un annuaire Active Directory. Ainsi, un utilisateur pourra accéder à GLPI à l'aide de son nom d'utilisateur et son mot de passe habituel (puisque ce seront les informations de son compte dans l'Active Directory).
GLPI propose nativement un modèle d'authentification LDAP, ce qui lui permet de s'appuyer sur un annuaire de comptes externe, comme l'Active Directory de Microsoft. Il faut savoir que les comptes utilisateurs de l'Active Directory seront importés dans la base de données de GLPI, grâce à un processus de synchronisation. Lorsqu'un utilisateur Active Directory se connecte pour la première fois, son compte est créé dans GLPI. Avant cela, il n'est pas visible, sauf si vous décidez d'effectuer un "import en masse" des comptes AD dans GLPI.
Avant de passer à la configuration, voici quelques informations sur l'environnement utilisé.
Pour cette démonstration, le domaine Active Directory "it-connect.local" sera utilisé et le contrôleur de domaine SRV-ADDS-02 sera utilisé. Ce serveur dispose de l'adresse IP "10.10.100.11" et la connexion sera effectuée en LDAP, sur le port par défaut (389).
- Le compte utilisateur qui sera utilisé comme "connecteur" pour permettre à GLPI de se connecter à l'Active Directory se nomme "Sync_GLPI". Il est stocké dans l'unité d'organisation "Connecteurs" de l'annuaire (voir image ci-dessous). Il s'agit d'un compte utilisateur standard, sans aucun droit particulier sur l'annuaire Active Directory. Faites-moi plaisir : n'utilisez pas de compte Administrateur.
- Tous les utilisateurs qui doivent pouvoir se connecter à GLPI à l'aide de leur compte Active Directory sont stockés dans l'unité d'organisation "Personnel" visible ci-dessous. Elle correspond à ce que l'on appelle la "Base DN" vis-à-vis du connecteur LDAP de GLPI. Les autres utilisateurs ne pourront pas se connecter. En fait, ce n'est pas utile de mettre la racine du domaine comme base DN : essayez de restreindre autant que possible pour limiter la découverte de l'annuaire Active Directory au strict nécessaire.
- Les utilisateurs de l'Active Directory pourront se connecter à GLPI à l'aide de leur identifiant correspondant à l'attribut "UserPrincipalName" (mis en évidence, en jaune, sur l'image ci-dessous). Cet identifiant, sous la forme "identifiant + nom de domaine", leur permettra se connecter à GLPI avec un identifiant qui correspond à leur e-mail. L'alternative consisterait à utiliser l'attribut "SamAccountName" (soit l'identifiant sous la forme "DOMAINE\identifiant").
Voilà, maintenant, nous allons pouvoir dérouler la configuration !
II. Installer l'extension LDAP de PHP
L'extension LDAP de PHP doit être installée sur votre serveur pour que GLPI soit capable de communiquer avec votre serveur contrôleur de domaine Active Directory (ou tout autre annuaire LDAP).
Connectez-vous à votre serveur GLPI et exécutez les deux commandes suivantes pour mettre à jour le cache des paquets et procéder à l'installation de l'extension.
sudo apt-get update
sudo apt-get install php-ldap
Cette extension sera installée et activée dans la foulée. Vous n'avez pas besoin de relancer le serveur.
III. Ajouter un annuaire LDAP dans GLPI
Désormais, nous allons ajouter notre annuaire Active Directory à GLPI. Connectez-vous à GLPI avec un compte administrateur, puis dans le menu "Configuration", cliquez sur "Authentification".
Au centre de l'écran, cliquez sur "Annuaire LDAP".
Puis, cliquez sur le bouton "Ajouter".
Un formulaire s'affiche à l'écran. Comment le renseigner ? À quoi correspondent tous ces champs ? C'est que nous allons voir ensemble.
Nom : le nom de cet annuaire LDAP, vous pouvez utiliser un nom convivial, ce n'est pas obligatoirement le nom du domaine, ni le nom du serveur.
Serveur par défaut : faut-il s'appuyer sur ce serveur par défaut pour l'authentification LDAP ? Il ne peut y avoir qu'un seul serveur LDAP défini par défaut.
Actif : nous allons indiquer "Oui", sinon ce sera déclaré, mais non utilisé.
Serveur : adresse IP du contrôleur de domaine à interroger. Avec le nom DNS, cela ne semble pas fonctionner (malheureusement).
Port : 389, qui est le port par défaut du protocole LDAP. Si vous utilisez TLS, il faudra le préciser à postériori, dans l'onglet "Informations avancées", du nouveau serveur LDAP.
Filtre de connexion : requête LDAP pour rechercher les objets dans l'annuaire Active Directory. Généralement, nous faisons en sorte de récupérer les objets utilisateurs ("objectClass=user") en prenant uniquement les utilisateurs actifs (via un filtre sur l'attribut UserAccountControl).
BaseDN : où faut-il se positionner dans l'annuaire pour rechercher les utilisateurs ? Ce n'est pas nécessaire la racine du domaine, tout dépend comment est organisé votre annuaire et où se situent les utilisateurs qui doivent pouvoir se connecter. Il faut indiquer le DistinguishedName de l'OU.
Utiliser bind : à positionner sur "Oui" pour du LDAP classique (sans TLS)
DN du compte : le nom du compte à utiliser pour se connecter à l'Active Directory. En principe, vous ne pouvez pas utiliser de connexion anonyme ! Ici, il ne faut pas indiquer uniquement le nom du compte, mais la valeur de son attribut DistinguishedName.
Mot de passe du compte : le mot de passe du compte renseigné ci-dessus
Champ de l'identifiant : dans l'Active Directory, quel attribut doit être utilisé comme identifiant de connexion pour le futur compte GLPI ? Généralement, UserPrincipalName ou SamAccountName, selon vos besoins.
Champ de synchronisation : GLPI a besoin d'un champ sur lequel s'appuyer pour synchroniser les objets. Ici, nous allons utiliser l'objectGuid de façon à avoir une valeur unique pour chaque utilisateur. Ainsi, si un utilisateur est modifié dans l'Active Directory, GLPI pourra se repérer grâce à cet attribut qui lui n'évoluera pas (sauf si le compte est supprimé puis recréé dans l'AD).
Ci-dessous, la configuration utilisée pour cette démonstration et qui correspond à la "configuration cible" évoquée précédemment.
Nom : Active Directory - it-connect.local
Serveur par défaut : Oui
Actif : Oui
Serveur : 10.10.100.11
Port : 389
Filtre de connexion : (&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
BaseDN : OU=Personnel,DC=it-connect,DC=local
Utiliser bind : Oui
DN du compte : CN=Sync_GLPI,OU=Connecteurs,OU=Tiering,OU=IT,DC=it-connect,DC=local
Mot de passe du compte : Mot de passe du compte "Sync_GLPI"
Champ de l'identifiant : userprincipalname
Champ de synchronisation : objectguid
Quand votre configuration est prête, cliquez sur "Ajouter".
Dans la foulée, GLPI va effectuer un test de connexion LDAP et vous indiquer s'il est parvenu, ou non, à se connecter à votre annuaire. Si ce n'est pas le cas (comme moi, la première fois), cliquez sur le nom de votre annuaire, vérifiez la configuration, puis retournez dans "Tester" sur la gauche afin de lancer un nouveau test. Pour ma part, le problème venait du champ "Serveur" : j'avais mis le nom DNS du serveur à la place de l'adresse IP, mais cela ne fonctionnait pas. Pourtant, mon serveur GLPI parvient bien à résoudre le nom DNS.
Par ailleurs, vous pouvez explorer les différents onglets : Utilisateurs, Groupes, Réplicats, etc... Pour affiner la configuration. L'onglet "Utilisateurs" est intéressant pour configurer le mappage entre les champs d'une fiche utilisateur dans GLPI et les attributs d'un compte dans l'Active Directory. Quant à l'onglet "Réplicats", vous pouvez l'utiliser pour déclarer un ou plusieurs contrôleurs de domaine "de secours" à contacter si le serveur principal n'est plus joignable.
IV. Tester la connexion Active Directory
Si GLPI valide la connexion à votre annuaire Active Directory, vous pouvez tenter de vous authentifier à l'application avec un compte utilisateur. Pour ma part, c'est l'utilisateur Guy Mauve qui va servir de cobaye. Son login GLPI sera donc "[email protected]" puisque je m'appuie sur l'attribut UserPrincipalName. Pour le mot de passe, je dois indiquer celui de son compte Active Directory.
Remarque : la source d'authentification doit être l'Active Directory.
Voilà, l'authentification fonctionne ! L'utilisateur a pu se connecter avec son compte Active Directory et il hérite du rôle "Self-service".
Dans le même temps, à partir du compte admin de GLPI, je peux remarquer la présence d'un nouveau compte utilisateur dont l'identifiant est "[email protected]" ! GLPI a également récupéré le nom, le prénom et l'adresse e-mail à partir de différents attributs de l'objet LDAP.
V. Forcer une synchronisation Active Directory
A partir de GLPI, vous pouvez forcer une synchronisation LDAP de façon à mettre à jour les comptes dans GLPI "liés" à des comptes Active Directory, mais aussi pour importer en masse tous les comptes des utilisateurs Active Directory. Ceci vous évite d'attendre la première connexion et vous permet de préparer le compte : attribution du bon rôle, etc.
Cliquez sur "Administration" dans le menu, puis "Utilisateurs". Ici, vous avez accès au bouton "Liaison annuaire LDAP".
Vous avez ensuite le choix entre deux actions différentes, selon vos besoins.
Si vous cliquez sur "Importation de nouveaux utilisateurs", vous pourrez importer en masse les comptes dans l'Active Directory. Il vous suffit de lancer une recherche, de sélectionner les comptes à importer et de lancer l'import grâce au bouton "Actions".
Remarque : vous pouvez aussi importer des groupes Active Directory. Pour cela, suivez la même procédure, mais en allant dans "Groupes" sous "Administration".
VI. Conclusion
En suivant ce tutoriel, vous devriez être en mesure d'importer les comptes utilisateurs d'un annuaire Active Directory dans GLPI, pour faciliter la connexion de vos utilisateurs. Sachez que si un utilisateur change son mot de passe dans l'Active Directory, ce n'est pas un problème : GLPI vérifie les informations lors de la connexion.
Dans cet article, nous allons comprendre, exploiter et corriger une vulnérabilité fréquente sur les environnements Active Directory : ASREPRoast.
Ce nom ne vous dit peut-être rien, mais il s'agit d'un défaut de configuration fréquent dans l'Active Directory. L'attaque ASREPRoast permet à un attaquant situé sur un réseau d'entreprise possédant un domaine de compromettre rapidement un compte utilisateur, et ainsi de passer d'un mode opératoire boite noire (attaque sans identifiants valides, juste une connexion au réseau) à un mode boite grise (attaque depuis un compte valide sur le domaine). Le passage d'un mode boite noire à boite grise change en général la donne de façon très importante lors d'une cyberattaque, car l'accès authentifié au domaine permet d'en extraire beaucoup d'informations.
L'objectif de cet article est de vous expliquer en détail cette vulnérabilité. Nous allons notamment voir comment elle peut être introduite sur un Active Directory, comment un attaquant peut l'exploiter et comment un défenseur peut l'identifier et la corriger.
C'est parti !
II. Qu'est-ce que l'attaque ASREPRoast ?
A. Dans les grandes lignes
Commençons par essayer de comprendre le nom de l'attaque. "ASREP" fait référence au message "KRB-AS-REP" du service Kerberos lors d'une authentification (réponse à un message KRB-AS-REQ, une requête d'authentification Kerberos). "Roast" renvoi simplement au mot "rôtir" ou "cuisiner" car l'on devra ensuite travailler un peu sur la donnée obtenue pour pouvoir l'utiliser.
Au sein d'un domaine, l'authentification Kerberos est assurée par le composant Key Distribution Center (KDC) des contrôleurs de domaine. Lorsqu'un utilisateur souhaite accéder à un service ou à une ressource réseau, il doit d'abord obtenir un Ticket Granting Ticket (TGT) auprès du KDC. Pour cela, l'utilisateur envoie une requête de type "KRB-AS-REQ" (Kerberos Authentication Service Request) au KDC, elle contient notamment des informations d'identification de l'utilisateur et une clé liée à son mot de passe.
Le KDC vérifie alors les informations d'identification fournies par l'utilisateur. Si celles-ci sont correctes et que l'utilisateur existe dans le domaine, le KDC lui délivre un TGT. Ce TGT est ensuite utilisé par l'utilisateur pour obtenir des tickets de session (TGS) auprès des services du domaine, lui permettant d'accéder à ceux-ci sans avoir à fournir à nouveau ses informations d'identification. Ce processus s'appelle pre-authentification.
Schéma d'une authentification Kerberos et de l'émission d'un TGT.
Cependant, il existe une configuration spécifique représentée par un attribut sur les comptes utilisateurs appelé "Do not require Kerberos preauthentication". Cet attribut autorise l'envoi d'un TGT pour un compte sans que le demandeur n'ait prouvé son identité au préalable.
Schéma de l'émission d'un TGT pour un utilisteur ayant l'attribut "Do not require Kerberos preauthentication".
En conséquence, n'importe qui sur le réseau peut obtenir un TGT représentant ce compte utilisateur et tenter d'usurper son identité. Il est important de noter que le TGT obtenu ne peut être utilisé que si la personne qui le détient connaît le mot de passe du compte associé. Cependant, en cas d'utilisation d'un mot de passe faible, le contenu du TGT peut être utilisé pour retrouver le mot de passe du compte utilisateur.
Le TGT ne contient pas directement le mot de passe de l'utilisateur. Mais, il contient des informations chiffrées grâce au secret de l'utilisateur, qui sont utilisés pour prouver l'identité de l'utilisateur lorsqu'il demande des tickets de session ultérieurs. Ainsi, des "traces" du mot de passe s'y trouve, ce qui permet de tenter de casser le TGT pour retrouver le mot de passe en clair.
Regardons à présent dans le détail ce qu'il se passe lors d'une authentification via Kerberos. Pour cela, j'ai effectué une capture réseau des échanges dans différents cas de figures.
AS-REQ pour un login inexistant
Lorsqu'un utilisateur souhaite s'authentifier auprès du service Kerberos, le client envoi dans un premier temps un message de demande d'authentification ("KRB-AS-REQ"), voici à quoi il ressemble sur une capture réseau (cliquez sur l'image pour zoomer) :
"AS-REQ" suivi d'une erreur "ERR_C_PRINCIPAL_UNKNOWN".
Dans le cas d'une demande d'authentification avec un login incorrect, c'est-à-dire qui n'existe pas dans l'Active Directory, le service Kerberos renvoi un message de type "KRB-ERROR : C-PRINCIPAL-UNKNOWN" en réponse à l'AS-REQ" du client. Le message est clair : l'utilisateur "MMARTIN1" n'existe pas dans l'Active Directory.
AS-REQ pour un login existant avec pré-authentification
Si le login est correct, le service renvoi une réponse de type "KRB-ERROR : PREAUTH REQUIRED". Cette réponse du service Kerberos indique que pour obtenir un TGT pour cet utilisateur, il faut au préalable s'authentifier, ce qui est plutôt une bonne nouvelle d'un point de vue sécurité. Rappelons que les TGT sont des tickets qui permettent de demander des TGS (Ticket Granting Service) pour accéder à un service au nom de l'utilisateur présenté dans le ticket. Il est donc préférable de prouver son identité (s'authentifier) au préalable.
À noter que cette différence de comportement dans la réponse du service ("PRINCIPAL_UNKNOWN "ou "PREAUTH REQUIRED") permet une énumération des utilisateurs basée sur un dictionnaire. Sans même connaitre le mot de passe associé à un compte, on peut savoir s'il existe dans l'annuaire, car le service Kerberos nous indiquera clairement cette information dans sa réponse.
Voici à quoi rassemble une réponse "PREAUTH_REQUIRED". Suite à cette réponse, notre client s'authentifie envoyant un message "AS-REQ", encore ? (cliquez sur l'image pour zoomer) :
Réponse "ERR_PREAUTH_REQUIRED" indiquant que le compte utilisateur existe dans l'annuaire.
Ce second message "AS-REQ" contient cependant un nouvel item, il s'agit d'une donnée chiffrée à l'aide d'une clé liée au mot de passe utilisateur. Si le service Kerberos parvient à déchiffrer ce message avec le mot de passe de l'utilisateur (qu'il possède de son côté grâce à l'annuaire et sa base NTDS.DIT) alors, il aura la preuve qu'il s'agit du bon mot de passe, et donc du vrai utilisateur. Tout cela sans que le mot de passe n'ait transité en clair sur le réseau. Pour plus de détails, sachez que la donnée chiffrée est un timestamp : c'est-à-dire la date et l'heure actuelle dans un format précis (notez le "pA-ENC-TIMESTAMP" dans la seconde AS-REQ).
Enfin, si les identifiants sont corrects, le service envoi un message de réponse "AS-REP" contenant notamment un TGT, qui permet de demander ensuite des TGS (cliquez sur l'image pour zoomer) à différents services :
Transmission d'un TGT par le service Keberos suite à une authentification réussie.
Voilà à quoi ressemble une authentification "classique" via Kerberos en vue d'obtenir un TGT.
AS-REQ pour un login existant sans pré-authentification
Cependant, Microsoft a ajouté un attribut aux objets utilisateur qui permet d'autoriser le service Kerberos à fournir un TGT à quiconque le demande, sans authentification : l'attribut "Do not require Kerberos preauthentication". Dans ce cas, un attaquant peut demander un TGT pour un tel compte sans avoir besoin de fournir de preuve d'identité valide. Voilà alors ce qu'il se passe (cliquez sur l'image pour zoomer) :
Obtention d'un TGT sans authentification préalable pour un utilisateur ayant l'attribut "No preauthentication required".
Une "AS-REQ", demandant un TGT pour l'utilisateur "RDUBOIS", puis une "AS-REP" du KDC délivrant TGT, le tout sans preuve d'identité (authentification). N'importe qui peut donc usurper l'identité de l'utilisateur "RDUBOIS" en demandant un TGT à son nom, puis utiliser ce TGT pour demander des TGS aux services du domaine et y accéder.
Pour être plus précis, rappelons que le TGT obtenu dans les messages "AS-REP" est chiffré et ne peut être utilisé sans connaître le mot de passe du compte utilisateur. Cependant, étant donné qu'il est chiffré avec un dérivé du mot de passe utilisateur, l'attaquant pourra tenter de casser ce mot de passe en Offline (localement, sans interactions supplémentaires avec le KDC ou le domaine), pour retrouver le mot de passe de l'utilisateur.
En résumé, quand cet attribut est présent sur un compte utilisateur, n'importe qui peut obtenir une donnée (le TGT) qui utilise un dérivé du mot de passe du compte utilisateur, et donc tenter de retrouver le mot de passe en clair. Même en étant confiant sur l'algorithme de chiffrement et la robustesse du mot de passe utilisé, reconnaissons qu'il est plutôt périlleux de fournir ce genre d'informations à un simple visiteur non authentifié sur notre système d'information.
J'espère que cette vue en détail des échanges Kerberos vous aura permis de mieux comprendre le fonctionnement de l'attaque ASREPRoast.
C. Pourquoi cet attribut ?
Certaines applications ne prennent pas en charge la pré-authentification Kerberos, il est ainsi courant de trouver des utilisateurs avec la pré-authentification Kerberos désactivée, permettant ainsi aux attaquants de demander des TGT pour ces utilisateurs. C'est la raison principale de l'existence de ce paramètre d'après la documentation Microsoft. La pré-authentification Kerberos peut également être désactivée pour d'autres raisons liées à des besoins spécifiques de sécurité ou de compatibilité avec d'autres systèmes.
Dans la réalité, il n'est pas rare de trouver de tels comptes, notamment sur des systèmes d'information qui ont un certain historique...
III. Configuration d'un Lab vulnérable
Attention, dans ce chapitre, nous allons configurer de manière volontaire un Lab vulnérable pour vous exposer le but et le fonctionnement de l'attaque.
NE PAS REPRODUIRE SUR UN ENVIRONNEMENT DE PRODUCTION.
Dans mon Lab de démonstration, j'ouvre la console "Utilisateurs et ordinateurs Active Directory", puis je sélectionne un de mes utilisateurs, ici l'utilisateur "RDUBOIS". Il faut ensuite faire un clic droit "Propriétés" sur cet objet et se rendre dans "Compte" :
Configuration de l'attribut "Do not require Kerberos preauthentication" sur un compte utilisateur.
Dans les "Options de compte", il faut trouver et cocher "La pré-authentification Kerberos n'est pas nécessaire" comme sur l'image ci-dessus.
Si vous vous souvenez des explications précédentes, l'attaque ASREPROAST est d'autant plus dangereuse si le mot de passe utilisé est faible, pour avoir un cas d'école, nous allons paramétrer le mot de passe de l'utilisateur "RDUBOIS" à "#1p@ssword" (ce n'est pas un mot de passe faible ? Vous allez voir que si ). Il faut à nouveau faire un clic droit sur l'objet puis "Réinitialiser le mot de passe" :
Paramétrage d'un mot de passe faible sur le compte utilisateur.
Vous l'aurez compris, pour effectuer une attaque ASREPRoast, il faut un login utilisateur à tester, voire plusieurs. Dans un premier temps, l'attaquant doit donc se constituer une liste de login (dictionnaire) qu'il soumettra ensuite au service Kerberos.
Dans le cas où l'attaquant n'est pas authentifié sur le domaine (boite noire) :
Si l'attaquant n'a pas de compte sur l'Active Directory, il peut utiliser différentes méthodes pour récupérer des logins valides. L'OSINT (Open Source Intelligence) est une méthode assez commune puisqu'avec quelques requêtes Google ou recherches Linkedin, on peut assez facilement retrouver une liste de personnes travaillant dans une entreprise. La recherche dans des fuites de données, basée sur le nom de l'entreprise ou l'adresse mail, est aussi fréquente.
Depuis l'intérieur du réseau (toujours sans compte valide sur le domaine), il existe un grand nombre de techniques également. Les imprimantes sont mon moyen favori, souvent mal protégées avec des interfaces d'administration exposées et verbeuses, elles stockent des carnets d'adresses qui exposent souvent des logins utilisateur. Les applications web internes, services SNMP, SMB et RPC mal configurés (authentification anonyme) ou même l'interception réseau sont également très efficaces.
Également, il est possible pour l'attaquant d'utiliser des dictionnaires pré-conçus utilisant des couples prénom-noms communs, voir des noms de comptes techniques comme "svc-ldap", "backup", "formation", "accueil", etc. Les dictionnaires que j'utilise souvent sont publics et fonctionnent en général très bien, bien qu'utilisant majoritairement des noms anglophones : https://github.com/insidetrust/statistically-likely-usernames.
Avec toutes ces méthodes, il est souvent très facile de se constituer une liste bien fournie de logins utilisateur potentiels. Il faut enfin savoir les formater grâce à la nomenclature actuelle de l'Active Directory ciblé : est-ce "marc.martin", marc_martin, "m.martin", "mmartin" ? etc.
Dans le cas où l'attaquant est authentifié sur le domaine (boite grise) :
Si l'attaquant possède déjà un compte sur le domaine, rien de plus facile. Une simple requête LDAP permettra de récupérer la totalité des logins utilisateur de l'annuaire, il aura alors une liste exhaustive des comptes à cibler, augmentant ses chances d'en trouver un avec l'attribut "Do not require Kerberos preauthentication".
Depuis Linux, une requête "ldapsearch" fera l'affaire :
J'utilise ici la commande "ldapsearch" pour récupérer les attributs "sAMAccountName" des utilisateurs du domaine, puis la commande "grep" pour isoler les lignes qui m'intéressent et enfin "cut" pour isoler uniquement le login de l'utilisateur. Si vous peinez à comprendre cette commande, n'hésitez pas à la décomposer dans votre environnement et à exécuter les commandes une à une. Le tout est enregistré dans le fichier "/tmp/userlist". Voici un exemple du résultat attendu :
Extraction des utilisateurs de l'Active Directory avec un compte valide sur le domaine via "ldapsearch".
Je me retrouve donc avec une liste de 1000 logins utilisateur valides dans le fichier "/tmp/userlist".
L'outil BloodHound va également récupérer la liste des utilisateurs pour les stocker dans un fichier JSON, qui pourra facilement être parcouru pour en extraire les logins. Je vous oriente sur mon cours sur BloodHound si vous souhaitez en savoir plus : Identifiez les faiblesses de votre Active Directory avec Bloodhound
Une fois cette liste, hypothétique, partielle ou complète à disposition, l'attaquant va pouvoir interroger sur le service Kerberos du domaine afin de voir si :
L'utilisateur existe dans l'annuaire;
Il dispose de l'attribut "Do not require Kerberos preauthentication".
B. Exploiter ASREPRoast depuis Linux
Depuis Linux, une multitude d'outils offensifs existent pour effectuer cette attaque. Je vais ici vous présenter les outils les plus classiques : "impacket" et "netexec".
Impacket est une bibliothèque Python utilisée pour interagir avec des protocoles de réseau tels que SMB, LDAP et Kerberos. Elle offre des outils pour la manipulation de paquets réseau, la création de serveurs et de clients pour ces protocoles, ainsi que des fonctionnalités avancées pour l'analyse et l'exploitation de vulnérabilités. Impacket est très largement utilisé pour les opérations offensives et de nombreux outils utilisent cette librairie.
En plus d'être une librairie très puissante, les créateurs d'Impacket fournissent des scripts qui l'utilisent afin d'automatiser certaines opérations et attaques, comme ASREPRoast. Je ne peux pas détailler ici la procédure d'installation de "Impacket" et de ses "examples scripts", je vous renvoie pour cela à la documentation officielle : Github - Impacket.
ASREPRoast en boite noire
Nous allons notamment utiliser le script "impacket-GetNPUsers" ("NP" pour "NoPreauth"). Dans le cas où nous sommes en boite noire, nous avons au préalable construit notre dictionnaire à partir de différentes sources. Nous pouvons utiliser ce dictionnaire pour réaliser une attaque ASREPRoast. Ici,"192.168.56.102" est l'adresse IP de mon contrôleur de domaine, qui héberge le service Kerberos (KDC)) :
Si l'on dispose d'un accès authentifié au domaine, encore mieux, "impacket-GetNPUsers" peut automatiser à la fois la récupération des utilisateurs dans la base LDAP, et l'envoi d'un "AS-REQ" en leur nom pour voir s'ils sont vulnérables à l'ASREPRoast :
Même principe pour "netexec", il suffira de spécifier l'utilisateur ("-u") et son mot de passe de ("-p") pour s'authentifier auprès du service LDAP afin de récupérer la liste des utilisateurs :
Voici le résultat attendu pour "impacket-GetNPUsers" et "netexec" :
Utilisation de "impacket-gtNPUsers" et "netexec" pour la réalisation d'une attaque ASREPRoast authentifiée.
On voit donc que plusieurs logins sont tentés sur le service Kerberos et que, pour certains, un hash au format "$krb5asrep$23$" est obtenu. Il s'agit d'une donnée extraite du TGT obtenu pour chaque utilisateur vulnérable, spécialement formaté pour être interprété par des outils de cassage de mot de passe.
Maintenant que nous avons ces hashs, nous pouvons tenter de les casser, par exemple, à l'aide de "JohnTheRipper" ou "hashcat" et de listes de mots de passe communs comme le dictionnaire de mot de passe "rockyou.txt" :
hashcat -m 18200 -a 0 ASREProastables.txt rockyou.txt
john --wordlist=rockyou.txt ASREProastables.txt
Ce cassage s'effectue totalement en local, sans interactions avec l'Active Directory ou le service Kerberos. Ainsi, aucune détection n'est possible. Également, l'utilisateur a ici tout son temps et la rapidité de l'opération dépendra de la robustesse du mot de passe et des ressources de calcul qu'il a à disposition. Si des mots de passe faibles ont été utilisés par les comptes utilisateurs vulnérables, ils seront retrouvés par ces outils :
Cassage du hash "krb5asrep" extrait du TGT de l'utilisateur obtenu via ASREPRoast.
Si les mots de passe sont très robustes, alors il faudra déployer des moyens considérables pour les casser. Ici, le mot de passe semble plutôt correct avec 3 alphabets et une longueur de 10 caractères, mais il se trouve dans le dictionnaire public et très connu "rockyou.txt". Nous venons de retrouver le mot de passe d'un utilisateur de l'Active Directory par l'intermédiaire d'un TGT signé grâce à un dérivé de son mot de passe par le service Kerberos.
C. Exploiter ASREPRoast depuis Windows
Sous Windows, l'outil le plus classique pour effectuer cette attaque est "Rubeus.exe", écrit en C#. Le plus simple est de l'exécuter sur une machine intégrée au domaine ou via un "runas.exe" :
Utilisation de "Rubeus.exe" pour la réalisation d'une attaque ASREPRoast.
Comme pour les outils Linux, le fichier "hashes.asreproast" contiendra les hashs contenus dans les TGT récupérés et pourra être passé à "hashcat" ou "JohnTheRipper" pour cassage.
V. Point de vue du défenseur
A. Lister les comptes utilisateurs avec preauth-notreq
Nous allons maintenant adopter le point de vue du défenseur ou blue team qui souhaite savoir si des utilisateurs vulnérables à ASREPROAST sont présents sur son domaine.
Lorsque nous sommes sur notre propre domaine et contrôleur de domaine, le plus simple est d'utiliser le module PowerShell "ActiveDirectory" qui permet de communiquer avec ADSI (Active Directory Services Interface). Nous pouvons notamment cibler l'attribut "useraccountcontrol" pour extraire les utilisateurs disposant de l'attribut "Do not require Kerberos preauthentication", exemple :
Nous avons la même liste utilisateur qu'obtenue via notre requête "ldapsearch" bien entendu, avec un filtre sur ceux qui ont déjà l'attribut "Do not require Kerberos authentication", mais nous utilisons ici des outils légitimes et plus accessibles pour les administrateurs système. J'ai notamment ajouté le "DN" et l'attribut "Enabled" en sortie de la commande (via le "Format-Table" ou "ft").
B. Corriger les comptes vulnérables
Une fois cette liste à disposition, il convient tout d'abord de déterminer :
Pourquoi ils sont/ont été utilisés, pour quels besoins, services et systèmes ?
Est-ce ce qu'ils sont toujours utilisés aujourd'hui ? (date de dernière authentification, dernier changement de mot de passe, journaux d'évènements)
Est-ce que l'attribut "Do not require Kerberos authentication" est vraiment utile et répond à un besoin fonctionnel ?
Une fois que ces questions ont toutes une réponse claire pour chaque compte, la décision de désactiver cet attribut peut être prise.
Corriger ASREPRoast via l'interface graphique
Depuis la console "Utilisateurs et ordinateurs Active Directory", effectuez un clic droit sur le compte utilisateur concerné, puis "Propriétés. Il faut ensuite se rendre dans "Compte" et localiser l'option suivante :
Désactivation de l'attribut "Do not require Kerberos preauthentication" sur l'Active Directory.
Une fois décochée, nous pouvons appliquer nos changements. La modification prend effet immédiatement.
Corriger ASPREPRoast via Powershell
Il est aussi possible de modifier la valeur de cet attribut en PowerShell via ADSI. Le cmdlet "Set-ADAccountControl" est fournie par le module PowerShell "ActiveDirectory" :
À nouveau, la modification est prise en compte immédiatement.
Mesure complémentaire en cas de besoin fonctionnel
Si l'attribut "Do not require Kerberos preauthentication" est nécessaire et répond à un besoin identifié et justifié, alors il convient de mettre un mot de passe très, très robuste à ce compte. L'idée est que même si un TGT est récupéré, l'attaquant ne puisse pas casser le hash qu'il contient en vue de récupérer le mot de passe en clair de l'utilisateur. Optez donc pour un mot de passe à plus de 30 caractères.
Dans l'idéal, il est également nécessaire de prévoir un renouvellement périodique de ces mots de passe afin de réduire leur exposition dans le temps. Si l'attaquant dispose de tout le temps disponible devant lui pour casser le hash contenu dans le TGT, alors il finira peut-être par y arriver (peut-être au bout de plusieurs années). Mais si le mot de passe du compte est changé tous les six mois, il n'aura potentiellement pas le temps de l'exploiter une fois qu'il l'aura cassé. Il s'agit d'une mesure de sécurité supplémentaire.
Limiter la propagation suite à une compromission
Il convient également de s'assurer que le compte qui dispose légitimement de l'attribut "Dot not require Kerberos preauthentication" possède des droits limités sur le domaine et le système d'information. La revue des ACL, appartenances aux groupes et l'application du principe de moindre privilège (configuration fine et minimaliste des droits pour répondre uniquement aux fonctions métiers) permettra de limiter au maximum les actions possibles de l'attaquant en cas de compromission du compte.
Changement de mot de passe
Enfin, il est à noter que si le compte a eu jusque-là cet attribut, n'importe quel utilisateur de votre domaine a peut être déjà récupéré un TGT et obtenu son mot de passe, ou est en train de tenter de le casser. Ces mesures de correction doivent donc s'accompagner d'un changement de mot de passe afin qu'un attaquant exploitant ou ayant exploité cette faiblesse ne puisse pas réutiliser le mot de passe compromis pour ce compte, ce qui sera possible même si l'attribut en question a été décoché.
C. Détecter une attaque ASREPRoast
Du point de vue du défenseur, nous allons également nous intéresser aux possibilités de détection d'une attaque ASREPRoast passée ou en cours sur le système d'information.
Détection via les journaux d'évènements
L'exploitation de l'ASREPRoast génère, comme toute interaction avec l'Active Directory, des évènements. Cependant, il n'est pas aisé de les distinguer clairement des activités légitimes et quotidiennes des utilisateurs du domaine. Il faut savoir que lorsqu'un "AS-REQ" est effectué sur un compte non vulnérable à l'ASREPRoast (et donc, échoue), aucun évènement de sécurité n'est généré. Seule l'émission d'un ticket Kerberos génère un évènement avec l'eventID 4768.
L'event ID 4768 est enregistré sur le contrôleur de domaine chaque fois qu'un TGT est émis. Il indique que le KDC a reçu une demande de TGT (AS-REQ) et qu'il a émis un TGT en réponse. L'évènement journalisé contient alors quelques détails intéressants sur la demande.
La requête est émise avec une authentification valide, auquel cas un TGT est émis en réponse à l'"AS-REQ".
La requête porte sur un utilisateur ayant l'attribut "Do not require Kerberos authentication", auquel cas pas besoin d'authentification, le TGT est tout de même émis en réponse à l'"AS-REQ".
Voici l'évènement tel qu'il apparaitra dans l'observateur d'évènement lors d'une demande de TGT classique, avec authentification (utilisation ici de "impacket-getTGT") :
EventID 4768 suite à une demande et émission de TGT classique, avec authentification.
On voit clairement qu'un TGT a été demandé et émis pour l'utilisateur "IT-CONNECT\mmartin" par le client "192.168.56.104". Nous allons également garder dans un coin de notre mémoire les informations relatives au "Type de pré-authentification" et "Type de chiffrement du ticket". Je réalise maintenant la même opération à destination du compte "IT-CONNECT\rdubois" et avec un outil offensif qui va directement demander un TGT sans authentification préalable (utilisation de "netexec") :
EventID 4768 suite à une demande et émission de TGT à la suite d'une attaque ASREPROast via "netexec".
Les informations journalisées sont globalement les mêmes lors d'une demande et émission d'un TGT sur un compte ne nécessitant pas la pré-authentification. Cependant, on peut noter deux exceptions (à noter que le résultat est le même lors d'une exploitation avec "impacket-getNPUsers") :
Le "Type de chiffrement du ticket" est passé à "0x17" au lieu de "0x12".
Le "Type de pré-authentification" est passé à "0" au lieu de "2".
L'utilisation d'un chiffrement à "0x17" (RC4-HMAC) est un comportement typique des outils d'attaque qui downgrade (abaissent) le niveau de chiffrement utilisé pour le chiffrement du TGT afin de rendre le cassage de son contenu plus aisé. Par défaut, le niveau de chiffrement "0x12" entraine l'utilisation du AES256-CTS-HMAC-SHA1-96 (Source : 4768(S, F): A Kerberos authentication ticket (TGT) was requested). Voilà un premier élément caractéristique d'une attaque ASREPRoast avec des méthodes et outils classiques.
Egalement, la documentation Microsoft est limpide concernant les valeurs du "Type de pré-authentification" :
La demande de TGT avec une valeur "0" à "Type de pré-authentification" est donc également un signal intéressant à surveiller. Pour finir sur cette détection, je vous propose une requête KQL (pour ELK) qui permet d'identifier les événements de demande/émission d'un TGT avec un chiffrement faible (RC4) ou sans pré-authentification :
event.code:4768 AND (winlog.event_data.TicketEncryptionType: 0x17 OR winlog.event_data.PreAuthType: 0)
Pour détailler un peu la requête. Il s'agit d'un filtre sur les évènements Windows ayant un évènement ID 4768 et qui ont, soit un "TicketEncryptionType" à "0x17" (RC4), soit un "PreAuthType" à "0". Voici le résultat sur l'ELK de mon lab (avec moins d'activité qu'un vrai SI, bien sûr) :
Visualisation dans ELK des évèenemtn caractértistique d'une attaque ASREPRoast
Pas de doute, il y a eu une activité suspecte sur mon SI entre 17h45 et 18h15, des TGT sans pre-authentification et avec un algorithme de chiffrement faible ont été demandés.
Surveiller les modifications des attributs utilisateurs
Pour aller plus loin, vous pouvez également chercher et surveiller les event ID 4738 (A user account was changed) et 5136 (A directory service object was modified) qui apparaissent lorsqu'un attribut utilisateur est modifié :
Journalisation de la modification d'un attribut utilisateur via l'eventID 4738.
Plutôt que la compromission, vous visualiserez alors tous les évènements d'activation/désactivation de l'attribut concerné sur des comptes utilisateurs, ce qui permettra de retrouver le moment où la vulnérabilité a été introduite sur le compte concerné. Là aussi, il faudra aller plus loin pour réellement identifier le nom de l'attribut modifié et s'assurer de n'obtenir que les alertes relatives à l'attribut "Do not require Kerberos preauthentication". Egalement, voici un exemple de requête filtre KQL pour cet évènement :
event.code:4738 AND winlog.event_data.UserAccountControl:*2096*
Voici l'aperçu d'un tel évènement dans la console ElasticSearch :
Visualisation de l'eventID 4738 relatif à l'ajout de l'attribut "Do not requiere kebreroas pre-authentication" dans ElasticSearch.
Utilisation d'un honey account
Si vous maitrisez correctement la sécurité de votre système d'information, notamment avec un SIEM et un SOC (Security Operation Center) efficaces, alors vous pouvez envisager la mise en place d'un honey account, ou "compte pot de miel". L'idée est de créer un compte utilisateur volontairement vulnérable à ASREPRoast afin que sa compromission génère un évènement de sécurité activement surveillé par la blue team.
Pour cela, il faut notamment être sûr que ce compte ne sera jamais utilisé de façon légitime par un utilisateur ou un service du SI. Ainsi, si une demande de TGT pour ce compte spécifique apparait dans les journaux d'évènement, ce sera forcément dû à une attaque ASREPRoast en cours.
Attention : La création et la gestion d'un compte pot de miel nécessitent une attention particulière. Il faut s'assurer que les politiques de sécurité et les procédures de surveillance sont bien établies pour garantir que le compte reste contrôlé et qu'il ne devienne pas une vulnérabilité supplémentaire. Il faut notamment s'assurer que l'honey account ait un mot de passe très robuste afin que le hash contenu dans son TGT ne soit jamais cassé, ce qui permettrait à l'attaquant d'obtenir un compte valide sur le domaine.
VI. Conclusion
J'espère que cet article vous a plu et que vous avez maintenant une meilleure idée des risques liés à cette attaque et de la façon de s'en protéger. J'ai essayé de faire en sorte qu'il soit complet en abordant le point de vue des attaquants comme des défenseurs.
N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !
Dans les centres de formation professionnelle, tels que les CFA, la gestion des apprenants est un véritable défi au quotidien, que ce soit pour la direction, l’équipe pédagogique ou le service informatique. En effet, les outils numériques étant de plus en plus présents et intégrés dans les programmes de formation, le service informatique doit être impliqué et il doit apporter des réponses concrètes aux besoins des étudiants et des formateurs.
Afin de pouvoir donner accès aux outils numériques, tels que les postes de travail, aux apprenants, tout en respectant les bonnes pratiques en matière de sécurité ainsi que le règlement RGPD, le centre de formation doit se rendre à l’évidence : chaque apprenant doit disposer de son propre compte utilisateur et ce compte lui est dédié. Se pose alors une question : comment gérer des centaines ou des milliers de comptes apprenants de façon efficace ? Ceci tout en tenant compte du fait que les effectifs évoluent toutes les semaines ou presque.
La société DELIBERATA a développé des outils pour répondre à ces besoins, notamment pour automatiser la gestion des comptes apprenants. Cet article a pour objectif de présenter de façon synthétique les outils mis au point par les équipes de DELIBERATA.
Quelques mots sur l’entreprise DELIBERATA
DELIBERATA, société de conseil et d’accompagnement informatique qui a développé une forte compétence depuis quelques années dans le domaine des centres de formation professionnelle, dont les CFA (centres de formation d’apprentis). Avec une connaissance approfondie de leurs environnements techniques, organisationnels et fonctionnels.
L’originalité de l’équipe DELIBERATA est sa polyvalence : les profils variés des 10 collaborateurs couvrent l’ensemble des outils et usages numériques des centres de formation (gouvernance informatique, administration des systèmes et réseaux, intégration logicielle, support aux utilisateurs, …).
DELIBERATA assure depuis 10 ans le service informatique de centres de formation. L’une des problématiques rencontrées est l’administration des comptes informatiques des apprenants : avec plusieurs milliers de comptes et de sessions informatiques à créer, modifier, désactiver chaque année, dans un contexte d’inscriptions et de clôtures d’inscription à traiter tout au long de l’année scolaire.
DELIBERATA a imaginé et développé plusieurs outils logiciels d’automatisation de la gestion des comptes informatiques, qui sont éprouvés quotidiennement par plusieurs dizaines de centres de formation au bénéfice de 25 000 apprenants.
Les outils de DELIBERATA
Dans la suite de cet article, nous allons évoquer les articles développés en interne par les équipes de DELIBERATA. D’ailleurs, ayant travaillé dans cette société pendant plusieurs années, sachez que je suis à l’origine des deux premiers outils qui sont présentés ci-dessous.
SYNC-YAO
Commençons par le premier outil nommé SYNC-YAO. Ce logiciel a pour objectif de gérer les comptes et les sessions de travail informatiques des apprenants, tout au long de leur cycle de formation.
L’outil s’appuie sur plusieurs services de chez Microsoft : l’annuaire Active Directory en tant que base de comptes principale, le rôle de serveur de fichiers pour le stockage des données des sections, et Microsoft 365 pour les adresses électroniques.
SYNC-YAO est capable de s’interfacer avec le progiciel YPAREO (éditeur YMAG) ou tout autre progiciel de gestion de la formation, en tant que source de données. Il prend en charge les configurations basées sur plusieurs sites.
En premier lieu, SYNC-YAO va procéder à la création des comptes Active Directory, Microsoft 365 et de l’adresse électronique associée, pour chaque apprenant du centre de formation.
Pendant la formation, SYNC-YAO va actualiser les comptes des apprenants pour tenir compte des changements : changement de groupe, correction orthographique du nom de famille, etc.
En sortie de formation, SYNC-YAO va procéder à la désactivation du compte Active Directory, à l’archivage des données de l’apprenant et effectuer l’attribution de la licence « Exchange Online pour les anciens élèves » au compte Microsoft 365. L’objectif étant de pouvoir garder contact avec les apprenants, notamment les apprenants diplômés.
A chaque exécution de l’application, un rapport est généré et il est transmis par e-mail à un ensemble de destinataires (service informatique, équipe pédagogique, etc.). Voici un exemple :
En résumé, SYNC-YAO va gérer les accès informatiques de chaque apprenant de son arrivée à son départ du centre de formation, en prenant en considération les éventuels changements. Chaque apprenant est traité de façon indépendante, et ce, quotidiennement.
SYNC-AD TEAMS
Autre logiciel intéressant, complémentaire à SYNC YAO : SYNC-AD TEAMS. Il gère les équipes Microsoft Teams pédagogiques et leurs membres. Son objectif est de créer et gérer une équipe Teams par section, tout en associant les apprenants et les formateurs rattachés au groupe.
À l’instar de SYNC-YAO, ce logiciel est capable de s’interfacer avec le progiciel YPAREO (éditeur YMAG) ou tout autre progiciel de gestion de la formation, en tant que source de données.
SYNC-AD TEAMS va créer une équipe Microsoft Teams « apprenants + formateurs » pour chaque groupe de formation enregistré dans le progiciel, intégrant en tant que « propriétaires » les formateurs ayant été associés ou planifiés pour ce groupe et comme « membres » les apprenants inscrits dans ce groupe.
Quotidienne, chaque équipe Teams sera mise à jour afin de prendre en compte les modifications de planning, les inscriptions et clôtures d’inscription d’apprenants ainsi que l’éventuelle modification de nom du groupe de formation.
En complément de l’équipe Teams, le logiciel crée et maintient à jour un groupe Microsoft 365 « apprenants » associé à chaque équipe Teams, regroupant uniquement les apprenants de l’équipe (sans les formateurs).
Plusieurs modes de fonctionnement sont proposés, dont la possibilité de rendre l’équipe pluriannuelle (c’est à dire associée à une promotion). A chaque exécution de l’application, un rapport est généré et il est transmis par e-mail à un ensemble de destinataires (service informatique, équipe pédagogique, etc.).
AD-EXAM
Troisième exemple d’application : AD-EXAM. Ce logiciel permet aux directions et services administratifs des CFA de créer les sessions informatiques dédiées aux examens, et qui seront exploitées par les candidats et les membres du jury.
Ainsi, sans solliciter le service informatique, le centre de formation peut générer ces sessions spéciales qui bénéficieront ensuite des restrictions nécessaires permettant d’être en conformité avec les consignes de l’examen.
Les services sur-mesure de DELIBERATA pour les centres de formation
Comme évoqué précédemment, l’offre de services de DELIBERATA s’applique également à d’autres composantes du système d’information des centres de formation, parmi lesquelles :
L’analyse décisionnelle (business intelligence) :
Objectifs :
Récupérer automatiquement les données utiles des progiciels exploités par les centres de formation (Ypareo, Hub3E, Sage…)
Aide à l’administration et l’utilisation du progiciel Ypareo (éditeur Ymag)
Développement d’interfaces applicatives (Ypareo-ARD, Ypareo-Moneweb, Ypareo-Hub3E, Ypareo-360Learning…)
Conception et développement d’applications sur mesure complémentaires au progiciel Ypareo (éditeur Ymag), interfacées de façon bidirectionnelle avec le progiciel
Définition de schéma directeur numérique, étude de faisabilité, chefferie de projet, accompagnement au changement, etc.
Dans ce tutoriel, nous allons effectuer le durcissement de configuration de machines sous Windows à l'aide d'un outil open source nommé HardeningKitty. Autrement dit, nous allons analyser la configuration de notre machine pour voir si elle répond aux bonnes pratiques en matière de sécurité.
Ceci est nécessaire car la configuration par défaut d'un système d'exploitation, que ce soit Linux ou Windows, n'est pas en adéquation avec les bonnes pratiques de sécurité. Certaines recommandations peuvent être trop contraignantes et la configuration doit être adaptée en tenant compte du contexte et des besoins de l'entreprise. Ainsi, c'est à l'administrateur système de faire le nécessaire pour améliorer la sécurité des postes de travail et des serveurs. Le hardening, ou durcissement, va permettre de réduire la surface d'attaque d'une machine.
Dans cet exemple, nous allons durcir la configuration d'un serveur Windows Server 2022, mais la procédure est identique pour une machine Windows 10 ou Windows 11 (d'ailleurs Windows 11 est utilisé pour la vidéo), ainsi que pour des versions plus anciennes de Windows Server. L'essentiel étant de récupérer l'image ISO d'installation depuis le site officiel de l'éditeur, en l'occurrence ici : Microsoft.
Vers qui se tourner pour obtenir des informations sur ces fameuses bonnes pratiques de configuration pour améliorer la sécurité de Windows ?
A. Microsoft Security Baselines
Tout d'abord, il faut savoir que Microsoft propose un ensemble de documents baptisés "Microsoft Security baseline" et correspondants à chaque version de Windows, Windows Server, et certaines applications comme le navigateur Microsoft Edge.
À chaque fois, Microsoft propose une documentation pour lister chaque paramètre à configurer et de quelle façon. Celle-ci est accompagnée par des modèles de GPO, ainsi que des modèles d'administration pour ces mêmes GPO (ADMX), et des scripts PowerShell.
Security Baseline pour Windows Server 2022 - Aperçu
Vous pouvez télécharger ces documents via ce lien.
B. Les guides du CIS Benchmark
Le CIS (Center for Internet Security) propose un ensemble de guides de bonnes pratiques pour de nombreux produits et services : Windows, Windows Server, Debian, Cisco, Apache, Fortinet, Google Chrome, Google Workspace, Kubernetes, SQL Server, VMware, Azure, etc... Ces guides, maintenus à jour au fil des versions, ont une excellente réputation. Ils sont très souvent utilisés comme référence lorsque l'on souhaite durcir la configuration d'un système ou d'une application.
Vous pouvez télécharger ces guides gratuitement, après avoir complété un formulaire où l'on vous demandera quelques informations vous concernant.
Si l'on prend l'exemple du guide dédié à Windows Server 2022, il contient 1065 pages. Pour chaque paramètre de configuration à modifier, vous avez une description, des notes, une explication (quel est l'intérêt d'activer / configurer tel paramètre), et les impacts potentiels. Il existe également des versions estampillées STIG (Security Technical Implementation Guide) où il y a un focus supplémentaire sur la partie cybersécurité.
Très intéressant, mais rapidement chronophage.
Vous pouvez télécharger ces guides via cette page.
C. Les autres ressources
Au-delà des ressources proposées par Microsoft et les guides du CIS, nous pouvons compter sur ceux d'autres organisations et entités : l'ANSSI en France, la BSI en Allemagne (l'équivalent de l'ANSSI), la CISA aux Etats-Unis, etc...
Mais à chaque fois, vous ferez surement le même constat :
Comment comparer les recommandations d'un guide avec la configuration d'un serveur ou d'un poste de travail ?
Comment configurer un serveur ou un poste de travail afin de respecter les bonnes pratiques sans devoir y passer "un temps fou" ?
C'est exactement pour répondre à ces deux problématiques que vous devez vous intéresser à HardeningKitty.
III. Découverte de HardeningKitty
A. HardeningKitty, c'est quoi ?
HardeningKitty est un outil gratuit que vous pouvez utiliser à la fois pour auditer la configuration de votre système et effectuer le durcissement de celle-ci. HardeningKitty est capable de s'appuyer sur la liste de recommandations de l'auteur de l'outil, mais également d'autres "security baselines" comme celles de Microsoft et du CIS. Ainsi, vous allez pouvoir automatiser le hardening de Windows 10, Windows 11, Windows Server, etc.
Le durcissement va modifier différents composants et services de votre système d'exploitation dans le but de réduire la surface d'attaque (ASR), configurer les journaux d'audit de Windows, configurer le pare-feu Windows Defender, activer / désactiver / configurer certaines fonctionnalités, etc. Dans une grande majorité des cas, HardeningKitty modifie le Registre pour effectuer la configuration.
Pour accéder au projet HardeningKitty sur GitHub, il y a deux liens. Un lien vers le projet source d'origine, et un lien vers un autre dépôt où vous pouvez retrouver chaque version stable signée par le certificat de scip AG. Ceci signifie que le script PowerShell d'HardeningKitty peut être exécuté sur une machine Windows même si elle autorise uniquement l'exécution de scripts signés (ceci fait écho à la stratégie d'exécution PowerShell).
Avant d'effectuer des modifications en masse sur votre machine Windows, il est primordial d'assurer vos arrières. Autrement dit, prenez les précautions habituelles : testez les modifications sur un environnement de tests et vérifiez vos sauvegardes.
Au-delà de permettre l'audit de la configuration d'une machine, HardeningKitty peut déployer la nouvelle configuration durcie. Forcément, ceci peut être à l'origine d'un ou plusieurs effets de bords. Nous verrons également qu'il y a une fonction de "backup" dans HardeningKitty.
Remarque : vous pouvez aussi envisager d'effectuer une sauvegarde de la base de Registre Windows, et même créer un snapshot s'il s'agit d'une machine virtuelle.
IV. Utilisation d'HardeningKitty sur Windows
A. Télécharger HardeningKitty
Commencez par télécharger la dernière version signée depuis GitHub. Pour ma part, il s'agit de la version 0.9.2. Vous obtenez une archive ZIP qu'il suffit de décompresser afin d'obtenir un ensemble de fichiers, notamment le module PowerShell correspondant à HardeningKitty.
Notez également la présence du dossier "lists" qui contient un ensemble de fichiers CSV : un fichier CSV par liste de bonnes pratiques supportées par l'outil.
Nous avons à chaque fois deux fichiers CSV : un pour les paramètres de l'ordinateur (machine) et un pour les paramètres de l'utilisateur (user).
B. Sauvegarde de la configuration actuelle
Avant même d'auditer notre configuration ou d'effectuer la moindre modification sur le système, nous allons sauvegarder l'état actuel. Attention, quand vous utilisez HardeningKitty, vous devez effectuer une sauvegarde correspond à la liste ou aux listes que vous envisagez de "déployer" par la suite.
Dans cet exemple, nous allons utiliser ces deux listes :
CIS Microsoft Windows Server 2022 (Machine) - 22H2 - 2.0.0
Soit le fichier : finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_machine.csv
CIS Microsoft Windows Server 2022 (User) - 22H2 - 2.0.0
Soit le fichier : finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_user.csv
Ouvrez une console PowerShell en tant qu'administrateur afin de pouvoir utiliser l'outil.
Positionnez-vous dans le répertoire d'HardeningKitty et importez le module :
cd C:\users\Administrateur\Downloads\HardeningKitty-v.0.9.2\
Import-Module .\HardeningKitty.psm1
Pour effectuer la sauvegarde des paramètres machines et utilisateurs pour les listes évoquées ci-dessus, utilisez ces commandes :
À chaque fois, nous obtiendrons un fichier de "sauvegarde" au format CSV dont le nom sera constitué de la façon suivante :
Backup_<nom de l'ordinateur>_<Date et heure actuelle>_<Machine ou User>.csv
Quelques secondes ou minutes sont nécessaires pour effectuer la sauvegarde.
Quand c'est fait, nous obtenons deux fichiers :
C. Auditer la configuration de la machine
La sauvegarde de la configuration étant effectuée, nous allons pouvoir auditer notre machine. Là encore, nous allons bien spécifier les noms des listes que nous souhaitons utiliser comme référence.
HardeningKitty doit être utilisé en mode "Audit" :
À chaque fois, HardeningKitty indique une note globale ainsi que le nombre de paramètres vérifiés et les résultats associés. Ici, nous pouvons qu'il y a eu 459 paramètres vérifiés et qu'il y en a 312 points de configuration à améliorer. L'idée étant de se concentrer en priorité sur ceux considérés comme "Medium" et "High". Imaginez un instant effectuer toutes ces corrections manuellement...
Your HardeningKitty score is: 3.57. HardeningKitty Statistics: Total checks: 459 - Passed: 147, Low: 43, Medium: 269, High: 0.
Le résultat dépend clairement de la liste utilisée. En effet, sur une même machine, mais avec la liste de vérification par défaut de l'outil (qui est le fruit de l'expertise de l'auteur de cet outil - Elle est estampillée Windows 10 !), le score obtenu est totalement différent :
Your HardeningKitty score is: 3.22. HardeningKitty Statistics: Total checks: 391 - Passed: 79, Low: 68, Medium: 243, High: 1.
Si l'on s'appuie sur la liste de Security Baseline de Microsoft pour Windows Server 2022, en prenant la configuration adaptée pour les contrôleurs de domaine (ici, l'outil est utilisé sur un DC), le résultat est encore différent :
Afin de pouvoir effectuer une analyse et avoir un bon aperçu de l'état actuel de la configuration du serveur, il est préférable de générer un rapport d'audit. Ceci est déjà le cas avec le paramètre "-Report". HardeningKitty va générer un fichier CSV que l'on pourra exploiter dans Excel.
Pour créer un rapport avec le nom de votre choix, ajoutez le paramètre "-ReportFile" suivi du nom du fichier. Nous allons réutiliser la même logique pour le nom du fichier de rapport. Voici un exemple :
Lorsque la phase d'audit est terminée, vous pouvez passer à l'action : demander à HardeningKitty de durcir la configuration de votre machine.
Remarque : comment est calculé le score d'audit ? Sachez que la formule utilisée pour calculer le score d'HardeningKitty est la suivante : (Points obtenus / Maximum de points) * 5 + 1.
D. Durcir la configuration de la machine
Pour durcir la configuration de la machine Windows Server 2022, nous utilisons le mode "HailMary" (Ave Maria). A ce sujet, la documentation officielle précise : "La méthode HailMary est très puissante. Elle peut être utilisée pour déployer une liste de résultats sur un système. Tous les résultats sont placés sur ce système selon les recommandations de la liste. Le pouvoir s'accompagne de la responsabilité. N'utilisez ce mode que si vous savez ce que vous faites. Assurez-vous d'avoir une copie de sauvegarde du système."
Le mode HailMary va nous permettre de déployer tous les paramètres de configuration contenus dans les deux listes que nous avons choisi d'utiliser.
Voici la commande à exécuter pour déployer les paramètres ordinateurs :
Sachez qu'avant d'effectuer des modifications sur votre machine, HardeningKitty va créer un point de restauration. Si le point de restauration ne peut pas être créé, ce qui sera le cas sur Windows Server car il faut utiliser la Sauvegarde Windows à la place, l'opération est arrêtée immédiatement. Nous devons donc réexécuter les commandes avec le paramètre "-SkipRestorePoint".
À chaque fois, et puisque nous avons précisé les paramètres "-Log" et "-Report", un fichier journal et un fichier de rapport (CSV) seront générés. Le fichier de log reprend toutes les lignes visibles dans la console. Voici un extrait du fichier journal "hardeningkitty_log_srv-adds-01_finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_machine-20240228-113957.log" :
[*] 28/02/2024 11:40:15 - Starting Category Administrative Templates: Windows Components
ID 18.10.89.1.1, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Client, AllowBasic, Registry key created
ID 18.10.89.1.1, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Client, AllowBasic, Registry value created/modified
ID 18.10.89.1.2, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Client, AllowUnencryptedTraffic, Registry value created/modified
ID 18.10.89.1.3, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Client, AllowDigest, Registry value created/modified
ID 18.10.89.2.1, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Service, AllowBasic, Registry key created
ID 18.10.89.2.1, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Service, AllowBasic, Registry value created/modified
ID 18.10.89.2.2, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Service, AllowAutoConfig, Registry value created/modified
ID 18.10.89.2.3, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Service, AllowUnencryptedTraffic, Registry value created/modified
ID 18.10.89.2.4, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Service, DisableRunAs, Registry value created/modified
Mais, priorisez la lecture du rapport avec Excel, ou un autre outil, pour l'analyse post-hardening. Ce rapport permet d'avoir une liste exhaustive des changements de configuration effectués.
Par la suite, si vous avez besoin de revenir en arrière, vous pouvez restaurer la configuration via cette commande (en adaptant le nom du fichier CSV) :
Si vous souhaitez durcir la configuration de vos machines en vous appuyant sur les recommandations de Microsoft, du CIS, du BSI, ou du DoD, alors HardeningKitty est probablement l'outil qu'il vous faut ! L'utilisation de cet outil devrait vous permettre de gagner énormément de temps. Néanmoins, vous devez prendre le temps d'analyser le contenu de ces guides et devez avoir une bonne connaissance de votre infrastructure et de ses particularités. Ceci vous permettra d'anticiper les éventuels effets de bords.
D'ailleurs, si vous envisagez de déployer la configuration recommandée par le CIS Benchmark, vous devez parcourir chaque guide afin d'avoir un aperçu des fonctions et services de Windows qui seront affectés lorsque le déploiement sera fait avec HardeningKitty. Cette recommandation s'applique également pour les autres guides.
Le seul bémol, c'est le fait qu'il soit nécessaire de l'exécuter machine par machine : ce qui pourra s'avérer utile lors de la création d'un master (image de référence) pour vos postes de travail ou serveur. En effet, ceci vous permettra de créer une image durcie.
HardeningKitty intègre bien un paramètre mode "GPO" (-Mode GPO) permettant de convertir une liste de résultats en une stratégie de groupe (GPO). Toutefois, ceci semble encore expérimental : "Pour l'instant, seuls les paramètres de registre peuvent être convertis et tout n'a pas encore été testé."
MaxPowerSoft Active Directory Reports generates various types of reports, eliminating the need to create PowerShell scripts to retrieve Active Directory data manually. In this review, I will elaborate on the key functionalities of the AD Reporting tool that are most beneficial.
This guide will explore adding an Azure Active Directory (Azure AD) group to the local administrator's group. This will enable Azure AD group members to perform tasks requiring administrator privileges on Windows 10 and Windows 11 computers.
Connexion
). Il faut à nouveau faire un clic droit sur l'objet puis "Réinitialiser le mot de passe" : 
