Threat Spotlight: Attacks on Log4Shell vulnerabilities

The Log4Shell complex of vulnerabilities in the Log4J software have now been publicly known for more than two months. Barracuda researchers analyzed the attacks and payloads detected by our systems since December 10, 2021, and they found that the volume of attacks attempting to exploit these vulnerabilities has remained relatively constant with a few dips and spikes over the past two months. Given the popularity of the software, the exploitability of the vulnerability and the payoff when a compromise happens, we expect to see this attack pattern continue, at least for the short-term.

While the volume of attacks on these vulnerabilities remains steady, our researcher uncovered some interesting insights into where the attacks originated. The majority of attacks came from IP addresses in the U.S., with half of those IP addresses being associated with AWS, Azure and other data centers. Attacks were also being sent from Japan, Germany, Netherlands, and Russia. Note that these are the IPs that performed scans and attempted intrusions. The actual payloads would have been delivered from other compromised websites or VPS hosts should the attack have gotten through. These IPs bearing the payloads are typically obfuscated using the Base64 encoding described in the examples below.

Highlighted Threat

Log4Shell vulnerabilities — Log4j is a Java-based logging audit framework which is an Apache project. Apache Log4j <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI-related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. The vulnerability impacts default configurations of several Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink, which are utilized by numerous organizations from Apple, Amazon, Cloudflare, Twitter, Steam, and others.

The vulnerability is triggered by sending a specific string to the Log4j software which means it is simple to exploit, and the broad utilization of this software means there are multiple attack vectors.

The Details

Let’s look at a few examples of the payloads that we’ve seen attempting to exploit these vulnerabilities over the past couple of months.

For the first one, let’s look at a relatively benign (or depending on your viewpoint, very annoying) payload:



After some research, we found this Java payload:

As expected, the YouTube video in this payload plays Rick Astley’s “Never Gonna Give You Up.” I do wonder if anyone was actually Rick-Rolled by this one. It is, as noted earlier, a benign payload in my opinion, but one that will get you patching very quickly!

Cryptomining payloads

The second example is something we saw a great deal of in the early days after the vulnerabilities first came to light — a Monero miner payload. It showed up from multiple different IPs, typically with the commands obfuscated in base64:

Decoding the base64 string gave us:

The actual payload on this URL was this script that setup the miner:

Targeting VMware installations

As time progressed, we saw reports that the Conti ransomware group was looking to compromise VMware installations using the Log4Shell vulnerabilities. Now, to our knowledge, these are mostly lateral movements from within a network. We didn’t see many examples of ransomware attacks against VMware installations and expect that this would be more an insider threat. However, while spelunking through our logs, we did see some other attempts to infect these installations. For example:

Decoding this gave us:

The payload has been taken down since we first saw the traffic; however, URLhaus identifies it as being a type of the Mirai DDoS botnet malware. Another version of this malicious download is still active and being sprayed similarly at VMware installations.

DDoS malware

For our last example, we’ll look at another type of DDoS malware:

Decoding this gives us:

This one is a variant of the BillGates malware. Originating around 2016, this malware originally targeted only Linux systems. This particular example has been offline for some time now.

Aside from these payloads, we also saw many other attempts — a lot of Kinsing, XMRig, and variants of the Mirai and Mushtik were in the logs, based on analysis of the base64-encoded commands embedded within the JNDI connection strings and assuming the LDAP servers being connected to were returning malicious class payloads that implement these base64-encoded commands. The most common of the payloads was Mirai in various forms and from varied sources. The prevalence of DDoS botnet malware seems to suggest that threat actors are working toward building out a large botnet for future use, and there should be an expectation of large DDoS attacks in the near future.

How to protect against these types of payloads

The best way to protect against log4shell specifically is to upgrade to the latest version of log4j. Maintaining up-to-date software and libraries helps ensure that vulnerabilities are patched in a timely manner.

Due to the growing number of vulnerabilities found in web applications, it is getting progressively more complex to protect against attacks. However, all-in-one solutions are now available to protect your web applications from being exploited because of these vulnerabilities. WAF/WAF-as-a-Service solutions, also known as Web Application and API Protection (WAAP) services, can help protect your web applications by providing all the latest security solutions in one easy-to-use product.

Report: The state of application security in 2021