Log4j Exploit Attempts Continue 1 Year Later

Log4j Exploit Attempts Continue 1 Year Later

Log4j is one of the most popular logging libraries and is used to create log files that track events and activities within a system or application. Log4j can be used to capture large volumes of data from both local and remote applications with minimal overhead costs and high performance. However, in December 2021, security researchers discovered a Log4j zero-day vulnerability that potentially compromised millions of devices.

In response to this disclosure, Apache released multiple software updates while security teams took additional measures to protect their networks. However, as expected, malicious actors are still attempting to exploit Log4j. To provide better visibility into these ongoing attempts, we have leveraged anonymized telemetry from our customers who have opted into information sharing. This allows us to gain insights into Log4j attempts specifically targeting OT/IoT environments.

In this blog, we recap Log4Shell, provide technical insights from our Labs, and reemphasize recommendations and best practices for keeping networks protected.

Log4Shell Recap

The Log4j vulnerability (CVE-2021-44228), dubbed “Log4Shell” and marked with a 10 out of 10 Common Vulnerability Scoring System (CVSS) score, is highly exploitable and can result in malicious actors remotely executing code on vulnerable servers. A few days after the initial disclosure, another Log4j vulnerability, CVE-2021-45105, was released which can allow a threat actor to launch a Denial of Service (DoS) attack.

Log4j utilizes a feature known as lookups. There are multiple lookups that can be used, however the two taken advantage of by Log4Shell are:

  1. Java Naming and Directory Interface (JNDI) lookup allows users to access resources stored remotely through a network connection. This allows for easy lookup of information needed to establish a connection.
  2. Environment lookup gives users access to environment variables located on the machine from which Log4Shell is being used. This means that any user-defined environment variables accessible from the machine being used can be accessed through Log4Shell.

In this case, the Log4j utility had message lookup substitution enabled by default. This allowed threat actors to embed malicious code within a request, allowing Log4j to automatically execute without any user intervention.

For a comprehensive overview of CVE-2021-44228, read our technical analysis of Log4shell here.

Insights from Nozomi Networks Labs

Immediately following the disclosure of Log4Shell, our security researchers developed packet rules to identify potential Log4shell activity in our customers’ environments. By leveraging anonymized telemetry from participating customers, we’ve gained valuable insights into the prevalence of Log4j exploit attempts.

Between May 16th and November 16th, 2022, we recorded over 60,000 first and second stage attempts in at least 14 of our customer environments. The following is a breakdown of attempted exploits utilizing the following protocols:

Location of first and second payload attempts
Figure 1. Protocols utilized in first and second payload attempts.
Figure 2. Location of first and second payload attempts.

Based on our telemetry, there have been 40,000 attempts to exploit the JDNI lookup in vulnerable servers using TCP. Threat actors prefer to use TCP over UDP and HTTP because it allows them to establish a reliable connection with the target system, which makes it easier to exploit known security vulnerabilities. TCP also provides security for data that is being transferred via encryption and authentication, allowing threat actors to transfer data without being intercepted.

Although there have been attempts to query LDAPS, RMI, and DNS, threat actors attempted to query LDAP about 40,000 times. LDAP is a standardized protocol that can be used on almost any operating system as well as a variety of programming languages, making it relatively easy for threat actors to build applications or scripts around the protocol.


A year since the disclosure of Log4j, threat actors remain persistent in exploiting the vulnerability in hopes of compromising an unpatched system. This is why it is important to ensure that Log4j is updated to the latest version to protect your organization from CVE-2021-44228, CVE-2021-45105, and other vulnerabilities.

For additional mitigations recommended by CISA, such as asset inventory of vulnerable assets, network scanning, and threat hunting, click here.

You can also find detailed information on how Nozomi Networks protect our customers from Log4shell here.