{"id":1047,"date":"2015-02-14T00:07:27","date_gmt":"2015-02-14T00:07:27","guid":{"rendered":"http:\/\/www.gironsec.com\/blog\/?p=1047"},"modified":"2015-02-20T16:47:24","modified_gmt":"2015-02-20T16:47:24","slug":"ctb-locker-and-dropper","status":"publish","type":"post","link":"https:\/\/www.gironsec.com\/blog\/2015\/02\/ctb-locker-and-dropper\/","title":{"rendered":"CTB-Locker and Dropper"},"content":{"rendered":"

Users of the net dread this screen. They feel when they see it all hope is lost.
\n\"zomg<\/a>
\nIn the case of this ransomware dropper, the same holds true.
\n\"ZOMG<\/a>
\nIn fact, in running this, I lost my downloads folder >:(
\n\"damnit\"<\/a>
\nIndeed, a risk all malware reverse engineers take. Live and learn right? Anywho, let’s dive into this bastard already.<\/p>\n

First things first, here’s what the thing looks like on VirusTotal:
\n\"virus_total\"<\/a>
\nA pretty dinky file to be honest, barely scratching 40 KB.
\n\"dinkyfile\"<\/a><\/p>\n

A quick peek in IDA shows us what its like under the hood:
\n\"quickidapeek\"<\/a>
\nMemory 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:
\n\"code_injection_point\"<\/a>
\nSee 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<\/a> 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.
\nThat 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:
\n\"start1_2\"<\/a>
\nAs 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.
\n\"start2\"<\/a>
\nThere’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?<\/p>\n

Let’s dump the exe in 008f0000 (right click dump, choose save file) and peek in IDA.<\/p>\n

\"quickidapeek_2\"<\/a>
\nThat’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. <\/p>\n

Further down from main, we see a function that attempts to grab something from the resources section (FindResource).
\n\"resource_section\"<\/a>
\nThere’s something there when we load the thing up with CFF Explorer:
\n\"findresource2\"<\/a>
\nA cab file? Sure ok, whatever. What’s in the cab file?
\n\"findresource3\"<\/a>
\nRTF document. My guess is file is shown to the user so they don’t think anything is up \/ wrong. <\/p>\n

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.
\n\"making_rounds\"<\/a>
\nThe 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.
\n\"download_stage2\"<\/a>
\nRecall that 00401A8A is for downloading files and takes 1 argument. The value pushed is ‘evalero.com\/img\/cario.tar.gz’.<\/p>\n

If the file is non existent \/ no good, then the malware continues after sleeping for 5 seconds with the next address in the list.
\n\"sleep5seconds_tryagain\"<\/a><\/p>\n

Since the first few links are dead ends, it takes a few iterations before finding a payload:
\n\"hardcoded_next\"<\/a><\/p>\n

This link actually worked.
\nHere’s what it looks like:
\n\"cairo_tar_gz\"<\/a>
\nEncrypted of course….<\/p>\n

After downloading the file, the malware stores the contents in EDI and decrypts via the function 0040179E.
\n\"cryptedfile1\"<\/a>
\nLet’s step on through
\n\"cryptedfile2\"<\/a><\/p>\n

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:
\n\"cryptedfile4\"<\/a><\/p>\n

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.
\n\"write_it_run_it_delete_it\"<\/a><\/p>\n

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:
\n\"_17\"<\/a><\/p>\n

Peeking in IDA shows us its packed (OF COURSE IT IS).
\n\"quickidapeek_3\"<\/a><\/p>\n

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]’.
\n\"code_injection_point2\"<\/a>
\nLook 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:
\n<\/p>\n

\n
.text:0040294<\/span>B                 cmp     ebx, 0<\/span>\r\n.text:0040294<\/span>E                 jz      loc_402A57\r\n.text:00402954<\/span>                 sbb     ecx, 0FFFFFF86h<\/span>\r\n.text:00402957<\/span>                 sub     ecx, 0FFFFFFDFh<\/span>\r\n.text:0040295<\/span>A                 sub     eax, eax\r\n.text:0040295<\/span>C                 dec     eax\r\n.text:0040295<\/span>D                 and     eax, [esi]\r\n.text:0040295<\/span>F                 mov     cl, byte<\/span> ptr unk_4070F1\r\n.text:00402965<\/span>                 sub     dword<\/span>_4071BE+2<\/span>, ecx\r\n.text:0040296<\/span>B                 add     dword<\/span>_4070EC+1<\/span>, ecx\r\n.text:00402971<\/span>                 sub     dword<\/span>_407030, ecx\r\n.text:00402977<\/span>                 sbb     ecx, 0FFFFFFA5h<\/span>\r\n.text:0040297<\/span>A                 add     esi, 4<\/span>\r\n.text:0040297<\/span>D                 add     ecx, ecx\r\n.text:0040297<\/span>F                 add     dword<\/span>_407030+3<\/span>, ecx\r\n.text:00402985<\/span>                 not     eax\r\n.text:00402987<\/span>                 sub     ch, cl\r\n.text:00402989<\/span>                 sbb     ecx, ecx\r\n.text:0040298<\/span>B                 or      ecx, 0FFFFFFA7h<\/span>\r\n.text:0040298<\/span>E                 mov     byte<\/span> ptr dword<\/span>_407116+2<\/span>, 0D5h<\/span>\r\n.text:00402995<\/span>                 sbb     dword<\/span> ptr unk_4070AC, ecx\r\n.text:0040299<\/span>B                 lea     eax, [eax-11h<\/span>]\r\n.text:0040299<\/span>E                 xor     ecx, 10h<\/span>\r\n.text:004029<\/span>A1                 mov     ecx, dword<\/span>_4070BA\r\n.text:004029<\/span>A7                 mov     dword<\/span>_407017, ecx\r\n.text:004029<\/span>AD                 mov     byte<\/span> ptr dword<\/span>_40710D, 8Dh<\/span>\r\n.text:004029<\/span>B4                 xor     eax, edi\r\n.text:004029<\/span>B6                 sub     ecx, 0FFFFFFDBh<\/span>\r\n.text:004029<\/span>B9                 mov     byte<\/span> ptr dword<\/span>_407012+2<\/span>, 4<\/span>\r\n.text:004029<\/span>C0                 adc     ecx, ecx\r\n.text:004029<\/span>C2                 clc\r\n.text:004029<\/span>C3                 sbb     eax, 0FFFFFFFFh<\/span>\r\n.text:004029<\/span>C6                 mov     byte<\/span>_407029, 37h<\/span>\r\n.text:004029<\/span>CD                 sbb     ecx, 57h<\/span>\r\n.text:004029<\/span>D0                 xor     dword<\/span>_4071FA+1<\/span>, ecx\r\n.text:004029<\/span>D6                 add     ecx, ecx\r\n.text:004029<\/span>D8                 xor     edi, edi\r\n.text:004029<\/span>DA                 sub     edi, eax\r\n.text:004029<\/span>DC                 neg     edi\r\n.text:004029<\/span>DE                 mov     byte<\/span> ptr dword<\/span>_40706F+2<\/span>, 42h<\/span>\r\n.text:004029<\/span>E5                 sbb     ecx, ecx\r\n.text:004029<\/span>E7                 mov     byte<\/span> ptr dword<\/span>_4070C1, 0C4h<\/span>\r\n.text:004029<\/span>EE                 or      ecx, 52h<\/span>\r\n.text:004029<\/span>F1                 rol     edi, 2<\/span>\r\n.text:004029<\/span>F4                 mov     byte<\/span> ptr dword<\/span>_407121+1<\/span>, 0FFh<\/span>\r\n.text:004029<\/span>FB                 mov     ecx, dword<\/span>_407162+2<\/span>\r\n.text:00402<\/span>A01                 add     cl, ch\r\n.text:00402<\/span>A03                 mov     byte<\/span> ptr dword<\/span>_4070C7+2<\/span>, 77h<\/span>\r\n.text:00402<\/span>A0A                 rol     edi, 6<\/span>\r\n.text:00402<\/span>A0D                 adc     ecx, 0FFFFFF9Fh<\/span>\r\n.text:00402<\/span>A10                 sbb     ecx, ecx\r\n.text:00402<\/span>A12                 push    eax\r\n.text:00402<\/span>A13                 pop     dword<\/span> ptr [edx]\r\n.text:00402<\/span>A15                 mov     byte<\/span> ptr dword<\/span>_40706F, 0CEh<\/span>\r\n.text:00402<\/span>A1C                 xor     dword<\/span>_4070F6+1<\/span>, ecx\r\n.text:00402<\/span>A22                 sub     edx, 0FFFFFFFCh<\/span>\r\n.text:00402<\/span>A25                 mov     ecx, dword<\/span>_4071FA\r\n.text:00402<\/span>A2B                 sub     dword<\/span>_40711D+1<\/span>, ecx\r\n.text:00402<\/span>A31                 and     ecx, 55h<\/span>\r\n.text:00402<\/span>A34                 or      dword<\/span>_407135, ecx\r\n.text:00402<\/span>A3A                 mov     byte<\/span> ptr dword<\/span>_40701B+2<\/span>, 7Bh<\/span>\r\n.text:00402<\/span>A41                 lea     ebx, [ebx-4<\/span>]\r\n.text:00402<\/span>A44                 mov     byte<\/span>_407069, 0EDh<\/span>\r\n.text:00402<\/span>A4B                 sbb     dword<\/span>_407104, ecx\r\n.text:00402<\/span>A51                 push    offset loc_40294B\r\n.text:00402<\/span>A56                 retn\r\n.text:00402<\/span>A57 ; ---------------------------------------------------------------------------<\/span>\r\n.text:00402<\/span>A57\r\n.text:00402<\/span>A57 loc_402A57:                             ; CODE XREF: .text:0040294E\u0018j<\/span>\r\n.text:00402<\/span>A57                 mov     edx, esp\r\n.text:00402<\/span>A59                 mov     esi, ds:GetModuleHandleA\r\n.text:00402<\/span>A5F                 push    esi\r\n.text:00402<\/span>A60                 mov     dword<\/span> ptr byte<\/span>_40707D, edi\r\n.text:00402<\/span>A66                 sub     dword<\/span>_4071F5, ebx\r\n.text:00402<\/span>A6C                 push    offset loc_4028F0\r\n.text:00402<\/span>A71                 mov     ah, byte<\/span> ptr dword<\/span>_40710D+2<\/span>\r\n.text:00402<\/span>A77                 mov     byte<\/span>_407195, 0DCh<\/span>\r\n.text:00402<\/span>A7E                 xor     al, 46h<\/span>\r\n.text:00402<\/span>A80                 jmp     dword<\/span> ptr [edx]\r\n<\/pre>\n<\/div>\n
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:
\n\"crypto_unpacked1\"<\/a>
\nPeeking 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?
\n\"function_unpacking\"<\/a><\/p>\n
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:
\n\"decryption_sequence_again\"<\/a><\/p>\n
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:
\n\"crypto_unpacked3\"<\/a><\/p>\n
Dumping the file and loading it into IDA shows us its packed. Of course. Why wouldn’t it be packed?
\n\"packedagain\"<\/a><\/p>\n
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.
\n0012FF8C   00495D50  P]I.  \/CALL to VirtualAlloc from _00AB000.00495D4D
\n0012FF90   00000000  ….  |Address = NULL
\n0012FF94   001FC000  .\u00c0\u001f.  |Size = 1FC000 (2080768.)
\n0012FF98   00001000  .\u0010..  |AllocationType = MEM_COMMIT
\n0012FF9C   00000004  \u0004…  \\Protect = PAGE_READWRITE<\/p>\n
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. <\/p>\n
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.
\n\"findfile\"<\/a>
\n0012C5B8   00743D5D  ]=t.  \/CALL to CreateFileW from 00743D57
\n0012C5BC   00869418  \u0018\u201d\u2020.  |FileName = “C:\\Documents and Settings\\All Users\\Application Data\\Adobe\\usnpcde”
\n0012C5C0   80000000  …\u20ac  |Access = GENERIC_READ
\n0012C5C4   00000000  ….  |ShareMode = 0
\n0012C5C8   00000000  ….  |pSecurity = NULL
\n0012C5CC   00000003  \u0003…  |Mode = OPEN_EXISTING
\n0012C5D0   00000002  \u0002…  |Attributes = HIDDEN
\n0012C5D4   00000000  ….  \\hTemplateFile = NULL<\/p>\n
It then checks for AV’s ekrn.exe and avp.exe (Kaspersky and Eset). Why now and not at the beginning? Who knows?
\n\"av_check\"<\/a><\/p>\n
After this it copies itself to the temp folder:
\nCopies itself to temp
\n0012C850   0074309C  \u01530t.  \/CALL to CreateFileW from 0074309A
\n0012C854   0012D2A0  \u00a0\u00d2\u0012.  |FileName = “C:\\DOCUME~1\\Joe\\LOCALS~1\\Temp\\ityksxm.exe”
\n0012C858   40000000  …@  |Access = GENERIC_WRITE
\n0012C85C   00000003  \u0003…  |ShareMode = FILE_SHARE_READ|FILE_SHARE_WRITE
\n0012C860   00000000  ….  |pSecurity = NULL
\n0012C864   00000002  \u0002…  |Mode = CREATE_ALWAYS
\n0012C868   00000000  ….  |Attributes = 0
\n0012C86C   00000000  ….  \\hTemplateFile = NULL<\/p>\n
Creates a task for persistence:<\/p>\n
0012CB30   7583B76D  m\u00b7\u0192u  \/CALL to CreateFileW from mstask.7583B767
\n0012CB34   00D173A0  \u00a0s\u00d1.  |FileName = “C:\\WINDOWS\\Tasks\\ilhorge.job”
\n0012CB38   00000000  ….  |Access = 0
\n0012CB3C   00000003  \u0003…  |ShareMode = FILE_SHARE_READ|FILE_SHARE_WRITE
\n0012CB40   00000000  ….  |pSecurity = NULL
\n0012CB44   00000003  \u0003…  |Mode = OPEN_EXISTING
\n0012CB48   00000000  ….  |Attributes = 0
\n0012CB4C   00000000  ….  \\hTemplateFile = NULL<\/p>\n
Then it sleeps for a little while, before finally exiting:
\n\"final_sleep\"<\/a><\/p>\n
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:
\n\"kek\"<\/a><\/p>\n
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.
\nHave a peek<\/a>. If you want the IDB file, have at it<\/a>.<\/p>\n
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.
\nFor now though, it seems someone else beat me to the punch<\/a>.<\/p>\n
Until then, stay safe and don’t trust anyone \/ anything from email.
\n\"1247938871381\"<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[7],"tags":[102,106],"_links":{"self":[{"href":"https:\/\/www.gironsec.com\/blog\/wp-json\/wp\/v2\/posts\/1047"}],"collection":[{"href":"https:\/\/www.gironsec.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gironsec.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gironsec.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gironsec.com\/blog\/wp-json\/wp\/v2\/comments?post=1047"}],"version-history":[{"count":10,"href":"https:\/\/www.gironsec.com\/blog\/wp-json\/wp\/v2\/posts\/1047\/revisions"}],"predecessor-version":[{"id":1106,"href":"https:\/\/www.gironsec.com\/blog\/wp-json\/wp\/v2\/posts\/1047\/revisions\/1106"}],"wp:attachment":[{"href":"https:\/\/www.gironsec.com\/blog\/wp-json\/wp\/v2\/media?parent=1047"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gironsec.com\/blog\/wp-json\/wp\/v2\/categories?post=1047"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gironsec.com\/blog\/wp-json\/wp\/v2\/tags?post=1047"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}