Keep in mind, I’m a student and have NO experience in penetration testing…so if my vocabulary is off or I start talking about something that is incorrect, I do apologize. I am always looking to learn 🙂

I am a firm believer in Office Macros for getting reliable code execution on a target system…especially since remote exploits are less common and people are resorting to client-side attacks instead…and Microsoft Office is being used in the majority of organizations, as well as its macros. Most people like to rely on actual exploits…I find this difficult.

Sometimes, it is hard to get a quick and accurate reading on what software and versions are being used on workstations in an organization. This can cause a problem when trying to use attacks that require an exploit (that being a browser exploit or an exploit in an application running on the machine), especially if you are attempting to simulate a targeted attack. There are some VERY reliable methods, such as the Java Applet attack from the Social Engineering Toolkit (This is an amazing attack and toolkit by @HackingDave, so check it out!)…but I am starting to notice that organizations are leaving Java completely out of their standard computer builds, which is required for the Java Applet attack to work. I did a little looking around, and found methods of getting access without an exploit, such as using office macros that contain shellcode. I took a look at these methods, and it does require a little work to get these finished documents passed an organization’s perimeter defenses and into the inbox of the target since the macro often contains the shellcode itself.

All of this can now be done by using Windows Powershell (which is installed on all Windows 7 machines and cannot be removed). I noticed that Matt Graeber (@mattifestation) released some great work that helps us use Powershell in an offensive manner. What I came up with takes Matt’s Invoke-Shellcode and uses it to execute a Powershell payload in memory. It then persists on the system by creating a task in the Task Scheduler that also uses Invoke-Shellcode to execute the payload on the system again. It took a lot of work (thanks to the hell that is Powershell quotes), but here it is:

*The macro code can be found over at https://github.com/enigma0x3/Powershell-Payload-Excel-Delivery/blob/master/MacroCode

* Matt Graeber’s Invoke-Shellcode can be found at https://github.com/mattifestation/PowerSploit/blob/master/CodeExecution/Invoke-Shellcode.ps1

1. First we create the macro. There are 2 functions within the macro…the first gets us initial access to the system by using Powershell to execute our payload. The second function uses Powershell to schedule a task that uses Powershell to re-execute our payload after the computer has been idle for 20 minutes. (Keep in mind that Windows checks idle time roughly every 15 minutes)

2. As long as the IP and port in the macro match your listener, all you need to do is send the document off. I recommend using a 32 bit payload as Invoke-Shellcode will determine the target’s architecture and execute accordingly. When you go to save it, make sure it is either a macro enabled document or an Excel 97-2003 workbook. Microsoft Office defaults macro security to “Disable all macros with notification”, meaning they will get this when they open it:

You can apply some SE into this in order to get them to click “Enable”.

3.  Once they click enable, the deed is done. It is important to note that when you get your shell back, you are running in the powershell.exe process. In other Office Macro attacks, you were put into the office process (such as excel.exe or winword.exe) and had to migrate out of that process before the user closed the document if you wanted to keep your shell. This attack lands you in the powershell.exe process, meaning they can close the document and you will keep your shell. Powershell.exe is also running as a stable process, meaning there is really no need for migration (which is good because AV can catch migrating). As long as the user doesn’t log off or reboot, the process stays open and you have your shell.

4. At this point, the user has no idea what is going on. There are no popup boxes or triggers that could alert the user that something malicious has happened. Everything is done in the background. Right after the user clicks “Enable” or opens the document, the shell comes in, the task is created and the box is owned. Note that the task is created with the name “Windows Update” and it simply calls Powershell to use Invoke-Shellcode to re-execute our payload.

Forensics wise, this attack is pretty clean. It doesn’t touch disk at all and it uses already integrated windows components to both compromise the machine as well as persist on it. You can also encode the Powershell commands if you would like.

I have to give a huge thanks to Matt Graeber (@mattifestation) for releasing Invoke-Shellcode. You can find his work here: https://github.com/mattifestation

I also have to give great thanks to Raphael Mudge (@armitagehacker) for his very helpful blogpost about persistence using schtasks.exe…it helped make the Powershell quotes a little bit less of a pain in the ass. You can find his blog here: http://blog.strategiccyber.com/

And of course OJ (@thecolonial) for helping me get the DOS popup to go away when executing the payload 🙂

-Matt Nelson (@enigma0x3)