Log4Shell: From Pre-Disclosure Probing to Mass Evasion
Analysis of attempted exploitation of CVE-2021-44228 — the Log4j vulnerability widely known as Log4Shell — reveals attackers were probing the flaw eight days before it was publicly disclosed. The first attempt to actively exploit the vulnerability came just nine minutes after disclosure. Since then, the threat landscape has shifted dramatically from simple scanning to sophisticated WAF evasion and aggressive data exfiltration campaigns.
From Simple Probes to Complex Obfuscation
Initial attack strings were straightforward and easy to identify, typically beginning with ${jndi:dns, ${jndi:rmi, and ${jndi:ldap. Basic pattern-matching rules caught these early attempts. However, attackers quickly adapted once these simple signatures were blocked, employing both standard evasion techniques and exploits specific to the Log4j Lookups language itself.
Generic evasion methods — such as encoding ${ as %24%7B or \u0024\u007b — are easily reversed by capable web application firewalls before rule matching is applied. The Log4j lookup language, however, provides far more versatile obfuscation options. For instance, the ${lower} lookup converts strings to lowercase: ${lower:H} becomes simply h. Attackers use this to disguise critical terms like jndi, making simple keyword blocking ineffective.
In live traffic, we observe attackers leveraging several specialized lookups for evasion:
${date}${lower}and${upper}${web}${main}${env}
These same lookups — especially ${env}, ${sys}, and ${main} — are also the primary vectors for data exfiltration, pulling environment variables, system details, and credentials from the target process. Docker, Kubernetes, and other platform-specific lookups expand the exfiltration surface further.
The Log4j language supports nested ${} expressions, enabling attackers to combine multiple keywords into complex evasion payloads. A single word like hide can be encoded as ${lower:${lower:h}}${lower:${upper:i}}${lower:D}e, rendering the letters of jndi invisible to naive string searches.
Another common evasion relies on the :- syntax, which outputs a specified default value when a lookup returns empty. Attackers reference non-existent environment variables to output arbitrary letters — for example, strings like ${::-h} or ${::::::-h} both resolve to the character h. Combinations of these techniques are increasingly common.
Given the breadth of evasion now in use, any occurrence of ${ in incoming data should be treated as suspicious. To assist customers, logged output can be sanitized by converting ${ to x{ before transmission.
Attack Evolution and Trend Data
During the first few days following disclosure, overt strings like ${jndi: dominated attack traffic. Since then, evasion has grown substantially, with the ${lower} lookup and URI encoding increasingly used to bypass blocking rules. A particularly popular evasion pattern observed is ${${::-j}${::-n}${::-d}${::-i}.
The exploitation phase has also matured. What began as reconnaissance has evolved into systematic data extraction. Blocked attack attempts seen in the wild include payloads attempting to retrieve user names, home directory paths, Docker image identifiers, Kubernetes and Spring configuration details, user and database passwords, hostnames, and command-line arguments through combinations of Log4j lookups.
Pre-Disclosure Activity
CVE-2021-44228 was publicly disclosed via a since-deleted tweet on 2021-12-09 at 14:25 UTC. Our systems logged three instances of attempted exploitation or scanning on December 1, 2021 — over a week before that disclosure. All three involved ${jndi:ldap} lookups injected into HTTP headers or URI parameters: one in the User-Agent header, one in the Referer header, and one in URI parameters.
After those three early probes, activity ceased until the first exploit attempt nine minutes after public disclosure, when a ${jndi:ldap} payload was injected via a URI parameter on a gaming website.
Mitigation Remains Critical
While WAF rules — deployed for paying and free customers alike — provide an effective external defense, they are not foolproof. Attackers are actively refining evasion techniques, and the exfiltration potential for credentials and sensitive system data remains significant. The long-term threat of follow-on attacks from extracted information is real.
Although blocking at the edge helps, the vulnerability can be triggered through server-to-server logging and other non-Internet channels. Patch all systems using affected Log4j versions immediately; do not wait, and do not rely on edge protections alone.



