A forum for reverse engineering, OS internals and malware analysis 

Forum for analysis and discussion about malware.
 #17811  by Xylitol
 Tue Jan 22, 2013 6:04 pm
Got another sample simmilar, and guess what:
Code: Select all
004024CF   .  43 52 5F 4D 3>ASCII "CR_M0x0402.062",0
004024DE   .  0A            DB 0A
004024DF   .  68 74 74 70 3>ASCII "http://397"
004024E9   .  31 31 30 31 3>ASCII "110121001i834555"
004024F9   .  31 32 33 37 3>ASCII "12377.com/una2/S"
00402509   .  46 36 33 34 3>ASCII "F6344-GWXS-WEQOZ"
00402519   .  36 2E 70 68 7>ASCII "6.php
",0
Original: https://www.virustotal.com/file/2f32838 ... 358877964/ > 24/45
Unpck: https://www.virustotal.com/file/5d3be4e ... 358878144/ > 18/46
Compilation timedatestamp.....: 2013-01-14 14:09:46
Attachments
infected
(62.02 KiB) Downloaded 67 times
 #17813  by Xylitol
 Tue Jan 22, 2013 7:49 pm
Belahzu wrote:xaoaznqm.exe attached below.
Same dead domain and same timestamp when unpacked.
if actor(s) have not moved the db to the new domain guys infected by your file are fucked.
Code: Select all
004024CF   .  43 52 5F 4D 3>ASCII "CR_M0x0402.062",0
004024DE   .  0A            DB 0A
004024DF   .  68 74 74 70 3>ASCII "http://397"
004024E9   .  31 31 30 31 3>ASCII "110121001i834555"
004024F9   .  31 32 33 37 3>ASCII "12377.com/una2/S"
00402509   .  46 36 33 34 3>ASCII "F6344-GWXS-WEQOZ"
00402519   .  36 2E 70 68 7>ASCII "6.php
",0
 #17816  by thisisu
 Tue Jan 22, 2013 9:38 pm
If this is Matsnu it is no longer using the same “locked-<original_name>.<4 random characters>” renaming method to the encrypted files like before (~6 months ago)

For reference:
DrWeb's decrypt tool (Matsnu) : ftp://ftp.drweb.com/pub/drweb/tools/matsnu1decrypt.exe
Kaspersky's decrypt tool (Rannoh) : http://support.kaspersky.com/downloads/ ... ryptor.zip
ESET's decrypt tool (Trustezeb.A): http://www.eset.com/de/download/utiliti ... amily/145/
Avira's decrypt tool (?) : http://www.avira.com/files/support/FAQ_ ... locker.zip

Sorry if I left out other vendors these are the only ones I know of.

I believe all the tools here require that the original file be the same size as the encrypted file which does not seem to be the case here with the Menu Wedding Dinner 1.xls files.
 #17817  by Belahzu
 Tue Jan 22, 2013 9:51 pm
Yeah, those tools aren't going to work due to the 1044 size increase. I think the other samples I have are probably all the same with the same dead URL.

@Fabian - The quarantine from Hitman below.
Attachments
password: malware
(268.82 KiB) Downloaded 57 times
 #17818  by Fabian Wosar
 Tue Jan 22, 2013 9:55 pm
thisisu wrote:If this is Matsnu it is no longer using the same “locked-<original_name>.<4 random characters>” renaming method to the encrypted files like before (~6 months ago)
Correct. It no longer changes the file name. Primarily because it seems there no longer is a central database containing the encryption keys and original file names. The encryption key for each file is most likely stored within the encrypted file. The encryption key is likely encrypted with a second key that is randomly generated and send off to the server.
thisisu wrote:DrWeb's decrypt tool : ftp://ftp.drweb.com/pub/drweb/tools/matsnu1decrypt.exe
Kaspersky's decrypt tool (they call it Rannoh) : http://support.kaspersky.com/downloads/ ... ryptor.zip
Both tools haven't worked for a long time. Matsnu/Trustezeb/Rannoh switched to a new encryption scheme several months ago. It essentially uses a different key per file. So the old trick with recovering the encryption key by comparing a pair of files and then using it to decrypt all other files no longer works.

There is a pretty nice write up from H. Caron and P. Rascagneres going into all the details of newer Matsnu/Trustezeb/Rannoh variants:
http://malware.lu/Pro/RAP001_malware_ra ... nu_1.1.pdf

The communication protocols are largly unchanged based on some static analysis. It even uses the same RC4 password to encrypt the communication. My guess why they changed the encryption is that their old model was prone to users running CCleaner and similar tools. In those cases CCleaner removed the database because it thought it was just a temporary file and the user could no longer decrypt his files which is bad for their "business".

It's just speculation on my end though based on observations and quick static analysis. I could be totally wrong :).
 #17820  by thisisu
 Tue Jan 22, 2013 11:40 pm
Fabian Wosar wrote:There is a pretty nice write up from H. Caron and P. Rascagneres going into all the details of newer Matsnu/Trustezeb/Rannoh variants:
http://malware.lu/Pro/RAP001_malware_ra ... nu_1.1.pdf
Quite possibly the best writeup I've ever read. Didn't understand the ASM stuff but really appreciated the efforts in translating it.
Once the ransomware is executed, files are encrypted and it is not possible to recover it without network traces.

With network trace, for example with a proxy, it is possible to recover the files. We provide two solutions in this report:
- A script to parse the hard drive of the infected machine and recover the files
- A fake command & control that gives the order to unlock and recover the files
But the 2 solutions need the id and the data variable sent by the client during the infection.
So since hXXp://397110121001i83455512377.com/una2/SF6344-GWXS-WEQOZ6.php is dead, not anything we can do here unless files were moved to another (online) domain with the master key information?
 #17821  by Fabian Wosar
 Tue Jan 22, 2013 11:55 pm
thisisu wrote:So since hXXp://397110121001i83455512377.com/una2/SF6344-GWXS-WEQOZ6.php is dead, not anything we can do here unless files were moved to another (online) domain with the master key information?
Well it has nothing to do with whether or not the location is dead to be honest. Even if the location was alive, the only way the server would return the key would be by submitting a valid UKASH code. Unless of course the script had some injection issues. In all other cases you would require physical access to the server to get access to the master keys.
 #17823  by Belahzu
 Wed Jan 23, 2013 12:31 am
Fabian Wosar wrote:
thisisu wrote:So since hXXp://397110121001i83455512377.com/una2/SF6344-GWXS-WEQOZ6.php is dead, not anything we can do here unless files were moved to another (online) domain with the master key information?
Well it has nothing to do with whether or not the location is dead to be honest. Even if the location was alive, the only way the server would return the key would be by submitting a valid UKASH code. Unless of course the script had some injection issues. In all other cases you would require physical access to the server to get access to the master keys.
Darn that sucks, guess I have some bad news to tell my users.