Honeypot : détecter les cyberattaques grâce à la technologie de leurre

Les pare-feu, antivirus, EDR, XDR et SIEM sont indispensables pour protéger un système d’information. Toutefois, ces solutions doivent analyser une quantité importante d’événements, parmi lesquels il peut être difficile d’identifier une véritable attaque.

Le honeypot adopte une approche différente : il met à disposition de l’attaquant une fausse cible spécialement conçue pour attirer son attention.

Puisqu’aucun utilisateur légitime ne doit accéder à cette ressource, toute interaction devient immédiatement suspecte.

Dans cet article, nous présentons le fonctionnement des honeypots, les principales fonctionnalités de Trapster et la possibilité de créer un compte leurre dans Active Directory.

Un honeypot, ou « pot de miel », est une ressource informatique factice qui ressemble à un véritable élément du système d’information. Il peut simuler :

• un serveur Windows ou Linux
• un partage de fichiers
• un service SSH ou RDP
• une base de données
• un serveur web
• un service LDAP
• un équipement réseau
• des identifiants ou des documents sensibles

Pour un attaquant qui explore le réseau, le honeypot apparaît comme une cible potentiellement intéressante : serveur de sauvegarde, base de données, partage administratif ou machine contenant des informations confidentielles.

En réalité, cette ressource ne contient aucune donnée de production. Elle est isolée, surveillée et conçue pour enregistrer les actions réalisées par l’attaquant.

Lorsqu’un attaquant compromet un poste de travail, il commence généralement par explorer son environnement afin de trouver d’autres machines, des comptes techniques ou des données sensibles.

Le honeypot permet notamment de détecter :

• les scans du réseau interne
• les tentatives de déplacement latéral
• l’utilisation d’identifiants compromis
• les connexions à des services inhabituels
• l’accès à de faux fichiers ou partages
• les activités qui n’ont pas été bloquées par l’antivirus ou l’EDR

L’intérêt principal du honeypot réside dans la qualité de ses alertes. Un serveur de production reçoit chaque jour de nombreuses connexions légitimes. Un serveur leurre, en revanche, ne devrait être contacté par personne. Une tentative de connexion constitue donc un événement à forte valeur pour l’équipe de sécurité.

Trapster est une solution française développée par Ballpoint, une entreprise spécialisée dans la sécurité offensive. Elle permet de déployer plusieurs types de leurres dans le système d’information :

• de faux serveurs
• des services réseau simulés
• de fausses bases de données
• des partages fictifs
• des fichiers leurres
• de faux identifiants
• de fausses clés API

Ces ressources sont placées à des endroits stratégiques du réseau, par exemple dans le VLAN des serveurs, le réseau des utilisateurs, la zone d’administration, l’environnement de sauvegarde ou la DMZ.

Lorsqu’un attaquant interagit avec un leurre, Trapster génère une alerte afin que l’équipe informatique ou le SOC puisse rapidement analyser l’événement.

Le fonctionnement de Trapster repose sur quatre grandes étapes.

Trapster fournit des machines virtuelles préconfigurées pouvant être installées sur des environnements comme VMware, Microsoft Hyper-V ou Proxmox.

Les leurres doivent être positionnés dans les zones qu’un attaquant serait susceptible d’explorer après avoir compromis une première machine.

Trapster peut simuler différents services couramment utilisés dans les entreprises, notamment : HTTP et HTTPS, SSH, FTP, RDP, SMB, DNS, LDAP, MSSQL, MySQL, PostgreSQL.

Un attaquant peut, par exemple, découvrir des machines portant des noms comme :

SRV-BACKUP-02
SQL-ARCHIVE
NAS-SAUVEGARDE
SRV-ADMIN
FINANCE-FS01

La cohérence du nom, du service et de son emplacement dans le réseau contribue à rendre le leurre crédible.

Lorsqu’un attaquant scanne ou contacte le honeypot, Trapster peut enregistrer différentes informations :

• l’adresse IP source
• le service ciblé
• la date et l’heure
• les identifiants utilisés
• les commandes exécutées
• les requêtes envoyées
• les fichiers ou charges utiles transmis

Ces informations facilitent ensuite l’investigation et la recherche d’autres activités similaires dans le système d’information.

Les alertes peuvent être transmises vers différents outils :

• courrier électronique
• Microsoft Teams
• Slack
• webhook
• Syslog
• API REST
• SIEM ou SOAR

L’équipe de sécurité peut alors corréler l’alerte avec les événements du pare-feu, de l’Active Directory, de l’EDR ou des équipements réseau.

Un honeytoken est une fausse information volontairement placée dans le système d’information.

Il peut s’agir :

• d’un faux identifiant
• d’une fausse clé API
• d’un document prétendument confidentiel
• d’un fichier de configuration factice
• d’un raccourci vers un faux partage
• d’un compte de service Active Directory

Aucun utilisateur légitime ne doit exploiter cette information. Son utilisation indique donc qu’une personne ou un programme réalise une action inhabituelle.

Les honeytokens sont particulièrement utiles pour détecter le vol d’identifiants, la consultation de fichiers sensibles et les tentatives de déplacement latéral.

Il est également possible de créer un honeypot sans déployer de serveur supplémentaire, en utilisant un compte Active Directory spécialement conçu pour attirer les attaquants. Ce compte, parfois appelé *honey account*, doit ressembler à un véritable compte technique :

svc_sql_archive
svc_backup_legacy
svc_vmware_backup
svc_netapp_snap

Il ne doit cependant être utilisé par aucun service, aucune application et aucun collaborateur.

Toute tentative d’authentification ou toute demande de ticket Kerberos associée à ce compte devient alors un indicateur de compromission.

Un ancien compte technique peut paraître plus crédible qu’un compte créé récemment. Il possède généralement :

• une date de création ancienne
• un historique de changements de mot de passe
• d’anciennes connexions
• un nom correspondant aux conventions de l’entreprise
• des attributs cohérents avec l’âge du domaine

Un attaquant expérimenté peut en effet vérifier la date de création du compte, sa dernière connexion, son historique ou la cohérence de son SPN. Un compte créé la veille, qui ne s’est jamais connecté et qui porte un nom trop évident risque d’être rapidement identifié comme un leurre.

La réutilisation d’un ancien compte nécessite toutefois de nombreuses précautions, que nous allons détailler ci-dessous.

Avant de réutiliser un ancien compte, il faut vérifier qu’il n’est plus utilisé par :

• un service Windows
• une tâche planifiée
• une application
• un script
• une base de données
• un outil de sauvegarde
• un équipement réseau
• un partage de fichiers

Il faut également contrôler ses appartenances aux groupes, ses anciens droits administratifs, ses SPN, ses délégations Kerberos, son éventuel SIDHistory, les autorisations directement attribuées à son SID, sa synchronisation éventuelle vers Microsoft Entra ID.

Le compte leurre ne doit disposer d’aucun droit réel.

Il ne doit jamais être membre des groupes Domain Admins, Enterprise Admins ou Administrators. Son mot de passe doit être long, aléatoire, unique et conservé dans un coffre-fort.

Il ne faut pas utiliser un mot de passe faible pour rendre le compte plus attractif. L’objectif est de détecter l’attaquant, pas de lui fournir un accès fonctionnel.

Un compte désactivé permet déjà de détecter :

• les tentatives de password spraying
• l’utilisation d’anciens identifiants
• les mots de passe conservés sur une ancienne machine
• les applications ou scripts compromis

Cette méthode présente peu de risques et constitue un bon point de départ.

Un compte activé, sans aucun droit et fortement restreint, permet d’aller plus loin en détectant :

• les demandes de tickets Kerberos
• les tentatives de Kerberoasting
• les connexions vers un serveur leurre
• l’utilisation d’identifiants découverts dans un honeytoken

L’activation doit uniquement intervenir après avoir validé les restrictions de connexion et les règles de détection.

Un compte de service possédant un SPN peut attirer l’attention d’un attaquant réalisant une reconnaissance Active Directory. Exemple :

Compte : svc_sql_archive
Serveur : sql-archive.entreprise.local
Service : Microsoft SQL Server
Port : 1433

Le serveur correspondant doit idéalement exister dans le DNS et être associé à un véritable honeypot Trapster.

Lorsqu’un attaquant demande un ticket Kerberos pour ce service, le contrôleur de domaine génère un événement de sécurité. S’il tente ensuite de joindre le faux serveur SQL, Trapster enregistre également la connexion.

La corrélation entre ces deux événements permet d’obtenir une alerte particulièrement fiable.

Les événements les plus importants sont notamment :

• 4769 : demande de ticket de service Kerberos
• 4768 : demande de ticket d’authentification Kerberos
• 4771 : échec de préauthentification Kerberos
• 4776 : validation d’identifiants avec NTLM
• 4624 : ouverture de session réussie
• 4625 : échec d’ouverture de session
• 4648 : utilisation explicite d’identifiants
• 4740 : verrouillage du compte

Une authentification réussie avec le compte leurre doit être considérée comme un incident critique.

Une tentative échouée ou une demande de ticket Kerberos doit également déclencher une investigation, puisque personne n’est censé utiliser ce compte.

Un poste utilisateur est compromis à la suite d’un hameçonnage.

L’attaquant commence à explorer Active Directory et découvre le compte svc_sql_archive, associé au serveur sql-archive.

Il demande un ticket Kerberos pour ce service, puis tente de se connecter au serveur SQL.

Le contrôleur de domaine génère un événement 4769. Quelques secondes plus tard, Trapster enregistre une tentative de connexion provenant du même poste.

Le SIEM corrèle les deux événements et génère une alerte critique.

L’équipe de sécurité peut alors :

• identifier le poste compromis
• vérifier son activité dans l’EDR
• isoler la machine
• désactiver les comptes compromis
• rechercher d’autres déplacements latéraux

Le honeypot permet ainsi de détecter l’attaque avant que l’attaquant n’atteigne un véritable serveur de production.

Non. Le honeypot complète les solutions de sécurité existantes.

Le pare-feu contrôle les communications, l’EDR protège les machines, le SIEM corrèle les événements et le honeypot révèle les interactions qui ne devraient jamais avoir lieu.

Cette combinaison permet de renforcer la défense en profondeur et de réduire le temps nécessaire pour identifier une compromission.

La sécurité par la tromperie permet de retourner les méthodes de reconnaissance des attaquants contre eux.

En déployant de faux serveurs, de faux services, des fichiers leurres et des comptes techniques factices, l’entreprise crée un environnement dans lequel chaque interaction suspecte peut révéler une attaque.

Trapster simplifie cette démarche en permettant le déploiement de honeypots adaptés à l’infrastructure et l’intégration des alertes avec les outils de sécurité existants.

La création d’un compte leurre Active Directory complète ce dispositif. Un ancien compte technique peut constituer une base crédible, à condition d’être soigneusement audité, privé de tous ses anciens droits et correctement surveillé.

Le principe reste simple : le leurre doit sembler intéressant pour l’attaquant, sans jamais lui fournir un accès réel.