We're proud to be named a 2024 Publisher's Choice winner!

We're an RSA Conference 2024 Innovation Sandbox Finalist!

A zero-day vulnerability is often considered a vulnerability in software or a service that may have been disclosed but has not been patched yet, while an exploit that attacks a zero-day vulnerability is called a zero-day exploit. Because they were announced before security researchers and software developers have a patch available, zero-day vulnerabilities pose a critical risk for the following reasons:

  • Cybercriminals race to exploit these vulnerabilities to cash in on their schemes
  • Vulnerable systems are exposed until a patch is issued by the vendor and the patch is applied

The recent rush to patch vulnerabilities in Log4j is an excellent illustration of how most organizations think about and address critical vulnerabilities — but patching alone is neither a guarantee nor an indicator that your environment has not been impacted by Log4Shell or another critical vulnerability.

The lifecycle of a vulnerability

Just as software development has a lifecycle, so do vulnerabilities. While the goal is to build and release high quality software that offers robust functionality, performs well, is secure, and delivers a good user experience, inevitably vulnerabilities are introduced into a codebase. It’s not intentional; it occurs when a change in code or a new product release results in a vulnerability. In the timeline below, that’s V(c) – the day the vulnerability is “created.” From this time on, the vulnerability exists. At some point, attackers find the vulnerability and begin to exploit it. That may be before or after it is found by the defenders, security researchers, and ethical hackers. Discovery may occur due to a security review, research, or through investigation of an attack that has already happened or is in progress.

Defenders typically follow vulnerability disclosure guidelines when they find a vulnerability. Vulnerability disclosure is the practice of reporting security flaws in software or hardware, disclosing them directly to the group or organization responsible for the vulnerable software or service. These stakeholders may prefer that the vulnerability is only disclosed publicly V(d) after patches are available.

The vulnerability timeline

Usually, vulnerabilities are called zero-day vulnerabilities during T1, the time between disclosure and when it is patched, V(p). Once that T1 period is over and we move into T4, a vulnerability is called a 1-day or n-days vulnerability.

The highest risk may be before disclosure

Thinking about the risk introduced by the vulnerability starting from the date of disclosure is the wrong approach, however. We need to think of zero-day for vulnerabilities during T3! T3 is a high-risk period, because there is an existing vulnerability in the system, and until it is found, disclosed, and patched, malicious actors can find it and use it for their own purposes.

During this period, it is exceedingly difficult to prevent and detect an intrusion due to the vulnerability in the codebase because no one knows what they should be looking for (or even that they should be looking). It’s important to be aware that attackers don’t wait for a vulnerability notification to try to get into your system. The vulnerability in the code existed long before the patch, so you may have had that door open for a year or more. Attackers may have already compromised your environment — you just don’t know about it yet.

There are many ways malicious actors may exploit a zero-day vulnerability: by creating backdoors that will allow them to exfiltrate data, execute a ransomware attack, or otherwise compromise your systems. In this scenario, attackers have the advantage of awareness of undisclosed vulnerabilities and the time to exploit them when they are unlikely to be detected.

A proactive approach to zero-day vulnerabilities

The challenge, therefore, is for organizations to find attackers dwelling in their environments. The best way to do that is through hunts – a proactive approach that assumes your organization is already breached by one or more zero-day vulnerabilities and search for indicators of compromise (IOCs). IOCs are pieces of forensic data that identify potentially malicious activity on a system or network.

Proactive threat hunting is driven by a hypothetical analysis of the tactics, techniques, and procedures (TTPs) of known adversaries and focused on an area likely to be compromised. Proactive hunts can also correlate the hypothesis with the attackers’ point of view.

Incident response teams do research and build up background knowledge based on their experience and use that to build patterns of attack and then hunt based on those patterns.

Technology and automation can help with this, by automatically searching for threats that are:

  1. Based on known vulnerabilities
  1. Based on the forensic footprints of one or more specific vulnerabilities
  1. Correlated with threat intelligence

The human factor is an essential element of proactive threat hunting because it relies on the hunters to define which scenarios and hypotheses to hunt for. Tackling these different scenarios by creating detailed playbooks helps you to run, re-run, and refine your hunts to maximize your effectiveness in finding unknown compromises.

For this process to be optimal, hunts should be run periodically and examine different hypotheses. It is also important to run the same hunts repeatedly to validate the results over time, because both the threat landscape and the organization’s environment are dynamic and change over time.

Patching is still important

While proactive threat hunting is important, it does not take the place of patching known vulnerabilities, just as patching doesn’t take the place of proactive hunts. For example, when the Apache Software Foundation released Log4j 2.15.0 for Java 8 users to address the remote code execution (RCE) vulnerability CVE-2021-44228, cybercriminals rushed to exploit the vulnerability Log4Shell. While the patching process is complex for Log4Shell for a variety of reasons, remember that attackers will continue to exploit the vulnerability until it’s no longer an option.

Zero-day vulnerabilities are typically involved in targeted attacks; however, many campaigns still use old vulnerabilities — because it works. Many attackers simply scan for known vulnerabilities and exploit them. Attackers need just one way in, so blocking any loopholes that you are aware of is essential to helping keep your organization secure. It’s also important to remember that patching does not evict existing attackers from your environment. You can only do so much to prevent an attack or close security holes, so you need to focus on detection and response to discover backdoors and indicators of compromise. Adopting a readiness mindset — not only when there’s a critical zero-day vulnerability disclosed, but on an ongoing basis — will help you increase your resilience before an incident and reduce the severity of impact if a cybercriminal exploits an unknown vulnerability to attack your organization.

9 fundamental ways cloud IR is different from traditional incident response

Read more about this topic in Security Magazine.


May 4, 2024

Don't miss these stories:

Mitiga Wins Global InfoSec Award for Cloud Threat Detection Investigation & Response (TDIR)

We’re proud to report that at the open of today’s RSAC24, Mitiga was awarded the Publisher's Choice Cloud Threat Detection Investigation & Response (TDIR) from Cyber Defense Magazine (CDM), the industry’s leading electronic information security magazine.

Here's Why Traditional Incident Response Doesn’t Work in the Cloud

Traditional incident response (IR) learned from on-premises investigations doesn’t work in the cloud. Today's threat actors are finding misconfigurations and vulnerabilities to allow them to penetrate cloud environments.

Why Did AWS Replace My Role’s ARN with a Unique ID in My Policy?

After several years of working with AWS, IAM remains one of the most frequently used services in my daily routine. Yet, despite my familiarity with it, a recent production incident taught me that there’s always more to learn.