Office Macros – file extensions, file format (content), and a few handling stereotypes…

November 5, 2016 in Incident Response

Macromalware is omnipresent. It’s ironic, given the fact it was dormant for so many years… We can only guess that its renaissance can be attributed to the fact the number of internet users increased tremendously since early 2000s and pretty much all of them are not security specialists – as such are more gullible to fall a victim of many of the social engineering tricks employed by the malware authors…

Update: Regarding the reason for the renaissance of the macro viruses: after I posted this piece Dr Vesselin Bontchev (Vess) – the renowned antivirus researcher and one of the best experts in VBA analysis – offered an alternative explanation. It is pretty interesting: not only it’s convincing, but also highlights the fact the ‘security notifications’ offered by software (AV, Office, browsers, etc.) often do more harm than help. In our quick Twitter convo Dr Vesselin Bontchev mentioned that:

  • In Office 2000 Microsoft made a change that killed macro malware. By default, it would IGNORE macros not signed with trusted key. No notification, nothing. As if the macros didn’t exist. Killed macro malware flat (and it was very prevalent at the time). Sadly, later versions of Office started showing notifications, like the dreaded “Enable content” button. Macro malware came back.

Isn’t that amazing? I am in security business for a while, and I do ignore and get annoyed by all these nagging notifications. I don’t read most of them anymore and tend to click stuff to just ‘get it out of my way’. What about your average computer user? It’s UI fail that drives the security fail.

In this post I don’t want to analyze any malware, and I don’t want to talk about evasion, obfuscation, etc.

I want to talk about the file extension, file format, and how this thing is being perceived as ‘handled’ and… how it is really handled.

You see, I believe there exists a couple of misconceptions about the macrodocuments. One is that Office files are labeled as such by their file extensions. This is very true, but I want to show that this misconception opens a few more new paths the macrodocuments can enter the systems of the victims in the future…

Misconception #1

The macro document needs to be stored in a file with an extension .docm, .xlsm, etc. to work

Using these file extensions doesn’t hurt, but macrodocuments can be stored inside .doc or .xls files as well. So, blocking .docm, .xlsm, etc. file attachments won’t stop all the macrodocuments.

Misconception #2

Blocking the macro-specific attachments is a good solution to prevent the delivery of macro documents.

This is true in many cases, but it omits one fact: Office is very err… flexible :).

You can run the following commands to see what files are associated with Office programs on your system:

  • assoc | findstr /i “word”
  • assoc | findstr /i “excel”
  • assoc | findstr /i “powerp”

(these are not all, btw.)

Here’s an example result:

  • assoc | findstr /i “word”
    • .doc=Word.Document.8
    • .dochtml=wordhtmlfile
    • .docm=Word.DocumentMacroEnabled.12
    • .docmhtml=wordmhtmlfile
    • .docx=Word.Document.12
    • .docxml=wordxmlfile
    • .dot=Word.Template.8
    • .dothtml=wordhtmltemplate
    • .dotm=Word.TemplateMacroEnabled.12
    • .dotx=Word.Template.12
    • .odt=Word.OpenDocumentText.12
    • .rtf=Word.RTF.8
    • .wbk=Word.Backup.8
    • .wiz=Word.Wizard.8
    • .wll=Word.Addin.8
  • assoc | findstr /i “excel”
    • .csv=Excel.CSV
    • .ods=Excel.OpenDocumentSpreadsheet.12
    • .slk=Excel.SLK
    • .xla=Excel.Addin
    • .xlam=Excel.AddInMacroEnabled
    • .xld=Excel.Dialog
    • .xlk=Excel.Backup
    • .xll=Excel.XLL
    • .xlm=Excel.Macrosheet
    • .xls=Excel.Sheet.8
    • .xlsb=Excel.SheetBinaryMacroEnabled.12
    • .xlshtml=Excelhtmlfile
    • .xlsm=Excel.SheetMacroEnabled.12
    • .xlsmhtml=excelmhtmlfile
    • .xlsx=Excel.Sheet.12
    • .xlt=Excel.Template.8
    • .xlthtml=Excelhtmltemplate
    • .xltm=Excel.TemplateMacroEnabled
    • .xltx=Excel.Template
    • .xlw=Excel.Workspace
    • .xlxml=Excelxmlss
  • assoc | findstr /i “powerp”
    • .odp=PowerPoint.OpenDocumentPresentation.12
    • .pot=PowerPoint.Template.8
    • .pothtml=powerpointhtmltemplate
    • .potm=PowerPoint.TemplateMacroEnabled.12
    • .potx=PowerPoint.Template.12
    • .ppa=PowerPoint.Addin.8
    • .ppam=PowerPoint.Addin.12
    • .pps=PowerPoint.SlideShow.8
    • .ppsm=PowerPoint.SlideShowMacroEnabled.12
    • .ppsx=PowerPoint.SlideShow.12
    • .ppt=PowerPoint.Show.8
    • .ppthtml=powerpointhtmlfile
    • .pptm=PowerPoint.ShowMacroEnabled.12
    • .pptmhtml=powerpointmhtmlfile
    • .pptx=PowerPoint.Show.12
    • .pptxml=powerpointxmlfile
    • .pwz=PowerPoint.Wizard.8
    • .sldm=PowerPoint.SlideMacroEnabled.12
    • .sldx=PowerPoint.Slide.12

Now that we know potential file extensions, we can create a simple macro document and create its copies with the respective file extensions to see which of these clones will – when opened – execute macro.

For the WinWord, I saved a file in a new Office format .docm and then copied the file to have the very same file, just with different extensions. I also enabled the macros to ensure I can test it w/o warnings and quickly. Then I opened them one by one from Windows Explorer. Many of them didn’t work, but some of them did…

Files with these extensions executed the AutoOpen macro:

  • .doc
  • .docm
  • .rtf
  • .wbk

Additionally, Office ‘complained’ about these formats:

  • .docx, .odt

docx

Update: after I posted this, Vess created a nice POC showing that it is possible to bypass it by downloading and executing macro hidden inside a remote template file linked to a .docx file – the demo can be found here.

  • .dotm, .dotx

dotm

 

The very same experiment can be repeated with the WinWord macrodocument saved in the old OLE format, as well as Excel workbooks, PowerPoint presentations (new and old formats), and other files from the Office package.

I guess we can agree that the .rtf and .wbk extensions are a bit of a surprise… You will find some more surprises with Excel files. I strongly encourage you to experiment on your own – this is why I do not post all the results (I went through all file extensions I could find, it’s worth it!).

Misconception #3

The file handling is determined by its file extension.

Of course, we have already disproven it in the previous section. Office is a clever cookie and it tries to determine what the file is by its file format (by reading file content). This is why .rtf, and .wbk files open and execute macros even if they are not truly RTF or WBK formats.

There is more.

If you rename your macrodocument to have a completely different file extension f.ex. .foobar, or even none at all… you will still be able to run the macros – the only trouble is forcing the user to drag&drop the doc to Office application (or open it in some other way), but this is just a social engineer’s child play, given so much evidence showing what efforts user make today to run macros…

Misconception #4

Blocking macrodocuments = blocking attachments.

In the previous points we have demonstrated that we can bypass this attachment block by using a non-standard file extension.

Also, need to highlight that the actual macro code is embedded _inside_ the attachments. As long as the malware author can force the user to open the attachment, Word will recognize the macro code inside the attached file and it will execute it.

Misconception #5

We must block macros in the whole company.

I actually agree with that and it’s not a misconception per se. But the assumption it is easy certainly is.

The problem is that this is an extremely difficult, often practically impossible task, and first and foremost – a subject to a lot of testing and politics beforehand:

  • You are not blocking in one place, but in many places – diff. setups/configurations across many countries (politics&technology)
  • People still use VBA a lot (especially in Excel)
    • for business
    • for admin tasks
    • for learning purposes
    • for whatever else reason… they really do… there is still a huge community of VBA programmers and these individuals work for many large orgs; can’t just disable their toy w/o causing a lot of issues
  • Apart from blocking, you need to ensure people cannot re-enable it
  • And last but not least… the ownership of change management
    • It’s perhaps less obvious, but enabling will happen sooner or later; in such cases exclusions are often added first per user, but as there is more and more demand and less and less time – per business unit, and larger user groups; some may be even done on emergency basis (customer sent a report that relies on VBA, and you just need to see it ASAP); over years this may create a significant user group with the macros enabled…

Beyond good ol’ Run key, Part 48

October 21, 2016 in Anti-Forensics, Autostart (Persistence), Forensic Analysis, Incident Response, Malware Analysis

I have just updated my very old post about HKLM\SOFTWARE\Microsoft\VBA\Monitors. I discovered its additional ‘properties’ while looking at the VBE (Visual Basic Engine). On the way, I have also discovered that Visual Basic for Application’s old-school IDE allows programmers to create Add-ins. A quick googling followed and I immediately found a number of Addins for VBE – I was actually quite surprised that there are so many!

Seriously, there is a huge interest in it! With all the C, Java, python programmers out there… it would seem that VBA is strong and here to stay…

So, anyway… I didn’t spend much time on it as many programmers already provide good examples of VBE Add-ins, so I will just document where to find the possible persistence entries.

The Add-ins are discovered by VBE by enumeration of the following key:

  • HKCU\Software\Microsoft\VBA\VBE\6.0\Addins\<AddInName>\…

Each Add-in has a dedicated subkey where it lists the properties:

  • Description – Full description
  • FriendlyName – Short name
  • LoadBehavior – A DWORD that indicates whether the Add-in is loaded at startup (1), is currently unloaded (0)
  • SatelliteDllName + SatelliteDllPath  – references to localized information about the plug-in

So, anyone wanting to load the VBE Add-in needs to set up the Registry key with the aforementioned values, and then create the appropriate entries under HKCR:

  • HKCR\<AddInName>\Clsid = <GUID>
  • HKCR\CLSID\{<GUID>}\InprocServer32 = …