Threat Stack’s Security Operations Center (SOC) recently discovered an ongoing and evolving cryptojacking campaign that leverages a new variant of the Shellbot malware, originally discovered by JASK in November 2018 and published in February 2019. In this new variant of the Shellbot campaign, Threat Stack has identified the addition of a new SSH brute force tool, a secondary command and control method, and the added ability to stop other cryptominers on infected servers.
A shell script named
tddwrt7s.sh is downloaded to /dev/shm or /tmp. The shell script is then executed with seven different URLs containing the same file (
dota.tar.gz) as arguments which contain the malware payload. The script chooses one of the URLs randomly, and then downloads the payload which is then uncompressed and executed.
This campaign uses a series of scripts and executables to install and persist on a target system. The first shell script (either
init2) removes old installations of the malware and then runs the script init. This both installs the malware components and makes them persistent on the system by stepping through a series of subfolders (a,b,c) and overwriting crontab.
One of the more interesting parts of this malware campaign is that it checks to see whether there are other cryptominers on the system and stops them if there are. This would normally be considered a good thing if it didn’t turn around and install its own cryptominer on the system. This is accomplished by a 272-line shell script named
The cryptominer is initialized through two shell scripts named
run. The shell script
a creates a new shell script named
upd and executes, which then executes
run. The script
run then runs either the 32-bit or 64-bit version of the cryptominer named
cron respectively. There is also a script named
stop which acts as a kill switch. The cryptominer makes connections to two MoneroHash IPs (188.8.131.52 and 184.108.40.206) and starts mining.
The initialization of the Command and Control component is accomplished through shell scripts also named
run. The script
a creates the script named
sync which executes
run. The scripts execute a packed perl script named
rsync and an executable named
ps. The perl script
rsync allows Command and Control via IRC, and
ps allows for SSH connections from malicious infrastructure and also locks users out of the system. There is also a kill switch script named
The Command and Control component consists of the files
ps. The file
rsync is a packed perl script which connects to a malicious IRC server which acts as the C2 infrastructure. It allows for both preconfigured commands and direct shell access. The file ps is likely used to establish another persistence mechanism by removing the compromised user’s
.ssh folder and creating its own.
The final component is the SSH brute forcer which, much like its compatriots, relies on a series of shell scripts to initialize. The shell script
start is run by one of the init scripts; it then creates a new shell script named
aptitude which runs the script named
run executes a shell script named
The shell script
go downloads a file containing an IP address which is named
xtr. Then an IP and password list (named
b respectively) is downloaded from the IP named in the
xtr file. These files are renamed to
p and then passed to a shell script named
tsm: timeout 90m ./tsm -t $threads -f 0 -s 10 -S 10 -p 0 p ip. This command starts the brute forcer, which runs for a set period of time and then restarts. Newer variations are set to run for 24 hours instead of 90 minutes.
Overall this is a sophisticated malware campaign that has been updated at least once during the investigation and will likely continue to be updated as time goes on. The main goal of this campaign appears to be monetary gain via cryptomining and propagating itself to other systems on the internet. However, the possibility of data exfiltration and/or lateral movement cannot be discounted as the malware appears to have the capability to perform more than just cryptomining.
The current form of the campaign will be detected by the Threat Stack Cloud Security Platform since it partially executes out of
/tmp/ and downloads files via
cURL. While it has been detected in both live customer environments and test environments, the full level of detection will be dependent on the rulesets enabled.
Threat Stack has been a great tool to have in our arsenal. We like the idea of sticking to our core business competencies - healthcare, healthcare marketing, and strategic planning - while being able to outsource or augment other things that are valuable but simply outside our area of expertise.
By integrating Threat Stack with our AWS Profiles and leveraging the host agent, we innovated knowing that we would be alerted if anything was out of line with best practices.
Threat Stack saved us hours previously spent chasing down security events, eliminating the need to hire another security resource.
A Threat Stack Security Analyst will walk through each step of the observed attack including the initial vector, malware campaign flow, and the actual log files and alerts triggered during the attack.
Including details of the malware components, the active cryptomining campaign flow, and future investigations.