Honeypots & Honeytokens — Déception Défensive

Pourquoi la déception est efficace

Les honeypots/honeytokens exploitent un fait simple : tout accès à un leurre est suspect.

• Peu de bruit (si bien conçu).
• Détection rapide des mouvements latéraux.
• Bon complément à la détection comportementale.

Honeypot vs Honeytoken

• Honeypot : système/service “leurre” qui attire l’attaquant (ex : faux serveur SSH).
• Honeytoken : artefact piégé (ex : faux identifiant, fichier leurre, clé API canari) qui déclenche une alerte lorsqu’il est utilisé.

Types de honeypots

Low-interaction

• Simule un service ; risque réduit.
• Bon pour détecter scans/automates.

Medium/High-interaction

• Environnement plus réaliste.
• Meilleure visibilité sur TTP mais risque plus élevé (pivot).

Exemples de honeytokens (défensifs)

• “Canary credentials” : identifiants factices surveillés.
• Fichiers leurres : passwords.xlsx, vpn-config.ovpn (factices) avec télémétrie.
• URL ou domaine canari.
• Clés cloud canari (non privilégiées) monitorées.

Toujours configurer des tokens de sorte qu’ils ne permettent pas d’accès réel significatif.

Bonnes pratiques de déploiement

• Isolation : segment dédié, egress limité, aucun accès à la prod.
• Observabilité : logs complets, horodatage fiable, capture des interactions.
• Alerting : alerte temps réel vers le SOC/SIEM.
• Hygiène : ne pas réutiliser de secrets réels ; éviter toute donnée personnelle inutile.

Intégration SIEM (pattern)

• Émettre un événement normalisé : honeytoken_triggered ou honeypot_interaction.
• Enrichir : host, user, segment, criticité, destination.
• Déclencher un playbook : ticket + isolation EDR + collecte d’artefacts.

Risques & précautions

• Ne pas transformer le honeypot en point de pivot.
• Clarifier le cadre légal et les règles internes (monitoring, privacy).
• Informer les équipes (au moins le SOC/IR) pour éviter les faux positifs.

Voir aussi

• SIEM — Collecte, Corrélation et Détection
• Active Defense — Tarpitting & Poisoning