Courses Detection engineeringDeception & alert quality

Honeytokens & deception

Decoys nothing legitimate ever touches.

Advanced25 min · lesson 13 of 15

Most detections wrestle with the signal-to-noise problem: telling malicious activity apart from a flood of legitimate activity. Deception flips that problem on its head — you plant things that only an attacker would ever touch, so any interaction is, by construction, high-confidence evidence.

Honeytokens and canaries

A honeytoken (or canary) is a decoy — a fake credential, a bait resource, a tripwire — that has no legitimate use, so nothing benign ever touches it. Because normal activity never interacts with it, an interaction is near-certain evidence of an intruder, giving you an alert with an extraordinarily low false-positive rate. Effective placements include a fake AWS access key in a config file or environment, a decoy admin account, a canary document or URL that phones home when opened, a bait database row, or a honeypot service. Place them where an attacker rummaging for credentials or data would naturally find them — exactly the spots your real detections struggle to distinguish from normal use.

a canary AWS key nobody should ever use

# Planted in a config an attacker would read. It grants NOTHING, but any
# attempt to use it fires a high-confidence alert (nothing legitimate does).
[default]
aws_access_key_id = AKIACANARY0000EXAMPLE      # decoy — monitored
aws_secret_access_key = ...decoy...
 
# Detection: alert on ANY API call using this key id in CloudTrail.
#   eventName = * AND userIdentity.accessKeyId = "AKIACANARY0000EXAMPLE"
#   ⇒ someone found and tried the bait → investigate immediately.

Why deception is high-value

Deception is cheap to deploy and produces some of the highest-signal alerts in your whole program, which is why it complements rule- and behavior-based detection so well: those fight noise, deception has almost none. A triggered canary tells you an attacker is present and actively hunting for credentials or data — often early in the intrusion, before they have done real damage. Spread canaries across the environment (cloud credentials, cluster secrets, file shares, databases) so wherever an attacker looks, they risk tripping one. Route canary hits as critical, page immediately, and treat any interaction as an incident until proven otherwise — a canary firing is almost never a false alarm.

Deception as high-signal detection

plant decoys

canary credentials

fake AWS/SSH/API keys

bait resources

decoy admin acct, docs, DB rows

why it works

nothing legitimate touches them

near-zero false positives

a hit = intruder present

often early in the intrusion

Deception inverts the signal-to-noise problem. Spread canaries where attackers look; treat any trip as a real incident.

A canary hit is almost never a false alarm — treat it as an incident

Because nothing legitimate interacts with a well-placed honeytoken, an alert on one is near-certain evidence of a real intruder. Route canary hits as critical with immediate paging, and investigate as a genuine incident until proven otherwise — under-reacting to your highest-signal detection wastes its whole value.

Timeline analysisAlert quality & tuning