| name | deploying-ransomware-canary-files |
| description | Deploys and monitors ransomware canary files across critical directories using Python's watchdog library for real-time filesystem event detection. Places strategically named decoy files that mimic high-value targets (financial records, credentials, database exports) in locations ransomware typically enumerates first. Monitors for any read, modify, rename, or delete operations on canary files and triggers immediate alerts via email, Slack webhook, or syslog when interaction is detected, providing early warning before full encryption begins.
|
| domain | cybersecurity |
| subdomain | ransomware-defense |
| tags | ["ransomware","canary-files","watchdog","detection","early-warning","deception","defense"] |
| version | 1.0.0 |
| author | mahipal |
| license | Apache-2.0 |
| nist_csf | ["PR.DS-11","RS.MA-01","RC.RP-01","PR.IR-01"] |
Deploying Ransomware Canary Files
When to Use
- Deploying proactive ransomware detection on file servers, NAS devices, or endpoint systems
- Building an early-warning system that detects ransomware before it encrypts business-critical data
- Supplementing EDR solutions with lightweight canary file monitoring on systems where agents cannot be deployed
- Testing ransomware incident response procedures by simulating canary file triggers
- Monitoring shared drives, home directories, and backup volumes for unauthorized file operations
Do not use as a replacement for endpoint protection, backup strategy, or network segmentation. Canary files are a detection layer, not a prevention mechanism.
Common Misconfigurations & Verification
- Decoy names that sort late:
Financial_Report_2026.docx sorts mid-alphabet, so a Z-A or A-Z enumerator may encrypt real data before reaching it. Pair each realistic name with a _AAAA_-prefixed and ~zzzz_-suffixed twin so a canary is always the first AND last file touched in each directory.
- Canaries clustered in one path: placing them only on user Desktops misses share roots and backup volumes. Seed every network-share root, Documents folder, and backup staging dir ransomware enumerates first.
- Only watching
on_modified: encrypt-and-rename ransomware writes Passwords.xlsx.locked and unlinks the original, firing on_moved/on_deleted. Confirm the handler covers created/modified/moved/deleted, not just modify.
- No process attribution / too slow: without
psutil capturing the offending PID, the alert can't drive isolation. Verify time-to-alert and that the process info is populated.
- Verification: programmatically modify, rename, and delete each canary and confirm alerts land on every channel (email, Slack, syslog) with correct before/after SHA-256 hashes; exclude backup/AV processes so they don't generate false hits.
Prerequisites
- Python 3.8+ with pip
- watchdog library (pip install watchdog)
- Write access to directories where canary files will be placed
- SMTP server credentials or Slack webhook URL for alerting
- Administrative access for placing canaries in system directories
Workflow
Step 1: Generate Canary Files
Create decoy files with realistic names and content that attract ransomware scanners. Files should have names like , , and contain plausible-looking but fake data. Place them in directories ransomware typically targets first: user desktops, Documents folders, network share roots, and backup paths.
