MalwareSoup

Thoughts on cyber threat intelligence, malware analysis, and other things

New Obfuscation Layer in Hancitor

The Hancitor downloader is known for leveraging malicious macros embedded in Microsoft Word documents to deliver various payloads. It has been most often seen delivering the well-known Pony info-stealer, but often distributes additional payloads like zLoader, and previously Vawtrek.

Hancitor is also known for its author's frequent modifications. Examples include changes in the Windows API calls used in malicious macros to execute shellcode, targeting different legitimate process for injection, and the recent addition of encrypting C2 information that was previously stored in clear text.

In a new modification first observed (well, first observed by me anyway) today, Hancitor has added a new layer of obfuscation by further encoding the binary that is injected into new processes.

The sample used for this post is available here

Hancitor's Method of Process Injection

A Hancitor infection begins with a malicious Word document that includes some macro code and a hidden form. The macro will decode shellcode embedded in one of the form's elements and then use a series of Windows API calls to write the code to memory and shift execution to the newly written code.

The shellcode is designed to locate an encoded binary in memory using a pre-defined string. Once the code has been located, it will be decoded, and written to memory where it will be associated with a new process. In previous samples this new decoded binary was a fully formed PE32 executable that could be dumped from memory and further analyzed in your debugger of choice.

Recent Changes

In the most recent sample, the dumped binary will not run without some modifications. When Hancitor allocates space in memory for its decoded binary it assigns memory protection allowing for read, write, and execute (RWE). However, typical executable regions allow for RE only. For previous versions of Hancitor this didn't really matter because the code wasn't self-modifying. This new sample, on the other hand, includes a stub for decoding a chunk of itself. The new binary includes a check to verify the permissions and will simply terminate if it fails.

If we try to patch and just skip that check, the decoding stub will begin and we'll trigger an access violation. To get around that problem, we can just open the memory map in OllyDbg and locate the memory region we're dealing with - 0x0041000 - and set the access level to full. This is only necessary if the binary has been dumped from memory before the new process was actually resumed. Had I allowed the shellcode to execute and spawn the new process with the appropriate permissions, it would have executed without triggering any errors.

Now we can continue debugging and see the decoding routine in action.

The decoding routine above will decode the necessary code so you can continue debugging the rest of the binary.

Hint - from here, set a breakpoint on CryptDecrypt and run the sample to decrypt the C2 information

Stay tuned for a more in-depth post on the evolution of the Hancitor downloader over time.