Les Honeypots au service d’Active Directory
Au cœur de la sécurité de votre système d’information, l’Active Directory est une cible de choix pour les attaquants. Mais si, au lieu de simplement subir les assauts, vous pouviez les anticiper et les détourner ? Cet article explore une approche offensive de la surveillance en transformant les mécanismes internes de l’AD en pièges intelligents. Découvrez comment des honeypots réalistes, conçus pour exploiter la psychologie des attaquants, peuvent non seulement détecter les menaces plus tôt, mais aussi alléger considérablement le fardeau de vos équipes de défense.
Pour passer de la théorie à la pratique, nous vous présenterons un outil clé en main permettant d’automatiser leur déploiement.
Il s’agit de l’adaptation francophone d’une publication originale en anglais, qui détaille ces mêmes concepts.
L'art du honeypot en environnement Active Directory
Le principe qui sous-tend les honeypots est très simple : il s’agit d’un système informatique, réseau, service (ou objet au sens large) leurre conçu pour attirer et piéger les acteurs malveillants. Il est intentionnellement créé pour ressembler à une cible légitime et vulnérable, attirant les attaquants dans un environnement contrôlé où leurs activités peuvent être surveillées et analysées sans risque pour le réseau réel de l’organisation.
En présentant une cible facile, les équipes de sécurité peuvent étudier les outils, les techniques et les procédures (TTP) utilisés par leurs adversaires. Ces informations sont précieuses pour renforcer les défenses des réseaux réels et comprendre les menaces émergentes. Les honeypots offrent un double avantage. D’une part, ils permettent d’analyser en direct les méthodes d’un attaquant lorsqu’il interagit avec un leurre. D’autre part, ils fonctionnent comme des alertes précoces qui signalent immédiatement sa présence aux équipes de sécurité, leur permettant de lancer la réponse à incident bien avant qu’une cible réelle ne soit compromise.
Pour que ces objets soient utiles, il est nécessaire d’avoir une connaissance et une expérience approfondies de la façon dont les attaquants pensent et de la manière dont l’exploitation des composants vulnérables se traduit dans la réalité. Ce qui rend les honeypots fascinants, c’est qu’ils incarnent un principe clé de la cybersécurité : pour bien se défendre, il faut penser comme un attaquant. Ce mécanisme d’amélioration par l’adversité est le même qui pousse les antivirus à évoluer constamment, en réponse aux nouvelles techniques de contournement.
Comme CrowdStrike le décrit, l’efficacité des honeypots dépend du temps que l’attaquant passe à essayer d’exploiter la configuration manifestement vulnérable, avant qu’il ne réalise que cette dernière est piégée.
Un honeypot à faible interaction utilise relativement peu de ressource et collecte des informations basiques à propos de l’attaquant. Ces honeypots sont assez simples à mettre en place et à maintenir. La plupart des honeypots en production sont des honeypots de faible interaction.
Dû au fait qu’ils sont peu sophistiqués, ces honeypots retiennent assez peu longtemps l’attention d’acteurs malveillants. Cela signifie qu’il est peu probable qu’ils constituent des leurres particulièrement efficaces, et ne produiront que des renseignements limités sur l’adversaire.
Compte tenu de la sophistication croissante de nombreux adversaires, certains attaquants avancés peuvent repérer des leurres de bas niveau et les éviter, voire les exploiter en leur fournissant des informations volontairement erronées.
Le principe des honeypots est facile à comprendre, mais ces derniers sont plus difficiles à conceptualiser car les alertes générées par ces derniers doivent être le plus fiable possible. Puisqu’aucun utilisateur légitime ne devrait jamais interagir avec, tout trafic ou activité dirigé vers le honeypot est, par définition, suspect ou malveillant. Mais créer des pièges trop évidents ou inefficaces (difficiles à maintenir, génère trop d’alertes et/ou de faux positifs…) distraira les équipes de sécurité des véritables menaces.
Les Honeypots appliqués à Active Directory
Ces idées de honeypots pour Active Directory ont été automatisés dans un script, déployés et testés en lab, mais ne seront efficaces que si combinés avec des règles de détection actives et d’un SIEM (Security Information and Event Management) :
ASREP-Roast
La fonction correspondante dans le script déploie un nouvel objet utilisateur dans le domaine. L’utilisateur peut en choisir le nom ainsi que l’Unité D’Organisation (OU) de destination. Le script va ensuite paramétrer le nouveau compte pour ne plus requérir la phase de pré-authentification Kerberos.
Sans trop rentrer dans le détail des conséquences de paramétrage (l’ASREP-Roasting est une attaque déjà très bien documentée). Un attaquant dans le domaine peut ainsi demander un ticket Kerberos pour le nouveau compte déployé (sans avoir besoin d’en connaître le mot de passe) afin d’essayer de craquer le hash qui a servi à chiffrer le ticket. Ce qui va intéresser l’attaquant dans cette situation, c’est le fait qu’il n’a nul besoin d’avoir déjà compromis un accès initial dans le domaine pour l’exploiter, ce qui peut ainsi constituer une de ses premières actions, et donc une détection rapide dans la potentielle chaîne de compromission.
Ainsi, surveiller un compte vulnérable à cette attaque permet de générer des alertes de très haute fiabilité, car seul un attaquant intéressant par le fait de prendre le contrôle de ce compte (qui peut donc se passer de la phase de pré-authentification pour accéder au domaine) tenterait de demander un ticket Kerberos pour ce dernier.
Surveiller les événements de demande de TGT (4768) pour ce compte vulnérable révélera toute tentative de récupération de ticket, et donc de potentielle tentative de crack de ce dernier. Tout événement de tentative d’authentification provenant de ce compte est à considérer comme un incident de sécurité car n’étant pas supposé demander de ticket.
Kerberoast
Parmi les attaques ciblant Kerberos, le Kerberoasting est une technique classique dont la popularité en fait une excellente opportunité de détection.
Le script déploie un nouvel utilisateur dans le domaine et lui assigne un Service Principal Name spécifique. Cette configuration autorise donc n’importe quel compte dans le domaine à venir requêter des Tickets de Service (ST) Kerberos pour le service paramétré lors du déploiement du compte.
Cela implique donc qu’un attaquant doté d’un accès initial dans le domaine pourra également demander des STs auprès du honeypot. Monitorer les événements 4769 (A Kerberos service ticket was requested) pour le compte déployé révélera alors les récupérations de tickets de service et les tentatives de crack du mot de passe qui aura servi à les chiffrer.
User Account
Il s’agit d’un simple utilisateur de domaine qui n’est pas censé interagir avec les autres objets dans le domaine. Ce compte utilisateur est paramétré avec le drapeau PasswordNotRequired, ce qui risque de susciter l’intérêt d’un attaquant en pleine énumération de mauvaises configurations.
Tout événement en provenance de ce compte est à traiter comme un incident de sécurité : authentification NTLM, demande de ticket Kerberos, authentification réussie ou échouée, accès à des objets (accès à un dossier partager, énumération utilisateur, interaction LDAP). Une possibilité intéressante pour ce honeypot pourrait être d’ajouter un faux mot de passe dans sa description afin qu’un attaquant le lise et tente de s’authentifier avec.
Pour ne pas exposer le reste du domaine aux risques d’énumération ou de modification, le compte déployé n’est pas autorisé à lire ni à effectuer aucune action dans le domaine. Un full Deny est appliquée pour le compte sur l’objet du domaine lui-même, afin de prendre le pas sur l’autorisation de lecture donnée au groupe Utilisateurs Authentifiés. L’audit des échecs d’authentification est ensuite configuré sur l’objet utilisateur lui-même :
Pre2K Machine Account
Ce honeypot repose sur l’exploitation de l’attaque Pre2k. Tout compte ordinateur créé avec l’option Assign this computer account as pre-Windows 2000 computer se voit donné un mot de passe égal à son nom d’ordinateur. En attendant qu’un réel ordinateur utilise ce compte pour s’authentifier au domaine et que le mot de passe soit automatiquement changé par Active Directory, ce compte pre-Windows reste inutilisé, mais effectivement capable de s’authentifier.
Cette configuration permet à un attaquant qui aurait récupéré une liste d’ordinateurs dans le domaine (ou l’ayant reconstitué à partir de la nomenclature des machines disponibles) d’essayer de s’authentifier sur chaque ordinateur à l’aide de leur nom.
Le script déploie donc un compte ordinateur honeypot qui est ajouté au groupe Pre-Windows 2000 compatible, et lui assigne un mot de passe égal à son nom d’ordinateur. De la même façon que pour le honeypot précédent, le compte se voit assigné un Full Deny sur l’objet du domaine.
Autologon
Cette fonction du script crée un nouvel objet GPO à lier à une unité d’organisation existante, qui contiendra des informations d’identification (couple username/password).
Un attaquant répertoriant les objets GPO dans le domaine trouvera très probablement le nom d’utilisateur et le mot de passe en clair dans la GPO.
Cependant, la particularité est que le compte spécifié dont le mot de passe apparaît dans l’objet GPO… n’existe pas. Les analystes n’ont alors qu’à surveiller les événements de tentative d’authentification contenant le nom du compte utilisateur honeypot et à considérer tout événement de ce type comme un incident de sécurité.
Group Policy Object
Cette fonction crée une nouvelle GPO dans le domaine, puis le lie à l’objet racine du domaine. Cette GPO ne pousse en réalité aucun paramètre à l’unité d’organisation et aux ordinateurs auxquels elle s’applique.
Celle-ci n’a d’autre but que d’être énumérée et lue par un attaquant potentiel. En effet, les outils des auditeurs et des attaquants ont tendance à lire toutes les GPOs du domaine auxquels les simples comptes utilisateurs ou machine ont accès en une seule fois, lors de l’accès initial. Ce comportement facilite le travail des défenseurs qui souhaitent mener des investigations sur l’énumération des GPO.
Enable-AllGpoAuditing
Cette fonction applique une règle d’audit à l’intégralité des GPOs du domaine, ce qui peut cependant générer un grand nombre d’événements.
Déployer des objets AD pour surveiller les attaques
Comme énoncé précédemment, le but de cet outil est de déployer des objets servant comme honeypots aux défenseurs et aux analystes en déclenchant des événements de sécurité fiables. Cependant, il est à noter que seulement déployer ces honeypots n’améliore en rien le niveau de sécurité d’un domaine AD. Ces derniers ont besoin d’être monitorés pour fonctionner en synergie avec des règles de détection actives exploités par de réels analystes
Ici, la versatilité de PowerShell se montre d’une grande praticité, non seulement pour facilement créer les objets utilisés pour la détection, mais aussi pour créer des règles d’audit. Le script a simplement besoin d’être importé et lancé depuis un Contrôleur de domaine, il suffit ensuite d’appeler la fonction correspondante au honeypots désirés en fournissant les bons paramètres (noms de compte, OUs, noms d’ordinateurs, etc )
En outre, l’amélioration du niveau de sécurité d’une forêt Active Directory ne passe pas exclusivement par l’implémentation de paramètres de sécurité ou par des projets de sécurisation, mais par une surveillance proactive de la part des équipes afin de capter au plus tôt les signaux faibles mais sans équivoque que les attaquants générés par les attaquants. C’est pour cette raison que des campagnes régulières de tests d’intrusion permettent à la fois d’évaluer le niveau de sécurité de la forêt mais peuvent également éprouver les défenses et niveaux de détection.
