Deception Technology: Decoys

Most detection tries to identify malicious activity among legitimate activity, which is hard and noisy. Deception inverts it: place things that no legitimate user has any reason to touch, and alert when anything does.

The mechanism

A decoy has no legitimate purpose. A credential that authenticates nothing real, a file nobody needs, a server that serves nothing.

Therefore any interaction is anomalous. Not statistically unusual — categorically unexpected.

The result is very high precision. Compared with behavioural detection, where most alerts are innocent, a decoy alert is nearly always something worth investigating. That makes it unusually cheap to operate.

The forms, from cheapest

Canary tokens. A file, a URL, a database entry, an email address that alerts when accessed. Free implementations exist and deployment takes minutes. This is the highest return per unit of effort in detection and it is widely skipped.

Place them in document stores, in source repositories, in backup locations — anywhere an intruder would look.

Decoy credentials. Accounts that exist in the directory, are never used, and alert on any authentication attempt. Effective against credential harvesting, because the harvest is indiscriminate.

Honeytoken records. Fake customer entries in a real database. Any use — an email to that address, a query for that record — indicates exfiltration, and it tells you which database.

Decoy files. Documents named to attract attention. Alerting on read.

Decoy hosts. Machines that look like real servers. More effort, more information about attacker behaviour.

Full deception networks. Commercial products building an entire fake environment. Substantial cost.

What they detect well

Lateral movement. An intruder exploring the network will probe things a legitimate user would not.

Credential harvesting, because harvested credentials get tried indiscriminately.

Insider reconnaissance. Someone browsing shares looking for valuable material.

Exfiltration, through honeytoken records that surface later.

Anything involving exploration, which is most intrusions.

What they miss

Targeted activity against a known objective. Someone who knows exactly which file they want will not encounter a decoy.

Anything not on the path. Coverage is only where you placed them.

Legitimate access to real data. An employee taking material they are authorised to access touches nothing fake.

Attacks that identify the decoys. Sophisticated adversaries look for them, and poorly built decoys are identifiable.

Making them credible

Realistic names. A file called "decoy.txt" catches nobody. A file called "2026 salary review draft" does.

Realistic placement. Where similar real material lives.

Realistic content. A decoy opened and found empty reveals itself.

Consistent metadata. Creation dates, ownership and modification times that match the surroundings.

Documented internally, so your own staff and auditors do not trigger them and waste a response.

Operating them

Alert to a channel that gets attention. These are rare and high-value; they should not sit in a queue.

Have a response plan. A decoy alert means someone is somewhere they should not be, and the response should be immediate rather than triaged over days.

Test them periodically. A decoy whose alerting has broken is worse than none, because you believe you have coverage.

Track how many exist and where. They accumulate and get forgotten, and the person who deployed them leaves.

Expect near-zero alerts. That is success, and it means occasional testing is necessary to distinguish success from a broken deployment.

The proportionate recommendation

Every organisation should deploy canary tokens. They are free, they take an afternoon, and they detect a category of activity nothing else catches at that precision.

Decoy credentials are worth the modest effort for anyone with a directory.

Full deception platforms are for organisations with a mature detection function that have exhausted cheaper improvements. Buying one before you have basic logging is the wrong order.

A first deployment in an afternoon

Concretely, for an organisation that has none of this.

Generate a handful of canary tokens from a free service. A document, a URL, a folder that alerts on access.

Place them where an intruder would look: the shared drive with finance in the name, the folder called backups, the source repository, the wiki page about credentials.

Name them realistically. "Q1 payroll draft", "vpn config", "customer export". A file called "canary" catches nobody.

Point the alerts at somewhere a person actually reads, not a queue.

Create one decoy account in the directory that is never used, and alert on any authentication attempt.

Document what you deployed and where, in a place your successor will find, so nobody triggers them during an audit and so they are not forgotten.

Then test one, and confirm the alert arrives.

That is an afternoon, it costs nothing, and it detects a category of activity that behavioural monitoring finds hard and expensive.