Hancitor Maldoc Bypasses Application Whitelisting

Published: 2016-11-06
Last Updated: 2016-11-06 17:39:29 UTC
by Didier Stevens (Version: 1)
6 comment(s)

For about two months I've seen malicious documents dropping Hancitor malware with the following method: VBA code injects shellcode in the Word process, this shellcode extracts an embedded EXE from the Word document to disk, and executes it.

Recently I found a variant that no longer writes the EXE to disk, but runs it with a technique called process replacement or process hollowing.

This sample (MD5 B107F3235057BB2B06283030BE8F26E4) contains VBA code that extracts encoded shellcode from a form property, injects it in the Word process and runs it. The shellcode contains both 32-bit and 64-bit code. If the Word process is a 32-bit process, the VBA code will execute the 32-bit shellcode, else if it is a 64-bit process it will execute the 64-bit shellcode.

The encoded, embedded EXE is embedded in the Word document via a PNG image. The encoded EXE is appended to a 1-pixel PNG image, which is inserted in the Word document. The EXE is base64 encoded, and then each base64 character is XORed with 15 and then has 3 subtracted from it. The encoded EXE is prefixed by string STARFALL followed by 4 bytes (2 bytes contain the size of the encoded EXE, 0x5AAC).

The EXE is a 32-bit application (MD5 CDCD2CA36ED9A2B060DD4147BC5F7706).

The 32-bit shellcode does a egg-hunt for string STARFALL, skips 4 bytes and then starts to decode the encoded EXE to memory. The size of the encoded EXE is hardcoded in the shellcode, it is not read from the 2 bytes prefix.

Then the shellcode proceeds with starting a new, suspended process (CreateProcess). If the 32-bit shellcode is running on 32-bit Windows, then the process that is created is %windir%\explorer.exe. If the 32-bit shellcode is running on 64-bit Windows, then the process that is created is 32-bit svchost.exe (%windir%\SysWOW64\svchost.exe). This host process is hollowed by removing the code mapped at the base address of the embedded EXE (ZwUnmapViewOfSection), new memory is allocated at the base address of the embedded EXE (VirtualAllocEx) and the PE header and sections of the embedded EXE are written to that newly allocated memory (WriteProcessMemory). Next the context of the suspended thread is modified by changing register EAX to the value of the entrypoint of the embedded EXE (GetThreadContext and SetThreadContext). Finally, the suspended process is started (ResumeThread).

The result of this process replacement is that the embedded, malicious EXE executes in stead of explorer.exe (or svchost.exe). Application whitelisting technology does not prevent the embedded EXE from running, because a whitelisted application was loaded (explorer.exe or svchost.exe).

Most anti-virus will not detect the embedded EXE because it is never written to disk.

The 64-bit shellcode does almost the same as the 32-bit shellcode, except that it always launches 32-bit svchost.exe.

If you want to know more about the tools I used to extract the shellcode and EXE, read my blog post Maldoc With Process Hollowing Shellcode.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Keywords:
6 comment(s)

Comments

Hi,

does EMET with the standard settings actually prevent this process hollowing by killing the affected processes? Bypassing app-whitelisting is worrying, even more worrying would be a variant that stays undetected even in EMET.
EMET protects the Word process from the injected shellcode by detecting the export address enumeration the shellcode does (EAF). But this can be bypassed.

EMET does not protect the host process (explorer.exe).
Microsoft has officially EOL'd EMET:

https://blogs.technet.microsoft.com/srd/2016/11/03/beyond-emet/

“Finally, we have listened to customers’ feedback regarding the January 27, 2017 end of life date for EMET and we are pleased to announce that the end of life date is being extended 18 months. The new end of life date is July 31, 2018.”

And they're doing it a year and a half before the EOL date for Windows 7, which means this is just another nudge to get people moving to Windows 10 sooner. Otherwise they would have killed it on the same date.
Hey D – I manage a Hancitor decryptor @ https://github.com/pan-unit42/public_tools/blob/master/hancitor/h_decrypt.py – might be useful. They’ve also moved on from STARFALL to BULLSHIT and changed the maldoc API’s twice since this variant.
thank for sharing this! I understand that the initial payload can bypass app whitelisting through the process hollowing technique. Are they able to maintain persistence and in your experience have you seen if the subsequent payloads that get downloaded also bypass whitelisting, without writing to disk and running using the same technique?
I wrote this diary entry because it's the first time I see this in a maldoc in-the-wild. So I can't rely on experience to tell you what such documents usually do.

There has been malware in-the-wild that achieves persistence without writing executables to disk.

Diary Archives