xorl %eax, %eax

Overview of 0days seen in the wild the last 7 years

leave a comment »

Starting in 2019 Google’s Project Zero (P0) team published a tracker for all 0days that were discovered to be exploited in-the-wild (either by Google or others). The data from this tracker start from August 2014 and continue to this day (for this post that is October 2021).

Using this data source, I created some simple graphs to better understand the 0day threat landscape for all of us tasked with cybersecurity responsibilities.

There are however a couple of assumptions I’m making by using this data set, those assumptions are:

  • This is a representative sample of all the 0days used in the wild
  • The data collected in this tracker are accurate

So, let’s start first of all with the trend which is one of least useful graphs but the one people are regularly interested in. The reason why this is generally useless is because the dates are the dates when those 0days were officially patched, not when they were initially acquired by the threat actors, or their first operational use. Additionally, those patching dates rely on the cybersecurity industry and community actively working to discover and remediate 0days in the wild. So, there might have been periods that those companies/people had different priorities and didn’t dedicate as much time on threat hunting and remediation for 0days.

For all those reasons, I do not consider the following one particularly useful but added it here for completeness. If there was any conclusion someone could make from this is that the end of the year and early winter is consistently the period were the least amount of 0day discoveries and mitigations happen.

A far more interesting statistic is which are the top targets. That can help us focus on what is more likely to get hit with 0days in the future. Looking at the statistics for the last 7 years (2014-2021) it is clear that by far the top target is Microsoft (50%), followed by Adobe (13.9%), Google (11.9%), and then Apple (10.3%).

Later in this post I’ll go into more details on the each of the products most commonly targeted on those vendors, which can help us drive our priorities (e.g. where to hunt for more, what to protect more, which are the highest risk vendors) or even understand what most threat actors are interested in acquiring.

The second high-level overview graph that is particularly interesting is the type of vulnerability exploited where we see that 71.1% was memory corruption, and 16% was a logic/design flaw. This is another interesting metric since it can help us prioritize our efforts in those issues.

Interestingly, those are also typically some of the hardest to thoroughly audit (especially in an automated manner) and this might also be a factor on why they were the most frequently used. I mean the combination of being hard to discover vulnerability via the automated means most vendors are using, and the fact that they typically enable a wide variety of exploitation avenues.

Now in the next part I’ll be going through each of the top 5 vendors affected by 0days in the wild and see which of their products were targeted the most. Again, to help us prioritize our efforts accordingly.

#1 Microsoft (50% of all discovered 0days were for this vendor)

  • Windows (46.4%)
  • Internet Explorer (22.7%)
  • Office (13.4%)
  • Windows kernel (8.2%)
  • All the rest: Exchange, VBScript, XML Core Services, Defender (9.2%)

#2 Adobe (13.% of all discovered 0days were for this vendor)

  • Flash (85.2%)
  • Reader (14.8%)

#3 Google (11.9% of all discovered 0days were for this vendor)

  • Chrome (95.7%)
  • Android (4.3%)

#4 Apple (10.3% of all discovered 0days were for this vendor)

  • iOS (55%)
  • WebKit (40%)
  • MacOS (5%)

#5 Mozilla (3.6% of all discovered 0days were for this vendor)

  • Firefox (100%)

The final graph that I found particularly useful to understand the threat landscape is the average patching time per each of those top 5 affected vendors. For this one, please note that the Google tracker does not have a data for all entries. Specifically, 94.85% of the entries include both dates (discovery and patching) so this is what was used for the following calculations.

In total the average patching time was 22.67 days from the discovery time to the patch being publicly available, but below you can also see this metric per vendor.

The average patching time (from discovery to patch being publicly available) for each of the top 5 affected vendors are:

  1. Microsoft: Average of 41.2 days between discovery and patching
  2. Adobe: Average of 8.1 days between discovery and patching
  3. Google: Average of 5.3 days between discovery and patching
  4. Apple: Average of 9 days between discovery and patching
  5. Mozilla: Average of 6.2 days between discovery and patching

Based on the above data, Microsoft is the highest risk vendor if we combine the amount of 0days found in the wild and the average patching time of 41 days. So, maybe your strategy should involve minimizing the use of those products and services, or spending more resources in security controls around them.

Another valuable insight that we can derive is that the most targeted software by adversaries that employ 0day exploits are web browsers and mobile phones. Especially for the latter (mobile phones), it’s an area where most organizations do not pay sufficient attention to secure them, at least not the same level as their core infrastructure services.

I’m certain there are many more assessments that can be made using the above data but hopefully that gives you a starting point and a source of inspiration on how to get strategic value from tactical information such as 0day exploits discovered in the wild.

Written by xorl

October 19, 2021 at 16:26

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: