The 20-millisecond problem: why ransomware still lands even when Defender is “working”

Most ransomware conversations get stuck in the same loop:

  • patching

  • awareness training

  • MFA

  • backups

  • “EDR will catch it”

All of that matters. But it quietly misses the part attackers exploit every day:

the gap between compromise and detection and the speed at which encryption happens once they decide to pull the trigger.

In a recent NHS-focused webinar, Glenn Wilkinson (Agger Labs, founder background in offensive security) put it bluntly: ransomware isn’t thriving because defenders are lazy, it’s thriving because it’s designed to work inside modern operational pressure.

And in healthcare, that pressure is amplified. Downtime isn’t an inconvenience, it can be a patient safety event.

Ransomware works because the business model works

Ransomware is not “advanced malware”. It’s an industry.

The underground economy has matured into a supply chain:

  • initial access brokers sell entry into environments

  • ransomware-as-a-service programs provide the encryption payload and negotiation playbooks

  • specialist affiliates bring social engineering and identity compromise

  • data theft turns encryption into double/triple extortion

That industrialisation matters because it changes the game for defenders:

You’re often not dealing with one attacker doing everything.
You’re dealing with a pipeline of specialists.

Why “we have Microsoft Defender” isn’t the end of the story

Microsoft Defender for Endpoint (MDE) does a lot well. In the NHS it’s also widely deployed, which is a good thing.

But the uncomfortable truth and this is echoed consistently across incident patterns, is: attackers plan around your controls.


If they know you’re a Defender estate, they test against Defender in their lab. If they want to deploy ransomware, they use playbooks that aim to:

  • land through a human channel (phish / impersonation / helpdesk reset)

  • steal credentials

  • move laterally

  • disable or bypass endpoint controls

  • then encrypt at scale

Glenn demonstrated a simple but important point: a ransomware payload doesn’t need to be “brand new” to get through.

If an attacker can:

  • make small modifications (to avoid signatures/reputation checks), and/or

  • sign a payload, and/or

  • tamper with security tooling

…then traditional detection can lose the race.

This is not a criticism of Defender. It’s simply not built as a single-purpose ransomware kill switch. It’s built as a broad platform.

The real fight happens at the moment of encryption

Once a ransomware operator is inside your environment, the final stage is brutally simple:

encrypt.

And the reason this stage is so dangerous is speed.

Encryption can turn from “nothing obvious” into “major incident” in seconds.

So the question becomes:

What happens at the endpoint when the encryption process starts?

That’s why the “last line” matters: endpoint-level prevention that is fast, local, and difficult to tamper with.

A different approach: ransomware “kill switch”, not general detection

In the webinar, the model described was not “replace your EDR”.

It was augment it with a dedicated ransomware prevention layer:

  • focused specifically on ransomware behaviours (not signatures)

  • local and deterministic (not cloud round-trips)

  • hardened against tampering (because attackers increasingly try to disable controls before encrypting)

In plain English:

If the process behaves like ransomware, terminate it immediately; before files are lost.

It’s not glamorous. It’s not a hundred dashboards.

It’s the seatbelt + airbag layer for the moment you most need it.

Why anti-tamper is becoming non-negotiable

There’s a second uncomfortable reality: a control that can be turned off is not a control — it’s a speed bump.

Modern attackers don’t just “launch ransomware”.
They often try to:

  • terminate security processes

  • hollow out or suspend EDR components

  • disable monitoring

  • remove restore points / shadow copies

  • create conditions where encryption runs unchallenged

So any serious ransomware resilience strategy needs to include:

  • detection/prevention of encryption behaviours

  • protection of the protective controls

If your endpoint security can be neutralised, you’ve lost the most important layer before the incident even “starts”.

What this means for NHS and healthcare environments

Healthcare has a uniquely difficult combination:

  • large estates

  • legacy systems that can’t move fast

  • high operational pressure

  • third-party access complexity

  • low tolerance for downtime

That’s exactly why attackers target it: the pressure to restore service is higher.

So the practical, mature question isn’t:

“How do we become unhackable?”

It’s:

“How do we maintain continuity even when something gets through?”

A pragmatic way to think about deployment

You don’t need to boil the ocean on day one.

A sensible approach is staged:

  1. Protect crown jewels first (critical servers, core systems)

  2. Validate in a monitor/baseline mode if available

  3. Expand to endpoints as confidence grows

  4. Ensure alerts can feed into your SIEM / SOC workflows

The goal is not another project.
The goal is reducing blast radius and preventing encryption.

The takeaway

The ransomware story in 2026 isn’t “defenders are failing”.

It’s this:

  • attackers are industrialised

  • compromise often starts with humans and identity

  • encryption happens fast

  • and broad detection platforms aren’t optimised to be a single-purpose kill switch

So if you’re serious about resilience, the question to ask your team is simple:

If encryption started right now on a critical system, what would stop it — in milliseconds — even if other controls were bypassed?

If the honest answer is “we’re not sure”, that’s where to focus next.

Previous
Previous

Key Takeaways from the Hoxhunt 2025 Cyber Threat Intelligence Report

Next
Next

Visibility alone isn’t reducing cloud risk