In March 2017, MS17–010 looked like another urgent Windows patch.
Clearly captured from “The Register” in 2019. A worthwhile read for anyone in IT.
Then WannaCry turned it into a global sorting exercise.
Some organizations had patched. Some had delayed. Some had systems they did not know were still exposed. Some were running SMBv1 because the old thing in the corner still depended on it, and nobody wanted to touch the old thing in the corner.
I still see that old thing in the corner.
My students use EternalBlue against Windows 7 systems in simulated critical infrastructure labs. The exploit is old enough to belong to history, and still works. Vendor-supported control systems sometimes depend on operating systems everyone else has already retired. Equipment lasts longer than the software assumptions around it.
EternalBlue became public through the Shadow Brokers leak, but that was not when the vulnerability began to matter.
The bug had existed long before the patch and the exploit had existed before the leak.
Someone knew.
That is the part we tend to soften when we talk about responsible disclosure. The phrase is useful. It gives researchers, vendors, and defenders a process. Report privately. Give the vendor time. Patch before publishing enough detail for attackers to move.
That process works best when everyone is operating inside the same room.
EternalBlue came from the other room.
The room where vulnerabilities are not tickets. They are access. They are capability. They are held because they can be used.
When the exploit leaked, a private capability became public infrastructure. Attackers could copy it. Defenders could scan for it. Vendors could point to the patch. Boards could ask why the patch had not been applied.
The visible clock started.
The hidden clock had been running for years.
A zero-day is counted from disclosure because defenders have had zero days to respond. The vulnerability itself may be old. It may have been sitting in the product for years. Publication only tells the rest of us what someone else may already have known.
Sometimes for a long time.
One of the articles that pulled me into security was in The Register, back in 2012.
“Hackers get 10 MONTHS to pwn victims with 0-days before world+dog finds out.”
The subhead was worse: “Tell no one, compromise everyone.”
That headline stayed with me because it made the hidden interval visible.
Years later, The Register described the same problem from the attacker’s side: “Bad guys are settling in, putting their feet up for the long haul.”
That is why the Nightmare Eclipse disclosures are worth more than a quick argument about etiquette. Nightmare Eclipse is the alias attached to a cluster of reported Windows security-component vulnerabilities, including issues involving Defender, BitLocker, WinRE, and local privilege boundaries.
The names are strange enough to sound fictional: BlueHammer, RedSun, UnDefend, YellowKey, GreenPlasma, MiniPlasma, RoguePlanet. The tone around them has become almost theatrical. Handles. Grudges. Public proof-of-concept releases. Microsoft statements. Researcher counterclaims. Legal language. Community backlash.
It would be easy to make the story about personality.
That would waste the lesson.
Microsoft is right that public exploit release can harm customers. Publishing working details for unpatched vulnerabilities compresses the time between disclosure and attack. It gives people with less skill a clearer path. It forces defenders into emergency work, especially when the affected components sit close to the centre of Windows security: Defender, BitLocker, WinRE, privilege boundaries.
A vendor must protect users from that.
A vendor also needs to keep researchers willing to knock on the door.
Vendors move at the scale of liability. Researchers move at the scale of reputation, frustration, ethics, or leverage. State actors move at the scale of time. Disclosure is where those clocks collide.
That is where Microsoft’s response feels brittle.
The official position may be correct. The disclosures may have violated coordinated vulnerability disclosure norms. Public proof-of-concept release may have been reckless. If a researcher skips private reporting, or publishes enough detail while systems remain exposed, the vendor has every reason to object.
But a legally defensible response can still make the next researcher hesitate before reporting.
And that becomes a governance problem.
The next researcher may not be dramatic. They may not want attention. They may not want a fight. They may simply decide that reporting the bug is too slow, too risky, or too likely to be dismissed.
Then the vulnerability stays private.
Someone else may still find it.
And that someone may not write a blog post.
We do not know whether the Nightmare Eclipse vulnerabilities were exploited before publication. However, now the vulnerabilities have names, defenders can check. They can search logs. They can test controls. They can ask whether Defender behaved properly when attacked through its own privileged surface. They can review BitLocker assumptions. They can decide whether recovery environments have been treated as security boundaries or as dusty maintenance spaces no one watches.
Before publication, there was no obvious thing to search for.
A SOC analyst opens a dashboard after the advisory lands. The CVE now has a name. The query can be written. The ticket can be assigned. The patch can be tracked.
Six months earlier, the same activity may have looked like noise.
A local privilege escalation does not always arrive waving a flag. It may look like a process with authority doing something processes with authority are allowed to do. A security product runs with high privilege because it has to. A recovery environment is trusted because it is supposed to recover things. A laptop protected by BitLocker is assumed to be protected until someone shows the assumption had a crack in it.
After disclosure, the crack has a label.
Before disclosure, the crack was still there.
“No known exploitation” is a statement about knowledge.
It is not a statement about reality.
It may mean nobody exploited the bug. It may also mean nobody checked properly. It can mean that the needed telemetry was never collected. It may mean the activity had blended into normal administrative behaviour. It may mean the attacker cleaned up. It may mean that evidence was never organized around the right question.
Those are different worlds hiding under one sentence.
EternalBlue showed what happens when a state-held capability escapes. The damage did not come only from a Windows flaw. It came from the interval: the time when the vulnerability was useful to one actor, invisible to defenders, and eventually available to everyone.
Nightmare Eclipse points at a different interval.
The time between a vulnerability existing and a vendor being forced to treat it as real.
That interval is where governance usually fails.
Patch management asks whether the update was applied.
Security governance must ask whether the organization would have noticed the exploit before the update existed. It has to ask whether native security controls are being treated as magic. It has to ask whether recovery partitions, privileged services, endpoint agents, and local admin pathways are monitored as attack surfaces or trusted as background machinery.
In practice, that means going back after disclosure and asking better questions of old data: which privileged processes behaved strangely, which security tools spawned unexpected children, which recovery paths were touched, which “trusted” components were never monitored because trust had become an assumption rather than a finding.
Most organizations are better at patch status than historical doubt.
That is understandable. Historical doubt is expensive. It does not fit neatly in a dashboard. It asks people to look backward through logs they may not have kept, for behaviour they did not yet know was suspicious, against systems they believed were already protected.
But that is where unknown attacks live.
They live in the gap between “fully patched” and “actually safe.”
State agencies understand that gap.
The NSA, FSB, and North Korea’s cyber units do not need magic. They need time, specialists, target knowledge, operational feedback, and permission to treat vulnerabilities as assets. They can hold a bug. They can test it quietly. They can use it only where the value is high enough.
Defenders usually meet the vulnerability later.
They meet it as an advisory or a patch.
Or a ransom note.
That asymmetry is why disclosure culture matters. A researcher report is one way to collapse the hidden interval. The vendor may dislike the researcher. The report may arrive with ego, anger, bad grammar, or public pressure. Some reports will be wrong. Some researchers will be difficult.
The process has to survive difficult people with valid bugs.
Otherwise the hidden interval gets longer.
Microsoft can be right about irresponsible disclosure and still wrong in the way it handles the relationship. Threatening language may protect the boundary for one incident while weakening the bridge for the next one.
Disclosure is how an unknown vulnerability becomes a governable vulnerability. Once the bug is public, everything accelerates: patching, exploitation, detection, regulation, blame. Before that, the vulnerability still exists.
It may be held or it may be sold. It may be rediscovered or it may be waiting in a folder until anger, theft, money, ideology, or accident moves it into the open.
Microsoft may be technically correct about responsible disclosure.
But I have to ask: does its response make the next private disclosure more likely?
But I have to ask: does Microsoft’s response make the next private disclosure more likely?
If the answer is no, then the response protects the boundary while weakening the bridge.
The next bug stays hidden longer.
The hidden clock keeps running.
Top comments (0)