Prendre rendez-vous

Honeypots & Deception

Comment détecter tôt les attaquants dans votre réseau interne grâce aux honeypots, honeytokens et plateformes de deception – avec une qualité de signal élevée et, par construction, très peu de faux positifs.

Les attaquants qui ont franchi les défenses périmétriques et endpoint se déplacent souvent longtemps dans les réseaux internes sans être détectés. Les technologies de deception interviennent précisément à ce niveau : systèmes leurres (honeypots), données et identifiants piégés (honeytokens) ainsi qu'environnements de tromperie orchestrés de manière centralisée, qui n'ont strictement aucune fonction pour les utilisateurs légitimes. Comme personne n'a de raison de toucher à ces ressources, presque chaque interaction constitue un signal d'attaque fiable – le nombre de faux positifs est, par construction, très faible. Cet article passe en revue les différentes variantes, leur placement judicieux, le cadre juridique en Allemagne ainsi que les limites et la charge d'exploitation.

L'essentiel en un coup d'œil

01

Honeypots à faible vs forte interaction

Les honeypots sont des systèmes sans finalité productive dont la seule mission est d'être attaqués – chaque interaction est donc par définition au moins suspecte. Les honeypots à faible interaction n'émulent des services ou protocoles isolés que de manière superficielle ; ils sont économes en ressources, rapides à déployer et peu risqués, mais offrent des enseignements limités et sont plus facilement identifiables comme leurres par les attaquants. Les honeypots à forte interaction mettent à disposition de véritables systèmes d'exploitation et applications et permettent une analyse approfondie des outils et des modes opératoires – au prix d'une charge d'exploitation et de sécurisation nettement plus élevée. Dans son étude de référence, l'ENISA a évalué 30 solutions de honeypots selon exactement cette taxonomie, en couvrant les variantes côté serveur comme côté client.

02

Honeytokens et canaries

Les honeytokens transposent le principe du leurre des systèmes vers les données et les identifiants : clés API piégées, documents, enregistrements de base de données, noms DNS ou adresses e-mail que personne n'utilise en exploitation normale. Si un tel objet est ouvert ou si une clé piégée est utilisée, il s'agit d'un indicateur de compromission quasi univoque – y compris là où les capteurs classiques font défaut, par exemple dans les services SaaS ou en cas d'exfiltration de données. Des services librement accessibles comme Canarytokens de Thinkst proposent plus de 30 types de tokens, des clés AWS aux fichiers kubeconfig en passant par les documents Office, et permettent de démarrer avec un effort minimal. Le NIST décrit cette démarche (« tainting »), aux côtés du détournement des attaquants (« misdirection »), comme une approche de la technique de cyber-résilience appelée deception.

03

Les plateformes de deception dans la pile de détection

La détection classique via SIEM, EDR ou NDR doit extraire les attaques de volumes massifs d'événements légitimes – avec le bruit de fond et l'effort de réglage correspondants. La deception inverse cette logique : comme les utilisateurs légitimes ne touchent jamais aux leurres et aux honeytokens, pratiquement chaque alerte est pertinente. Les plateformes de deception orchestrent les leurres de manière centralisée, injectent les alertes dans le SIEM ou le SOC et fournissent une télémétrie riche en contexte pour la réponse à incident. Depuis 2022, MITRE Engage offre en outre un framework dédié qui structure les activités de denial, de deception et d'adversary engagement et les aligne sur des comportements d'attaquants réellement observés. Pour les opérateurs d'installations critiques, la deception peut compléter les systèmes de détection d'attaques exigés par le § 31 BSIG – mais elle ne saurait les remplacer.

04

Un placement judicieux

La deception est efficace là où les attaquants se déplacent après l'accès initial : dans les segments de réseau internes, dans l'Active Directory, sur les systèmes de fichiers et de sauvegarde, dans les environnements cloud et, de plus en plus, dans les réseaux OT. Les bonnes pratiques consistent à déployer des systèmes leurres dans chaque segment pertinent et des honeytokens dans les dépôts de code, les fichiers de configuration et les magasins d'identifiants – c'est-à-dire le long des chemins qu'empruntent typiquement les mouvements latéraux et l'élévation de privilèges. Un honeypot exposé publiquement sur Internet ne génère en revanche essentiellement que du bruit de fond issu des scans de masse et contribue peu à la détection d'attaques ciblées contre votre propre réseau. La crédibilité est déterminante : les conventions de nommage, les niveaux de correctifs et les métadonnées des leurres doivent correspondre à l'environnement réel, et l'infrastructure de deception doit être strictement séparée du réseau de production.

05

Cadre juridique en Allemagne

L'exploitation de honeypots sur sa propre infrastructure est licite en tant que pure mesure de détection – l'attaquant accède de son propre chef aux systèmes de l'exploitant, ce qui ne constitue pas une « incitation » pénalement répréhensible. Il faut clairement distinguer cela du « hack back » : les accès actifs à des systèmes tiers ne sont pas autorisés pour les entreprises en Allemagne et restent punissables faute de base légale d'autorisation (notamment §§ 202a et suivants StGB) ; la deception s'arrête à la frontière de son propre réseau. Sur le plan de la protection des données, le traitement des données ainsi générées (par exemple des adresses IP) peut régulièrement se fonder sur l'intérêt légitime au sens de l'art. 6, par. 1, point f) du RGPD – le considérant 49 mentionne expressément la garantie de la sécurité des réseaux et de l'information, dans la mesure où le traitement est strictement nécessaire et proportionné à cette fin. Une vigilance particulière s'impose dans le cas où un honeypot à forte interaction compromis serait détourné comme tremplin pour des attaques contre des tiers : la doctrine pénale évoque ici des risques de complicité pour les exploitants, raison pour laquelle le trafic sortant doit être strictement limité au niveau technique.

06

Limites et charge d'exploitation

La deception ne détecte que les attaquants qui interagissent effectivement avec les leurres – elle ne remplace ni la prévention ni la détection généralisée, mais complète les deux par une source de signal supplémentaire d'une grande précision. Les attaquants expérimentés tentent de démasquer les honeypots par fingerprinting ; des artefacts d'émulation, des systèmes invraisemblables ou l'absence de traces d'utilisation détruisent l'illusion et dévalorisent la mesure. L'exploitation exige donc un entretien continu : mise à jour des leurres, adaptation aux évolutions de l'environnement, playbooks définis pour les alertes et responsabilités claires au sein du SOC. L'étude de l'ENISA identifiait déjà l'ergonomie, la documentation et les besoins en personnel comme des obstacles majeurs à l'utilisation des honeypots – les plateformes modernes et les services de honeytokens abaissent nettement ce seuil, sans toutefois éliminer complètement l'effort de maintenance.

Normes & sources

Le contenu de cette page s'appuie sur les guides et études suivants, accessibles publiquement.

ENISA · 2012

Proactive Detection of Security Incidents II – Honeypots

Étude de référence évaluant 30 solutions de honeypots selon la taxonomie faible/forte interaction (côté serveur et côté client), y compris les obstacles à leur déploiement.

MITRE · 2022

MITRE Engage v1.0

Framework de planification des activités de denial, deception et adversary engagement ; successeur de MITRE Shield, publié au printemps 2022.

NIST · 2021

NIST SP 800-160 Vol. 2 Rev. 1: Developing Cyber-Resilient Systems

Décrit la deception comme technique de cyber-résilience avec les approches misdirection (détournement vers des environnements contrôlés) et tainting (ressources marquées).

Thinkst · 2026

Canarytokens Documentation

Documentation du service gratuit de honeytokens comptant plus de 30 types de tokens, dont des clés cloud, des documents Office et des déclencheurs basés sur DNS.

KriPoZ – Kriminalpolitische Zeitschrift · 2024

Research Honeypots – Strafbarkeitsrisiken für IT-Sicherheitsforschende?

Analyse juridique des risques pénaux liés à l'exploitation de honeypots, notamment la problématique de la complicité en cas de détournement d'un honeypot comme tremplin d'attaque.

Bundesministerium der Justiz / gesetze-im-internet.de · 2025

Gesetz über das Bundesamt für Sicherheit in der Informationstechnik (BSIG)

Le § 31 BSIG impose aux opérateurs d'installations critiques des systèmes de détection d'attaques conformes à l'état de l'art ; version issue de la transposition de NIS2.

Intégrer la deception de manière ciblée dans votre détection ?

Nous évaluons avec vous où les honeypots et honeytokens apportent le plus grand gain de détection dans votre environnement – de façon neutre vis-à-vis des éditeurs, juridiquement rigoureuse et intégrée à votre SOC. Parlons-en.