Researchers said a new variant of the Hancitor downloader has shifted tactics and adopted new dropper strategies and obfuscation techniques on infected PCs. Researchers at Palo Alto Networks are currently tracking the biggest push of the Hancitor family of malware since June that it says has shifted away from H1N1 downloader and now distributes the Pony and Vawtrak executables.
The variant uses native API calls within Visual Basic code to carve out and decrypt embedded malware from malicious Word documents.
“Lures were expected, until we started digging into the actual documents attached and saw an interesting method within the Visual Basic macros in the attached documents used for dropping the malware,” wrote Jeff White, senior threat researcher at Palo Alto Networks, in a report.
White said that there is nothing remarkable about the MS Office OLE2 Word Document that uses a standard ploy pushing recipients to “enable content” and run the malicious macro. Rather, what interested researchers was the technique used to drop the malware along with the relationship it discovered between Hancitor’s VB macros and embedded shellcode.
“This was the first time we’ve seen (this dropping technique) used in this way,” White said.
Ryan Olson, researcher at Palo Alto Networks Unit 42 team, explains that droppers typically use Office documents that either download an executable or have an executable inside of it. In this case Hancitor embeds the executable into the VBA and decodes and executes the function on its own.
“When you have embedded code inside an Office document you open up more risk of being detected by an antivirus program,” said Olson in an interview with Threatpost. “With Hancitor the code is embedded in the VB that encrypts it in a way that the AV isn’t going to find it. In this case they are using CallWindowProcA instead of ShellExecute or CreateProcess which an AV program will likely see.”
Noteworthy is the fact the macro contains logic that can determine host system’s architecture and whether the OS is 32-bit or 64-bit. “What is really interesting is that the authors went through the trouble to actually write their own base64 decoder purely in VB,” White said.
In a complex chain of events centering around API calls tied VirtualAlloc, RtlMoveMemory, and CallWindowProcA, the VB macro runs through several stages.
“The macro base64 decodes the payload into a local byte-array and then we come to our first API call, VirtualAlloc… Afterwards, the VB macro continues to setup the next call to RtlMoveMemory and then calls it with the location of the memory from the previous call and our base64 decoded byte array,” White said.
After code has been copied to the executable WINWORD.EXE process memory, the macro sets up the last API call for CallWindowProcA. These actions redirect code execution to shellcode, White said.
From here, the shellcode is directed to load shellcode values and seek out the malware binary. The binary is encrypted and only decrypted after a number of sub-routines are executed. Next, it places the binary in the temp directory, which then ends up writing itself to ‘%SYSTEMROOT%/system32/WinHost.exe’. At this point, the malicious Hancitor downloader has been fully loaded on the victim’s machine, according to White.
“From the encoded shellcode within the macro and using native API calls within VB code to pass execution to carving out and decrypting the embedded malware from the Word document, it’s a new use of Hancitor that we’ll be following closely,” White notes.
