Canary files are decoys placed where ransomware will reach them early, alphabetically first in each directory or in high-value shares, and monitored for any write, rename or delete. Because no real user or application should touch them, the alert has an extremely low false-positive rate. They also fire during encryption rather than after, which gives you a window to contain the spread.
Signals at a Glance
| Signal | Where | ATT&CK |
|---|---|---|
| Write, rename or delete on a decoy file | Security 4663 with SACL, EDR file events | T1486 |
| Decoy touched by a process that is not on the allowlist | Security 4688 / Sysmon 1 correlation | T1486 |
| Several decoys across different shares touched by one account or host | SMB audit, file server logs | T1486 |
| FSRM file screen violation on a protected path | FSRM event log | T1486 |
Placement and Auditing
- Place decoys in every user-reachable share and at the top of profile folders. Names that sort first (leading underscore or digits) get hit first, and realistic names and sizes stop an encryptor skipping them.
- Create files that look like documents (office files, PDFs, small databases) with plausible content, and keep a record of their paths and hashes outside the shares you protect.
- Apply a SACL that audits write, delete and rename for Everyone on each decoy, and turn on the Object Access auditing policy for file systems on the servers that host them.
- Use FSRM file screens on the same shares for a second signal: an active screen can run a command on violation, such as blocking the offending SMB session.
Once auditing is on, a Splunk search on Security event 4663 identifies who touched the decoys and from where. Replace the path pattern with your own naming convention:
index=wineventlog sourcetype="WinEventLog:Security" EventCode=4663
Object_Name="*\\_zz_do_not_touch*"
(Accesses="*WriteData*" OR Accesses="*DELETE*" OR Accesses="*AppendData*")
| stats count dc(Object_Name) as decoys_hit values(Object_Name) as objects
earliest(_time) as first latest(_time) as last
by host, Account_Name, Process_Name
| eval window_s = last - first
| where count >= 1
| sort - decoys_hit
# tune/validate: exclude your own scheduled integrity check that reads the decoys.
Turning a Touch Into Containment
The value of a canary is speed. Route the alert to a high-priority queue and automate the first action, because encryption proceeds at disk speed while analysts work at human speed:
- Disable the SMB session or the account that touched the decoy, and isolate the source host through your EDR.
- Snapshot or fence the affected share so unaffected data is preserved while you scope.
- Treat any non-allowlisted touch as an incident, and tune by excluding only your integrity checks, never a user or a backup product by default.
- Rotate decoy names periodically. A family that learns your naming convention can skip it, so do not publish the pattern.
Microsoft’s FSRM file screening and active-screen documentation covers the server-side mechanism, and the CISA #StopRansomware guidance supports early-warning and rapid isolation. Canary files complement behavioural detection but do not replace it, since some encryptors target specific directories or extensions. Baseline your environment so legitimate scanners do not trip them.
Build Detections That Fire
Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.
- Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
- Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
- 24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.
Stay ahead of emerging threats. Get notified when we publish new intelligence reports and advisories.
Subscribe to Alerts