About eight weeks ago, a critical RCE vulnerability present in every Samba version since 2010 was reported and patched. This vulnerability is mostly known as “SambaCry” after the famous WannaCry attack targeting Windows systems vulnerable to “EternalBlue” SMB exploit. The vulnerability lies in a logical bug, which enables an attacker with write-only access to a share to load a malicious samba module and execute arbitrary code.
Immediately after writing & publishing the first public POC code, I wrote a yara signature for a possible exploit payload and we began monitoring our data feeds for threats exploiting this vulnerability. Over time, we have noticed countless bind/reverse shells and droppers. Most of them are either Metasploit payload or other publicly available implants.
On June 9th, Kaspersky Labs published an article about “EternalMiner” — a financially driven cryptocurrency mining malware turning victim machines into “a workhouse on a large farm, mining crypto-currency for the attackers”.
Less than a week later, we were able to observe copycat cybercriminals actively exploiting the vulnerability with a similar yet improved setup for better cryptomining & control over the victim machines. Naturally, we decided to name this threat “CopyMiner”!
As we mentioned above, the copycats used a similar yet improved setup. Implementing a multistage flexible approach with daily updates from multiple backup servers, a persistent backdoor for better control of the victim machines and even a more efficient cryptominer for better consumption of the victim machine’s resources! The copycats took EternalMiner to the next level as an operation suitable for multiple victim’s machines. In the following sections, we will drill down on each component of the following graph, comparing CopyMiner’s setup vs EternalMiner:
2. “CopyMiner” Dropper
On the 14th of June a small unique dropper sample was uploaded to VirusTotal. The dropper starts executing from “samba_init_module” exports then tries to fetch a payload from the server & execute it as root user in the background. This is done using a hard-coded obfuscated bash one-liner as you can see in the picture below.
** sample hash: 444d0fae73e1221b81dc6c5d53cf087afa88248fc22ef36e756841ab04df24a8
The payload (http://update1.sdgndsfajfsdf[.]info/u1) is a short bash script which relays on system tools for 3 main tasks
1. Setup daily updates from 3 different backup servers using crontab.
2. Drop and execute Tsunami backdoor & CPUMiner in the background.
3.Prevent further exploitation by other players who might compete for resources(patch smb.conf).
** We were also able to fetch the daily update script from a live server (http://update.sdgndsfajfsdf.info/upd). It seems that this script is just a stripped version of the payload script, lacking the daily updates setup functionality:
CPUMiner is an open source cryptomining command line utility supporting multiple coins/algorithms. It seems that the attackers used “cpuminer-multi” – multithreaded more efficient version of the original @poolers cpuminer used by EternalMiner. This sample was “upgraded” it in a similar way as EternalMiner so it could run standalone without command line parameters. Once started, the upgraded cpuminer automatically login into the attackers private mining pool server (p.theywant[.]in:8080), unlike the public mining pool server used by EternalMiner (xmr.crypto-pool[.]fr:3333).
5. Tsunami Backdoor
Alongside CPUMiner the payload script would also fetch & execute “Tsunami” (also known as Kaiten) which is an old Linux irc backdoor/ddos botnet best known for been used to infect IOT devices and OSX systems in the past. The source is publicly available and could be used by anyone. This sample (d8e93252f41e8b0d10cffa92923eeab94c6c42e8acc308e91340df102042c8c8) is configured with hardcoded c2 irc server (asdgsd.uselesslongdomain[.]info). We were able to connect to the live irc server using credentials hard coded in the malware. In the following picture you can see two victims currently logged in (running as root user).
6. Quickly adopting
We found that the domain used to host the payload file (sdgndsfajfsdf[.]info) was registered on June 13th. Not only that but the first malicious CPUMiner/Tsunami samples were uploaded to VT a day after(June 14th), meaning that the attacks started within a short time of only 4-5 days after the original EternalMiner publication!
7. Indicators of Compromise