Ransomware is a business, defend like one

Ransomware looks like a single event, a lock screen and a note. Look closer and the note fronts a business that divides labor, prices risk, and competes for market share.

Behind the note, an industry

What appears as one break-in usually reflects a supply chain. Developers maintain the ransomware brand and codebase, affiliates run intrusions, and initial access brokers sell footholds into networks. Payment launderers, obfuscation vendors, and data leak hosts round out the stack. Each role is narrow, repeatable, and replaceable, which is why output rises even when an individual crew takes a hit. Costs spread across many actors, and replacements show up quickly because the barrier to entry is low.

Consider a representative flow. An access broker sells a cloud tenant with weak multi factor configuration to an affiliate. The affiliate buys a subscription obfuscation service that keeps loaders undetected. After lateral movement, a data-leak host publishes samples to pressure the victim while negotiators handle chats. None of these actors must be exceptional, they must simply be adequate at their slice.

Actionable tip: model a ransomware incident as a chain of suppliers, not a single adversary. Maintain a short register of the three most common footholds seen in recent cases, for example reused credentials in remote access, misconfigured identity policies, and exploited public apps. This list anchors tabletop exercises and directs logging. It works when an environment has at least basic central logging, it fails if identity and endpoint telemetry are unavailable or siloed.

The extortion funnel, where to break it

Ransomware operations behave like a funnel, leads enter at the top and only later convert to ransom. Breaking the funnel early is cheaper than fighting at the bottom. Use this structure to decide which controls deserve attention first.

Stage 1, Discovery

• Goal: find exposed services and weak identity settings at scale.
• Break point: external attack surface monitoring, alerting on new internet facing assets and risky authentication flows.

Stage 2, Access

• Goal: buy or steal valid sessions and credentials.
• Break point: conditional access tied to device health, phishing resistant authentication, and fast session revocation.

Stage 3, Expansion

• Goal: move laterally, disable defenses, collect data.
• Break point: least privilege on admin tools, network segmentation, and enforcement of driver blocklists to prevent kernel tampering.

Stage 4, Monetization

• Goal: exfiltrate and encrypt, then pressure via leak sites.
• Break point: egress controls that block unknown destinations, immutable backups, and a preapproved legal and communications playbook.

Stage 5, Retention

• Goal: maintain access for repeat extortion or resale.
• Break point: post incident identity hygiene, rotating keys, and validating software inventory against a known good baseline.

Non obvious contribution: treat this as a conversion funnel that can be measured. A practical leading indicator is the dwell time between first successful external login and the first lateral admin action. If that interval shortens across incidents, investment in stages 1 to 2 is lagging. This metric fails if admin action detection is unreliable.

Why BYOVD and EDR killers work

Endpoint detection and response tools watch for lateral movement and suspicious behavior. Attackers counter with EDR killers that abuse Bring Your Own Vulnerable Driver, loading a legitimately signed but flawed driver, then using its kernel privileges to stop agents and tamper with eventing. The mechanism is simple: user mode malware calls a trusted driver interface, the driver performs privileged actions on its behalf, and security controls lose visibility at the root. Because the same drivers are reused, these anti tools spread quickly.

Controls with trade offs

• Kernel driver blocklists, stop known bad or risky drivers from loading. Trade off, must be updated promptly, a stale list creates a false sense of safety.
• Virtualization based code integrity, enforces strong signing policies for kernel modules. Trade off, may impact legacy peripherals that depend on older drivers.
• EDR self protection, hardens processes and services against tampering. Trade off, determined kernel abuse can still succeed, so this is necessary but insufficient.
• Attestation of newly loaded drivers, alerts on rare or first seen modules in the fleet. Trade off, requires baseline data and tuning to avoid noise.

Concrete example: an affiliate deploys a loader that fetches a printer driver known to expose arbitrary memory writes. The driver disables the agent, then the affiliate uses native admin tools to stage encryption. A simple mitigation is to enforce a known good driver allow list on critical servers. This works when the server fleet is homogeneous, it fails if diverse hardware drivers are required.

Scenario, a franchise style intrusion in slow motion

Context

A manufacturing tenant with a flat domain, mixed Windows versions, and EDR on endpoints. Driver policies are permissive due to a legacy device.

T+0, Trigger

An initial access broker sells a valid cloud admin session obtained through password reuse. Conditional access allows logins from unmanaged devices for break glass accounts. The affiliate adds a new app registration and creates a covert mailbox rule. The control that failed, break glass policy exceptions were never reviewed.

T+4h, Cascade

The affiliate enrolls a workstation, then uses remote management to pivot. EDR flags lateral movement, but the alert is auto closed due to a noisy rule. The affiliate deploys an obfuscated loader that downloads a vulnerable graphics driver, kills the agent, and runs credential discovery. Kernel abuse permits tampering with event logs, reducing telemetry.

T+36h, Response

Network encryption begins, data from engineering shares has already been exfiltrated to a newly registered domain. Backups are intact, but leak site samples increase pressure. The team blocks the driver family via group policy, rotates privileged credentials, and rebuilds compromised workstations from gold images. Legal and communications activate a prepared statement tailored to suppliers.

Lesson

Two weak links enabled the cascade, unmanaged cloud admin exceptions, then a permissive driver policy. The EDR was necessary, but kernel level tampering outpaced it. A periodic review of high privilege exceptions and a driver allow list on servers would have broken the chain earlier.

Read the market like an operator

Defenders benefit from the same market view that adversaries use. Track the health of the anti tool ecosystem, because it predicts how hard endpoint defenses will be pressed. Think in terms of supply entering the funnel, not only incidents exiting it.

Signals to track

• Which vulnerable drivers are circulating in public kits, and whether signing revocations are keeping pace.
• Shifts in initial access, for example, growth in session theft versus phishing, visible in authentication logs.
• Affiliate chatter patterns, not names, but the mix of tools they purchase, such as obfuscators and loaders.

Questions to ask

• Can the stack withstand driver based tampering for a defined window, or does visibility collapse instantly.
• What happens if a managed service provider in the supply chain is compromised, which roles hold transitive admin.
• Which three controls reduce conversion earliest in the funnel, and do they have owners and test cases.

Decisions to rehearse

• Rapid conditional access tightening without locking out critical workflows.
• Server side egress blocks when leak site pressure escalates.
• Driver allow list updates in hours, not days, when a new kernel threat appears.

Falsifiable claim: the reuse half life of popular vulnerable drivers will continue to shrink as signing revocations accelerate. Expect shorter windows between first public appearance and effective blocking, which pushes affiliates toward user mode tampering and identity abuse. This claim fails if revocations slow or vendors relax kernel policies, in that case driver abuse remains a staple and visibility stays at risk for longer.

What not to do

Anti pattern, backups only as the ransomware plan

Restoring from backups does not end extortion when data theft is the primary pressure. Attackers publish samples and target suppliers or customers to force payment. Avoid relying on backups alone whenever leak site pressure is plausible, because the mechanism of harm is reputation and legal exposure, not data loss. Pair immutable backups with outbound data controls, a prepared communications plan, and documented decisions on what to disclose and when. This approach works when outbound filtering can block newly registered destinations and file transfer oddities, it fails if egress is wide open.

Anti pattern, driver blocklists that age quietly

Manually curated blocklists often lag, which turns a control into theater. Affiliates exploit this by rotating to adjacent drivers that share the same flaw. Avoid static spreadsheets when kernel integrity is at stake, because the failure mode is silent bypass at scale. Prefer platform enforced allow lists, virtualization based code integrity, and automated alerts on first seen drivers. This holds when hardware and applications can tolerate stricter signing, it fails if legacy devices require outdated drivers and no compensating controls exist.