Watching the WatchBog: New BlueKeep Scanner and Linux Exploits

Written by and

    Share article
    FacebookTwitterLinkedInRedditCopy Link

    Top Blogs

    • 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.

    Intro to WatchBog Cryptomining Malware

    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 CVE2019-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:

    Intezer Analyze analysis of watchbog

    Intezer Analyze analysis

    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 of WatchBog

    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:

    Technical Analysis

    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.

    ELF executable

    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:

    optimizing static compiler


    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:

    footprint of the malware execution

    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:

    .onion C2
    .onion C2
    .onion C2

    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:

    HTTPS proxy

    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:

    C2 under this key

    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") \
    	final += chr(int(stri))

    The initial message contains the compromised system information:

    pasted image 0 38

    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:

    WatchBog’s API hosted

    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:

    pasted image 0 41

    The scanner will then attempt to find vulnerable RDP servers from the IP list provided by the CNC:

    WatchBog scanning RDP ports

    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=”.

    pasted image 0 39

    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:

    pasted image 0 54

    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.


    The WatchBog client includes five exploits for the following CVEs:

    pasted image 0 49

    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:

    pasted image 0 53
    Solr exploit as it appears in the test version.


    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.

    analysis of watchbog



    Paul Litvak

    Paul is a malware analyst and reverse engineer at Intezer. He previously served as a developer in the Israel Defense Force (IDF) Intelligence Corps for three years.

    Ignacio Sanmillan

    Nacho is a security researcher specializing in reverse engineering and malware analysis. Nacho plays a key role in Intezer\'s malware hunting and investigation operations, analyzing and documenting new undetected threats. Some of his latest research involves detecting new Linux malware and finding links between different threat actors. Nacho is an adept ELF researcher, having written numerous papers and conducting projects implementing state-of-the-art obfuscation and anti-analysis techniques in the ELF file format.

    Generic filters
    Exact matches only
    Search in title
    Search in content
    Search in excerpt