While ransomware has been an extremely popular tactic for criminals on Windows over the past year, it has been seen spreading to other operating systems. Android devices have seen some attempts to use ransomware and even OS X has had a few variants of ransomware be seen in the news. Linux has not had as much attention paid to it, though there was an emergence of a ransomware in late 2015, Linux.Encoder.1 – interestingly enough, this malware was actually rewritten for OS X and found in the wild as KeRanger. Since then, there hasn’t been too many variants or new families of Linux ransomware, though we continue to look out for them.
Recently however, it would appear that someone has been dabbling in creating new ransomware. The purposes are not fully clear as the malware doesn’t appear to spread, nor is it fully functional. However, it is interesting to see these files in the wild and apparently being tested. Maybe this is the year of mainstream malware for Linux? Or maybe not, still just testing out the grounds. While ransomware could potentially gain some foothold on the Linux user base, it would likely need to find a better infection vector to propagate similar to how other operating systems are being targeted.
Locating malware for Linux in the “weird” things
While performing normal searches inside our corpus for “weird” things, a script packer called SHC popped to the top. There were recent samples submitted to VirusTotal in the wild which were also using this packer. There is also a “untraceable” function which can be used in an attempt to detect debuggers which are attached to the binary. This isn’t difficult to circumvent, though is interesting none the less, to see which samples are packed with this opposed to those which are not. It was quite easy to stop the untraceable function due to the unobfuscated call to ptrace and simple checking;
After skimming the source, we can quickly identify easy ways to unpack the script which is encrypted inside the binary. Locate the 256 byte RC4 key and then the text section which contains the script, use the “alleged rc4” function and decrypt the payload. After automating this unpacking process and looking at the resulted scripts, there are plenty of uninteresting ones such as;
(Unpacked from 92699f81c69b73e9b875cb3b2df1d55666fc049a24d8ea7f88b639a06172e49e)
To semi-interesting things like a Spanish language “attack kit”;
( Unpacked from e84ded23edddad3ffdbb670be3e852c3f6b9db27a279fa37e03771ba705ae1d1 )
However, the most interesting one that we found which attempts to detect debuggers contains a bash script based ransomware;
The odd part, as mentioned before, is that this doesn’t seem to be finished. The bash script will attempt to check for the presence of openssl on the machine and download a precompiled version of it if not present (we’ll get to this a bit later). Then, it will generate a key on the machine as follows;
key=$("$openssl" rand -base64 32 2>/dev/null | cut -d "=" -f1 2>/dev/null)
This generates a random key which will always be 44 characters long, with a character set of 64 possible characters ( A-Za-z0-9+/). Meaning there are 64^44, or 2.9642775e+79 possible keys that could be generated. After generating this key it is emailed off to the creator using a free vfemail.net email address using the swaks library which it downloads. The email would contain the following identifiers and appear like this to the creator;
Subject:
FROM: [email protected], HOSTID: 007f0101, HOSTNAME: honeypot
Body:
*** FROM: [email protected]
*** KEY: GT+LKe334qCCp6wk4+cMoQIJEu/LXkSqpQ7KRTbOyVg ***
*** HOSTID: 007f0101 ***
*** KERNEL: Linux honeypot 4.4.0-24-generic #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
*** MAC(s): f4:8e:38:c0:ae:ee f4:8e:38:ce:a3:ee
*** UUID: UUID=106aece2-23a6-49cb-80ac-c5ea1e5e56eee /boot ext2 defaults 0 2
This information would appear to be able to fingerprint the target, scraping the external IP address, MAC addresses, UUID’s from the hard drives. Interestingly enough they used the hostid command which will generate a hex id off of the ipv4 address of the machine, though most newer machines will generate the same 007f0101 token since they should be configured for ipv6. The author also seems, “nice enough”, that if the email fails to send – it will append the key to the .bashrc file. In theory this means if no one is able to receive the key, it is possible for the infected user to still recover it in the .bashrc.
After emailing off the key, the script will look for the following file extensions which are accessible to the current user and encrypt them using AES256 with the key generated;
- doc / docx
- txt
- xls / xlsx
- ppt / pptx
- odt
- accdb
- html / php
- jpg / bmp / gif / png
Each of these files will be encrypted in the same directory the previous resided in, with the extension .enc001 added to it. The user will then have a file presented to them, $HOME/encrypted_warning.txt, with the following contents;
The malware would also leave a few other traces behind that it existed, other than encrypting files. For example in the /tmp/ directory, there would be a list of all the files it found and attempted to encrypt in file such as /tmp/.jpg.bak – along with the file /tmp/.X1-lock being present if it had run and attempt to encrypt files and /tmp/.X2-lock being present if it attempted to decrypt things.
Half baked?
This still leaves us with some puzzling questions. Who is making this, and why, if they are going to try and encrypt and ransom things, are they not asking for money or telling us how to get the key for decrypting? This lead me to go back and look at the script for anything that I might have missed.
For sending an email, the script will download “swans” from the developer’s official site;
http://www.jetmore.org/john/code/swaks/files/swaks-20130209.0/swaks
However it will also attempt to download openssl, if it cannot find it, from this site;
http://brezular.com/wp-content/uploads/2016/07/updater.gz
This is, interesting, to say the least as it appears to have been uploaded this month using WordPress. This however, assumes we trust the directory structure of the url. This seems interesting though, as there is no actual reference to the download anywhere on the internet, even on the blogging system itself. If we goto the main landing page, we can see that this is a personal blog for “a professional soldier of the Slovak Armed Forces” who seems to enjoy all things Linux. There are also interesting similarities between some of the bash code written in other articles. This could all be coincidence, or the owner of the site is planning to blog about a POC ransomware, or the site has been compromised, or the owner simply posted an openssl binary using an odd name with no external references to what it is – and the scripts original author found it and is using it. The only other interesting link to this potential site is from the submitter data found VirusTotal;
So the original file was submitted from SK (Slovakia).There are only currently two copies of samples which can be found in the wild, one submitted from the US appears to be identical to the one from SK, however it was watermarked as seen below;
These all seem to be interesting tidbits of data. However in the end, we still don’t know if this is actively being used, academic, or just being tested before deployed. We also are not sure if there is any specific route for infection planned, or if it is similar to some Windows ransomware which would simply try to trick the user into running the binary. Regardless, it is an interesting thing to keep a look out for as this coder and other potential malicious actors turn to the Linux platform as a target. Similar to KeRanger, maybe we will see this bash script reused for systems like OS X later down the road.
Tying up loose ends
After originally writing this analysis and having a day or so to mull it over, we decided to email the owner of website hosting the updater.gz file and inquire if they knew it was there, potentially they were compromised – or maybe, they are the author of the bash file? Turned out our hunch was correct. The author of the malware and owner of the web site is one in the same. Upon asking why they created it, they said it was for a forensics class they would be teaching. Still unsure why they are uploading it onto VirusTotal and why it appears multiple people have access to the file. There doesn’t seem to be many reasons to upload something you’ve created yourself to VirusTotal, other than to see if vendors detect it as malware – which you would know is malware if you’re the creator. Hopefully the source of this won’t fall into the wrong hands and end up being repurposed in new malware for Linux.
Special thanks to @michalmalik for his help!
Samples Analyzed:
2dad6ecf4b56322159358f0377a06b07914ab7857c0df10d67ed7c7d472d90e0 (US submitted, watermarked, packed file)
65c1bfa4d2098686179d0a4be4b483c3d062ff5eb0ae58cc3f5f7ea548c77b9d (SK submitted, packed file)
e2fc7ba20c6c18beaee29391f19ac14b0d11bc47bfc94289dcdd6191bd563da3 (Unpacked shell script)
Do you run a small or medium business? Are you anxious to learn how to prevent your IP from being stolen or destroyed by criminals? Check out our white paper, “Ransomware is Here: What You Can Do About It,” and contact SentinelOne today.
