A forum for reverse engineering, OS internals and malware analysis 

Forum for analysis and discussion about malware.
 #27181  by Blaze
 Sat Nov 07, 2015 11:31 am
Linux ransomware.
First, the Trojan encrypts files in the following directories:

Trojan also encrypts files from directories whose names start with one of the following strings:

You do not have the required permissions to view the files attached to this post.
 #27183  by Xylitol
 Sat Nov 07, 2015 1:40 pm
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
 #27209  by nfx
 Wed Nov 11, 2015 1:12 pm
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/
 #27251  by unixfreaxjp
 Tue Nov 17, 2015 1:47 am
@Blaze good work for swiftly sharing the sample in here. Thanks.
Blaze wrote:Linux ransomware.
First, the Trojan encrypts files in the following directories:
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:
Code: Select all
/root/.ssh (exclusion)_
/usr/bin (exclusion)_
/etc/ssh (exclusion)_
Extension files aimed:
Code: Select all
Pseudo file/folder with string pattern matching aimed:
Code: Select all
Sample: https://www.virustotal.com/en/file/fd04 ... /analysis/
(same one I guessed)
Last edited by unixfreaxjp on Tue Nov 17, 2015 5:08 am, edited 5 times in total.
 #27252  by unixfreaxjp
 Tue Nov 17, 2015 1:56 am
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.
Last edited by unixfreaxjp on Tue Nov 17, 2015 5:49 am, edited 1 time in total.
 #27253  by unixfreaxjp
 Tue Nov 17, 2015 5:01 am
(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
 #27264  by unixfreaxjp
 Wed Nov 18, 2015 1:29 am
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! :)