In May 2023, the Cl0p ransomware group exploited a Structured Query Language (SQL) injection zero-day vulnerability, tracked as CVE-2023-34362, in Progress Software's MOVEit Transfer platform. The group used the flaw to install a web shell named LEMURLOOT on MOVEit Transfer web applications. The campaign eventually compromised more than a thousand organizations and exposed data belonging to tens of millions of people.
Ransomware attacks can start with a zero-day vulnerability, and MOVEit proves it happens at scale. The more useful answer for a founder or IT manager budgeting security spend is more nuanced. Researchers studying cyberattack patterns note that most cyberattacks likely use known vulnerabilities, not zero-days. This article explains how ransomware operators weaponize zero-days once they find them. It also breaks down how a zero-day differs from an unpatched known flaw sitting in production, and what an organization can do while waiting for a vendor fix.
Zero-Day vs. Known, Unpatched Vulnerability: The Distinction That Matters
A zero-day vulnerability is a software flaw the vendor has not yet identified or fixed, meaning no official patch exists at the moment attackers begin using it. A known, unpatched vulnerability is different: it already has a public Common Vulnerabilities and Exposures (CVE) identifier and, in most cases, a vendor-issued patch, but the patch has not yet been applied inside a particular organization's environment. Security researchers consider zero-day exploits inherently more dangerous than known-vulnerability exploits, because no signature, patch, or workaround exists yet.
The gap between disclosure and remediation is where most ransomware risk concentrates. Recent Verizon Data Breach Investigations Report (DBIR) analysis found that only 26% of critical vulnerabilities listed in the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog were fully remediated by organizations in 2025, a drop from 38% the previous year. Median remediation time is also moving in the wrong direction: organizations now take a median of 43 days to remediate a known-exploited vulnerability, up from 32 days in the prior year. A known flaw with a patch sitting unapplied for six weeks creates almost the same window of exposure as an undisclosed zero-day.
How Ransomware Operators Turn One Flaw Into a Full Breach
A single exploited vulnerability rarely causes a ransom demand by itself. It opens a door, and the operator walks through a fairly consistent sequence:
- Exploit the vulnerability to gain unauthenticated or elevated access to an internet-facing system
- Install a web shell or backdoor to maintain persistent access without needing to re-exploit the flaw
- Escalate privileges and move laterally across the network to reach file servers, backups, and domain controllers
- Exfiltrate sensitive data to support a "double extortion" threat of public release
- Deploy the encryption payload and issue the ransom demand
The MOVEit campaign followed this pattern closely. Beginning on May 27, 2023, the Cl0p ransomware group exploited a previously unknown SQL injection vulnerability in Progress Software's managed file transfer (MFT) solution known as MOVEit Transfer. The group infected internet-facing web applications with a web shell named LEMURLOOT, which was then used to steal data from underlying MOVEit Transfer databases. The Kaseya VSA incident in 2021 followed similar logic through a Remote Monitoring and Management (RMM) platform. Attackers exploited CVE-2021-30116, a zero-day authentication bypass and arbitrary code execution vulnerability in Kaseya VSA, and used it to send malicious commands to VSA servers, which then distributed those commands as legitimate management tasks to every endpoint managed through that VSA instance. In both cases, the zero-day was the entry point, not the entire attack. The damage came from what operators did afterward: persistence, lateral movement, and mass deployment.
Do Zero-Days Actually Drive Most Ransomware Attacks?
The data suggests known, unpatched vulnerabilities still cause more breaches than undisclosed zero-days, even though zero-days generate the biggest headlines. Recent DBIR findings show vulnerability exploitation has become the leading initial access vector for the first time in the report's history, accounting for 31% of all initial access, up from 20% the year before. The CISA KEV catalog itself blends both categories: it tracks zero-days and N-days together, meaning many "actively exploited" flaws on that list already had patches available for months or years before attackers used them.
Zero-days do carry outsized weight in specific incident types. An earlier DBIR edition found breaches involving third parties rose to 15% of all breaches, a 68% increase from the previous year, driven in large part by zero-day exploits used in ransomware and extortion attacks. Managed file transfer tools, VPN gateways, and edge appliances tend to draw this kind of concentrated zero-day attention because a single flaw can reach thousands of downstream customers at once.
The Vulnerability Management Lifecycle: Where Zero-Days Fit
A vulnerability management lifecycle is a structured, ongoing process for identifying, assessing, and remediating software weaknesses before attackers can exploit them. The National Institute of Standards and Technology (NIST) frames enterprise patch management around three core phases. The final stage of NIST's Software Vulnerability Management Lifecycle is execution of the selected risk response. For risks an organization chooses to reduce, this stage adds preparation, implementation, verification, and continuous monitoring of that response. Within execution, NIST identifies four possible risk responses: an organization can accept, mitigate, transfer, or avoid an identified risk.
A zero-day disrupts this lifecycle at the planning stage, because there is no patch to schedule. The organization is forced into "mitigate" mode using compensating controls rather than "remediate" mode using a vendor fix, at least temporarily. That distinction matters for budgeting and staffing: teams that already run a mature lifecycle with current asset inventories can pivot to compensating controls within hours, while teams still building basic patch cadence tend to discover exposure only after an incident.
Threat Modeling and Intrusive Testing: Preparing for the Flaw Nobody Has Found
Threat modeling cannot predict a specific zero-day, but it narrows the blast radius before one appears. NIST defines threat modeling as a form of risk assessment that models the attack and defense sides of a logical entity, such as a piece of data, an application, a host, a system, or an environment. By mapping data flows, trust boundaries, and internet-facing assets ahead of time, a security team already knows which systems matter most when an emergency advisory drops, rather than scrambling to build that inventory during an active incident. CISA has pointed to this same discipline as a way to shrink the software industry's overall zero-day exposure, noting that stronger testing environments combined with threat modeling throughout the product development lifecycle are likely to reduce overall product vulnerabilities.
An intrusive test complements that modeling work by actually attempting exploitation rather than just cataloging weaknesses. A penetration test is a common example of intrusive testing, where ethical hackers or security professionals simulate attacks on a network or system to uncover potential vulnerabilities. A vulnerability scan, by contrast, is a non-intrusive test that identifies existing vulnerabilities and the steps needed to eliminate them without attempting to breach anything. Intrusive testing will not surface an undisclosed vendor flaw, but it regularly uncovers custom application logic errors, exposed management interfaces, and weak authentication paths that behave exactly like a zero-day for that specific organization until someone finds and fixes them.
What to Do When a Patch Doesn't Exist Yet
When a vendor confirms a zero-day and has not yet shipped a fix, response shifts entirely to compensating controls. Federal guidance around recent VPN and edge-device zero-days offers a useful template. When CISA addressed one actively exploited Check Point VPN flaw tied to ransomware activity, the recommended interim measures included disabling support for legacy remote access clients, enforcing IKEv2-only authentication, requiring machine certificate authentication for all VPN connections, and enabling updated Intrusion Prevention System (IPS) signatures to detect exploitation attempts.
Similar guidance applies broadly whenever no patch exists yet:
- Restrict or remove internet exposure of the affected system where operationally possible
- Apply vendor-published workarounds or configuration changes immediately
- Add Web Application Firewall (WAF) or network-layer rules targeting known exploit patterns
- Increase monitoring and log review for indicators of compromise on the affected system
- Segment the affected system from core infrastructure to limit lateral movement
These measures buy time, not permanent security. CISA's guidance on a separate Zimbra Collaboration Suite zero-day made the limitation explicit, stating that such measures should be considered temporary only, since determined attackers may find ways around them. The agency emphasizes that patching remains the only definitive solution to eliminate the vulnerability. Once a patch does appear, the organization needs a workflow ready to test and deploy it immediately rather than waiting for the next scheduled maintenance window.
Moving Forward
Ransomware operators will keep using zero-days whenever the payoff justifies the effort of finding or buying one, and incidents like MOVEit and Kaseya confirm the damage can be severe. For most organizations, though, the bigger day-to-day risk sits in the gap between a patch's release and its actual deployment. A disciplined vulnerability management lifecycle, realistic threat modeling, and periodic intrusive testing close that gap faster and leave less room for either kind of exploit to matter.
Planet 9 is a Bay Area cybersecurity consulting firm specializing in SOC 2, HIPAA, and CMMC readiness for SMBs in healthcare, SaaS, and technology. Our vCISOs and compliance managers help organizations choose the right approach, configure GRC tools if needed, and get audit-ready without wasted time.
