How the exploit works

1. Victim app logs attacker-supplied input from an HTTP header.
2. Attacker LDAP server responds with a reference to Exploit.class.
3. Victim fetches Exploit.class via HTTP.
4. Static initializer in Exploit runs, spawning a reverse shell back to the attacker.

2. Risk

• Impact: Unauthenticated RCE - highest possible severity.

• Who/what is at risk:

  • Any Java application using Log4j <= 2.14.1.
  • Internet-facing and internal services that log user-controlled input (e.g., HTTP headers).

• Consequences:

  • System compromise (shell access).
  • Data exfiltration.
  • Pivoting into internal networks.
  • Evasion of perimeter defenses (attacks via internal services).

3. Proof of Concept

Prerequisites

1. docker + docker-compose
2. netcat
3. make

Build and start

Exploit

1. Start a netcat listener:

2. Trigger exploit:

3. Netcat receives a reverse shell from the victim:

4. Remediation

Preferred fix

• Upgrade to Log4j 2.17.1 or later.
• This is the only complete and long-term fix. Earlier versions patched partially but still left exposures:
  • CVE-2021-45046: RCE via non-default logging configuration
  • CVE-2021-45105: DoS via self-referential lookups
  • CVE-2021-44832: RCE via certain JDBC appender configurations

Interim mitigations (if upgrade not possible)

1. Buy time

• Restrict inbound exploit strings (${jndi: patterns) with a WAF or middleware.
• Restrict outbound LDAP from application servers with egress filtering.

2. Disable lookups:

3. Harden JVM:

Operational mitigations

1. Audit dependencies and runtime

• Generate an SBOM (gradle dependencies, Snyk, Wiz, etc.).
• Search deployed images/servers for log4j-core-*.jar, including fat JARs.
• Triage and prioritize mitigations for the riskiest workloads.

2. Monitor & detect

• Watch for exploit attempts in logs (${jndi:...}, ${${lower:j}ndi:...}, etc.).
• Monitor outbound LDAP traffic for callbacks.
• Treat findings as potential compromises, escalate for incident response (forensic investigation, removal of malicious artifacts, rotation of secrets, etc.).

3. Vendor patches

• Track vendor advisories (e.g., Elasticsearch) - many ship bundled Log4j.
• Apply hotfixes or workarounds provided until official patches are available.

4. Strategic Improvements

• Enforce "deny by default" policy for outbound traffic filtering.
• Enforce dependency scanning in CI/CD.
• Formalize response playbooks so teams know exactly what to do during the next "10.0 CVSS" vulnerability.
• Run resilience drills/tabletops to test readiness for a "new Log4Shell-class" incident.

5. References

• Apache Security Advisories