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

We're an RSA Conference 2024 Innovation Sandbox Finalist!

What happened with the Log4j library?

Security teams all over the world are rushing to deal with the new critical zero-day vulnerability called Log4Shell. This vulnerability in Apache Log4j, a popular open-source Java logging library, has the potential to enable threat actors to compromise systems at scale.

What do you need to know?

  • The Log4Shell vulnerability is rather easy to exploit
  • Threat actors are actively compromising systems as we speak
  • There is a patch available and also a myriad of quick fixes and remediations
  • Organizations should identify assets that use the Log4j library and patch them immediately

What is the scope of the incident?

Log4j is one of the most popular Java logging libraries, used by a vast number of applications. Threat actors attempted to use this exploit on more than 31.5% of corporate networks globally, according to Check Point Software.

Large companies and enterprises, such as Amazon, Apple, Twitter, CloudFlare, Steam, and Baidu have servers vulnerable to this attack, according to a GitHub repository. Additionally, more than 200 global companies and manufacturers have already published security advisories and bulletins according to this list.

Leveraging this critical vulnerability, attackers can anonymously exploit remote systems. The scope, impact, and scale are incomparable to anything the security industry has seen in the past few years.

What are the technical details?

CVE-2021-44228 (aka Log4Shell) is a Remote Code Execution (RCE) vulnerability in Apache Log4j, a ubiquitous library used for logging by many Java-based applications. Versions 2.0-beta9 to 2.14.1 are affected by this vulnerability.

By exploiting it, an attacker can execute malicious code on a server that runs a vulnerable version of Log4j. The steps are simple:

The steps to exploit the vulnerability in Log4j are simple

What is the incident timeline?

Log4j Incident Timeline

The bad news

Offensive teams were quick to develop exploits to this vulnerability and use them at scale.

However, security and DevOps teams are struggling to discover, orchestrate, patch, remediate, manage, prioritize, monitor, detect, and respond.

Unfortunately, the abundance of content, security advisories, detection rules and blog posts only makes it harder to keep up with the pace, prioritize effectively, and make informed decisions.

The good news

We at Mitiga curated a list of resources to help you with your efforts: Detections, remediations, IoCs, notable blog posts, and more.

We will constantly update this blog post and the attached list and help you focus on the important things.

And finally: the list of everything

Following is a link to our Github page:


Contributors: Eitan Freda, Adi Belinkov, Nir Ben Eliezer

Learn how cloud incident response is different from traditional IR (and why it matters)


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.