Deceiving those who come to deceive you: Honeytokens and padded cells
Cette publication est également disponible en :
Français (French)
« 兵者，詭道也 »
"All warfare is based on deception."
1. Facing threats: data breaches are becoming the norm
Data leaks are no longer the exception; they are the background noise of the web. IDOR (Insecure Direct Object Reference) vulnerabilities, where an identifier is manipulated to access someone else’s data, rank among the most common and easiest to exploit; often, all it takes is incrementing an integer in a request. Added to this are automated exfiltration, mass scraping, and API enumeration. The common thread among all these attacks is that they cause data to leave the system when it never should have.
The knee-jerk response is budgetary: buying increasingly expensive WAFs, stacking up signatures, and multiplying rules. Yet, detection based on potentially anomalous behavior inevitably generates false positives, as legitimate usage can sometimes mimic such patterns. We are shifting the problem, not solving it.
2. Tactical Response : regaining the initiative
Tactical Response flips the script. Instead of simply erecting walls, we set traps and prepare the terrain so that, when the attacker strikes, they find themselves at a disadvantage. We accept the possibility, or even the reality, of an ongoing intrusion, and we design the environment to reliably detect and smoothly neutralize it.
"The supreme art is to subdue the enemy without fighting." The goal is not to be impregnable. The aim is to ensure that a successful attack yields nothing and backfires on its perpetrator.
The centerpiece is the honeytoken: a decoy record (such as an account, IBAN, or email address) that is never generated by any business process and never accessed by any legitimate user. Its sole function is to be seen. If it appears in transit, there is no innocent explanation.
3. Application security cannot be bought for millions.
A multi-million-euro WAF doesn’t know your application; it simply applies generic rules. You, however, know which endpoints expose objects, which identifiers are enumerable, and which responses contain sensitive data. That intimate knowledge is worth more than any commercial signature.
Intelligent security means placing the right detection in the right spot: instead of inspecting thousands of incoming attack patterns, you monitor a handful of values that must never leave the system. It is a detection method with a zero false-positive rate, because it relies not on heuristics but on a hard fact: “this specific string is passing through the WAF.”
Secure intelligently, not more heavily. Application awareness is the best sensor.
4. The principle in a single image
A legitimate user never encounters a honeytoken; they access the actual production environment. An attacker who is enumerating or exfiltrating data, however, eventually triggers one and, without realizing it, is immediately diverted to a clone populated with fake data.
Schematic diagram – Padded Cell by Deception Technology
5. Preparing your application
5.1 - Plant honeytokens… at random intervals
Step one: inject decoy records into the production database, interspersed with real ones. The key to remaining inconspicuous is to avoid grouping them together. Honeytokens assigned consecutive IDs (98, 99, 100) or clustered at the end of the table would immediately stand out to an observant attacker. Instead, they are distributed at random intervals across the ID range, a few decoys scattered among genuine accounts at unpredictable positions.
To put it concretely, let’s imagine a classic table users, with the columns name, first name, email, address, IBAN, phone. Most of the lines correspond to real customers. But at certain randomly selected positions, IDs 1428, 3961, 7044…, we slip in an entirely fictitious record:
| id | name | firstname | address | IBAN | |
|---|---|---|---|---|---|
| 1427 | (real entry) | … | … | … | … |
| 1428 | Mickael | Culline | m.culline@love.me | 12 rue des Lilas, Papamica | CH76 9999 0000 1234 5678 9012 345 |
| 1429 | (real entry) | … | … | … | … |
This “Mickael Culline” does not exist. It is not the masked data of a real person; it is a completely fabricated identity, seemingly consistent (plausible name, valid IBAN format) but not linked to any actual individual. It serves only one purpose: to act as bait.
The key point is that each decoy carries at least one unique and unlikely value, such as an IBAN from a range reserved for this purpose or a dedicated email domain (e.g., @…decoy), that would never appear in a legitimate response. It is precisely this value that the WAF monitors in outbound traffic. Finally, the fact that a record is a decoy remains strictly internal information (a database flag that is never exposed); from the attacker’s perspective, there is nothing to distinguish “Mickael Culline” from a real customer.
5.2 - Build the decoy clone (padded cell)
Step two: deploy an exact replica of the application. Same code, same interface, same API schemas, but backed by a completely fake database. No real data must be accessible within it. Think of it as a padded cell: the attacker finds exactly what they expect, except that everything is fabricated. The illusion must be flawless; otherwise, the trap becomes obvious and is blown.
5.3 - Automated deployment via CI/CD
Production and the clone share the same application artifact; only the database differs. The CI/CD pipeline builds the image once and then deploys it twice: once with real seed data (plus honeytokens) and once with entirely fictitious seed data. This keeps both versions perfectly synchronized—any code update reaches both production and the decoy simultaneously, ensuring the illusion remains unbroken.
6. Deployment architecture
Target architecture
7. Configure your WAF (ModSecurity)
The entire containment mechanism relies on just two ModSecurity rules running on your existing Apache server. The first detects a honeytoken in the response body and flags the source; the second redirects flagged sources to the clone.
Step 1. Prepare your WAF.
SecRequestBodyAccess On
SecResponseBodyAccess On
SecRequestBodyLimitAction ProcessPartialStep 2. The IP collection—first, to be initialized in Phase 1.
### 5 - IP addresses collection for correlation:
SecAction phase:1,id:5,initcol:ip=%{REMOTE_ADDR},nolog
Step 3. Prepare a file containing all the decoy values we have placed.
...
m.culline@love.me
elodie.fournier17@example.test
lea.morel29@example.test
samuel.henry39@example.test
hugo.robin49@example.test
...Step 4. Identify whether a response contains any of these decoys
The `@pmFromFile` operator loads the list of decoy markers (using literal matching—fast and ReDoS-free). Upon detecting any honeytoken in the output, the flag `ip.padded_cell=1` is set with a 3-hour (10,800 s) expiration, which resets with each new trigger.
### 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"
Step 5. Transparently redirect the attacker to the Padded Cell.
Two crucial details. Phase 2 (not 1): in phase 1, the request body is not fully read, causing the proxy to fail with a `REQUEST_BODY phase incomplete` error. And `%{REQUEST_URI}` in the target: without the path, the backend receives an empty body; with it, the POST request and its JSON payload reach the clone intact.
### 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'"
From that moment on, the attacker is seamlessly redirected to the “padded cell”, using the same URL, with no errors or visible redirects. They believe they are continuing their exfiltration, while in reality, they are gathering nothing but decoys. Simultaneously, a qualified alert is sent to the SOC, not just another probabilistic signal, but confirmation that exfiltration was underway, given that a honeytoken never legitimately passes through the WAF. This containment creates a valuable window for observation:
- Trace back to initial vector. By replaying the attacker’s path up to the triggering honeytoken, the SOC identifies the specific vulnerability that was exploited (IDOR, authorization bypass, injection, etc.) and fixes it in the actual production environment.
- Observe safely. While the adversary manipulates fake data in a low-stakes environment, the team studies their TTPs in real time: targeted paths, enumeration cadence, and tooling.
- Enriching the CTI. IP addresses, fingerprints, and behaviors feed into Cyber Threat Intelligence databases, transforming an intrusion attempt into actionable intelligence.
8. Validate and test
- Negative test first. Navigate the application as a legitimate user: no honeytoken should ever appear in the response, and no state switch should occur. If this happens, the marker is not unique enough.
- Positive test next.Simulate an IDOR attack by enumerating IDs until you hit a decoy. Verify that Rule 100 triggers and the `padded_cell` action is applied.
- Containment. The subsequent request must be served by the clone (fake data), using the same URL, without a 403 error or visible redirection, and the POST body must successfully reach the decoy backend.
- Expiration. In the absence of a new trigger, verify that the system returns to normal after the duration specified in ModSecurity.
- Telemetry. Confirm that each trigger is sent to the SIEM: it is a high-confidence IOC.
9. Proof of Concept
10. Limitations and scope
No defense is a silver bullet, and deception technology is no exception. Three caveats are worth noting explicitly.
Ceception does not cover every scenario. The mechanism relies on the assumption that the attacker is enumerating targets, as seen in scraping or large-scale IDOR exploitation, where they will statistically eventually hit a decoy. However, an adversary targeting a specific real account, because they already know the victim’s ID, can exfiltrate data without ever touching a honeytoken. In this case, the “padded cell” is not triggered. Deception is a complementary detection layer, not a substitute for access control; the true fix remains eliminating the IDOR vulnerability at the source. Its effectiveness increases with the number and distribution of decoys.
“Free” does not mean “effortless”. ModSecurity requires no licensing fees, which is a significant advantage over commercial solutions. However, the complete system entails operational costs: hosting and maintaining a production-identical clone, keeping it synchronized with every release (hence the need for CI/CD), generating and maintaining credible fake datasets, and managing telemetry within the SOC. The investment shifts from software budgets to engineering resources, yet it remains negligible compared to the cost of a data breach.
It is stricly a defensive framework. Everything takes place within a perimeter you control: your application, your clone, and your rules. This is not about “hacking back” or attacking the attacker; rather, it involves keeping them occupied on a low-stakes battlefield. Finally, pay attention to SOC-side logs: observing an intruder may result in collecting data about them, which must be processed in compliance with applicable legal frameworks (such as GDPR or the Swiss nLPD). Disappointment is an active defensive stance, not a counterattack.
11. What this approach really changes
No “honey” data should legitimately pass through the WAF. If it does, it is necessarily an exfiltration. Not a probability, but a certainty. At that moment, the attacker is redirected to the clone and operates on fake data.
Meanwhile, the SOC observes. It watches the TTPs unfold in real time within a low-risk environment: which paths are targeted, the pace of enumeration, and the tools used. This provides the intelligence needed to enrich CTI, precisely identify the exploit, and remediate the vulnerability in the actual production environment.
Above all, this approach caps the volume of exfiltrated data. Instead of waking up to find millions of real records out in the wild, the organization is left with only a few hundred genuine rows before the switchover kicks in and returns nothing but fake data. The leak is contained, tracked, and worthless to the adversary.