CVE-2021-44228: Impact of Log4j Zero-Day Vulnerability

December 10, 2021
Luke Richards
Threat Intelligence Lead
CVE-2021-44228: Impact of Log4j Zero-Day Vulnerability

Update: December 13, 2021  

Threat Actors Exploiting Log4j Zero-Day Vulnerability

As we’ve continued to monitor the situation, Vectra has observed multiple attempts from threat actors to exploit systems. To begin with, these were basic call backs with the initial exploit attempt coming from TOR nodes — these mostly pointed back to “bingsearchlib[.]com” with the exploit being passed into the User Agent or the URI of the request.

Since the initial wave of exploit attempts, there have been many changes in tactics by the threat actors using this vulnerability. Notably, there has been a shift in the commands being used, and the threat actors started obfuscating their requests. This originally included stuffing the User Agent or URI with a base64 string, which when decoded by the vulnerable system caused the host to download a malicious dropper from attacker infrastructure. Following this, the attackers started obfuscating the JDNI string itself, by taking advantage of other translation features of the JDNI process. Examples of this are:


All of these achieve the same objective, to download a malicious class file and drop it onto the target system, or to leak credentials of cloud-based systems.

Stay tuned to the Vectra Blog for further developments.


Original Post: December 10, 2021

Initial Discovery of Log4j Zero-Day Vulnerability

On 10th December 2021, a new 0day was discovered in the log4j application. This 0day, now tracked as CVE-2021-44228, takes advantage of the parsing of LDAP logs, and the parsing of the LDAP url in the jndi engine. This engine will automatically look up variables in logs to improve the output of the logs. For example “Logging from ${java:vm}” would output as "Logging from Oracle JVM”. This however, leads to a problem when parsing directory services using this method. When parsing these variables, if there is a dot “.” in the string, the log4j server will look up a remote address and parse the response with the jndi engine.

By using a tool such as, an attacker can craft a malicious payload, and direct the log4j server to this java payload, which will then be run in engine leading to the RCE. For more details, refer to the blogs and GitHub repositories in the references.

Log4j is a very widely used logging solution for Java-based applications, web apps, and modules. Applications from Steam, to Minecraft have been shown as vulnerable, but also multiple ToR nodes have also been attacked .

One of the biggest problems that users face with this vulnerability, is that the attack surface is incredibly large. As shown by the pictures in this GitHub repository.

It is worth noting as well, it is not only LDAP that is vulnerable, but other directory service parsers including Remote Method Invocation (RMI) and, Common Object Request Broker Architecture (CORBA).

The recommendation from the developers is to upgrade the log4j systems to log4j 2.15.0, available on Maven Central.

If you are using a log4j enabled system, you should refer to the developer for updates to their systems and assume that those hosts which run log4j are compromised.

Detecting Log4j Zero-Day Exploits (CVE-2021-44228)

One of the biggest problems with this vulnerability, is that the initial vector is difficult to detect. It presents as a string in a log, you could look at the raw input to the log4j server, and alert on all LDAP external connections. Alternatively, you could look for external connections from log servers to Java class files.  

If you have access to metadata, using tools such as the Vectra AI platform for example, one telltale sign of attempts to compromise servers would be to search for the following patterns in text fields such as User-Agent: /\$\{jndi:.*/

This will find attempts to compromise the servers but won’t confirm if there has been a compromise. The assumption is that at least one server in an estate will be compromised, and Vectra can confirm that scan attempts have been seen across multiple sources.

In order to find hosts that may have been compromised, it may be possible to look at hosts that are downloading JAVA, Jar or Class files. However, if a host has been compromised, the best way to detect that, is to observe a host and look for suspicious behavior, especially since the attack surface is huge and the initial vector is hard to detect given the pervasive use of log4j.

The Vectra AI platform highlights hosts with suspicious behavior by observing network traffic, and using machine learning and AI to classify the traffic. We would expect to see hosts which have been compromised to have Command and Control type detections, lateral movement detections, or local application or service accounts being used across the estate. If an edge device is compromised, there may also be more reconnaissance activity from those devices inside the DMZ.

It is also worth noting that those systems which run log4j may be deep within the network. For example, part of an Elastic cluster, and if that’s the case, those hosts will need to be identified as well.

To this end, it would be recommended to find those hosts on an estate which potentially run log4j (Apache Tomcat, Apache Struts, etc.) and move them into a group, or tag them, so it will be more convenient to monitor and follow up, given the above detection profile and search terms.


What is the Log4j zero-day vulnerability?

The Log4j zero-day vulnerability (CVE-2021-44228) allows attackers to execute arbitrary code through log messages.

What are the impacts of the Log4j zero-day vulnerability?

The impact includes potential data breaches, unauthorized access, and exploitation of vulnerable systems.

What are the recommended actions for organizations using Log4j?

Organizations should update to Log4j 2.15.0, monitor for suspicious activity, and follow best practices for security.

How are threat actors exploiting the Log4j vulnerability?

Threat actors use obfuscated JDNI strings and base64 encoding to exploit the Log4j vulnerability.

What industries are most affected by the Log4j vulnerability?

Industries using Java-based applications, such as gaming, cloud services, and enterprise software, are most affected.

How can organizations detect Log4j exploits?

Organizations can use AI-driven threat detection tools to identify unusual behaviors indicative of Log4j exploits.

How can AI help in defending against Log4j exploits?

AI helps by detecting anomalous behaviors, identifying hidden tunnels, and automating threat detection processes.

What is CVE-2021-44228?

CVE-2021-44228 is a critical vulnerability in Log4j that allows remote code execution via crafted log messages.

What tools can help detect Log4j exploits?

Tools like Vectra Cognito Detect use AI and machine learning to identify and respond to Log4j exploit attempts.

How can Vectra AI help with Log4j vulnerability management?

Vectra AI provides continuous threat detection, real-time analysis, and automated response to manage Log4j vulnerabilities.