Ransomware in H1 2026: what the first six months taught defenders

A note on method before anything else. This post deliberately names no victims, quotes no breach-specific figures, and attributes nothing to a named crew. Ransomware reporting is noisy, attribution is contested, and half the "statistics" in circulation are extortion-site counts that measure attacker marketing, not attacker success. What is solid — because it repeats across independent public reporting and across the incident-response and readiness engagements we see directly — is the pattern. Patterns are what defenders can act on anyway. Here is what the pattern looked like in the first half of 2026.

Five shifts that defined the half

1. Extortion without encryption is now a default, not a variant

The most consequential shift is the quiet one: a growing share of extortion operations never deploy a locker at all. Steal the data, threaten publication, skip the noisy, failure-prone encryption phase entirely. From the attacker's side this is simply better economics — encryption is the stage most likely to trip an EDR, most likely to fail at scale, and least necessary now that regulators and customers make data exposure expensive on its own. From the defender's side it invalidates a lot of muscle memory. If your ransomware playbook's tripwires are mass file modification and ransom-note file drops, a data-theft-only operation walks past every one of them. The detection burden moves upstream — to credential misuse, staging behaviour, and abnormal egress — and the "we have backups, we're fine" recovery posture answers a question the attacker is no longer asking.

2. Initial access is a phone call

Help-desk social engineering — calling the service desk, impersonating an employee, and talking an agent into a password or MFA reset — kept its place as one of the most reliable entry techniques in public reporting this half. It works because it targets the seam between identity systems and human process: the help desk is designed to fix access problems quickly, and its verification questions were written before convincing voice synthesis was free. The technical control most estates are missing is not another mail filter; it is telemetry and detection on the reset event itself — a reset followed within hours by new-device enrollment, privileged group changes, or first-time access to sensitive systems is a sequence worth an alert, every time.

3. Edge appliances and file-transfer systems: days from CVE to campaign

The half continued the now-familiar rhythm: a critical CVE lands in an internet-facing appliance — a VPN concentrator, a gateway, a managed file-transfer product — and mass exploitation follows within days, sometimes before the patch is broadly deployed, occasionally before it exists. These devices are attractive for structural reasons: they are internet-facing by design, they hold credentials and sessions by function, and they typically run no EDR, so the first host-level telemetry a defender gets is from the second machine the attacker touches. File-transfer systems carry the extra sting that, for a data-theft crew, the target is the loot: exploiting one merges initial access and collection into a single step.

4. Hypervisors targeted for blast radius

ESXi-class hypervisor targeting remained the preferred force multiplier for the crews that do still encrypt. The logic is arithmetic: encrypting one hypervisor host takes down every guest on it, so a handful of machines yields an outage measured in hundreds of servers. Hypervisors share the edge appliance's telemetry problem — no EDR agent on the host, thin logging by default — and add a governance one: the virtualization team often manages them outside the SOC's visibility entirely, on a management network whose reachability from the general estate nobody has actually verified lately. That reachability question — which compromised credentials could reach vCenter or the ESXi management interfaces? — is answerable in advance, and almost nobody answers it in advance.

5. Brands churn faster than trackers can name them

Finally, the naming problem got worse. Affiliates move between programs, crews rebrand after law-enforcement pressure, and toolkits are shared, sold and leaked — so tracker taxonomies churn while the underlying tradecraft barely moves. The defender's lesson is to stop keying defenses to names. The TTP layer — the reset-then-enroll sequence, the staging-then-egress pattern, the hypervisor management-interface access — is far more stable than the brand layer, and it is the layer your detections should live at.

The kill chain, stage by stage, with the telemetry that catches it

Strip away the branding and H1's operations walk a recognisable chain. Each stage is observable — but note the right-hand column carefully, because almost every stage is best observed in a different telemetry plane. That fact is the structural argument of the second half of this post.

Read the right-hand column top to bottom: identity, endpoint, network, data, backup, hypervisor. No single tool sees the whole chain. Which brings us to the uncomfortable part.

Why single-console defense keeps failing at this

In post-incident reviews the same finding recurs: every stage of the attack was visible in some tool. The reset was in the identity logs. The fan-out was in the network flows. The staging was in endpoint telemetry. What did not exist was the connective tissue — nobody, and no system, joined them while it mattered. We have a name for this: correlation debt. Each tool boundary the analyst must cross costs a query, a context reload, an entity-name reconciliation ("is WKS-0231 the same box as ws0231.corp.local?") and, typically, tens of minutes. An H1-pattern operation that moves from foothold to staging in a few hours can afford to buy the defender's console-hopping time; it is the cheapest thing the attacker purchases all campaign.

The math is unforgiving. If catching the chain requires joining four planes, and each join costs thirty minutes of analyst work in a siloed stack, the stack has a built-in latency floor of two hours after someone decides to look — and the deciding-to-look part depends on one of the per-stage alerts surviving its own tool's noise. Meanwhile a data-theft-only crew needs no "impact" stage at all: by the time the encryption tripwires would have fired, the operation is complete.

What the graph changes

This is exactly the problem shape a graph-native platform was built for, and it is worth being specific about the four mechanisms rather than waving at "correlation".

Lateral movement is a path pattern, not an alert

On a knowledge graph where hosts, identities, sessions and flows are nodes and edges, lateral movement stops being "seventeen unrelated medium-severity alerts" and becomes a single detectable shape: one identity, walking edges it has rarely or never walked, in a time-compressed sequence, toward assets of ascending value. A path query expresses in one rule what would take a brittle pile of per-tool correlation searches:

# Fan-out toward management infrastructure after a fresh
# credential reset — the H1 signature sequence, as one rule.

FROM identity.events
| WHERE event.action == "password_reset" AND source.channel == "helpdesk"
| JOIN graph.path(
    start = identity.user,
    edges = ["AUTHENTICATED_TO", "EXECUTED_ON"],
    within = 6h, min_hops = 3
  )
| WHERE path.targets ANY IN asset.tags("mgmt", "backup", "hypervisor")
  AND  path.novelty > 0.8        # edges this identity rarely walks
| ALERT severity = high, title = "Post-reset fan-out toward management plane"

The novelty term does real work: fan-out by a domain admin doing patch night is old edges; fan-out by yesterday's reset identity is new ones. Baselines, not thresholds.

Blast radius is pre-computed, not estimated mid-incident

The hypervisor question — what can reach the management plane? — should never be answered for the first time during an incident. Because the graph holds trust and reachability edges continuously, blast radius from any node is a standing traversal: compromise this identity, and here is the set of backup consoles, hypervisor interfaces and domain controllers within k hops. Run it before the incident and it is a hardening worklist (every path to vCenter is a path to shrink); run it during one and containment scoping takes minutes. We covered the concept in depth in blast radius as a first-class concept; H1's hypervisor pattern is its clearest use case yet.

Retro replay answers "were we already hit" on publication day

The days-from-CVE-to-campaign rhythm creates a recurring morning: a new family's TTPs or an appliance exploit's indicators are published, and leadership asks whether you were already hit. In a siloed stack that is a multi-day hunt across retention windows. On Netgraph it is retrospective detection: write the new behaviour as an NQL rule, replay it across the telemetry you already hold, and answer the question the same day — with the matches landing in the same triage queue as live detections. Given that H1's exploitation windows opened before many defenders patched, "were we hit in the gap" is no longer an occasional question. It is a monthly one, and it deserves a push-button answer. (More on this in retrospective detection: the quietly overlooked superpower.)

Attack simulation proves the playbook before the attacker does

Finally, coverage claims need evidence. Netgraph's attack-simulation module runs staged scenarios — including the ransomware chain: access, credential theft, fan-out, staging, egress — against the live estate and validates them with real telemetry read-back: did the alerts actually fire, did the expected log rows actually land, which stages produced silence. The silences become tracked detection gaps with owners. This matters because the alternative — assuming your EDR "covers ransomware" because the datasheet says so — is precisely the assumption the encryption-less shift just invalidated.

"Every tool we owned saw its piece of the attack. What we bought afterwards wasn't another tool that sees more — it was the thing that joins what we already see, fast enough to matter." — SOC lead, large Indian enterprise.

A ten-point hardening checklist for H2

Pragmatic, ordered roughly by leverage per unit of effort:

1. Harden the help-desk reset path. Callback-to-registered-number verification for any credential or MFA reset; no exceptions for urgency, because urgency is the pretext.
2. Alert on the reset-then-enroll sequence. Password reset or MFA change followed within hours by new-device enrollment or privileged access is a standing detection, not a hunt.
3. Inventory your edge honestly. Every internet-facing appliance and file-transfer system, with owner, version and a patch SLA measured in days. If you cannot list them today, that is finding zero.
4. Pre-compute blast radius to the management plane. Enumerate every identity and network path that can reach hypervisor management, backup consoles and domain controllers — then shrink the list deliberately.
5. Isolate and instrument the hypervisor plane. Management interfaces off the general network, logging shipped to the SOC, and NDR watching the VLAN's ingress edges as the compensating sensor for the missing agent.
6. Detect staging, not just encryption. Mass archive creation, database-dump signatures, unusual write volume to staging paths — instrumented and tested, because the data-theft variant ends here.
7. Baseline egress. Volume-over-baseline per host and identity toward cloud-storage and uncategorised destinations; throttled exfiltration beats thresholds but not baselines.
8. Wire backup-platform signals into the SOC. Snapshot deletion, retention-policy changes and immutability toggles are pre-encryption tripwires — treat them with page-someone severity.
9. Run the simulation both ways. Full-chain scenario and staging-plus-egress-only scenario, quarterly at minimum, with telemetry read-back and named owners for every gap found.
10. Rehearse the no-encryption extortion decision. Tabletop the case where nothing is down but the data is gone: who decides on engagement, notification and the regulatory clock? The six-hour and 72-hour clocks apply regardless of whether anything was encrypted.

None of these ten requires a moonshot. Most require the planes you already collect to land in one place, speak one query language, and describe one set of entities — which is, not coincidentally, the subject of the next post in this series, Why unified telemetry works. And if you want the standing program that keeps this checklist honest quarter after quarter rather than heroic once, that is a CTEM loop — covered in An effective CTEM strategy.

For the substrate reasoning behind the path-pattern approach, see the graph-native correlation whitepaper. For how detection gaps found by simulation flow back into deployed, tested rules, see closed-loop detection engineering.