I was playing around in Word yesterday and thought of a neat idea. To start off, what I am about to show you will blow away any user set macros in Normal.dotm. That being said, this is kind of cool.

Let me start with all of the code. Everything you need to setup and execute this attack can be found here:

https://github.com/enigma0x3/WordPersistence

**You will need to host Invoke-Shellcode, the malicious Normal.dotm and persist.ps1 for this to execute correctly**

**It is also important to note that you MUST create the malicious Normal.dotm by opening a new word document, creating a new macro, pasting in the code and then saving it as Normal.dotm. Once created, you can then host it.

The way this works is like so: You craft an excel document and send it off to the target. They open said document and it executes a payload. While you are sitting there with your meterpreter session, it does the following:

1. It changes the macro security settings in Word/Excel

2. It creates a registry key that executes the hosted persistence script on startup

3. It drops a malicious Normal.dotm in C:\Users\{username}\AppData\Roaming\Microsoft\Templates

If you don’t know, Normal.dotm is the base template for all Word documents. If a macro sits in it, it executes EVERY SINGLE TIME Word is opened. Now, let me show you!

To start off, create your macro with the code on Github and send it. Once opened, here is what happens:

1. You get your shell

2. It then disables the macro security settings so the malicious Normal.dotm macro can execute on startup (and also changes the Excel settings just because)

————————————————————-AND BAM————————————————————————-

3. It also drops a malicious Normal.dotm (overwrites the old one) in C:\Users\{username}\AppData\Roaming\Microsoft\Templates

NOTHING FISHY HERE 🙂

**This new Normal.dotm file has a macro called AutoExec that executes our new payload. This payload will execute whenever word is opened or in this case, it gets called on startup by persist.ps1.

4.  Finally, a registry key is created that executes persist.ps1 that you are hosting. What happens is on startup, persist.ps1 opens a new WINWORD instance pointing to Normal.dotm (which is now malicious) and tells it to execute the AutoExec macro. Once done, it quits. All of this happens in the background.

When the user reboots, it executes persist.ps1 (even though it isn’t on disk) which calls Word to open Normal.dotm…all done in the background. Next thing you know, you are having a shell party. WEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE

I hope you enjoy.

-Matt Nelson (@enigma0x3)

The Java Signed Applet attack is a very well known and used Social Engineering attack vector for getting reliable code execution on a system. As many of you may know, Oracle recently released an update that prevents self-signed applets from executing. Because of this, this attack just got a little more difficult to execute. In my opinion, this attack vector is close to dead. As a result, Pentesters will need to start looking at other reliable methods for getting code execution through Social Engineering. I have done a little work on this over the past few weeks, so I figured I would put all the information in one place.

This attack technique leverages Invoke-Shellcode. You have 2 options when using this attack. You can either host Invoke-Shellcode, or you can use @mattifestation‘s PowerSploit module and embed Invoke-Shellcode within the macro. Here’s an example:

Out-EncodedCommand -ScriptBlock ([scriptblock]::Create((ls Function:\Invoke-Shellcode).Definition + “Invoke-Shellcode -Shellcode (@(1,2,3)) -Force`n`n”)).

If you haven’t looked at PowerSploit, check it out. It is a great tool.

1. Disable Proxy Settings

This macro disables any proxy settings, executes a payload and then persists by adding 2 scheduled tasks. One executes a payload after 30 minutes of idle time and the other kills any proxy settings after 30 minutes of idle time. This macro will take care of any troublesome proxies.

The code for this can be found here:

https://github.com/enigma0x3/Office-Client-Side-attack/blob/master/ProxyMacro

And a walk-though can be found here:

https://enigma0x3.wordpress.com/2014/01/15/new-feature-added-to-powershell-payload-excel-delivery/

2. Persist with Scheduled Tasks

This macro simply executes a payload and then persists by scheduling a task that executes a new payload after 30 minutes of idle time.

The code can be found here:

https://github.com/enigma0x3/Office-Client-Side-attack/blob/master/SchTasksMacro

And a walk-through can be found here:

https://enigma0x3.wordpress.com/2014/01/11/using-a-powershell-payload-in-a-client-side-attack/

3. Web Persistence

This macro executes a payload and then creates a registry key that executes a hosted persistence script. This persistence script basically goes out and checks the set website for the set keyword. If the keyword is found, it executes a new payload.

The code can be found here:

https://github.com/enigma0x3/Office-Client-Side-attack/blob/master/WebPersistenceMacro

And a walk-through can be found here:

https://enigma0x3.wordpress.com/2014/01/17/command-and-control-using-powershell-and-your-favorite-website/

4. Persist by dropping malicious Normal.dotm and calling it on startup:

The code can be found here:

https://github.com/enigma0x3/WordPersistence

And a walk-through can be found here:

https://enigma0x3.wordpress.com/2014/01/23/maintaining-access-with-normal-dotm/

Hopefully this can be of some use. Let me know if you have questions or problems. *RIP Signed Java Applet Attack*

-Matt Nelson (@enigma0x3)

To start out, I have to give HUGE credit to @scriptmonkey_ for posting this amazing article. I’m sorry Microsoft didn’t listen to you…hopefully this enforces it a little bit.

**This method is only good for cases where there is a 2nd route out of the network or the organization allows outbound connections outside of the proxy.**

I was lurking on Twitter yesterday when I ran into a retweet of this post. In a nutshell, it describes how you can disable proxy settings that are managed via Group Policy. I have heard (keep in mind, I’m 20 and have no pentest experience) that getting a shell out when there is a proxy in the way can be a little challenging. Because of this, I decided to implement this into both the macro and the persistence task. That way, whenever you want your shell, the proxy will be disabled. Here is how it works:

In most organizations, you will see this on all the workstations:

They have some proxy configured via group policy and disallow any changes. This can be kind of a pain (so I have heard).

*If you want to recreate this, you can find instructions on how to disable changing Automatic Configuration Settings here

So first, let’s create our document. I have updated the Macro code, which has 2 new functions. The first one (Proxy) disables the proxy for the initial shell, and the 2nd one (ProxyKillTask) schedules a task that disables it when the computer is idle for 20 minutes. If the user reboots and the proxy settings return, this will disable it again before your persistent shell kicks off.

1. Create your document using the updated macro provided at https://github.com/enigma0x3/Powershell-Payload-Excel-Delivery/blob/master/MacroForProxies and send it.

2. Now let’s set the scene of the victim. This is going to take place under a non-privileged account with proxy settings managed by Group Policy.

Once the document arrives in the user’s inbox, it will be opened. Once opened, here is what happens:

1.  The first thing the macro does is disable the proxy. It does this before it executes the payload to ensure there is no proxy standing between you and the target.

2. Once disabled, it executes the payload.

3. Once executed, it schedules a task to persist on the machine (called Windows Update). This is nothing new and you can read about it here if you wish to know more.

4. Right after that, it schedules another task and calls it Microsoft Update.

What this task does is simple. It calls powershell.exe to edit the DefaultConnectionSettings key located in HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections. What you need to know is this:

The proxy settings are determined by the 8th place in the data set. If a proxy is on, you will see a value other an 00 or 01. To break this down a little more, the 8th place will show 09 when “Automatically detect Settings” is checked for IE proxy settings:

Now if you set “Use automatic configuration script” (if there is a .pac or something involved), it will read differently:

What the macro and persistence task do is basically use Powershell to read the contents of the key and then replace the 8th value of the array with a 01. (01 is value for no proxy). After the macro runs, we will find this:

As you can see, this completely disabled the proxy on the machine, allowing for a direct bypass of whatever that proxy was designed for.

I hope you find this useful! I also hope Microsoft get’s their stuff together as this is definitely a security flaw.

-Matt Nelson (@enigma0x3)

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)