The first public case of the Log4j Log4Shell vulnerability used to download and install ransomware has been discovered by researchers.

Last Friday, a public exploit was released for a critical zero-day vulnerability named ‘Log4Shell’ in the Apache Log4j Java-based logging platform. Log4j is a development framework that allows developers to add error and event logging into their Java applications.

The vulnerability allows threat actors to create special JNDI strings that, when read by Log4j, cause the platform to connect to and execute code at the included URL. This allows attackers to easily detect vulnerable devices or execute code supplied by a remote site or via Base64 encoded strings.

While this vulnerability was fixed in Log4j 2.15.0 and even tightened further in Log4j 2.16.0, it is being widely exploited by threat actors to install various malware, including coin miners, botnets, and even Cobalt Strike beacons.

First Log4j exploit installing ransomware

Yesterday, BitDefender reported that they found the first ransomware family being installed directly via Log4Shell exploits.

The exploit downloads a Java class from hxxp://3.145.115[.]94/Main.class that is loaded and executed by the Log4j application.

Once loaded, it would download a .NET binary from the same server to install new ransomware [VirusTotal] named ‘Khonsari.’

This same name is also used as a the extension for encrypted files and in the ransom note, as shown below.

Khonsari ransom note
Khonsari ransom note

In later attacks, BitDefender noticed that this threat actor used the same server to distribute the Orcus Remote Access Trojan.

Likely a wiper

Ransomware expert Michael Gillespie told BleepingComputer that Khonsari uses valid encryption and is secure, meaning that it is not possible to recover files for free.

However, the ransom note has one oddity – it does not appear to include a way to contact the threat actor to pay a ransom.

Emsisoft analyst Brett Callow pointed out to BleepingComputer that the ransomware is named after and uses contact information for a Louisiana antique shop owner rather than the threat actor.

Therefore, it is unclear if that person is the actual victim of the ransomware attack or listed as a decoy.

Regardless of the reason, as it does not contain legitimate contact information for the threat actors, we believe this is a wiper rather than ransomware.

While this may be the first known instance of the Log4j exploit directly installing ransomware (wiper?), Microsoft has already seen the exploits used to deploy Cobalt Strike beacons.

Therefore, it is likely that more advanced ransomware operations are already using the exploits as part of their attacks.