The Alert That Needs No Triage: Honeytokens in a Working SOC

Introduction

Most of a SOC analyst’s day is spent answering one question: is this normal? A PowerShell command line, an impossible travel login, a scanner hitting a subnet. Each one needs context before it means anything, and most of them turn out to be a backup job or a consultant on a VPN.

Honeytokens are the exception. A decoy artifact has no legitimate use at all, so any interaction with it is a high confidence signal that someone is inside. There is no benign explanation to rule out. The alert is the verdict.

That is a strange and valuable thing to have in a queue full of maybes, and it is still deployed far less than it should be.

The one property that matters

A honeytoken is any piece of data whose only expected use is misuse: a fictitious database record, an unused credential, a bait file. Canary tokens are the popular implementation of that idea, adding a ready-made beaconing mechanism so the artifact calls home by itself. Every canary token is a honeytoken, but not every honeytoken beacons automatically.

The defining trait is the absence of legitimate use. A normal account belongs to a human or a service, and separating malicious activity from that person’s daily work is the hard part of detection. A decoy account has no daily work. The baseline is silence, so a single authentication, an LDAP query pulling its attributes or one password guess is the event you care about.

Compare that to the economics of everything else we run. Signature and anomaly detections buy coverage at the cost of noise, and the analyst absorbs the difference. A decoy costs almost nothing to deploy and produces almost nothing until the day it produces the incident.

It works, and there is a public example

On Saturday 26 April 2025, alerts started firing at Grafana Labs. One of the thousands of canary tokens deployed across their code and infrastructure had been triggered, notifying their global team immediately. A vulnerable GitHub Actions workflow had let an unauthorized user reach a set of tokens.

The mechanism is worth appreciating. The attacker had exfiltrated environment variables, deleted their fork to cover their tracks, and then ran TruffleHog to check which of the stolen credentials were actually live. One of them was a fake AWS key. Validating it was what rang the bell.

Grafana’s Detection and Response team later wrote that the notification, thanks to where the token had been placed, revealed the exact entry point. They rotated credentials, disabled the affected workflows and audited the repositories, and confirmed no production access and no customer data exposure.

The follow up is the part people skip. In May 2026 Grafana disclosed a separate GitHub token theft in which an attacker downloaded the private codebase, and again the company only learned of the breach when a canary token fired. Same control, very different outcome. The token told them an intruder was there. It did not stand between the intruder and the repositories, and it fired at the moment the attacker happened to touch a decoy rather than at the moment they got in.

That is the honest framing for a client conversation. Honeytokens compress dwell time. They do not prevent anything, and how early they fire depends entirely on where you put them.

Where to plant them

Four places worth planting a honeytoken and what each one fires on

The logic behind those four is the same each time: sit on the path the attacker has to walk anyway. Someone looking for lateral movement will enumerate AD. Someone looking for data will browse the file share. Someone who just phished a mailbox will go through SharePoint. Someone who dumped a CI environment will test the keys.

Thinkst’s open source Canarytokens project covers most of this out of the box, self hostable if you would rather not send alerts to a third party, and each token binds to a memo so you know where it was planted plus an alert channel by email or webhook. On the identity side, Microsoft Defender for Identity lets you tag accounts as honeytoken entities, and any authentication activity involving them raises an alert in the portal.

The part that actually goes wrong

The token is the easy half. Deployments fail on process.

Decoys that are too obvious are the classic one. A honeypot-admin-01 sitting in AD is not deception, it is signage. Realism belongs in metadata and placement, in the correct OU with a plausible description, never in real privilege, and you never grant rights for the sake of realism.

There is a more subtle version of the same mistake. A red teamer checking badPwdCount and badPasswordTime will spot a supposed human user who has apparently never once mistyped their own password. Accounts with a suspiciously complete set of filled attributes give themselves away too.

Alert ownership is the other killer. If nobody is on the hook to respond, decoys become noise like everything else, and the first real hit lands in a queue where three previous ones were closed as false positives by someone who could not tell what the token was. This is exactly why the memo field matters: an alert you cannot place is an alert you cannot close.

Then there is maintenance. OU restructuring, naming standards, a new admin tool or a bulk licensing rule can all touch a decoy by accident. Design for stability, exclude the accounts from HR and lifecycle flows, hide them from the address list, and keep a register of what is planted where. A honeytoken nobody remembers deploying is a future false positive with a very confusing investigation attached.

Conclusion

Deception has an image problem. It sounds like an advanced capability for mature programmes, and it is mostly a text file in the right folder and an account that should never log in. For an MDR the appeal is structural rather than clever: it is one of the very few detections that improves the queue instead of adding to it, and it works identically across every client stack because it depends on attacker curiosity rather than on vendor telemetry.

Start with one decoy per client, somewhere an attacker has to look, with a named owner and a documented response. If it never fires, it cost you an afternoon. If it fires once, you will know what it means before you finish reading the alert.