Ransomware rarely starts with encryption. By the time files are locked and ransom notes appear, the attacker has usually been inside for a while. They already know where data lives and which systems to hit first. The real fight happens earlier, when activity still looks half-legitimate and easy to dismiss.
And if you’re running IT for a 50- or 200-person company, you’re not less of a target. Attackers know smaller organizations have thinner defenses. The median ransom payout in 2024 was $200,000. That’s enough to be devastating for an SMB, and enough to be worth an attacker’s time.
Sophos’s 2025 State of Ransomware report puts the average recovery cost at $1.53M (excluding the ransom). For smaller organizations, it’s around $638K, which is still existential for most. Mandiant’s 2025 data puts ransomware dwell time at just 6 days. Sophos says 4 days. Arctic Wolf documented Akira campaigns that went from VPN login to full encryption in under an hour.
The detection window is collapsing. Here’s how to make the most of what’s left.
What ransomware looks like in your environment
Ransomware is an intrusion that ends in disruption. The stages: gain access, move laterally, prepare impact, extort. Detection depends on recognizing what each stage looks like in your logs.
Initial access comes from phishing, exposed RDP or VPNs, unpatched edge devices, or stolen credentials (now the second-most-common vector at 16% of investigations, per Mandiant). If RDP is open to the internet, even on a non-standard port, attackers will find it.
Pre-encryption staging is where the real damage gets set up, and where most detection opportunities exist. Attackers steal data for extortion leverage, hunt for backup infrastructure to destroy, and position for maximum impact.
Modern extortion almost always combines encryption with data theft. Double extortion threatens to leak your data. Triple adds DDoS. Quadruple goes directly after your customers, partners, and regulators. For SMBs, the customer-contact angle is particularly dangerous. You might survive downtime, but not your clients’ data on a leak site.
Top ransomware detection methods
No single tool catches ransomware in every environment. That needs to be the starting point of this entire conversation, because it’s the thing most vendor marketing actively obscures.
Here’s what actually happens in the field: every major EDR platform – CrowdStrike, SentinelOne, Huntress – gets bypassed. Not theoretically, not in a lab. In real engagements, skilled attackers silence EDR and successfully encrypt machines that have top-tier solutions installed. Red team operators (ethical hackers) do it routinely during validation assessments, and ransomware groups do it in the wild. These are good products that catch a lot of attacks. But if your entire security strategy depends on any single one of them being perfect, you will eventually get burned.
What actually stops ransomware is layered defense. Not some abstract layers, but layers as a deliberate architectural choice where each detection method covers a different angle of attack, so that when one fails (and it will), another one catches the activity from a different vantage point.
Think about it this way. An attacker gains access through a phished credential. The EDR doesn’t flag the login because it’s a legitimate account using a legitimate VPN. But your DNS logging spots the compromised machine querying a domain that’s never appeared in your environment before. Or the EDR misses the attacker running PsExec because it’s a legitimate admin tool, yet your canary file on the shared drive trips when the ransomware starts encrypting alphabetically and hits the decoy before reaching real data. Or the attacker successfully kills the EDR agent on the endpoint, but the network layer catches the sudden 200GB outbound transfer to a cloud storage bucket that your accounting server has never talked to before.
Each layer alone has gaps. Together, they force the attacker to evade all of them simultaneously, which is dramatically harder than evading any one of them.
Here’s what each layer covers and where it falls short.
Signature-based detection (traditional AV) catches known ransomware binaries and file extensions. Low false positives, but completely blind to anything new, customized, or using built-in system tools. It’s a baseline layer, not a strategy.
Behavior-based detection (EDR) watches for suspicious process chains, privilege abuse, and ransomware-like patterns on individual machines. This is your most important single detection layer. It catches things signatures miss, like unusual process trees and mass file modifications. But it can be silenced by a skilled attacker, and it misses activity that uses legitimate admin tools in ways that look “normal enough” to the detection engine. EDR needs to be paired with other layers that see what it can’t.
Network monitoring (DNS/proxy/firewall logs) catches what endpoint tools are blind to: unusual outbound data transfers, connections to suspicious destinations, command-and-control traffic patterns. This layer often reveals staging and data exfiltration before encryption even starts. Even basic DNS logging, which most business firewalls already support and costs nothing to turn on, can flag connections to domains your environment has never contacted before. When the attacker is living off the land (LotL) with your own admin tools and the EDR doesn’t flag it, the network layer catches the traffic those tools generate.
Anomaly/behavioral correlation (UEBA or MDR) ties weak signals from different sources into a single picture. An unusual VPN login, followed by RDP access to a server that account has never touched, followed by a spike in file writes. Each individually explainable, but together within a two-hour window they become a high-confidence alert. For SMBs, an MDR service (Managed Detection and Response) is the practical version of this: a third-party team monitoring your environment 24/7 and calling you when patterns look wrong. Providers like Huntress, Sophos MDR, or Arctic Wolf are built for organizations that can’t staff a round-the-clock security team.
Deception (honeypots, canary files, and decoy infrastructure) is arguably the most underused detection layer in small and midsize environments, which is strange because it’s also one of the cheapest and most reliable. The core idea is simple: you place fake resources in your environment that have no legitimate reason to be accessed. When something touches them, you know it’s either an attacker or malware, because nothing else would.
This works at multiple levels. At the file system level, you create decoy folders on your shared drives with names that look valuable – “AA_Financials,” “AA_ClientData,” “Passwords_backup.” Inside those folders you place decoy documents. At the server level, you can set up a honeypot machine with a name like “AA-FileServer” that exists only to be found. At the document level, tools like Thinkst Canarytokens let you create files (Word docs, PDFs, spreadsheets) that phone home the moment they’re opened, telling you exactly when, from what IP, and on what device.
The reason deception works so well against ransomware specifically is that ransomware is almost always programmatic. It doesn’t carefully choose which files to encrypt first. It iterates through whatever it can reach, usually in alphabetical order. That means your “AA_Financials” folder gets hit before your real production data. The ransomware announces itself while still chewing through worthless decoys, buying you time to respond before real damage starts.
What makes this layer different from everything above is the false positive rate. EDR generates alerts that need triage. SIEM correlation rules fire on things that turn out to be legitimate. Network monitoring flags traffic that’s unusual but harmless. Deception doesn’t have this problem. Nothing legitimate should ever touch a honeypot folder, open a canary document, or connect to a decoy server. When an alert fires, it’s real. That near-zero false positive rate means you can set these alerts to CRITICAL priority, the kind that page you at 3am, and trust that when the phone rings it’s not a false alarm.
Which detection layer catches what, and when
| Attack stage | What the attacker does | Signature/AV | EDR | Network monitoring | UEBA/MDR | Deception |
|---|---|---|---|---|---|---|
| Initial access | Phishing, exploiting VPN/RDP, using stolen credentials | Catches known malware droppers | Flags suspicious process launches from email or browser | Spots connections to known-bad IPs/domains | Detects unusual login patterns (new location, odd hours) | No coverage at this stage |
| Credential harvesting | Running Mimikatz, dumping LSASS, kerberoasting | Catches known tools by hash | Detects credential dumping behavior and suspicious LSASS access | Limited visibility | Correlates privilege escalation with prior anomalies | No coverage at this stage |
| Lateral movement | PsExec, RDP pivoting, SMB spreading, WMI commands | Misses living-off-the-land tools | May flag unusual parent-child process chains | Catches unusual internal traffic patterns between hosts | Ties together multi-host activity into a single alert | Honeypot servers trip when accessed by unexpected accounts |
| Discovery and staging | Mapping shares, identifying backups, exfiltrating data | No coverage | May detect mass file enumeration | Catches large outbound transfers and C2 traffic | Correlates data movement with prior suspicious activity | Canary files trip when attacker opens decoy documents during recon |
| Backup destruction | Deleting backup repos, disabling VSS, wiping shadow copies | May catch known backup-deletion scripts | Detects VSS deletion commands and backup agent tampering | Limited visibility unless backup traffic patterns change | Flags backup console login anomalies | Canary files in backup-adjacent folders trip as attacker navigates to backups |
| Encryption | Mass file modification, ransom note deployment | Catches known ransomware variants | Detects mass file rename/modify behavior | Catches ransomware C2 callbacks | High-confidence alert from combined signals | Honeypot folders hit first (alphabetical order), alerting before real data is touched |
The table makes the case for layers visually: no single column covers every row. Signature/AV is blind to anything past initial access unless the attacker uses known tools. EDR has the broadest coverage but can be silenced. Network monitoring catches exfiltration that endpoint tools miss. UEBA/MDR ties weak signals together. And deception is the only layer that catches activity during encryption with near-zero false positives, but it offers nothing during the early stages. You need all of them working together.
This is what layered detection looks like in practice. No single layer is sufficient. The combination is what makes ransomware detection work.
Best ransomware defense practices
This ordering comes from what actually fails first in real ransomware incidents, not from what looks good in a security framework slide deck.
1. Protect your backups – they’re the first target, not the last resort. This is usually the very first thing ransomware operators go after. In roughly 9 out of 10 incidents, attackers target backup infrastructure before they trigger encryption. The logic is simple: if you can restore, you have no reason to pay. So they eliminate that option first.
Don’t use your domain admin account to manage backups. Use a separate, dedicated account with credentials that don’t exist anywhere else. Don’t join the backup server to the domain if you can avoid it. Enable immutability (write-once storage that can’t be modified or deleted even by an admin) on your backup repositories. Veeam hardened Linux repos, Wasabi S3 with object lock, and Backblaze B2 with object lock all support this at reasonable price points. Maintain at least one copy that is physically disconnected from everything else: tape, rotated USB, or a cloud target that’s only online during the backup window.
Monitor your backup console for anomalous behavior. Failed jobs, vanishing retention points, unfamiliar login sessions. These aren’t IT glitches to investigate Monday morning. They’re potential early indicators that someone is already inside and preparing to cut off your recovery path.
And test your restores. Not “job completed successfully” in the console, but actual restore tests where you boot a VM or mount a database and verify it works. A backup you’ve never tested is a backup you don’t have.
2. Deploy your deception layer with the alphabetical trick. Now that you understand how deception detection works, here’s the specific deployment that gets the most out of it. Create shared folders named “AA_Financials” or “AA_ClientData” on every file server, and if possible, set up a honeypot server named “AA-FileServer.” The “AA” prefix matters because ransomware works alphabetically, so these get hit first. Give everyone read access so the ransomware’s compromised account can reach them. Place Thinkst Canarytokens inside each folder. Set CRITICAL-level alerts on all of it, the kind that page you at 3am.
The result: when ransomware starts encrypting, it announces itself on worthless decoy data before touching your real files. You get an alert with high confidence that it’s not a false alarm, and you get it while the ransomware is still busy with decoys instead of production data.
3. Have a response plan ready before the alert fires, and know how to find patient zero fast. When a honeypot or canary trips, you need to find the source machine immediately. The technique that works consistently in the field: check the “Owner” property on any encrypted or modified file. In most ransomware attacks, the encrypted file will list the owner as the account that performed the encryption. That gives you patient zero in seconds instead of hours.
Here’s the critical part that most people get wrong: do NOT shut off access to the honeypot folder or server until you have confirmed patient zero. If you cut access prematurely, the ransomware process simply moves to the next available target and your honeypot has bought you nothing. Let it keep chewing on the decoy data while you trace the source. The honeypot is doing its job, keeping the ransomware busy on worthless data. Don’t interrupt that by reacting too fast to the wrong thing.
Once you’ve identified patient zero, isolate the machine and kill the compromised identity at the same time. Use EDR to network-isolate the host (or pull the cable). Disable the Active Directory account, kill all sessions, revoke cloud tokens. Speed matters here. You can always re-enable a clean account, but you can’t un-encrypt a file server.
4. Decide who can pull the plug before it’s 2am on a Saturday. The organizations that come out of ransomware incidents relatively intact are almost always the ones where someone made the big call early. Pulled the plug on production, isolated aggressively, asked questions later. Over and over, the pattern holds: a forward-thinking engineer who just makes the huge call and takes an entire production system offline saves the entire organization. A few hours of unplanned operational downtime is painful, but it’s cheap compared to a week of encrypted servers and an Active Directory rebuild.
Decide in advance who has the authority to isolate a production system without escalating through three approval levels. Write it down. If that decision requires a CEO sign-off while the attack is spreading, you’ve already lost the containment window.
5. Know your data flows. If you know which systems talk to which under normal conditions, it’s dramatically easier to spot abnormal connections during an incident and figure out the blast radius before it becomes unmanageable. You don’t need a network diagram tool for this. A spreadsheet showing “Server X talks to Y for backup, Z talks outbound for email relay, nothing else goes to the internet” is enough. When containment starts and you’re trying to figure out how far the attacker got, that map is the difference between a targeted response and blind guessing.
6. Drill until the response is muscle memory. Run ransomware simulations with your team. Walk through realistic scenarios. Get to know what the early signs look like. The difference between organizations that contain ransomware quickly and those that don’t is almost never better tools. It’s that the team has practiced. They’ve built the muscle memory. They know the runbook exists because they helped write it, and they’ve walked through it recently enough to remember where the credentials are stored and who to call.
For a small team, this doesn’t require a formal tabletop exercise with an outside facilitator. It means walking through the scenario once a quarter: “EDR flags ransomware behavior on Server01 at 2am. What’s the first thing we do? Who does it? Where’s the runbook?”
Ransomware response workflow
When monitoring flags something suspicious, the goal is speed with evidence.
Find patient zero first. Check the “Owner” property of encrypted files. The owner is usually the account that encrypted them. That gives you patient zero fast.
Let honeypots keep working. If you have decoy shares, don’t kill access to them until you’ve confirmed the source machine. Cutting access prematurely just pushes the ransomware to the next target.
Isolate and kill the identity simultaneously. EDR-isolate the machine (or unplug the cable). Disable the compromised AD account, kill sessions, revoke cloud tokens. Don’t wait for full confirmation. You can re-enable a clean account, you can’t un-encrypt a file server.
Assess lateral movement in parallel. Check if the compromised account touched other systems. Look for SMB connections, new admin accounts, unexpected scheduled tasks. With fast campaigns like Akira, this can’t wait until isolation is complete.
Verify backups immediately. Log in from a clean machine. Check for deletion attempts, failed jobs, unfamiliar sessions. Keep air-gapped copies disconnected until the threat is fully contained.
Recover and verify. Rebuild from clean images, restore from verified-clean backups, patch the entry point. The Northshore School District learned the cost of skipping this: their two-person sysadmin team had to rebuild 180 Windows servers and reconstruct Active Directory from scratch because their backups weren’t properly tested.
Post-mortem: fix the gap, not the person. What worked? What failed? Were honeypots in the right places? Did someone ignore an alert? Update the runbook. Attackers will come back if the door stays open.
Anti-ransomware tools and solutions
If you’re an SMB picking one stack: Microsoft Defender for Business (EDR, included in M365 Business Premium) + Huntress or Sophos MDR (24/7 human-reviewed monitoring) + Thinkst Canarytokens (free canary files) + immutable backups. That covers behavioral detection, expert alerting, deception-based early warning, and ransomware-proof recovery on a realistic budget.
For teams with more technical depth, Wazuh (free open-source SIEM/XDR), Velociraptor (free endpoint forensics for mid-incident hunting), and Suricata (free network IDS) are all production-grade tools, but they require setup and maintenance that most SMBs can’t realistically staff.
The bottom line
Ransomware dwell time has dropped from weeks to days to, in some campaigns, under an hour. But you don’t need a million-dollar security budget to defend against this.
You need EDR on every machine, someone watching the alerts (even if it’s an MDR service), canary files and honeypot shares in the right places, backups that are disconnected, immutable, and actually tested, and a one-page plan for what to do when things go wrong.
No single product will save you. Anyone who tells you otherwise is selling something. What saves organizations is layers that compensate for each other, a team that’s practiced the response, and the willingness to overreact when the alert fires. The difference between a bad week and a company-ending disaster usually comes down to whether those basics were in place before the attack started.
from StarWind Blog https://ift.tt/IFo3aur
via IFTTT
No comments:
Post a Comment