It has been 31 days since the initial public disclosure of a critical remote code execution (RCE) vulnerability in the Apache Log4j logging library that upended enterprise security at the close of 2021. In that time, since the initial CVE-2021-44228 (critical), we’ve already seen five more related CVEs
- CVE-2021-45046 (critical)
- CVE-2021-4104 (high)
- CVE-2021-42550 (moderate)
- CVE-2021-45105 (moderate)
- CVE-2021-44832 (moderate))
and several updates to the library from 2.15.01 on December 9th to 2.17.1 on December 28th.
The importance of this class of vulnerabilities in such a ubiquitous library must not be forgotten with the next spin of the cyber news cycle: with millions of vulnerable devices, attacks are likely to continue for as long as such devices running unpatched software can be found by threat actors.
In this post, we round up all the activity to date concerning Log4Shell exploits to underscore the importance of timely discovery and patching of affected systems.
Log4j Initial Impact | Criminals and Researchers Equally Alert
As described in more detail here, there are two novel characteristics of a Log4j attack:
- The attacking string can be injected into any user input that will be logged such as an http header, a username, or a file name.
- The server the attacker communicates with and the server being attacked can be completely different and even located within different networks. In this case, internal logging servers located within trusted networks can suddenly communicate with attackers on the internet.
These characteristics provide a simple and potent tool and it took less than 24 hours after public disclosure of CVE-2021-44228 for attackers to generate over 60 permutations of the attack string.
Within hours of the public disclosure, we saw discussion and adoption of the issue within well-known underground Russian crime forums.
Researchers in the Chinese hacking community also claimed to have seen evidence of fast-automated exploitation tools Log4j_RCE_Tool, ReverseShell PoCs and an increasing number of articles on exploiting additional JNDI vulnerabilities in IBM WebLogic servers.
Meanwhile, researchers found that their Log4j honeypots were lighting up with alarming speed within 24 hours of the initial disclosure.
December 2021 | Log4Shell Attacks In the Wild
The first wave of attacks using the Log4Shell exploit were relatively unsophisticated actors dropping various cryptominers on victims. Perhaps most audacious of these was a reported 8-day long hack of HP AMD-based 9000 EYPC servers that was used to mine around 3.4 million Raptoreum coins, with an approximate value of $110,000. It is thought that the attackers were able to cash-out about half of the coins they mined before the operation was shut down.
Miner attacks were quickly followed with the appearance of a number of new ransomware families taking advantage of Log4j as a means of initial access, such as Khonsari ransomware. Attackers exploited Log4j to download and launch a malicious Java class file, which then retrieved the Khonsari ransomware payload from a C2.
Additional ransomware families soon followed, including TellYouThePass. This family had been relatively dormant prior to the Log4j vulnerability disclosure. TellYouThePass has both Windows and Linux variants, allowing it to attack the majority of servers likely to be vulnerable to Log4j exploitation.
Conti Attacks Log4j-Vulnerable Devices Not Exposed to the Public Internet
Within days of the flaw being disclosed, Conti ransomware campaigns were reportedly observed taking advantage of the vulnerability, with multiple campaigns focused on high-value vCenter environments. This development is noteworthy as the target machines were not necessarily exposed to the public internet. Rather, where the Conti operators had already gained an initial foothold into a target’s network, they exploited Log4j to compromise and encrypt vulnerable vCenter servers within the network.
Naturally, the Emotet crew has been taking advantage of Log4j as well. For example, vulnerable servers were quickly compromised and used for staging and payload hosting within the greater Emotet network. While we fully expect Emotet to embrace Log4j for direct delivery, we have yet to observe this development. However, we do currently see the use of Log4j to deliver Cobalt Strike Beacons, which can then be followed by any number of payloads.
In mid-December, Vietnamese crypto-exchange ONUS was attacked via exploitation of Log4j. The attack likely occurred within two to three days of the initial Log4j disclosure. The company patched their vulnerable servers sometime after the 13th of December, by which time the company had already been breached. The attackers later attempted to extort the company out of $5 million. For that amount, the attackers offered not to leak a cache of stolen data including PII. After the Fintech firm refused to pay, the attackers attempted to sell this data on a well-known hacking forum on December 25th:
Ransomware operators and extortionists are not the only ones getting in on the action. The actors behind Dridex have also expediently adopted the use of this exploit for their own nefarious purposes. In mid to late December, we saw mass distribution of Dridex by way of Log4j. In most cases, the exploit was used to load a malicious Java class, followed by a .HTA file containing a VBScript. From there we see more of a standard DLL-based flow.
January 2022 | Regulators and CISA Add Pressure to Remediate Log4j
On January 4th, the pressure for enterprises to ensure they have taken appropriate steps to remediate assets running vulnerable Log4j libraries was ramped up even further by the FTC.
Noting that Log4j “poses a severe risk to millions of consumer products” and that the vulnerability is being widely exploited by a growing set of threat actors, the FTC said on January 4 that it will
Meanwhile, on Jan 6, 2022 CISA noted that, based on submissions to the agency’s catalog, there are at least 2800 distinct products that contain Log4j. The agency estimates that despite the determined action by many admins and security teams during December 2021, there are likely still “hundreds of millions” of individual devices still affected by the Log4j vulnerabilities.
What Comes After Log4j?
Log4j could be just the the beginning of a whole new class of bugs. It turns out that the JNDI API is very attractive as a means of compromise as it allows simple unauthenticated remote code execution. A new JNDI-based “Log4j-like” critical vulnerability was disclosed on Jan 7, 2022. Tracked as CVE-2021-42392, this related RCE flaw was discovered in H2 database consoles, an open-source relational database management system written in Java. Although far from as widespread as the Log4j vulnerability, it is estimated to affect almost 7000 assets including popular frameworks like JHipster, Play framework and Spring Boot.
Conclusion
Unfortunately for overworked admins and security teams, a new year doesn’t mean an end to old problems, and exploitation of the Log4j and related JNDI vulnerabilities is going to be haunting many defenders for some time to come. Again, we urge all to stay ahead of the Log4j situation and ensure vulnerable software is patched to the latest version of Log4j or removed where that is not possible.
If there’s any silver lining to this dark cloud it is that in order for threat actors to capitalize on vulnerabilities, they need to engage in malicious behaviour, and that’s where on-device, AI-powered endpoint protection comes into its own. Whether its cryptominers or malware loaders, ransomware or banking trojans, deploying an autonomous detection and mitigation solution is an essential part of defending the modern organization from compromise.
If you would like to see how SentinelOne can help defend your organization, contact us or request a free demo.
