Home › Content

VBA Macro analysis: Beware of the Shift Key!

Mon, 12/05/2016 - 06:30 — decalage

Many malware analysts like to use the VB Editor in MS Word or Excel to analyze malicious macros, because it provides a nice debugging environment. It is a convenient solution to run VBA code in its native context, in order to unmask heavily obfuscated macros.

Holding the SHIFT key

To achieve this, it is necessary to press the "Enable Content" button, and then Alt+F11 to open the editor and access the VBA source code. The well-known trick is to hold the SHIFT key down while opening the document/workbook, until Enable Content is pressed. The Shift key disables automatic macro triggers such as Document_Open or AutoOpen, which are used as entry points in most malicious macros.

It is then possible to study the source code without being infected, to set breakpoints or to replace the dangerous statements by innocuous ones, and to run the code step by step to understand its behaviour.

Issue 1: The SHIFT key only works when it is pressed

What is less known, is that it is not sufficient to press the Shift key only when opening a file. The Shift key is only producing its effects when it is pressed. Therefore, if a macro uses other triggers such as Document_Close, it may run its malicious payload when the file is closed, unless the analysts does not forget to press the Shift key again, while closing the file...

To test it, you may simply create a Word document with the following macro. Then close it, and reopen the file while pressing the Shift key. The Document_Open message should not show up. Now release the Shift key, and close the document: the Document_Close message will appear.

Private Sub Document_Open()
    MsgBox "Document_Open"
End Sub
Private Sub Document_Close()
    MsgBox "Document_Close"
End Sub

Issue 2: ActiveX triggers

In August 2016, some malware authors started to use obscure ActiveX objects such as InkPicture in their macros:

It turns out that ActiveX objects can generate events that trigger VBA macros. Some of those events, such as InkPicture_Painted, are triggered as soon as a document/workbook is opened, once "Enable Content" was pressed. Many other ActiveX objects can trigger various events that can be exploited to run malicious macros:

According to my tests with recent versions of MS Word (2016 and 2013), ActiveX object events are NOT disabled when the user holds the Shift key down.

It means that there is no simple way to open a malicious document using ActiveX triggers in MS Office, to analyze it with the VB Editor without running the payload.

Bottom line: Do NOT trust the Shift Key!

Solutions?

First, I would say it is not a good idea to open a suspicious file in MS Office applications, without reviewing the VBA source code beforehand. The safest solution is to start by extracting the VBA code using tools such as oledump or olevba. See this article for more information.

Then, review the code to identify all potential entry points, and especially the ones that may bypass the Shift key trick. olevba may help for this, by showing you the list of known entry points (tagged with "AutoExec" in the first column of the table below):

If all entry points are similar to Document_Open or AutoOpen, then you may open the file in MS Office, and press "Enable Content" while holding the Shift key down.

If not, then you may try the following steps:

  1. Save the VBA macro code from olevba or oledump into a text file.
  2. Open the suspicious file in MS Office, WITHOUT pressing "Enable Content".
  3. If you are in Protected View, click on "Enable Editing".
  4. Go to the FILE menu.
  5. Click on "Save As" and save the file in a macro-free format, such as "Word Document (.docx)".
  6. Close the application.
  7. Verify that the new file does not contain any macro, using olevba or oledump.
  8. Reopen the macro-free file that you just saved.
  9. If there are ActiveX objects, you may need to press "Enable Content". SInce macros have been removed, it should be safe.
  10. Open the VB Editor using Alt+F11.
  11. Copy and paste the VBA code that you extracted at step #1 back into the document, procedure by procedure. Identify were the macro runs code, and replace those statements by MsgBox or something innocuous.
  12. Your document is now ready to be analyzed and deobfuscated, using the debugging features of the VB Editor.

Another nice side effect of this methodology, is that it works even if the VBA Project is protected by a password.

Please contact me if you know other tricks to adress the limitations of the Shift key.