Overview
- We have discovered a new version of WatchBog—a cryptocurrency-mining botnet operational since late 2018—that we suspect has compromised more than 4,500 Linux machines in newer campaigns taking place since early June.
- Among the new Linux exploits, this version of WatchBog implements a BlueKeep RDP protocol vulnerability scanner module, which suggests that WatchBog is preparing a list of vulnerable systems to target in the future or to sell to third party vendors for profit.
- The malware is currently undetected by all security vendors.
- In this blog post we provide prevention and response recommendations for Windows and Linux users, in addition to a YARA signature for detecting this and future threats that share the same malicious code.
Introduction
WatchBog is a cryptocurrency-mining botnet that was spotted as early as November 2018. The group is known to be exploiting known vulnerabilities to compromise Linux servers. The group was documented in the past by the Alibaba Cloud Security department.
Since the last publication regarding this group, it has upgraded its implants by implementing a new spreading module in order to improve the coverage of vulnerable servers. We have detected a new version of WatchBog, which incorporates recently published exploits—among them being Jira’s CVE-2019-11581 (added 12 days after the release of the exploit), Exim’s CVE-2019-10149, and Solr’s CVE-2019-0192.
We also found that this spreader module incorporated a BlueKeep scanner.
BlueKeep, also known as CVE–2019-0708, is a Windows-based kernel vulnerability, which allows an attacker to gain RCE over a vulnerable system. The vulnerability is present in unpatched Windows versions ranging from Windows 2000 to Windows Server 2008 and Windows 7. There is no known public PoC available for achieving RCE with this vulnerability, and no attack has been spotted in the wild yet. The incorporation of this scanner module suggests that WatchBog is preparing a list of vulnerable systems for future developments with regards to BlueKeep.
The Jira, Solr and BlueKeep scanner modules were all added in the time frame of 13 days. WatchBog seems to be accelerating the incorporation of new functionalities as of late.
The spreader binary is currently undetected by security vendors:
After uploading this file to Intezer Analyze we can immediately see that it shares code with WatchBog, before even beginning to reverse engineer the file:
While investigating this new spreader module, we discovered a flaw with its design that allowed us to stage a ‘man-in-the-middle’ attack, to help us analyze the binary. We provide an analysis of this module in the technical analysis below.
Technical Analysis
The WatchBog threat actor group runs an initial deployment script when infecting a target. This script sets up persistence via crontab and downloads further Monero miner modules from Pastebin, as has been previously documented by Alibaba Cloud.
The interesting addition to this script is the following part in the end of the script:
As per the WatchBog’s script’s typical way of operating, the script downloads another base64-encoded payload from Pastebin, which further downloads another module and then executes it:
However, this is not another miner module. Rather, it is the new spreader module.
From a quick view this is a plain dynamically linked ELF executable. However, once we started analyzing the executable, we were surprised to see that this was actually a Cython-compiled executable requiring us to expand our analysis efforts.
Cython-compiled binary
As stated by this Medium article about Cython:
“Meet Cython, an optimizing static compiler that takes your .py modules and translates them to high-performant C files. Resulting C files can be compiled into native binary libraries with no effort. When the compilation is done there’s no way to reverse compiled libraries back to readable Python source code!”.
The compiled binary does, however, include some hints to the original Python module:
Initialization
Initially, the binary creates a file at /tmp/.gooobb in which it writes its pid as a footprint of the malware execution. Consequent attempts to launch the spreader will fail while this file exists.
The binary then retrieves its C2 servers from Pastebin:
An .onion C2 server address is also hardcoded in the binary and is used as a fallback.
We can estimate the number of victims infected based on the number of visits to the Pastebin links:
As seen above, we suspect around 4,500 endpoints were infected with the use of these specific Pastebin links. As WatchBog is known to have been active before June 5—which is the upload date of these Pastebins—we believe additional machines may have been infected with the use of older Pastebin links.
The binary first attempts to connect to one of the available static C2 servers.
We observed that the onion C2 server had an expired certificate.
Normally, HTTPS clients check the validation of the SSL certificate that they are interacting with. However, this was not the case with WatchBog’s implants. This led us to assume that the WatchBog client did not verify the certificate when using HTTPS, otherwise it would reject it and refuse to communicate with the C2.
This flaw allowed us to setup a transparent HTTPS proxy with our own certificate and stage a ‘man-in-the-middle’ attack to analyze WatchBog SSL/TLS traffic:
The binary then generates a unique key for the infected victim and sends an initial message to the C2 under this key. The following images include a sample request and response payloads from the SSL/TLS decrypted traffic:
These packets were encoded to obfuscate its content. During the analysis, we were able to determine the encoding algorithm used. The following script decodes the payload:
final = ""
arr = input()
for a in arr:
stri = "begin 666 \n{0}\n \nend\n".format(a) \
.decode("uu").strip('\x00') \
.decode("hex") \
.decode("base64")
final += chr(int(stri))
print(final[::-1])
The initial message contains the compromised system information:
This information will be merged and hashed to build the route of WatchBog’s API hosted in its CNCs. The server replies with a “task” for the bot to perform on a list of targets:
BlueKeep Scanner
In this newer version of WatchBog it seems that the group has integrated an RDP scanner in order to find vulnerable Windows machines to the BlueKeep vulnerability. This scanner is a Python port from zerosum0x0’s scanner hosted in Github. We can make this assessment based on function name similarities:
The scanner will then attempt to find vulnerable RDP servers from the IP list provided by the CNC:
WatchBog scanning RDP ports
The default Windows service port for RDP is TCP 3389, and can easily be identified in the packets with “Cookie: mstshash=”.
We can observe the use of the string ‘watchbog’ as the username of the RDP mstshash field.
Among some of the IP lists we found being supplied for RDP scanning, we spotted that some of the IP addresses belonged to Vodafone Australia and Tencent Computer Systems infrastructure.
After the scanning stage, the WatchBog client returns an RC4 encrypted list of vulnerable IP addresses encoded as a hexadecimal string:
Encrypted scanned IP addresses
The threat actors behind WatchBog may be gathering a list of vulnerable BlueKeep Windows endpoints for future use, or perhaps to sell to a third party to make a profit.
Spreading
The WatchBog client includes five exploits for the following CVEs:
- CVE-2019-11581 (Jira)
- CVE-2019-10149 (Exim)
- CVE-2019-0192 (Solr)
- CVE-2018-1000861 (Jenkins)
- CVE-2019-7238 (Nexus Repository Manager 3)
Available “pwn” modules
Furthermore, two modules for bruteforcing CouchDB and Redis instances exist together along with code to achieve RCE.
All of the exploited “pwn” modules allow an attacker to achieve remote code execution.
Once a vulnerable service is discovered to which exists an exploit module, the binary spreads itself by invoking the right exploit and installing a malicious bash script hosted on Pastebin.
We were able to find an early test version of the spreader module uploaded to HybridAnalysis, including an exploit to Solr CVE-2019-0192, an exploit to ActiveMQ CVE-2016-3088, and a module utilizing a technique to gain code execution over cracked Redis instances:
Solr exploit as it appears in the test version
Conclusion
We presented our findings regarding the high pace of adaptation that WatchBog is maintaining by integrating recently published exploits and updating its implants with more up-to-date offensive technologies.
It is important to highlight that Python malware can become harder to analyze if it is deployed natively with engines such as Cython. That is in contrast to other Python native frameworks such as pyinstaller, where Python code can not be recovered.
The incorporation of the BlueKeep scanner by a Linux botnet may indicate WatchBog is beginning to explore financial opportunities on a different platform. Currently, no known public RCE BlueKeep PoCs exist and it will be interesting to monitor this group once a PoC is published.
Prevention and Response
- We recommend to update your relevant software to its latest version:
- We suggest Windows users refer to Microsoft’s customer guidance in order to mitigate the BlueKeep vulnerability.
- We suggest Linux users, who use Exim, Jira, Solr, Jenkins or Nexus Repository Manager 3, to update to the latest versions.
- We suggest Linux users, who use Redis or CouchDB, to ensure that there are no open ports that are exposed outside of trusted networks.
- We recommend Linux users who suspect that they are infected with WatchBog to check for the existence of the “/tmp/.tmplassstgggzzzqpppppp12233333” file or the “/tmp/.gooobb” file.
- We have also created a custom YARA rule based on WatchBog’s malicious code for detecting this threat.
Genetic Analysis
WatchBog is indexed in Intezer’s genetic database. If you have a suspicious file that you suspect to be WatchBog, you can upload it to Intezer Analyze in order to detect code reuse to this malware family. You are welcome to try it in our free community edition.
IOCs
b17829d758e8689143456240ebd79b420f963722707246f5dc9b085a411f7b5e
26ebeac4492616baf977903bb8deb7803bd5a22d8a005f02398c188b0375dfa4
cdf11a1fa7e551fe6be1f170ba9dedee80401396adf7e39ccde5df635c1117a9
https://9d842cb6.ngrok[.]io
https://7dc5fb4e.ngrok[.]io
https://z5r6anrjbcasuikp.onion[.]to
https://pastebin[.]com/raw/Dj3JTtnj
https://pastebin[.]com/raw/p3mGdbpq
https://pastebin[.]com/raw/UeynzXEr
https://pastebin[.]com/raw/MMCFQMH9
3.14.212[.]173
3.14.202[.]129
3.17.202[.]129
3.19.3[.]150
18.188.14[.]65
The post Watching the WatchBog: New BlueKeep Scanner and Linux Exploits appeared first on Intezer.
