LAST UPDATED Dec 21, 2021
We’re about a week and a half into the release of the Log4j2 vulnerability, and to date we’ve seen both a lot of related malicious activity, and a lot of changes in exploits. In terms of activity level, we were actually surprised at how fast we saw an uptick in attacks related to this vulnerability. Within days, we saw thousands of attempted attacks. We’re also seeing exploits morphing and evolving quickly. We outline what we have seen thus far below, and we’ll publish more details as we collect them.
The exploit activity thus far
Specifically, to date, ThreatX has blocked about 50,000 events stemming from the Log4j2 vulnerability. At this early stage, we’re seeing this vulnerability being primarily used for crypto mining with botnets. We’re also starting to see some profiling, or some indication that the attackers are probing systems to figure out what’s there, what they can access. What this means to us is that, for now, the attackers are going for the low-hanging fruit, which is fast cash. This vulnerability exposes thousands and thousands of servers, which means attackers can almost certainly generate some crypto with that kind of access. But, at the same time, these attackers, and others we haven’t seen yet, are most likely working on different, more targeted attacks. We don’t know anything for sure yet, but the potential for data exfiltration, ransomware, and other types of malware are there, so I tell organizations to assume there are low and slow attacks in the works.
Attacks changing fast
We’ve already seen exploits related to this vulnerability changing and evolving. As information about CVE-2021-44228 started coming out, leveraging the Java naming and directory interface [JNDI] that was vulnerable to Remote Code Execution [RCE], organizations started profiling their applications and identifying what was vulnerable. As that progressed, security researchers started sharing more crafty and clever payloads – leveraging the Java library functions like “lower,” “upper,” and concatenating strings. Now, attackers are mixing these functions with encoding such as URL or Base64, which make the attacks harder to detect. Just in the past week or so, researchers have discovered a new attack vector that may allow an attacker to trigger the Log4j vulnerability within localhosts.
This is definitely not over; we’ve got to be proactive about keeping up with these attacks. See our recent 20-minute webcast for more details on our experience with the Log4j2 vulnerability. We’ll keep sharing information as we uncover it; please reach out if you have questions or need more information.
