Users of the net dread this screen. They feel when they see it all hope is lost.
In the case of this ransomware dropper, the same holds true.
In fact, in running this, I lost my downloads folder >:(
Indeed, a risk all malware reverse engineers take. Live and learn right? Anywho, let’s dive into this bastard already.
First things first, here’s what the thing looks like on VirusTotal:
A pretty dinky file to be honest, barely scratching 40 KB.
A quick peek in IDA shows us what its like under the hood:
Memory packed. How the hell do I know that just peeking real quick? Whenever there’s a bunch of uninitialized data (yellow) that looks like garbage, its most likely its memory packed. This most likely means they’re gonna try the either the RunPE method, or some sort of code injection. Looking through the thing in IDA, I’m not seeing the prerequisites for RunPE, but I do however see one function that stands out for code injection:
See the ‘jmp dword ptr[esi]’ sequence? This is where the malware will make its process leap to another section after preparing the loader. Also note the VirtualAllocEx call for used for allocating some space in another region. The code sequence appears to loop through code and inject it into the region returned by the VirtualAlloc call, then when its done, jumps to it.
That said, let’s load this thing into the debugger and get to work. I start by setting my breakpoints on the usual malware fare (Process creations, file, memory, thread manipulation, etc), and start, breaking at the code space mentioned in IDA:
As I suspected, the malware is injecting the code in ECX into the space pointed to by ESI or in this case 003E0000. We see our jump and more (new) instructions. Let’s hit F9 and continue on through.
There’s a lot going on in this picture. As I said in red, we got a hit, a VirtualProtect call that’s modifying the address space of the original byte space 00400000 from outside (003F00FB). Casual observation shows us an exe header in our registers pointing us to another address space at 008f0000. What does this mean? It means the malware dumped its loader into 008f0000 and is attempting to write the contents into itself in 00400000 (original address space). A form of self modifying code. This also means I was wrong with my RunPE guess. Oh well, can’t win em all right?
Let’s dump the exe in 008f0000 (right click dump, choose save file) and peek in IDA.
That’s a bit more like it. Note the URL’s hard coded inside. This seems to be our stage 2. There are few functions (thank GOD) which makes reversing this much easier.
Further down from main, we see a function that attempts to grab something from the resources section (FindResource).
There’s something there when we load the thing up with CFF Explorer:
A cab file? Sure ok, whatever. What’s in the cab file?
RTF document. My guess is file is shown to the user so they don’t think anything is up / wrong.
The other functions are responsible for downloading the stage2, and decrypting / running it. For that, let’s step through. In this case, I used ollydump after the process changed its original bytes with the newly loaded sequence. Skipping past the part where it launches the RTF doc we just dissected with ShellExecute, we see a number of functions and a sleep.
The sub routine at 00401a8a just downloads a file. In this case, the malware is downloading the index page from Windows update I guess in an attempt to fool heuristics? After the long sleep, the malware goes through its stage2 loop and attempts to download the encrypted file.
Recall that 00401A8A is for downloading files and takes 1 argument. The value pushed is ‘evalero.com/img/cario.tar.gz’.
If the file is non existent / no good, then the malware continues after sleeping for 5 seconds with the next address in the list.
Since the first few links are dead ends, it takes a few iterations before finding a payload:
This link actually worked.
Here’s what it looks like:
Encrypted of course….
After downloading the file, the malware stores the contents in EDI and decrypts via the function 0040179E.
Let’s step on through
Looking at the code, it looks like it looks like simple XOR, but with a few extra steps. It also appears to write the contents after decryption into EAX. Let’s be lazy and run until return:
Sure enough, at address 01760000 we have our decrypted file complete with exe header. After returning, the code then writes the file, runs it with ShellExecute, sleeps for 10 seconds and deletes the file, exiting.
So what’s in this new file we just decrypted? It’s slightly larger than the original file and has a generic looking icon too:
Peeking in IDA shows us its packed (OF COURSE IT IS).
Note the FindResource call, and the long red section. This is actually garbage. Most of this binary is like this just to anger me. The only code I’m interested in is at 00402A80 with ‘jmp dword ptr [edx]’.
Look familiar? it should, it’s the same code injection jump from the previous binary. How does the thing inject the code after decrypting it? Beats the heck outta me, but there’s a lot of jumping around involved:
.text:0040294B cmp ebx, 0 .text:0040294E jz loc_402A57 .text:00402954 sbb ecx, 0FFFFFF86h .text:00402957 sub ecx, 0FFFFFFDFh .text:0040295A sub eax, eax .text:0040295C dec eax .text:0040295D and eax, [esi] .text:0040295F mov cl, byte ptr unk_4070F1 .text:00402965 sub dword_4071BE+2, ecx .text:0040296B add dword_4070EC+1, ecx .text:00402971 sub dword_407030, ecx .text:00402977 sbb ecx, 0FFFFFFA5h .text:0040297A add esi, 4 .text:0040297D add ecx, ecx .text:0040297F add dword_407030+3, ecx .text:00402985 not eax .text:00402987 sub ch, cl .text:00402989 sbb ecx, ecx .text:0040298B or ecx, 0FFFFFFA7h .text:0040298E mov byte ptr dword_407116+2, 0D5h .text:00402995 sbb dword ptr unk_4070AC, ecx .text:0040299B lea eax, [eax-11h] .text:0040299E xor ecx, 10h .text:004029A1 mov ecx, dword_4070BA .text:004029A7 mov dword_407017, ecx .text:004029AD mov byte ptr dword_40710D, 8Dh .text:004029B4 xor eax, edi .text:004029B6 sub ecx, 0FFFFFFDBh .text:004029B9 mov byte ptr dword_407012+2, 4 .text:004029C0 adc ecx, ecx .text:004029C2 clc .text:004029C3 sbb eax, 0FFFFFFFFh .text:004029C6 mov byte_407029, 37h .text:004029CD sbb ecx, 57h .text:004029D0 xor dword_4071FA+1, ecx .text:004029D6 add ecx, ecx .text:004029D8 xor edi, edi .text:004029DA sub edi, eax .text:004029DC neg edi .text:004029DE mov byte ptr dword_40706F+2, 42h .text:004029E5 sbb ecx, ecx .text:004029E7 mov byte ptr dword_4070C1, 0C4h .text:004029EE or ecx, 52h .text:004029F1 rol edi, 2 .text:004029F4 mov byte ptr dword_407121+1, 0FFh .text:004029FB mov ecx, dword_407162+2 .text:00402A01 add cl, ch .text:00402A03 mov byte ptr dword_4070C7+2, 77h .text:00402A0A rol edi, 6 .text:00402A0D adc ecx, 0FFFFFF9Fh .text:00402A10 sbb ecx, ecx .text:00402A12 push eax .text:00402A13 pop dword ptr [edx] .text:00402A15 mov byte ptr dword_40706F, 0CEh .text:00402A1C xor dword_4070F6+1, ecx .text:00402A22 sub edx, 0FFFFFFFCh .text:00402A25 mov ecx, dword_4071FA .text:00402A2B sub dword_40711D+1, ecx .text:00402A31 and ecx, 55h .text:00402A34 or dword_407135, ecx .text:00402A3A mov byte ptr dword_40701B+2, 7Bh .text:00402A41 lea ebx, [ebx-4] .text:00402A44 mov byte_407069, 0EDh .text:00402A4B sbb dword_407104, ecx .text:00402A51 push offset loc_40294B .text:00402A56 retn .text:00402A57 ; --------------------------------------------------------------------------- .text:00402A57 .text:00402A57 loc_402A57: ; CODE XREF: .text:0040294Ej .text:00402A57 mov edx, esp .text:00402A59 mov esi, ds:GetModuleHandleA .text:00402A5F push esi .text:00402A60 mov dword ptr byte_40707D, edi .text:00402A66 sub dword_4071F5, ebx .text:00402A6C push offset loc_4028F0 .text:00402A71 mov ah, byte ptr dword_40710D+2 .text:00402A77 mov byte_407195, 0DCh .text:00402A7E xor al, 46h .text:00402A80 jmp dword ptr [edx]
Let’s dive right in and break on this jump like last time shall we? Stepping into the function brings me into the area of 00A90000:
Peeking through shows a lot of dynamic address resolution and unpacking. Instead of simply just calling functions, the malware dynamically builds a string of a function and then calls it. Weird right?
Like before in stage1, it also replaces the bytes in itself before running. It took some time to find the decryption sequence, but here it is and yes its XOR:
See the STOS instruction? That instruction copies the value of EAX and places it in the location ES:[EDI] or 00AB0010. This is basic self modifying code with encryption. The LOOPD instruction tells it to loop and jump X number of times (657910 or so). Executing until return and checking in the dump the address 00AB0000 shows us what we want:
Dumping the file and loading it into IDA shows us its packed. Of course. Why wouldn’t it be packed?
Which means once again I have to dive in to see what it does. I mean I could continue the program, but this is a good stopping point. Immunity complains that its packed (DUH). The first thing I encounter is a call to VirtualAlloc, most likely to free up some space and mark it RWE.
0012FF8C 00495D50 P]I. /CALL to VirtualAlloc from _00AB000.00495D4D
0012FF90 00000000 …. |Address = NULL
0012FF94 001FC000 .À . |Size = 1FC000 (2080768.)
0012FF98 00001000 ... |AllocationType = MEM_COMMIT
0012FF9C 00000004 … \Protect = PAGE_READWRITE
In an effort to save time, I need to wrap this up. The thing calls VirtualProtect next to set the range, it jumps around a lot before eventually unpacking fully and calling its main function in another address 00690000.
Eventually in the unpacked portion, the malware starts looking for files via the FindFirstFile api with a *.* wildcard. It loops through every file in the user’s working directory and base directory (nice enough to skip the system directory and program files folder), inspecting each file extension for MDF, XLS, DOC, PDF, ZIP, 7Zip, etc, but it doesn’t encrypt them yet. Only on the second run.
0012C5B8 00743D5D ]=t. /CALL to CreateFileW from 00743D57
0012C5BC 00869418 ”†. |FileName = “C:\Documents and Settings\All Users\Application Data\Adobe\usnpcde”
0012C5C0 80000000 …€ |Access = GENERIC_READ
0012C5C4 00000000 …. |ShareMode = 0
0012C5C8 00000000 …. |pSecurity = NULL
0012C5CC 00000003 … |Mode = OPEN_EXISTING
0012C5D0 00000002 … |Attributes = HIDDEN
0012C5D4 00000000 …. \hTemplateFile = NULL
It then checks for AV’s ekrn.exe and avp.exe (Kaspersky and Eset). Why now and not at the beginning? Who knows?
After this it copies itself to the temp folder:
Copies itself to temp
0012C850 0074309C œ0t. /CALL to CreateFileW from 0074309A
0012C854 0012D2A0 Ò. |FileName = “C:\DOCUME~1\Joe\LOCALS~1\Temp\ityksxm.exe”
0012C858 40000000 …@ |Access = GENERIC_WRITE
0012C85C 00000003 … |ShareMode = FILE_SHARE_READ|FILE_SHARE_WRITE
0012C860 00000000 …. |pSecurity = NULL
0012C864 00000002 … |Mode = CREATE_ALWAYS
0012C868 00000000 …. |Attributes = 0
0012C86C 00000000 …. \hTemplateFile = NULL
Creates a task for persistence:
0012CB30 7583B76D m·ƒu /CALL to CreateFileW from mstask.7583B767
0012CB34 00D173A0 sÑ. |FileName = “C:\WINDOWS\Tasks\ilhorge.job”
0012CB38 00000000 …. |Access = 0
0012CB3C 00000003 … |ShareMode = FILE_SHARE_READ|FILE_SHARE_WRITE
0012CB40 00000000 …. |pSecurity = NULL
0012CB44 00000003 … |Mode = OPEN_EXISTING
0012CB48 00000000 …. |Attributes = 0
0012CB4C 00000000 …. \hTemplateFile = NULL
Then it sleeps for a little while, before finally exiting:
When it runs again from the scheduled task, that’s when it changes your background and asks you to read its nice little message, informing you how to get your files back:
Never once does the malware’s second stage write its unencrypted contents to disk, its all contained in RAM making scraping more difficult. I was able to pull the asm contents of the main unpacked function into an IDB file and a text file. There are over 405 THOUSAND lines of assembly code in this bitch. Sure, some of it is data, and most of it is statically linked crap like crypto algorithms, but still, lots of shit to go through.
Have a peek. If you want the IDB file, have at it.
When I have time to revisit (Workshop in 1 month!!!!) I will go into more detail about the encryption used, but its pretty tight stuff – RSA Public key encryption. Block ciphers for large files.
For now though, it seems someone else beat me to the punch.
Until then, stay safe and don’t trust anyone / anything from email.
