According to researchers, a new version of the Hancitor downloader has abandoned its previous tactics and is currently relying on new obfuscation techniques and dropping strategies.
Palo Alto Network experts are now monitoring the biggest Hancitor wave since June. However, it has replaced its H1N1 downloader with the Vawtrak and Poly payloads, which it`s currently distributing. This particular version is using native API calls within Visual Basic (VB) code to carve out and decrypt attached malware from malicious Words 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.” – said in a report the senior threat researcher at Palo Alto Networks, Jeff White.
White points out that what surprised them was not the usage of the Word documents, which standardly execute the malicious macro script when “enable editing” is allowed. In fact, what drew researchers` attention was the technique dropping the malware together with the relationship it discovered between Hancitor’s Visual Basic macros and embedded shellcode.
“This was the first time we’ve seen (this dropping technique) used in this way.” – White said.
Typically, droppers are relying of MS office documents which have an executable inside of them or download one if they don`t. And yet, Hancitor uses neither of these two tactics. Instead, it embeds the executable into the Visual Basic for Application and decodes and executes the function on its own, explains Ryan Olson, a researcher at Palo Alto Networks Unit 42 team.
“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.”
Another thing which is worth mentioning is the macro`s ability to define the host`s system architecture and whether the OS is 64-bit or 31-bit, due to a logic it contains.
“What is really interesting is that the authors went through the trouble to actually write their own base64 decoder purely in VB.” – White adds.
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 explained.
Once the code is copied to the executable WINWORD.EXE process memory, the macro makes the last API call for CallWindowProcA. These actions redirect code execution to shellcode. Then the shellcode is directed to load shellcode values and seek out the malware binary. After that the binary is encrypted and only decrypted after a number of sub-routines are executed. Next, the binary is placed in the temp directory, which then ends up writing itself to “%SYSTEMROOT%/system32/WinHost.exe”. According to White, then the Hancitor downloader has been fully loaded on the victim’s PC.
“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.”– notes White.
