You Don't Have to Run an Exploit to Know If You're Vulnerable

The timeline that vulnerability management was built on has quietly disappeared. For decades, defenders could count on weeks or months between a flaw becoming public and anyone actually turning it into a working attack.

Two forces closed that gap at once.

The first is sheer volume: new flaws are piling up far faster than ever before, with the first half of 2026 alone producing more CVEs than any full year on record prior to 2024, arriving at an alarming rate of roughly one every 7.4 minutes. 

The second is speed. AI has quickly erased what was left of the cushion, as we mentioned in a recent article. Today, turning an advisory into a live exploit no longer takes skilled, patient effort. The Zero Day Clock, which tracks time-to-exploit across tens of thousands of CVEs, now puts the median time for 2026 at well under a day, down from a matter of weeks just a few years earlier.

Unfortunately for security teams, defenses haven't moved anywhere near that fast, and no team can patch its way out of a backlog that’s literally growing by the minute. But volume was only part of the problem: only a fraction of a percent of those CVEs was ever turned into a live, in-the-wild attack.

What opens up is a widening stretch of time where attackers act freely, with defenders powerless to stop them. The compounding problem is proof, separating the handful of threats that can actually be turned against you from the tens of thousands that never will.

The Risk Lives Where You Can't Fire 

Running pentests continuously instead of once a quarter certainly narrows that stretch, but it carries a hard ceiling. A live exploit, used by automated pentest tools, can only be launched where it’s safe to do so and where a usable exploit already exists, which in most enterprises covers only 10 to 15% of their actual attack surface. 

But the rest goes unproven with traditional automated pentesting tools: the flaws without a public exploit, the regulated and air-gapped systems too sensitive to withstand a real attack, and the freshly disclosed bugs adversaries are already using while defensive tooling is still catching up.

However, proving exploitability does not require a public exploit or a live shot at a system too critical to risk. Whether physical or virtual, a chain is only as strong as its weakest link, and you don’t have to load the whole chain to find out which link would break. Picus Platform proves exploitability either way, exploit in hand, or not.

This coverage gap is exactly why CISOs are moving budget from patch velocity to validation, and our latest guide lays out the full case with the numbers to defend it in front of a board. Get your copy below.

Prove the Chain, Not the Exploit

Here’s the part that starts legitimately rebalancing the equation: you can prove whether an exploit works against you without having to actually pull the trigger.

Every exploit is a sequence of dependent steps: initial execution, defense evasion, privilege escalation, credential theft, lateral movement. The attacker needs each required step to land, and a step only lands if your environment allows it to.

Map a vulnerability to the steps its exploitation depends on, then test each against the defenses you’ve actually deployed. If a required step has no viable path through your controls, the chain can't be completed, and the exploit fails on that asset, even though the vulnerability is still there. The opposite holds true: If every required step would succeed, the exposure is genuinely exploitable, and you can back that verdict with evidence rather than a hunch.

It's the logic of rocket engineering. Engineers qualify the engine, the fuel system, and the heat shield one at a time, all before a launch is ever attempted, and if a critical component fails its test, they know the vehicle can't fly, without having to risk a launch.

A Worked Example: Nightmare-Eclipse

The freshly disclosed-bug case gets concrete the moment a single person drops a run of Windows zero-days, and the criminal ecosystem picks them up. That’s exactly what happened with Nightmare-Eclipse. The exploit code was public on GitHub inside a week, but running the actual malware against your own domain controller to find out if it lands is not a test anyone should sign up for.

Looking back at how this specific timeline played out is the clearest illustration of why proving the chain, not firing it, is such an effective way of deciding which patches to prioritize.

Nightmare-Eclipse (aka Chaotic Eclipse, Dead Eclipse) is not a ransomware crew or a state-sponsored group. It is, by all available evidence, one security researcher with deep Windows-internals knowledge and a personal grudge against Microsoft. 

Beginning in early April 2026, the actor published a string of Windows zero-day exploits as uncoordinated disclosures, with no coordinated timeline and, in most cases, no CVE and no patch at release. 

Three of the releases fit together into a single, self-contained privilege-escalation-and-blinding playbook.

• BlueHammer: Local privilege escalation via a privileged file read, exploiting a race condition in Windows Defender. An EICAR bait file pushes Defender into a remediation workflow that creates a Volume Shadow Copy snapshot, briefly exposing the SAM, SYSTEM, and SECURITY hives. BlueHammer uses Cloud Files callbacks and opportunistic locks to win that race, reads the hives, dumps the local NTLM hashes, and escalates to SYSTEM.

• RedSun: The same primitive set, inverted into a privileged file write. Instead of reading the SAM hive, RedSun redirects a SYSTEM-level write into C:\Windows\System32, overwrites TieringEngineService.exe with an attacker binary, then triggers the Storage Tiers Management COM object to launch it as SYSTEM.

• UnDefend: A Defender disruption tool. It locks Defender's signature files (mpavbase.vdm, mpavbase.lkg), blocks definition updates, and blocks the signature base from reloading on service restart, all while reporting a healthy, current status to the EDR console. 

Chained, the outcome is a machine with no privilege barrier and a security stack that lies about its own health. 

Replicate Behavior: Building the TTP Chain

Turning the intrusion into a safe test means converting each attacker's behavior into a discrete action Picus can run and measure without having to actually fire the real exploit.

Several actions make up the chain; but three carry most of its weight:

1. Create a new service, "Evilsvc" (Execution). BlueHammer's escalation ends by registering a temporary Windows service with CreateService so its payload runs as SYSTEM. The emulated action installs a harmless test service, standing in for that final execution step without launching anything malicious.

2. Dump the SAM hive via Volume Shadow Copy (Credential Access). This is BlueHammer's core primitive. Rather than touch the live, locked registry, the attacker reads the SAM, SYSTEM, and SECURITY hives out of the Defender-created shadow copy and decrypts the NTLM hashes offline. The emulated action reproduces that VSS-based hive access, the exact behavior a credential-theft control should catch.

3. Disable the Windows Defender service (Defense Evasion). In the real chain, UnDefend blocks Defender's updates and stops its signature base from reloading, all while deceptively reporting a healthy status to the console. Picus does not need that malware to validate the step; it emulates the technique with unDefender, a Threat Library action that safely stops the Windows Defender service, testing whether your tamper protection holds regardless of which tool attempts to evade it.

When run in sequence against your live controls, these steps show whether the full chain, SYSTEM access, credential theft, along with a blinded Defender would actually succeed in your environment, or whether one of your defenses breaks it first.

This way, you can prioritize patching and hardening where the chain would actually complete and reach that decision without firing a single exploit, including on the systems you could never test live. Our TTP-chaining two-pager walks through this exact process step by step, from CVE ID to a defensible decision, with a second worked example. Get your copy below.

Cover the Whole Surface, and Keep Proving It 

Live exploitation and TTP-chaining were never competing methods; they fit together symbiotically.

The strongest programs run both, then run them again every time the environment shifts, because a control that broke the chain last month may not survive the next configuration change. Exploitability is a question to continuously keep asking, not a box to tick once.

This is the loop Picus closes. Where an exploit exists and firing it is safe, Autonomous Pentesting detonates the real chain for the strongest proof available. Where it’s not, on the restricted, air-gapped, or business-critical assets, or the CVE that dropped this morning with nothing weaponized yet, TTP-chaining proves exploitability by inference.

Breach and Attack Simulation then re-checks every verdict, so last quarter's "accept" never quietly turns into this quarter's breach.

The result is one platform, one on-demand answer: "What can actually be exploited here, right now?" 

Take the case still sitting in your backlog. The next Nightmare-Eclipse release with no patch yet, the air-gapped box you will never launch against, the advisory that landed a few hours ago.

Book a demo and watch as Picus tests your unique environment against live exploits and TTP chains.

Sponsored and written by Picus Software.