Tromper qui vient vous tromper : Honeytokens et padded cell
Cette publication est également disponible en :
English (Anglais)
« 兵者，詭道也 »
« Toute guerre est fondée sur la tromperie. »
1. Faire face aux menaces : la fuite de donnée devient la norme
Les fuites de données ne sont plus l’exception, elles sont le bruit de fond du web. Les IDOR (Insecure Direct Object Reference), où l’on manipule un identifiant pour accéder aux données d’autrui, figurent parmi les vulnérabilités les plus fréquentes et les plus triviales à exploiter : il suffit souvent d’incrémenter un paramètre dans une requête. À cela s’ajoutent les exfiltrations automatisées, les scrapings massifs et les énumérations d’API. Le point commun de toutes ces attaques : elles exfiltrent de la donnée qui n’aurait jamais dû être accédée.
La réponse réflexe est budgétaire : acheter un WAF toujours plus cher, empiler des signatures, multiplier les règles. Mais une détection fondée sur des comportements potentiellement anormaux génère toujours du faux positif, parce qu’un usage légitime peut parfois y ressembler. On déplace le problème, on ne le résout pas.
2. Tactical Response : reprendre l'initiative
La Tactical Response renverse la posture. Plutôt que de seulement dresser des murs, on pose des pièges et on prépare le terrain pour que, le jour où l’attaquant agit, ce soit lui qui se retrouve en terrain défavorable. On accepte l’idée que l’intrusion est possible, voire déjà en cours, et on conçoit l’environnement pour la détecter de façon certaine et la neutraliser en douceur.
« L'art suprême est de soumettre l'ennemi sans combattre. » On ne cherche pas à être imprenable. On cherche à ce que l'attaque réussie ne rapporte rien et se retourne contre son auteur.
La pièce maîtresse, c’est le honeytoken : un enregistrement leurre (compte, IBAN, e-mail) qu’aucun flux métier ne produit jamais et qu’aucun utilisateur légitime ne consulte. Sa seule fonction est d’être vu. S’il apparaît en transit, il n’existe aucune explication innocente.
3. La sécurité applicative ne s'achète pas à coups de millions
Un WAF à plusieurs millions d’euros ne connaît pas votre application. Il applique des règles génériques. Vous, vous savez quels endpoints exposent des objets, quels identifiants sont énumérables, quelles réponses contiennent des données sensibles. Cette connaissance intime vaut plus que n’importe quelle signature commerciale.
Sécuriser intelligemment, c’est placer la bonne détection au bon endroit : non pas inspecter des milliers de motifs d’attaque en entrée, mais surveiller une poignée de valeurs qui ne doivent jamais sortir. Une détection à taux de faux positif nul, parce qu’elle ne repose pas sur une heuristique mais sur un fait : « cette chaîne précise est en train de traverser le WAF ».
Sécuriser intelligemment, pas plus durement. La connaissance de l'application est le meilleur capteur.
4. Le principe en une image
L’utilisateur légitime ne croise jamais un honeytoken : il atteint la vraie production. L’attaquant qui énumère ou exfiltre, lui, finit par en faire sortir un et bascule aussitôt, sans s’en apercevoir, vers un clone peuplé de fausses données.
Schéma de principe - Padded Cell par Deception Technology
5. Préparer son application
5.1 - Semer les honeytokens… à intervalle aléatoire
Première étape : injecter des enregistrements leurres dans la base de production, mêlés aux vrais. Le point clé pour rester discret : ne pas les regrouper. Des honeytokens alignés sur des id consécutifs (98, 99, 100) ou tous entassés en fin de table sautent aux yeux d’un attaquant attentif. On les répartit donc à intervalles aléatoires dans l’espace des identifiants, quelques leurres noyés parmi les vrais comptes, à des positions imprévisibles.
Concrètement, imaginons une table utilisateurs classique, avec les colonnes nom, prénom, email, adresse, IBAN, téléphone. La plupart des lignes correspondent à de vrais clients. Mais à certaines positions choisies au hasard, disons les id 1428, 3961, 7044…, on glisse un enregistrement entièrement fictif :
| id | nom | prénom | adresse | IBAN | |
|---|---|---|---|---|---|
| 1427 | (vrai client) | … | … | … | … |
| 1428 | Mickael | Culline | m.culline@love.me | 12 rue des Lilas, Papamica | CH76 9999 0000 1234 5678 9012 345 |
| 1429 | (vrai client) | … | … | … | … |
Ce « Mickael Culline » n’existe pas. Ce n’est pas la donnée masquée d’une personne réelle : c’est une identité intégralement inventée, cohérente en apparence (nom plausible, IBAN bien formé) mais qui ne renvoie à aucun individu. Elle n’a qu’une seule fonction : servir d’appât.
Le point essentiel est que chaque leurre porte au moins une valeur unique et improbable, un IBAN d’une plage que vous réservez à cet usage, un domaine e-mail dédié (@…decoy, par exemple), qui n’apparaîtra jamais dans une réponse légitime. C’est précisément cette valeur que le WAF surveillera en sortie. Enfin, le fait qu’une ligne soit un leurre reste une information strictement interne (un drapeau en base, jamais exposé) : du point de vue de l’attaquant, rien ne distingue « Mickael Culline » d’un vrai client.
5.2 - Construire le clone leurre (padded cell)
Deuxième étape : déployer une copie conforme de l’application, même code, même interface, mêmes schémas d’API, mais adossée à une base de données intégralement fausse. Aucune vraie donnée ne doit y être accessible. C’est la cellule capitonnée : l’attaquant y retrouve exactement ce qu’il attend, sauf que tout est factice. L’illusion doit être parfaite, sinon le piège se voit et brûle.
5.3 - Déploiement automatique par CI/CD
Prod et clone partagent le même artefact applicatif : seule la base change. Le pipeline CI/CD construit l’image une fois, puis la déploie deux fois, avec le seed réel (plus honeytokens) d’un côté, le seed 100 % fictif de l’autre. Les deux versions restent ainsi parfaitement synchronisées : toute évolution du code arrive simultanément sur la prod et sur le leurre, et l’illusion ne se fissure jamais.
6. Architecture de déploiement
Architecture cible
7. Configurer son WAF (ModSecurity)
Tout le dispositif de confinement tient en deux règles ModSecurity, sur un Apache que vous avez déjà. La première détecte un honeytoken dans le corps de réponse et marque la source ; la seconde confine les sources marquées vers le clone.
Etape1. Préparer son WAF
SecRequestBodyAccess On
SecResponseBodyAccess On
SecRequestBodyLimitAction ProcessPartialEtape2. La collection IP, d’abord, à initialiser en phase 1
### 5 - IP addresses collection for correlation:
SecAction phase:1,id:5,initcol:ip=%{REMOTE_ADDR},nolog
Etape3. Préparer un fichier avec l’ensemble des valeurs de leurres que nous avons placé
...
m.culline@love.me
elodie.fournier17@example.test
lea.morel29@example.test
samuel.henry39@example.test
hugo.robin49@example.test
...Etape4. Identifier si une réponse contient un de ces leurres
L’opérateur @pmFromFile charge la liste des marqueurs leurres (matching littéral, rapide, sans ReDoS). Au moindre honeytoken repéré en sortie, on pose ip.padded_cell=1 avec une expiration de 3 heures (10 800 s) qui se recharge à chaque nouveau déclenchement.
### 100 - Deception: compte leurre détecté dans le response body
SecRule RESPONSE_BODY "@pmFromFile deception-list.txt" \
"id:100,phase:4,log,\
msg:'Deception: Fake account detecte dans le response body',\
severity:'CRITICAL',\
tag:'deception-technology',tag:'decoy:account',tag:'honeytoken',\
setvar:ip.padded_cell=1,expirevar:ip.padded_cell=10800"
Etape5. Rediriger de manière transparente l’attaquant sur le Padded Cell
Deux détails décisifs. La phase 2 (et non 1) : en phase 1, le corps de requête n’est pas entièrement lu et le proxy échoue sur un REQUEST_BODY phase incomplete. Et %{REQUEST_URI} dans la cible : sans le chemin, le backend reçoit un corps vide. Avec, le POST et son payload JSON arrivent intacts sur le clone.
### 101 - Padded cell : proxy transparent vers le backend leurre
SecRule IP:padded_cell "@eq 1" \
"id:101,phase:2,proxy:http://127.0.0.1:8081%{REQUEST_URI},log,\
msg:'Padded cell active: proxy vers backend leurre',\
tag:'deception-technology',tag:'padded-cell'"
À partir de cet instant, l’attaquant est redirigé de façon totalement transparente vers la padded cell : même URL, pas d’erreur, pas de redirection apparente. Il croit poursuivre son exfiltration alors qu’il ne récolte plus que du leurre. Au même moment, une alerte qualifiée remonte au SOC, pas un signal probabiliste de plus, mais la confirmation qu’une exfiltration était en cours, puisqu’un honeytoken ne franchit jamais le WAF de façon légitime. Ce confinement ouvre alors une fenêtre d’observation précieuse :
- Remonter au vecteur initial. En rejouant la trajectoire de l’attaquant jusqu’au honeytoken déclencheur, le SOC identifie la faille réellement exploitée (IDOR, contournement d’autorisation, injection, etc…) et la corrige sur la vraie production.
- Observer sans risque. Pendant que l’adversaire manipule de fausses données sur un environnement sans enjeu, l’équipe étudie ses TTPs en direct : routes ciblées, cadence d’énumération, outillage.
- Enrichir la CTI. IP, empreintes et comportements viennent alimenter les bases de Cyber Threat Intelligence, transformant une tentative d’intrusion en renseignement exploitable.
8. Valider et tester
- Négatif d’abord. Parcourez l’application en utilisateur légitime : aucun honeytoken ne doit jamais apparaître en réponse, aucune bascule ne doit se produire. Si c’est le cas, un marqueur n’est pas assez unique.
- Positif ensuite. Simulez l’IDOR en énumérant les id jusqu’à toucher un leurre. Vérifiez que la règle 100 déclenche et que padded_cell est posé.
- Confinement. La requête suivante doit être servie par le clone (données fausses), même URL, sans 403 ni redirection visible, et le body POST doit bien arriver au backend leurre.
- Expiration. Sans nouveau déclenchement, vérifiez le retour à la normale après la durée spécifiée dans ModSecurity.
- Télémétrie. Confirmez que chaque déclenchement part vers le SIEM : c’est un IOC de haute confiance.
9. Proof of Concept
10. Limites & cadre
Aucune défense n’est une solution miracle, et la déception n’y échappe pas. Trois réserves méritent d’être posées noir sur blanc.
La déception ne couvre pas tous les scénarios. Le dispositif repose sur une hypothèse : l’attaquant énumère. C’est le cas d’un scraping ou d’une exploitation d’IDOR à grande échelle, qui finit statistiquement par heurter un leurre. Mais un adversaire qui cible un compte réel précis, parce qu’il connaît déjà l’identifiant de sa victime, peut exfiltrer sans jamais toucher un honeytoken. La padded cell ne se déclenche alors pas. La déception est une couche de détection complémentaire, pas un substitut au contrôle d’accès : la vraie correction reste de supprimer l’IDOR à la source. Elle protège d’autant mieux qu’on multiplie et qu’on dissémine les leurres.
Gratuit ne veut pas dire sans effort. ModSecurity ne coûte pas de licence, et c’est un vrai atout face aux solutions commerciales. Mais le dispositif complet a un coût opérationnel : héberger et maintenir un clone à iso-production, le garder synchronisé à chaque release (d’où le CI/CD), générer et entretenir des jeux de fausses données crédibles, et exploiter la télémétrie côté SOC. L’investissement se déplace du budget logiciel vers l’ingénierie, mais il reste sans commune mesure avec le prix d’une fuite.
Un cadre défensif, strictement. Tout se joue sur un périmètre que vous maîtrisez : votre application, votre clone, vos règles. Il ne s’agit pas de hack-back, on n’attaque pas l’attaquant, on l’occupe sur un terrain sans enjeu. Attention enfin aux logs côté SOC : observer un intrus peut amener à collecter des données le concernant, à traiter dans le respect du cadre légal applicable (RGPD, nLPD en Suisse). La déception est une posture de défense active, pas une contre-attaque.
11. Ce que cette approche change vraiment
Aucune donnée honey ne devrait franchir le WAF de façon légitime. Si elle le franchit, c’est forcément une exfiltration. Pas une probabilité, une certitude. À partir de cet instant, l’attaquant est déplacé vers le clone et travaille sur du faux.
Pendant ce temps, le SOC observe. Il voit les TTPs se dérouler en direct sur un environnement sans enjeu : quelles routes sont ciblées, quel rythme d’énumération, quels outils. De quoi enrichir la CTI, identifier précisément l’exploitation, et corriger la vulnérabilité sur la vraie prod.
Et surtout, l’approche plafonne le volume exfiltré. Au lieu de se réveiller avec des millions d’enregistrements réels dans la nature, on se retrouve avec quelques centaines de vrais lignes, avant que la bascule ne prenne le relais et ne retourne que des fausses données. La fuite est contenue, tracée, et sans valeur pour l’adversaire.