“Zero days” are popular items in cyber security discussions. They grab headlines, they often feature in high-profile conference presentations, they can even apparently spawn television shows. Yet for all the attention and frequent discussion in non-technical audiences, the term itself seems a bit slippery. Terms like “zero day attack” are thrown around without diving into what precisely makes these items stand apart from other intrusions, capabilities, and adversary actions.
At its core, a zero day refers not so much to an attack (or even an exploit) but instead denotes a vulnerability. More specifically, a zero day is a vulnerability within a given application, piece of software, etc., that someone other than the software’s developers and designers know of while those same designers are completely unaware of that vulnerability’s existence. This disconnect in knowledge is what makes a “zero day” interesting, and potentially frightening – but if and only if that discovered vulnerability is also weaponized following discovery and before the product vendor learns of its existence.
The typical, responsible vulnerability research and disclosure process resembles the chart below. A vulnerability researcher identifies a flaw in software. In addition to the flaw, the researcher also identifies a way to use or action that flaw in the form of an exploit, typically a Proof of Concept (POC) to demonstrate the item to the impacted vendor. While a working exploit exists, the responsible disclosure process means the exploit remains private while the vendor works on a fix. Once a fix is ready, disclosure and patch release can take place. At this time, the vulnerability (and potentially the POC) become public knowledge, allowing others to analyze the patch and other information to develop exploits. This sequence of events, particularly the public disclosure and subsequent exploit development, lead to sayings such as “patch Tuesday, exploit Wednesday” when referring to Microsoft’s update cadence.
While the above sequence of events is hardly perfect, it works reasonably well enough. Provided details on the vulnerability or its POC remain private, the process allows a vendor to create a fix and make it available (or even potentially push it out automatically) to end users. As a result, the first time any “bad actors” who would like to weaponize a given vulnerability get a chance to even identify such a thing exists is the same time the patch becomes available for people to address the vulnerability. There are certainly exceptions to this process depending on patch verification and testing cycles, high-availability hardware uptime requirements, industrial systems and other cases. But again, this process generally works well enough for most people and most situations.
A zero day differs from the above in the availability of knowledge and the timing of notification to the impacted vendor. A zero day scenario means after vulnerability discovery, the researcher does not disclose the flaw to the vendor, but instead either directly develops a working exploit, or sells the knowledge of the vulnerability to someone who can build such an item. “Zero day exploitation” can now take place as no one – not the vendor, not the victims – is aware of precisely how networks are breached, enabling use (and, as seen in the ProxyLogon examples, potentially widespread use) before the vendor (or other researchers) identify that something is amiss.
There are exceptions to the above timeline. Discovery by certain entities – say, some particularly patient state-sponsored or -affiliated actors – may result in the vulnerability (and even an exploit) being “shelved” so as not to “burn” it prematurely. Such discussions focus on various cost-benefit determinations as to whether it makes sense to utilize the vulnerability before someone else finds it, to hold on to it for the proverbial “rainy day” when it is truly needed, or even to disclose it to the vendor to patch because it represents a risk to the discoverers as well. These discussions are mirrored in items such as the US Vulnerability Equities Process (VEP) and other bureaucratic formulae for deciding such things.
A so-called “vulnerability stockpile” or similar concept may certainly be concerning – maybe even frightening! – but absent action such items represent a dormant risk. While awaiting use at some future, undetermined time, the related vulnerability could be identified by others and patched, the software in question could be replaced or retired, and various other items could happen rendering the stockpiled item useless.
The real concern around zero days is their use after discovery. But much like the patching process, where disclosure creates a race condition between end-users applying the patch and bad actors developing exploits for the public vulnerability, the zero day exploitation process contains risks. Namely, use a given technique too wildly, too indiscriminately, and the chances someone figures out what’s going on increase steadily. Thus bad actors need to exercise some degree of due care and diligence in using such capabilities to avoid “burning” them prematurely. Once an exploit based on a zero day vulnerability transitions to more widespread application, you can basically set a timer as it will be discovered eventually.
Now, the above consideration may not matter so much if the vulnerability is something like a software flaw in gas turbine generator code that would cause a natural gas power plant to explode. Using such a vulnerability even once would be too many times. But in most (not all, but most) of such extremely dire cases, the access, knowledge, and communication necessary to even be in position to deploy such a gruesome vulnerability means an actor could, at that point, just turn the generator off if they wanted to, meaning a number of other items must fall into place to ensure weaponization. Thus while concerning, these catastrophic, cyber-physical related vulnerabilities represent the conclusion of a long chain of events. As such we shouldn’t see them much (if ever, outside of armed conflict), and when we do it is likely already too late with other, more pressing problems manifest (like missiles flying and bombs dropping).
Instead of dwelling on world-ending vulnerabilities, defenders and network owners will likely deal mostly with zero days focusing on initial access. This access bias is demonstrated by the “free market” of vulnerability and exploit sales, where items targeting mobile platforms and web browsers (or related applications) often command the most attention (and money). The reason is, once access is achieved (and preferably in a stealthy, unknown manner), the vast majority of security programs are relatively too immature to prosecute an investigation. Essentially, crack the perimeter and related access controls, and you have near complete freedom to further an intrusion or collect information. This is especially the case for consumer-oriented platforms like iOS, the subject of many monetized zero days in the mercenary hacking scene.
Now that we have a set of capabilities (exploits for zero day vulnerabilities) that we will assume are items of concern (since they are actively under exploitation) the “clock is ticking” for attackers as each subversion of the vulnerability risks being caught. Unless the entity is extremely discrete, or very lucky, getting caught (or the vulnerability being inadvertently patched) is an eventuality. Once identification is (finally) achieved, the timeline shifts again as the former “zero day” now becomes a “+1 day” or “n-day.” In this case, the vulnerability in question is now publicly identified, and potentially a patch exists (although not necessarily immediately).
In this scenario, we find ourselves again in a delicate time period. In the case of an identified (now former) zero day vulnerability, exploit code already exists but a patch may not. Or if a patch exists while the exploit remains non-public, the same race condition discussed previously between applying the patch and others reversing it to develop public exploits begins. Now what was once a likely secretive, discretely deployed capability becomes widely available and applicable to multiple threat actors. This describes the “+1 day” scenario.
The “+1 day” terminology may seem arcane and unnecessary, but this is an extremely important concept to understand – and one that the vast majority of popular discussion gets woefully wrong. To use an example, let’s look at MS17-010 vulnerability, linked to the “EternalBlue” exploit. Patched as a Critical vulnerability by Microsoft in March 2017, the item was – prior to this point – a zero day vulnerability used by the US National Security Agency (among others for reasons). This intelligence agency connection became clear when the ShadowBrokers entity leaked the EternalBlue exploit for the (now patched) vulnerability one month later, in April 2017. The exploit then quickly gained widespread attention when it was used to power the WannaCry ransomware incident, and included with (although not a dominant factor for) the NotPetya event a few months later.
Some might view the timeline above to be irrelevant or pedantic, emphasizing “the NSA lost control of their tools, we should be outraged!” That might make some people feel better, but it misses the point and significance of these events completely. While a valid argument exists over whether MS17-010 should have been disclosed on discovery prior to 2017 through the VEP by NSA, once the item was revealed to Microsoft the “zero day” argument becomes irrelevant. The item is now known, received a patch, and further activity transitions from zero day activity to +1 day operations. After 14 March 2017, any entity could reverse engineer the MS17-010 patch to identify the precise flaws in Server Message Block version 1 (SMBv1) and create their own exploit. That adversaries rapidly incorporated a leaked exploit approximately two months later shows not deviousness on their part in co-opting a former NSA tool, but rather laziness in recycling another entity’s exploit for a known, now-patched vulnerability.
EternalBlue use, and MS17-010 exploitation more widely after March 2017, raises questions about vulnerability disclosure processes, but its impact is rooted more in patching and vulnerability management processes. Organizations essentially had a two month window to identify, test, and deploy a patch clearly marked by Microsoft as “Critical” on release. That industry failed to notice this and take appropriate action is a blackmark on network and vulnerability management processes, and a gift to malicious actors.
Expanding away from EternalBlue, hyperbolic conversations about “zero days” are in many cases discussions over widespread weaponization of vulnerabilities post disclosure than any sort of widespread use during a vulnerability’s zero day phase. Even in the case of widely-applicable, true zero day situations such as the recently discovered FORCEDENTRY item in Apple software, actual use of this item was quite narrowly focused prior to public disclosure. That means that this exploit, and similar items, are certainly threats to specific entities, but are most definitely not world-ending immediate crises.
Even in cases where a zero day situation seems to hold but widespread use exists, the story is actually a bit more complex. Looking at ProxyLogon again, initial exploitation of this Microsoft Exchange vulnerability was associated exclusively with operations linked to the HAFNIUM threat actor. For reasons still not adequately explained, exploitation activity spread to other entities starting in January 2021, with even more entities getting in on the fun shortly before patch release in March 2021, followed by widespread use after disclosure. A visualization is available from this timeline from DomainTools:
The expanded use prior to public disclosure in March 2021 is very strange, and indicates one of a number of possibilities:
- Multiple entities independently discovered the vulnerability and weaponized it prior to disclosure. (Not likely.)
- Multiple entities were able to access communications or other items related to the actual vulnerability disclosure, and weaponized this information. (Scary, but not likely.)
- HAFNIUM shared vulnerability and exploit information with other parties. (Odd, but seems plausible.)
While evidence is scarce, what little exists seems to suggest #3 as the most likely hypothesis. In any case ProxyLogon’s “zero day” period appears to be prior to January 2021 (when Microsoft first learned of the vulnerability), with a murky, “quasi zero day” period between January and March, before becoming a +1 day on 02 March 2021. This represents a complex and confusing case, but still supports previous observations: ProxyLogon and related activity was a serious, but focused, threat prior to disclosure before morphing into a steadily more widespread intrusion vector from early January 2021 onward as more and more parties learned of its existence.
The real concern around zero days appears to reside in two main areas based on the above discussion:
- Focused targeting (to maintain equities and capabilities) in the period prior to discovery.
- Rapid movement to widespread targeting once disclosed and transitioned to +1 day status.
If we wish to meaningfully and significantly improve widespread security, #1 seems not terribly relevant. Instead, focusing on frictions and gaps surrounding #2 appears quite useful. The most significant risk to the majority of entities comes in the murky period between zero day disclosure (when it ceases to be a zero day) and patch application. Minimizing this time period from disclosure to patch seems to be the most valuable contribution researchers, vendors, and policymakers can make to combat what is lazily called the zero day threat.
Certainly residual risk remains with #1, especially for high-profile, high-value targets. In this case, an emphasis on layered defense and robust monitoring is most appropriate. As noted above, the most valuable and worrisome zero day items are access-focused (like EternalBlue, ProxyLogon, and FORCEDENTRY). But once achieving access, adversaries still must take control of endpoints compromised and expand outward – which present opportunities for defenders to identify suspicious activity and mitigate follow-on actions. So while the zero day is problematic, it is merely a mechanism to accelerate through or skip over one step in the overall cyber kill chain, as opposed to a magic weapon allowing exploitation, control, and weaponization all in one.
To conclude, zero day vulnerabilities are very interesting, but are less worrying than many commentators would lead the public to believe. Certainly these can be incredibly problematic, especially for certain focused audiences like critical infrastructure and political dissidents in repressive regimes, but even then a zero day represents just one facet in an overall intrusion lifecycle. Other options exist to address such intrusions once they take place, and we as an industry must recognize and invest in such capabilities as they will enable defense and response for a variety of vectors beyond vulnerability exploitation. If we as a community are truly concerned about vulnerabilities, our investments should be made in improving and accelerating the patching process to minimize the time of most concern between disclosure and patch application.
