[Fabian Wosar]

Attached are two variants of a new crypto malware that first showed up a few days ago.

The encryption of the first variant is rather simplistic. It just does a simple XOR using a static key that is used on every system. The key used is 0x3035353331623139626238343662313863303966393739656562343239616433.

The second variant changed the encryption scheme. It now generates a new per-infection key on each system. This per-infection key appears to be the SHA256 of something. I didn't look into of what exactly yet because the malware author failed at securing his server and left all generated keys open to be downloaded by anyone. If someone wants a dump of all keys, please let me know.

The per-infection key is then used to derive a new encryption key for every 0x4000 byte block of a file that is being encrypted. The key for the block is essentially the SHA256 of the per-infection key plus the file name including path plus the index of the block being encrypted starting with 1. So if the per-infection key is d9ae3f2910a4de28315216bd1152746db1b539fa3b545ac7d24401f3d39ec581 for example and the file being encrypted is located in C:\file.ext the first 0x4000 bytes would be encrypted using SHA256("d9ae3f2910a4de28315216bd1152746db1b539fa3b545ac7d24401f3d39ec581C:\file.ext1"), the second 0x4000 bytes would be encrypted with SHA256("d9ae3f2910a4de28315216bd1152746db1b539fa3b545ac7d24401f3d39ec581C:\file.ext2") and so on.

I didn't look into how the malware derives the key stream it uses to XOR the original bytes with from the SHA256 yet due to lack of time. I hope to get to it later today but I am not that familiar with VB6 and the disassembled code looks horrible. So if one of you with more experience in reversing VB6 code wants to give it a shot, the function that encrypts a block using the SHA256 derived as the key for the block is located at 0x0042FF80 in the variant 2 sample.

[Mohamed Shetta]

I had a quick look on variant two and here is my findings,

The per-infection key generation procedure is located at 0x0042F8B0. The key is the SHA-256 of the current time plus the result from calling each of the following API, GetCurrentProcessID GetProcessHeap GetActiveWindow GetClipboardOwner GetDesktopWindow GetForegroundWindow GetShellWindow

Example for the output string: 4:31:18 PM 1968 3796 1376256 0 131572 65556 658342 65716
SHA256: D5A753361DA639EB9024A83355768D2E243784E553E434E1995384D81A52C1C3

So its almost impossible to replicate the same key that was used at the time of the infection.
Fortunately the ransomware uses rtcSaveSetting to save the key for later usage. You will find the key in the registry

Code: Select all

HKEY_CURRENT_USER\Software\VB and VBA Program Settings\CLOCK\CData\C

I doubt that the key gets deleted as the ransomware doesn't import the function rtcDeleteSetting.

[Fabian Wosar]

I doubt that the key gets deleted as the ransomware doesn't import the function rtcDeleteSetting.

While it is not deleted, there at least exists code that will set it to an empty string again. Take a look around 0x0042F422. It calls the method that sets the value you mentioned with an empty string. I haven't checked if the code path can be reached through normal means though as the malware does include a lot of disabled debugging code. So you still may be correct.

Have you looked into the block encryption function by any chance?

[Mohamed Shetta]

I haven't checked if the code path can be reached through normal means though as the malware does include a lot of disabled debugging code.

The code execution reaches this function just after finishing the encryption of the files.

Have you looked into the block encryption function by any chance?

Nope, I thought everything is clear over there so I didn't check. is there something vague over there?

[DecrypterFixer]

Wanted to chime in and say that even after successful decryption from infection. So i think you may be right that it is not hit to remove the string.

EDIT: Well, i guess it must throw the encryption key back in the reg after a successful decryption which threw me off, as i just had a few users send me their reg entries and its removed. So ill simply show myself out :)

[Fabian Wosar]

Nope, I thought everything is clear over there so I didn't check. is there something vague over there?

Don't know yet to be honest as I haven't had time to look into it yet :).

[Fabian Wosar]

Okay, the algorithm used to encrypt the block appears to be standard RC4.

[sysopfb]

PClock - criminal_case_for_you.scr

Crypter -

Code: Select all

F:\Krypton_15.0_NR\Bin\StubNew.pdb

packed and unpacked in attached