Linux ransomware.

First, the Trojan encrypts files in the following directories:
/home
/root
/var/lib/mysql
/var/www
/etc/nginx
/etc/apache2
/var/log

Trojan also encrypts files from directories whose names start with one of the following strings:
public_html
www
webapp
backup
.git
.svn

http://vms.drweb.com/virus/?i=7704004&lng=en

Attached.

the code is lame, It could have been "wormable" but not even, in one line you can do the same thing...
You can even do simpler, prevent mount of the volume, the /media directory is not affected.

http://detux.org/report.php?sha256=cfca ... e9a04e6486

Xylitol wrote:http://detux.org/report.php?sha256=cfca ... e9a04e6486

Automated analisys doesn't make much sense there, until you pass valid arguments to trojan.

As I was picking through the args look to be:

./sample [encrypt|decrypt] [RSA Key]

We mentioned that the AES key is generated locally on the victim’s computer. We looked into the way the key and initialization vector are generated by reverse-engineering the Linux.Encoder.1 sample in our lab. We realized that, rather than generating secure random keys and IVs, the sample would derive these two pieces of information from the libc rand() function seeded with the current system timestamp at the moment of encryption.

http://labs.bitdefender.com/2015/11/lin ... ption-key/

@Blaze good work for swiftly sharing the sample in here. Thanks.

Blaze wrote:Linux ransomware.

First, the Trojan encrypts files in the following directories:
/home
/root
/var/lib/mysql
/var/www
/etc/nginx
/etc/apache2
/var/log

Just back from our ELF workshop. The above list is incomplete. Maybe the dynamic analysis bumped to permission matter. Since the information is vital to us, sysadmins, let me rephrased them with below, this is according to the code of the binary. I don't know how many variant of this, yet, I attached link to sample I face.

Directories aimed: Extension files aimed: Pseudo file/folder with string pattern matching aimed: Sample: https://www.virustotal.com/en/file/fd04 ... /analysis/
(same one I guessed)
#MalwareMustDie

Xylitol wrote:the code is lame

I agree. It seems to be a quicky job, unexperienced, yet dangerous idea.

tWiCe wrote:Automated analisys doesn't make much sense there, until you pass valid arguments to trojan.

True, infact it relied on the argument commands.

p1nk wrote:As I was picking through the args look to be:
./sample [encrypt|decrypt] [RSA Key]

correct. kind of like that..which is why I agree with @Xylitol.

Good analysis by Dr.Web: http://vms.drweb.com/virus/?i=7704004&lng=en I have nothing to add in the summary.

(beforehand see here for cypt file/dir list and for comments of the threat)
Just a quicky strolling the decrypting parts of this ELF Linux ransomware as per below, using sample I posted above in x86-64.

This is the function that is used to decrypt all of the crypted file..called, decrypt_all(), which is showing the args passed,
(arguement dependable).

In the end of the decrypt_all or can be called directly too, there's the decrypt_file() contains the logic to decrypt-
each AES crypted files using AES after its key cracked using private key beforehand..only this part that -
"may" have a bit of "complicatation"..

Some blah blah preparations before decrypting (grep that mentioned string as hint..)

Stream of data is read here by stdio.h (posix block onput/output) via fread_unlocked (void *data, size_t size,
size_t count, FILE *stream)

This is the main course, the decrypter..

↑After decrypted the data is written via fwrite_unlocked (const void *data, size_t size, size_t count, FILE *stream) it is -
needed stdio.h too..(this is so funny..I won't comment much but..we are seeing a work of an amateur here OMG :lol: )

As you can see in the source codes set used below, down to (mostly all) system calls are statically compiled with their -
hope to run this ransomware independently (which is useless in some way though)..

Additionally..to my memo, the whole project source list are in C, with main shitty crypter codes in main.c:


#MalwareMustDie | reversed by @unixfreaxjp

An additional.. more of "copy paster evidence" :)
let's take a look into file restoring decryption, and AES key restoring decryption done by this ransomware.

You can see in the above last picture of my reversing pad here in 0x400836 that aes_decrypt function was called. If you trailed that function you will see that the decrypting process (for restoring the crypted files) is using the function called mbedtls_aes_setkey_dec and mbedtls_aes_crypt_cbc - it is a well known function to decrypt AES on the CBC crypt mode if you familiar with the Polar SSL, since they are functions described in the mbedtls/pk.h - So apparently the coder is copy pasting these codes for the ransomware decryption purpose.
Below is the reversing illustration (click to enlarge)

Those two calls that are significantly important for decrypting functions, the mbedtls_aes_setkey_dec (0x4005db) is a decrypting AES function and by default is using the 128 bit length key (like what this ransomware used..default base setting of a pure copy-paste :D ) - and mbedtls_aes_crypt_cbc (0x4005f9) that is explaining the CBC crypt method in AES is used.

Also in the above last picture here in 0x400753 was stated the call to private_decrypt() and following its trail you'll see the call for mbedtls_pk_decrypt() with the purpose to decrypt the AES key for restoring encrypted files by this ransomware, by using the RSA private key. This function is also using Polar SSL source code used for decrypting an encrypted messages/communication, and it is supported to RSA keys with the default padding type PKCS#1 v1.5, and again, this is what the RSA specification used by these copy-paster :lol:
The flow of private key decrypting of the AES key used for restoring files, can be seen with commented reversing code below:


Understanding these methods is making us easier to seek a howto prevent and even the ways in cracking "the necessaries" to restore the crypted file. There are weaknesses in the scheme of this ransomware that can be used for it. I leave it to you all to provide mitigations.

Moreover, this is not the first time that open source codes were used by the criminal in a malware.. And this is a sample of bad result of too many ransomware concept and source codes that is openly shared in internet, there are more bad that good in sharing these kind of stuff openly.

@unixfreaxjp of MalwareMustDie - heil to fellow unix shell reversers - thanks for cool aeim asm.emu/emuwrite from pancake - it worked well! :)

Linux.Encoder.2: https://news.drweb.com/show/?i=9709&lng=en&c=14

14ffe3ef5ccfbbc9a03ebd67d70b7cbf521db3f2
541966dd25ce48a8f54b270b9aed2fba3f021d29
57cf90a1cea89e13c3fd625854dd6b81228796b9
aebb9bf852d848e22e8a7bba4d64874c7953460d
b45f8f33ff54ece377fad73a8f89857c2bc114ac