implementing-honeypot-for-ransomware-detection

Place realistically named decoy files in share roots and subdirectories, then monitor them with FSRM file screens or a FileSystemWatcher registered for Changed, Deleted, and Renamed events. Any modification triggers a high-confidence alert since legitimate users never touch the canaries.

The workflow uses Windows FSRM for ransomware-extension file screening, PowerShell FileSystemWatcher for real-time canary monitoring, Thinkst Canary or canarytokens.org for trackable document tokens, and OpenCanary as an open-source honeypot daemon option.

No. Honeypots are a supplementary deception layer with near-zero false positives, not a replacement for EDR, network monitoring, or backups. They excel at catching variants that evade signature-based detection by triggering on file modification behavior.

Many ransomware families write an encrypted .locked copy and delete the original, which fires Renamed and Deleted events rather than Changed. Register handlers for all three event types to avoid missing encrypt-then-rename behavior.

Exclude backup agents and AV scan accounts from object-access auditing so legitimate bulk access does not generate alerts. Also use realistic canary names instead of obvious ones, and test end-to-end alerting with a controlled encryption tool.