Decoys as Zero Day Sensors: Deception, Isolation and Early Signal

Decoys detect zero days because they have no legitimate users, so benign traffic is close to zero and any unusual request stands out. Unlike signatures or anomaly models, they do not need prior knowledge of an exploit. They work best against exploits sprayed across the internet or flat networks, not targeted attacks.

Most of the security stack we buy is built to recognise things that have already been seen somewhere else, which is exactly why it struggles with zero days: a signature cannot exist for an exploit nobody has catalogued, a patch cannot exist for a flaw the vendor does not know about, and an anomaly model trained on busy production traffic has to find one malicious request in a haystack of millions of legitimate ones. Decoys can expose previously unknown exploitation without an exploit specific signature, because they remove legitimate application use from the problem, which makes suspicious interactions far easier to investigate. Internet facing decoys still receive substantial background traffic from scanners and automated tools, so an unexpected interaction is a lead rather than proof, and confirming a zero day means analysing what the attacker actually achieved.

This post argues that decoys can expose previously unknown exploitation while it is still quiet, that the evidence for this is now much stronger than anecdote, and that their value depends on three things done well: services realistic enough to be exploited, containment strong enough to survive that exploitation, and investigation fast enough to act on unfamiliar requests and their effects. Where I lean on published research I have tried to state exactly what each source measured, and the links are collected at the end.

1. The core idea: a system nobody should touch

A decoy is any asset that exists only to be interacted with by an adversary: a honeypot that emulates a VPN concentrator, a fake admin portal, a database with plausible but worthless rows, a credential that should never be used, or a document that phones home when opened. Because no employee, customer or batch job has any reason to talk to it, the base rate of legitimate business activity is zero; scanners, crawlers and research projects still generate a substantial volume of automated traffic, but much of it is repetitive enough to classify and set aside, and this single property changes the economics of detection in a way that almost nothing else in the stack does.

For zero day discovery the consequence is subtle but important. A production VPN gateway sees so much traffic that a novel exploit attempt is statistically invisible until it succeeds and something downstream breaks, whereas a decoy of the same gateway, sitting on an address with no business purpose, sees only scanners, crawlers and attackers, which means a request shape that has never been seen before stands out against a background that, while large, is mostly made of patterns already seen many times. MITRE put the asymmetry neatly when it launched its Engage framework: with deception, it said, “the adversary only needs to be wrong once”, which reverses the usual complaint that defenders have to be right every time.

The claim I am making is deliberately narrow. Decoys do not find every zero day, they are poor at catching targeted attacks against assets the attacker has already mapped, and they only see exploitation that reaches them, but for the class of exploits that are sprayed across the internet or across a flat internal network, they are one of the earliest and cleanest sensors available.

2. A short history of lying to attackers

The idea is older than most of the tools we now use to implement it. Clifford Stoll’s The Cuckoo’s Egg (1989) and Bill Cheswick’s paper An Evening with Berferd (1991) both describe defenders deliberately leading an intruder around a controlled environment in order to watch what he did, and Lance Spitzner’s history of the field treats those two works as the first public documentation of honeypot concepts, followed by Fred Cohen’s Deception Toolkit in 1997 and the first commercial product, CyberCop Sting, in 1998.

The Honeynet Project then turned this from craft into architecture. Its “Know Your Enemy” papers insisted that every deployment satisfy two requirements, Data Control and Data Capture: contain what the attacker can do, and record everything they do without them noticing. That vocabulary is still the right one, and it underpins the isolation design later in this post.

The early honeynets also produced one of the first well documented cases of a decoy confirming live exploitation for a defender community. In January 2002 CERT/CC issued advisory CA-2002-01, stating that it had used network traces provided by the Honeynet Project to confirm that the Solaris CDE dtspcd buffer overflow was being actively exploited. To be precise about it, that flaw had already been disclosed the previous November, so this was confirmation of in the wild use rather than discovery of an unknown bug, but it established the pattern that matters here: a monitored system with no real users provided the evidence that changed the advisory.

The modern formalisation is MITRE Engage, launched in 2022 as a planning framework for adversary engagement, deception and denial, which maps its activities onto ATT&CK and treats deception as a programme with goals rather than a box on the network.

3. The evidence that decoys see unknown exploits first

The strongest argument for decoys is that they keep catching real zero days in the wild, and increasingly they do it weeks before the vendor advisory. The table below lists the cases I think are well enough documented to rely on, with a note on what kind of sensor actually saw the activity, because that distinction matters.

The PTZOptics case is the cleanest illustration of the mechanism. In GreyNoise’s own words, “an attacker had developed and automated a zero-day vulnerability exploit” and was spraying it across the internet, which meant it inevitably hit a sensor whose only job was to notice unfamiliar requests; as GreyNoise’s technical write up describes, the defenders then worked backwards from the captured payload to the two vulnerabilities and disclosed them through VulnCheck. The FortiWeb case follows the same shape, with a vendor specific honeypot catching a working chain that researchers at watchTowr later reproduced, and it also shows a second benefit: the honeypot evidence was public while the vendor was still silent, so defenders who watched decoy telemetry had weeks of warning that nobody else did.

Log4Shell is included precisely because it cuts the other way: the earliest signal came from a large production edge, and GreyNoise’s sensors saw exploitation attempts from 9 December once proof of concept code was circulating, which is a reminder that decoys catch sprayed exploitation well and quiet, targeted testing much less well.

GreyNoise’s Early Warning Signals research is a different kind of evidence and deserves to be kept separate from these captures. Across 216 spikes in activity against enterprise edge technologies observed from September 2024, GreyNoise reports that 80 percent were followed by a new CVE for the same technology within six weeks and 50 percent within three weeks. That is a correlation between attacker activity and later disclosure, not a captured exploit. It does not establish that the spikes exploited the vulnerabilities later disclosed; the report publishes no baseline for how often those products receive a CVE in an arbitrary six week window, and vendors like these publish advisories frequently; and it has not been validated prospectively, so it does not imply that a new deployment would anticipate disclosures 80 percent of the time. Its authors also note the pattern held only for edge products from a specific set of vendors. The fair reading is that a spike against a product you run is a reason to raise readiness, which is how section 6 uses it, rather than a forecast.

The broader context explains why this matters so much now. Google’s Threat Intelligence Group tracked 75 zero days exploited in 2024, of which 33 targeted enterprise technology and 20 of those hit security and networking products, which are exactly the internet facing edge devices that are easiest to impersonate with a decoy and hardest to instrument with conventional endpoint tooling.

4. Designing decoys that attract zero day exploitation

A decoy only earns its keep if the exploit you care about actually reaches it and actually runs far enough to reveal itself, so the design problem has two halves: being worth attacking, and being real enough to be exploited rather than merely probed. The following principles are the ones I would insist on.

1. Impersonate what attackers are hunting, not what is convenient to emulate. The GTIG and GreyNoise data both point at edge products: VPN concentrators, firewalls, web application firewalls, managed file transfer and remote access gateways. A decoy fleet that mirrors the vendors and product lines you actually run at your perimeter gives you a sensor for the exploits most likely to be aimed at you, and a fleet that also covers the vendors you do not run gives you a view of the wider campaign.
2. Prefer high interaction for zero day work. Low and medium interaction honeypots answer the requests their authors anticipated, which is fine for credential spraying but weak for novel exploits, because an unknown exploit usually targets a code path the emulator never implemented, so you may capture the first request but never see the second stage. Running the vendor’s own virtual appliance or real firmware, where licensing allows, means the vulnerable code is genuinely present and the full chain can execute inside your containment.
3. Be indistinguishable from the real thing on the wire. Vetterl and Clayton showed at USENIX WOOT 2018 that the popular low and medium interaction honeypots could be fingerprinted at internet scale with a single packet, identifying 7,605 instances, because they relied on off the shelf protocol libraries that behave subtly differently from the servers they impersonate. Banners, TLS certificates, cipher ordering, HTTP header order, favicon hashes, error pages and timing all need to match the real product, and the simplest way to achieve that is to run the real product.
4. Give it a believable life. Attackers build target lists from certificate transparency logs, passive DNS and internet scan datasets, so a decoy needs a plausible hostname, a real certificate, sensible DNS and an address range that does not scream research network. Spreading sensors across several providers and, if you can, some of your own address space, avoids the trap of every decoy living in one well known cloud block.
5. Keep patch parity deliberate. The same Cambridge work found that the SSH honeypots whose patch level it could determine were often badly out of date, with 27 percent not updated within the previous 31 months. For zero day hunting the decoy should generally run the current, fully patched release, because an exploit that succeeds against a fully patched system is by definition interesting, while a separate set of intentionally lagging versions can catch n day exploitation and tell you how quickly attackers weaponise new advisories.
6. Seed the inside as well as the edge. Internet facing decoys catch initial access exploits, but many zero days are used after a foothold, against internal management interfaces, hypervisors and identity systems. Internal decoys and honeytokens, such as fake credentials, cloud keys, VPN profiles and documents, are cheap to place and, as Thinkst describes, tokens that require an attacker to actively use them generate almost no false positives, which makes them ideal tripwires deep inside the estate.

5. Containing compromised decoys

The uncomfortable truth about a decoy built to catch zero days is that you are deliberately running vulnerable, attacker reachable software and hoping it gets owned, so the isolation has to assume the decoy is fully compromised from the first minute. An internet connected sensor cannot be air gapped, so what people usually mean by “air gapping the decoys” is really containment, built from three separations: the decoy shares nothing with production, the attacker cannot use the decoy to reach anyone else, and the evidence leaves the decoy by a path the attacker cannot travel back along. The Honeynet Project’s warning still applies: Data Control mitigates risk, it does not eliminate it, and every extra outbound freedom you give the attacker buys more intelligence at the price of more liability.

Separation from production. Decoys should live in their own cloud organisation or on their own hardware, with no shared identity provider, no domain join, no shared secrets store, no shared CI pipeline keys, no shared logging agents and no shared management plane. The test I use is simple: if an attacker obtained root on the decoy and every credential on its disk, is there any token, trust relationship, route or DNS zone that gets them one step closer to a real system? If the answer is anything other than no, the decoy is a liability rather than a sensor. Internal decoys are harder because they must look like part of the estate, so they should sit on segments where they are reachable but from which nothing is reachable, with their own local accounts and no trust back into the directory.

Data Control on egress. Outbound traffic from the decoy enclave should pass through a gateway the decoy cannot see or configure, with default deny, per destination rate limits, and a resolver that answers from a sinkhole so that second stage downloads and callback domains are recorded without being reached. Where you do want to capture a second stage payload, a recording proxy that fetches once, stores the object and serves it back gives you the sample without letting the host talk freely, and an inline intrusion prevention layer can drop or rewrite anything that looks like an attack leaving the enclave, which is the modern equivalent of the Honeynet’s snort inline honeywall.

Capture from below, not from inside. Anything you install inside the guest, such as an EDR agent or a logging daemon, is visible to the attacker and can be killed, tampered with or used to fingerprint the decoy. Capture should come from underneath: full packet capture from a hypervisor tap or cloud traffic mirroring, session keys exported by the appliance or its load balancer so TLS can be decrypted after the fact, virtual machine introspection or snapshots for memory and disk, and command logging at the hypervisor or serial console layer.

One way telemetry. Evidence should leave the decoy enclave along a single outbound path into a separate analysis enclave, never by analysts logging into the decoy from the corporate network, and the flow has three stages: trusted capture, an ingestion store, and an analysis collector. For on premises sensors a hardware data diode enforces the one way property physically. Cloud sensors have no equivalent, so there the boundary is access control rather than physics: the capture layer beneath the decoy writes into an ingestion store in a separate account, using credentials that can create objects but cannot read, list or delete them, and the collector pulls from that store rather than accepting connections, because a collector that receives pushes is by definition accepting traffic. Write permission alone does not stop an attacker who steals those credentials from overwriting earlier evidence, so overwrites have to be prevented explicitly, for example with S3 conditional writes that refuse to replace an existing object, combined with versioning or object lock. Everything that arrives, telemetry and samples alike, should be treated as hostile input: parsed defensively, never trusted for its own claims about what happened, and detonated only in a third, fully offline sandbox.

Disposability. Every decoy should be rebuilt from a golden image on a schedule and immediately after any confirmed compromise, with the pre revert snapshot preserved as evidence, and there should be a tested kill switch that isolates the whole enclave in seconds if a decoy starts being used to attack third parties.

flowchart LR
    internet["Internet<br/>attackers and scanners"]
    subgraph decoy["Decoy enclave"]
        appliances["Decoy appliances<br/>real vendor images,<br/>current and older builds"]
        egress["Egress gateway<br/>default deny, rate limits,<br/>sinkhole DNS, recording proxy"]
        capture["Capture from below<br/>hypervisor tap, full pcap,<br/>snapshots, TLS session keys"]
    end
    ingest["Ingestion store<br/>separate account,<br/>create only, no overwrite"]
    subgraph analysis["Analysis enclave"]
        collector["Collector<br/>pulls from the store,<br/>treats input as hostile"]
        sandbox["Offline sandbox<br/>detonate samples"]
        triage["Triage<br/>novel templates,<br/>retro hunt production logs"]
    end
    production["Production estate<br/>no route, no shared identity, no shared secrets"]
    internet --> appliances
    appliances -- all egress --> egress
    appliances -. observed by .-> capture
    capture == write only ==> ingest
    collector -- pulls --> ingest
    collector --> sandbox --> triage
    decoy x-. no path .-x production

The decoy can only reach the internet through the egress gateway, capture happens underneath it rather than inside it, and evidence lands in a create only ingestion store that the analysis enclave pulls from, so nothing in the decoy enclave ever holds a connection into analysis, and production has no route or trust relationship to either zone.

6. Observing meaningful signals early

An internet facing decoy is never quiet, because it is scanned constantly, so the practical skill is not collecting data but separating the tiny amount of novelty from the enormous volume of commodity traffic, and doing it fast enough to act before an advisory, or an attacker, forces the pace. I find it useful to think in three tiers of signal, each with its own response.

The techniques that move a finding up that ladder quickly are these.

1. Subtract the known, then study the residue. Tag every request against published exploit signatures and known scanner fingerprints, and treat whatever remains as the candidate set. This is essentially what GreyNoise described with Sift in the PTZOptics case, using automation to surface traffic that matched no known threat for a human to examine, and it scales because the residue is small.
2. Cluster on request shape, not source address. Attackers rotate infrastructure constantly, but an exploit has a structure. Normalising requests into templates, by stripping hostnames, random tokens and encoding differences, lets you alert on the first sighting of a template and then watch how fast it spreads across sensors, which distinguishes one researcher poking at a product from an automated campaign.
3. Watch for effects, not only requests. A request log tells you what was attempted, while a diff of accounts, configuration, processes and filesystem tells you what worked. The FortiWeb exploit’s observable outcome was the creation of new administrator accounts, which is a strong signal on a decoy that no human ever administers, though it still needs explaining, because stolen or default credentials leave exactly the same artefact.
4. Run differential decoys. Deploying the same product at the current patch level and at older levels side by side turns the decoy fleet into an experiment: exploitation that only succeeds against older builds is n day activity, while exploitation that succeeds against the fully patched build is the strongest early indicator of a zero day you can get without a vendor telling you. Before calling it a probable zero day, though, confirm the exact version and configuration of the decoy that was hit, rule out credential reuse, misconfiguration and known but unpatched flaws, and reproduce the exploitation against a clean build of the same release.
5. Treat per technology spikes as a leading indicator. GreyNoise’s study found spikes against specific edge technologies were followed by a new CVE within six weeks in 80 percent of the cases it examined. Whatever the underlying cause, a sharp rise in probing against a product you run is a reasonable trigger to restrict its management interfaces, raise logging and pre stage change windows before any advisory exists.
6. Retro hunt your production edge immediately. A decoy finding is most valuable when it tells you where to look in the real estate, and Log4Shell showed why the lookback matters: Cloudflare’s earliest evidence predated disclosure by over a week, which meant defenders who only searched from the disclosure date forward missed the first activity. Every novel template should be searched backwards through production web, VPN and firewall logs as far as retention allows.
7. Plant tokens inside the decoy. Honeytokens left on the decoy itself, such as credentials, cloud keys and configuration files, extend visibility into what the attacker does after the exploit lands, and because they alert out of band they still fire if the attacker has disabled logging on the host.
8. Pre agree the playbook. The difference between a decoy that finds a zero day and one that helps you is whether someone owns the next four hours: who reviews novel tier findings, who can apply a production mitigation without a change board, and who contacts the vendor, CERT or a coordinator such as VulnCheck for responsible disclosure.

7. Document honeytokens: files that call home

Network decoys tell you someone is attacking; document honeytokens tell you someone has already got inside and is reading, copying or exfiltrating, which makes them the natural complement to everything above. The mechanism is always the same: the file contains a reference that makes the application opening it perform a network lookup against an address unique to that one file, so the lookup itself is the alert. Because the address was never used anywhere else, a single resolution tells you that this specific token was resolved or accessed; whether a person opened the document, or a mail scanner, sandbox, indexer or other automated process handled it, is the next question to answer (Thinkst, for example, documents PDF token alerts caused by Palo Alto WildFire analysing the file), by identifying the triggering process and correlating with other evidence.

The instinct is to reach for embedded JavaScript in a PDF, but in practice the most reliable tokens use the least privileged callback available. Script in PDFs is frequently disabled, prompts the user, or gets the file flagged by mail and endpoint scanners, whereas a passive lookup is far less conspicuous. Thinkst’s open source Adobe PDF Canarytoken, for example, works by getting a reasonably compliant reader to perform a DNS lookup on a unique hostname when the document opens, and the documentation is candid that this tells you the document was opened and gives only a rough idea of where. The same family of techniques extends well beyond PDFs.

Placement matters more than cleverness. Tokens belong where legitimate users have no reason to go but attackers always do: file shares with enticing names, mail archives, backup sets, object storage buckets, code repositories, password manager folders, and inside the decoys themselves, so that the post exploitation phase of a zero day captured in section 3 also tells you what the attacker went looking for. An alert whose source sits outside your estate deserves particular urgency, but it does not by itself prove the file has left: a DNS token usually reports the resolver rather than the reader, and many organisations resolve through external providers. Correlate the alert with file access logs, the process that touched the file and egress records before concluding that data was exfiltrated. Profiling your own scanners and indexers in advance, so their callbacks can be recognised, is what keeps these alerts low noise.

The honest limitation is that silence proves nothing. A careful adversary opens stolen documents in an offline analysis VM, many viewers block remote content by default, and DNS only tokens reveal the resolver rather than the reader, so tokens are a strong lead when they fire and a very weak signal when they stay quiet.

8. Fingerprinting statements so every copy has a provenance

The same thinking applies to the documents a bank issues every day, but with a very different goal. When a customer’s statement turns up somewhere it should not be, in a fraud case, a dispute, a leaked data set or a complaint that “the bank leaked my statement”, the question that matters is which issuance this copy descends from: did the client download it themselves, through which channel, on which date, or was it reprinted by staff, exported by an internal process, or shared with a third party under consent? If every rendered statement carries a unique fingerprint recorded in an issuance ledger, that question becomes a lookup that narrows the investigation. A fingerprint identifies which issuance a copy descends from, however, not which later holder lost it, so everything this section describes produces investigative leads that must be corroborated with access logs and document distribution records.

What the fingerprint encodes. Each rendering of a statement gets an identifier that the ledger maps to the customer, the statement period, the channel (mobile app, internet banking, emailed statement, branch print, call centre, open banking API or other third party), the time, and where relevant the session, staff member or API client that requested it. The identifier itself should be opaque, a random value or a keyed MAC, so that it reveals nothing to someone holding the document, and the ledger that resolves it is itself sensitive data that deserves tight access control and audit.

flowchart LR
    channels["Channels<br/>app, web, email,<br/>branch, call centre, API"] --> renderer["Statement renderer<br/>stamps a unique fingerprint:<br/>QR, signature, hidden marks"]
    renderer -- records --> ledger["Issuance ledger<br/>customer, period, channel,<br/>time, staff or API client"]
    copy["A copy surfaces<br/>dispute, fraud case,<br/>leak or DLP claim"] --> extract["Extract fingerprint<br/>scan QR, verify signature,<br/>decode hidden marks"]
    extract -- lookup --> provenance["Provenance<br/>which issuance, channel and actor;<br/>altered or not"]
    ledger -. resolves .-> provenance

The renderer stamps every copy and writes the stamp to the ledger at issuance, so when a copy later surfaces, the fingerprint extracted from it resolves to exactly one issuance event without the bank ever needing to watch the document in between.

Layer the marks, because each one fails differently. No single technique survives everything a document goes through, so the fingerprint should be carried several ways at once.

1. A visible issuance reference and signed QR code. This survives printing, scanning and photographing, and doubles as a public verification service: a lender or landlord can scan it to confirm the statement is genuine and unaltered, which attacks the separate problem of forged statements used in loan fraud. A valid code can be copied onto an altered statement, though, so verification must compare the content presented with the authenticated content held by the bank, not merely confirm that the code resolves.
2. A cryptographic signature over the content. A PDF digital signature, with its hash recorded in the ledger, covers the revision that was signed. PDFs can carry later incremental changes, which the verifier has to evaluate by comparing the presented file with the signed version, as Adobe’s verification guidance describes. An incremental save preserves the signed revision, but the signature does not survive printing, scanning or re rendering, and some tools that rewrite a PDF in full invalidate it, which is why it is only one layer.
3. Invisible marks in the content itself. Tiny per issuance variations in character spacing, line breaks, glyph choices or background texture carry the identifier inside the page, and marks in the text layer such as zero width characters survive copy and paste. Tom Ross described catching a forum leaker by encoding each viewer’s username in zero width characters, but the same write up is a reminder that these marks are easy to detect and strip once someone knows to look, so they belong alongside more robust layers, never alone.
4. Metadata identifiers. XMP and document IDs are trivial to strip and should be treated as a convenience for the cooperative case, not evidence.

The mathematics for doing this properly is well established. Chor, Fiat and Naor’s Tracing Traitors (CRYPTO 1994) introduced schemes for identifying the source of leaks when data is distributed to many parties, and Boneh and Shaw’s collusion secure fingerprinting (CRYPTO 1995) addresses the harder case where several recipients compare copies to find and erase the marks. Encoding the identifier with error correction, and spreading it across the page, is what lets a fingerprint survive a crop, a redaction or a low quality scan. There is also a cautionary precedent: EFF describes the colour laser printer tracking dots it decoded in 2005 as able to “link each printed page to the printer that printed it”, and the controversy that followed came largely from the fact that nobody had been told, which is a good argument for disclosing statement fingerprinting in your terms and privacy notices.

Decoy statements carry the beacons; real statements carry the fingerprints. The two techniques in this post meet most usefully in a decoy statement: a statement that looks exactly like a real one but belongs to a fictitious client, has no operational purpose at all, and carries a call home token from section 7. These can be seeded wherever real statements live, in statement archives, document stores, mail and CRM exports, reporting extracts and backups, and because no legitimate employee ever needs to open a statement for a client who does not exist, a beacon firing is a high value lead: unexpected token activation that needs attributing. The token tells you where that decoy was seeded, but copies propagate into backups, replicas and exports, so it marks a lineage to investigate rather than necessarily the store that was accessed. The next step is to establish what triggered it, a person, a security scanner or an automated document process, and correlate that with access logs; accounting for approved scanners before escalating is what keeps these alerts quiet enough to act on. Genuine client statements carry no beacon at all, only the passive fingerprint, so the programme sees misuse of the decoys the moment it happens and resolves the provenance of a real statement only when a copy surfaces and needs investigating.

How this informs a DLP claim. The value shows up when something goes wrong, and the table below is how I would expect an investigation to read the evidence. None of these rows is a finding on its own.

Testing an extortion group’s “proof”. The same ledger answers one of the most stressful questions a bank can face. Extortion crews routinely back a breach claim with a handful of sample documents, and a bank that fingerprints its statements can generate strong leads about where those samples came from within hours instead of arguing about them for days. The design requirement that makes this work is that every rendition carries its own fingerprint, not just the copies delivered to clients: the copy written to the statement archive, each bulk batch run, internal exports, backups and anything sent to a print house should all be distinguishable from each other and from what a client downloads.

That last row is the neatest part of combining the two techniques: decoy statements seeded into every store behave as a strong breach indicator, because they should only appear in a proof pack if someone took them from somewhere inside the bank’s estate. The absence of decoys proves much less. The attacker chooses which documents to show, so a pack with no decoys in it offers little reassurance unless decoys are seeded densely enough, and the volume taken is known well enough, to make their absence statistically meaningful. Every row in this table is a lead to be corroborated with access logs and distribution records before it shapes the regulatory notification analysis or the conversation with the extortionists.

The language in those conclusions is deliberately careful. A fingerprint proves which issuance a copy descends from, not who handed it on afterwards, and it can be defeated by retyping the content or photographing it at low resolution, so it should be presented as provenance evidence that narrows an investigation rather than as proof that a particular person leaked a document. Before relying on it, test survivability properly: print, scan, photograph, screenshot, OCR, re save through common PDF tools and partial redaction, and record which layers survive each.

9. Pitfalls

Being fingerprinted. A decoy that attackers can identify is worse than useless, because sophisticated actors will avoid it or feed it misleading traffic, and the Cambridge work shows that for emulated honeypots this is a class problem rather than a bug to patch. High interaction decoys built on the real product, placed in plausible address space and kept current, are the main defence.

Becoming a launchpad. If a decoy is used to attack a third party, you own that problem legally and reputationally, which is why the Honeynet Project devoted a chapter of Know Your Enemy to liability under the heading Do No Harm. Egress control, rate limits and a tested kill switch are not optional, and legal and regulatory counsel should review the programme before the first sensor goes live, particularly in a regulated industry.

Licensing and vendor terms. Running real vendor appliances as bait may conflict with licence terms, and disclosure of anything you find must follow coordinated disclosure norms rather than a blog post, so involve procurement and your vulnerability disclosure owner early.

Operational drag. High interaction decoys are expensive to build, rebuild and analyse, and the output is only as good as the triage behind it. A modest fleet with disciplined analysis will outperform a large fleet whose alerts nobody reads, and many organisations will get most of the edge coverage by subscribing to a commercial sensor network and reserving their own decoys for the products they actually run.

10. Closing thoughts

The edge devices that attackers now favour for zero day exploitation are, conveniently, the easiest things in the estate to impersonate and the hardest to instrument directly, which makes them the natural place to start a deception programme. The recent record, from PTZOptics to FortiWeb, suggests that a well isolated, high interaction decoy watched by people who know what normal looks like can give weeks of warning that no signature, patch feed or vendor advisory will, and the GreyNoise data suggests that shifts in attacker attention against the products we run are worth watching as a reason to raise readiness.

None of this replaces patching, segmentation or a competent detection team, but it changes the question from “have we been hit by something known?” to “what is being tried against things like ours that nobody has named yet?”, and for a defender that is a much better question to be able to answer.

References

1. Cheswick, B. (1991). An Evening with Berferd, in Which a Cracker Is Lured, Endured, and Studied.
2. Spitzner, L. (2002). Honeypots: Tracking Hackers, “The History of Honeypots”. Addison Wesley.
3. The Honeynet Project (2004). Know Your Enemy: Learning about Security Threats, 2nd edition. Addison Wesley.
4. The Honeynet Project. Know Your Enemy: Honeynets and Know Your Enemy: GenII Honeynets (mirrored copies).
5. CERT/CC (2002). Advisory CA-2002-01: Exploitation of Vulnerability in CDE Subprocess Control Service.
6. MITRE (2022). MITRE Launches Engage Framework to Defend Against Cyber Attacks; framework at engage.mitre.org.
7. Vetterl, A. and Clayton, R. (2018). Bitter Harvest: Systematically Fingerprinting Low and Medium Interaction Honeypots at Internet Scale. USENIX WOOT 2018; see also the Cambridge repository record.
8. The Record (2021). Log4Shell attacks began two weeks ago, Cisco and Cloudflare say; Cloudflare’s own analysis is indexed under blog.cloudflare.com/tag/log4shell.
9. GreyNoise (2024). GreyNoise Intelligence Discovers Zero Day Vulnerabilities in Live Streaming Cameras with the Help of AI; coverage in BleepingComputer.
10. GreyNoise (2025). GreyNoise Uncovers Early Warning Signals for Emerging Vulnerabilities and the full report.
11. Google Threat Intelligence Group (2025). Hello 0-Days, My Old Friend: A 2024 Zero-Day Exploitation Analysis.
12. Dark Reading (2025). Critical Fortinet FortiWeb WAF Bug Exploited in the Wild; see also The Register and Cybersecurity Dive.
13. Thinkst. Canarytoken Overview and Use Cases and Canarytokens.org: Quick, Free, Detection for the Masses.
14. OPSWAT. Sending Logs, Alerts, and Telemetry Through a Data Diode.
15. Thinkst. Adobe PDF Canarytoken and Windows Directory Canarytoken documentation.
16. Tripwire (2018). Find out who is leaking your secrets with help from invisible zero width characters, describing Tom Ross’s technique.
17. Chor, B., Fiat, A. and Naor, M. (1994). Tracing Traitors. CRYPTO 1994, LNCS 839.
18. Boneh, D. and Shaw, J. (1995). Collusion Secure Fingerprinting for Digital Data. CRYPTO 1995, LNCS 963, pp. 452 to 465.
19. Electronic Frontier Foundation. Printer dots and the 2005 DocuColor decoding announcement.
20. Information Regulator (South Africa). inforegulator.org.za, for POPIA guidance on lawful processing of personal information.
21. GreyNoise Labs (2024). CVE-2024-8956, CVE-2024-8957: How to Steal a 0-Day RCE (With a Little Help from an LLM).
22. Amazon Web Services. How to prevent object overwrites with conditional writes. Amazon S3 User Guide.
23. Adobe. Compare signed document versions. Acrobat help.
24. Thinkst. Alert Annotation: Palo Alto WildFire PDF Token.