Générer des attaques d'envergure sans un parc de machines

Un problème récurrent en Intelligence Artificielle est de parvenir à collecter suffisamment de données pour entrainer un modèle. Dans notre cas, travailler avec les journaux d’évènements de Windows n’est pas chose aisée, car il n’existe pas d’ensemble de données correspondant exactement à ce dont nous avons besoin. Pour remédier à cela, nous avons relevé nos manches et simulé un environnement Active Directory (AD) pour mener des attaques et constituer notre propre ensemble de données.

L’Active Directory est une partie importante de l’infrastructure informatique ; beaucoup d’entreprises utilisent cette technologie pour la gestion des droits.

Du fait de cet usage fréquent, il faut noter que les systèmes d’Active Directory sont vulnérables à divers types de menaces. En effet, ils jouent un rôle clé dans l’attribution d’autorisations aux utilisateurs. Par exemple, il existe plusieurs outils permettant de deviner les mots de passe dans un Active Directory. En général, trois étapes sont requises :

Énumération des noms d’utilisateurs : récupération de la liste des noms d’utilisateurs

Password spraying : test de mots de passe populaires et courants sur chaque nom d’utilisateur

Obtention d’un accès : une des combinaisons identifiant-mot de passe a fonctionné ; le compte peut être utilisé pour lister les actifs sur le réseau de l’AD, exploiter des services authentifiés et faire courir un risque à l’organisation.

Il est intéressant pour une équipe dédiée à l’IA d’étudier comment détecter ces attaques. Voyons comment nous avons créé des attaques dans des machines virtuelles pour les analyser.

Construire une infrastructure virtuelle

Qu'est-ce qu'un Active Directory (AD)

L’AD est un service d’annuaire développé par Microsoft et qui fonctionne sur Microsoft Windows Server. Dans l’AD, les utilisateurs, les groupes, les applications et les équipements sont stockés en tant qu’objets. Ils sont classés selon leur nom et leurs attributs. Un groupe d’objets sur la même base d’Active Directory est appelé un domaine.

Ce système permet aux administrateurs de gérer les droits et de contrôler les accès aux ressources réseau. Les utilisateurs disposent d’accès authentifiés et autorisés à des équipements, des applications en mode Cloud ou sur site de manière fiable et pratique.

Composante principale de l’AD, les Active Directory Domain Services vérifient l’accès quand un utilisateur se connecte au système ou tente de se connecter sur le réseau. Ils assignent et imposent aussi des politiques de sécurité. Les serveurs qui en ont la charge sont appelés contrôleurs de domaine (Domain Controllers).

Créer l’environnement Active Directory

Notre but est ici de créer une petite infrastructure informatique contenant un contrôleur de domaine et quatre clients (qui sont des utilisateurs). Il ne nous en faut pas plus, car ce petit nombre suffit pour simuler des données tant inoffensives que malveillantes.

Faire fonctionner cinq ordinateurs en continu est un processus pénible et coûteux en matériel. Pour résoudre ce problème, nous optons pour des machines virtuelles. Nous nous sommes appuyés sur ce tutoriel pour créer l’infrastructure.

Sur chacune de nos machines, nous installons l’agent de notre outil d’Endpoint Detection Response (EDR), afin de suivre nos données sur une pile dédiée.

Pour créer nos VM et les connecter, nous les installons sur un serveur dans notre infrastructure. Comme ces machines peuvent prendre de la place, l’objectif est de réduire leur taille autant que possible : supprimer les fichiers non nécessaires, désinstaller les programmes inutilisés et vider la corbeille.

Pour la gestion de nos machines, nous optons pour VirtualBox. Peut-être vous demandez-vous comment nous avons exposé nos VM sur notre serveur. Après avoir uploadé le fichier .ova sur le serveur, une série de commandes doit être réalisée :

vboxmanage import vm.ova #  This command imports one or more virtual machines into Oracle VM VirtualBox
vboxmanage modifyvm vm --vrde on # Enables the VirtualBox Remote Desktop Extension (VRDE) server
vboxmanage modifyvm vm --vrdeaddress x # The IP address (replace x by the IP) of the host network interface the VRDE server will bind to
vboxmanage modifyvm vm --nic2 bridged --nictype2 x --bridgeadapter2 x # Configures the type of networking, replace x by what your computer needs : https://www.virtualbox.org/manual/ch06.html
vboxmanage startvm vm --type headless # Start the virtual machine

Pour se connecter aux machines, un client RDP est requis (je recommande Remmina). Nous disposons à présent d’une infrastructure et pouvons générer des données !

Générer les données

Avant de commencer à générer des données, il nous faut savoir sur quel type de données nous travaillons.

Les données requises viennent du journal d’évènements de Windows, listant les évènements liés au système, à sa sécurité, et aux applications stockées sur un système d’exploitation Windows. Un évènement peut être identifié par son nom de journal, sa date, son type de tâche, son identifiant, sa source, son niveau, son utilisateur et son ordinateur.

Les évènements dont nous avons besoin sont dans « Microsoft-Windows-Security-Auditing », en particulier les types Audit logon events (« Auditer les événements de connexion ») et Audit account management (« Auditer la gestion des comptes »).

Les données inoffensives

Les évènements qu’il nous est possible d’analyser sont liés à des actions d’authentification, surtout générés au moment de la connexion, de la déconnexion ou du verrouillage/déverrouillage de l’ordinateur, à savoir les évènements sous les identifiants 4624, 4634, 4648, 4625 et 4768.

Comme les données que nous considérons viennent d’actions effectuées par un utilisateur, il est difficile de collecter rapidement une grande variété et quantité d’évènements pour analyse. Les données bénignes sont difficiles à obtenir immédiatement, à moins que la VM ne soit lancée ou verrouillée/déverrouillées plusieurs fois d’affilée. Il n’existe pas de solution directe à ce problème. Néanmoins, les données ainsi générées ne reflètent pas la réalité, car elles ne simulent pas correctement l’activité d’un vrai utilisateur.

Il faut plusieurs jours, voire semaines pour que le nombre d’évènements bénins soit suffisant pour être analysé. Ce processus chronophage nécessite parfois aussi des interventions humaines sur la VM. Pour accélérer le processus, une fois le format de l’évènement connu, nous pouvons synthétiquement générer plus de données par oversampling des évènements initialement créés. En effet, les évènements étudiés présentent souvent la même structure. Ce procédé d’oversampling est effectué par ajout d’évènements issus de connexions réussies (de type 4624), qui sont les plus simples à reproduire.

Les données malveillantes

Nous avons consulté le GitHub d’Atomic Red Team pour avoir une idée des attaques possibles, principalement sur des tactiques d’accès aux données d’authentification. Nous nous sommes basés sur une technique de brute force. Plusieurs outils sont disponibles pour générer des attaques sur un AD. Nous avons choisi de nous concentrer sur trois outils connus : Kerbrute, Talon et CrackMapExec.

Quand on génère des attaques, il est essentiel de consigner l’heure afin que les données soient correctement étiquetées au moment de l’analyse.

Nous avons aussi été aidés par un membre de l’équipe CTI (Cyber Threat Intelligence) — comme le montre cet article, ce n’est pas la première fois que nous collaborons avec cette équipe. Cette aide nous a permis de comprendre comment fonctionnent certaines attaques et a apporté des informations précieuses sur la manière de créer et d’exécuter des scénarios d’attaques complexes sur les machines.

Par exemple, pour lancer une attaque par password spraying avec CrackMapExec, nous avons exécuté la commande suivante :

ip_address est l’adresse IP de la machine que nous voulons attaquer. Les fichiers texte contiennent les noms d’utilisateur et mots de passe les plus communs.

Pour chaque attaque, nous avons eu droit à un rapport détaillé sur le scénario et les évènements identifiables.

Conclusion : un laboratoire pour générer des données réelles et aider l’IA

Cette infrastructure permet à l’équipe d’IA de gagner du temps en générant des données qui lui assurent aussi une plus grande indépendance. Cet article décrit la génération de journaux d’événements Windows, car l’équipe dédiée à l’IA travaille actuellement sur un modèle de détection des authentifications suspectes sous Windows.

Ces VM permettront à notre équipe, au-delà de ces journaux d’événements, d’étudier d’autres types de données. Pour ce qui est des améliorations techniques, nous pourrions créer un calendrier pour nos VM afin de les activer/désactiver à des heures normales de bureau et de reproduire le comportement d’un utilisateur. VirtualBox n’est pas la meilleure option, car il est lent et consomme beaucoup de ressources, nous pourrions plutôt utiliser QEMU pour gérer nos machines virtuelles.

Les données restent le principal problème quand on étudie un nouveau sujet dans le domaine de l’IA. Toutefois, nous avons vu que ce problème peut être résolu avec un laboratoire dédié à la génération de données réelles aussi proches que possible de ce qui se voit en production.