Research

Can Threat Intelligence Prevent Ransomware Attacks? What It Can Stop, What It Cannot, and Three Questions to Ask of Any Feed

Patrick Duggan · · 3 min read

Can Threat Intelligence Prevent Ransomware Attacks? What It Can Stop, What It Cannot, and Three Questions to Ask of Any Feed

Threat intelligence can stop some ransomware attacks and shorten others, but it cannot prevent ransomware by itself. If you want it to earn its place, use it for three jobs: block known attacker infrastructure, decide which patches come first, and notice an intruder before the encryption starts. Then check that your feed is fresh, exact and first-hand, which is the part most buyers skip.

Left to right, a ransomware attack as four stages with where threat intelligence helps. One: getting in, by stolen credentials, exposed remote access, unpatched edge devices or phishing; intelligence helps with patch priority from the CISA Known Exploited Vulnerabilities list but cannot see a valid login. Two: working inside the network, where intruders use tools and servers that may already be listed; blocking known command-and-control and download hosts can break the chain here. Three: preparing to encrypt, where tooling indicators help detection. Four: encryption, where intelligence is too late and only offline backups help. A band lists three questions for any feed: how old is the indicator, is it an exact match or a whole range, and who saw it first.

The short answer

"Prevent" is too strong, and "useless" is too weak. A ransomware attack is a chain of steps, and threat intelligence helps at some links and not at others. The honest question is which links it covers.

What it can do

Block infrastructure that is already known. Intrusions use servers: places malware is downloaded from, addresses it calls home to, domains that host phishing pages. When those are on a blocklist before the attacker uses them against you, the connection fails and the chain can break. The word "can" matters. The block only works if the indicator was listed in time and the traffic passes through something that enforces the list.

Tell you which patches come first. CISA's Known Exploited Vulnerabilities catalog lists flaws that attackers are using now, and it carries a field marking whether a vulnerability has been used in ransomware campaigns. That turns a thousand-item patch queue into a short one. Exposed edge devices such as VPNs and firewalls are a common way in, so those entries deserve attention first.

Help you spot the intruder before the encryption. Ransomware operators often spend time inside a network before they encrypt anything, and the length of that time varies from case to case. Indicators for their tools, hashes of known loaders and the servers those tools contact, give your detection something to match during that window.

What it cannot do

  • See something nobody has seen yet. An indicator cannot be listed before someone observes it. A feed is behind by design, so its value lies in infrastructure that gets reused.
  • Stop a valid login. If an attacker signs in with a real stolen password, there may be no bad address or file to match. Multi-factor authentication and credential hygiene do that job, not a feed.
  • Fix exposure. An internet-facing service that should never have been reachable is a configuration problem, and intelligence only tells you it is being scanned.
  • Help after encryption starts. At that stage only offline, tested backups and a rehearsed recovery plan matter.

Three questions to ask of any feed

These come from mistakes we have had to correct in our own work, not from theory.

  1. How old is the indicator, and what does the date mean? A timestamp often records when the indicator entered the feed, not when anyone observed the threat. A record imported from a vendor report on Tuesday is not "ahead of" that vendor. Ask for the date of first observation and who made it.
  2. Is it an exact match or a whole range? Blocking a network range because it contains one bad address can cover the real threat, but it is protection by coverage, not detection of that address. Ask which you are buying.
  3. Who saw it first? A feed that redistributes free public lists gives you what everyone already has. That has real value for teams that lack the time to collect them, but it is not early warning. First-party observation, or independent confirmation from several unrelated sources, is.

What to do

  • Enforce a current blocklist where traffic actually passes, such as your DNS resolver or firewall, and confirm it updates automatically.
  • Patch the Known Exploited Vulnerabilities entries that touch your exposed systems first.
  • Turn on multi-factor authentication everywhere that matters, and remove remote access nobody uses.
  • Keep backups offline and test a restore. This is the only control that works at stage four.
  • Use indicators for detection too, not only blocking, so an intrusion in progress shows up.

These steps are our view, drawn from how intrusions generally unfold. They are not a formal standard, and the right order depends on your environment.

Limits

This is a general explainer. We cite no statistics here and make no claim about how often any control stops an attack. The details of an attack chain differ from group to group.

Five percent of this is wrong somewhere. It always is. If you have a case where intelligence changed the outcome, or failed to, tell us.

Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.

Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register