Code execution in Microsoft Word is easier than ever, thanks to recent research done by Etienne Stalmans and Saif El-Sherei. Executing code in MS Word can be complicated, in some cases requiring the use of Macros or memory corruption. Fortunately, Microsoft has a built in a feature that we can abuse to have the same effect. The best part, it does so without raising any User Account Control security warnings. Let's look at how it's done.
Using Microsoft documents to deliver a payload is as old as Word itself, and over the years many different attack vectors have been explored. Some examples are macros, add-ins, actions, and Object Linking and Embedding (OLE). They were all plagued by one problem though, security alerts.
Wouldn't it be nice if Microsoft was kind enough to build us a "feature" that would let us get around those pesky security alerts? Luckily for us, they did, Dynamic Data Exchange. Although it wasn't intended for that, of course.
Windows provides several methods for transferring data between applications. One method is to use the Dynamic Data Exchange (DDE) protocol. The DDE protocol is a set of messages and guidelines. It sends messages between applications that share data and uses shared memory to exchange data between applications. Applications can use the DDE protocol for one-time data transfers and for continuous exchanges in which applications send updates to one another as new data becomes available.
To put that in simple terms, DDE executes an application and sends it data. We can use it to open any application, including command prompt, and send it data, or in our case, code.
This means we can create a Word document that runs code on opening. What code you run is up to you!
You can just use this to scare friends as a simple prank, or you could use it to install a Remote Access Tool like Pupy. It only takes a few seconds to modify a Word document, so let's see how it's done.
Begin by opening a new Word document. Now, we need to do some social engineering. Conversely, if you happen to have access to the target's computer, you can open a recent document of theirs that they are likely to open again. If you do that, you can skip the rest of this step.
While the user will not get any security warnings, there will still be two pop-ups they get when they open the document. They also need to say yes to both for the code to execute. A previous article on Word hacking went over some social engineering tricks we can use.
This social engineering attack takes advantage of the fact that the user can see the document when the pop-up appears. This lets us put something at the top of the document to make the document appear more legitimate to the user.
Below are two examples of documents used to get a user to enable macros. Our attack doesn't require macros to be enabled, but these are excellent examples of making a document appear legitimate.
Now that we have some social engineering in place we are ready to move on to adding a field.
The field will contain the code we are going to execute, so we need to find a good place for it. The most important thing to consider here is whether or not it matters if the user finds your code.
Without further inspection, all they will see is "!Unexpected End of Formula," which could be worked into the social engineering attack. Depending on your situation, try to place it somewhere appropriate. Placing it at the very bottom of the document is a good choice, or if it is a longer document, bury it in the middle somewhere.
Once you have your place selected, go to the top left and click the "Insert" tab and then look for "Quick Parts" on the right side of the bar, it's exact location may be slightly different depending on which version of Word you are using.
Then click "Field" and you should get a pop-up box.
In the pop-up make sure "= (Formula)" is selected and click "OK."
After the last step, you should have had "!Unexpected End of Formula" appear within the document. That is our field, but to put code in it, we need to toggle it. Do so by right-clicking the field, and then clicking "Toggle Field Codes," which should change the appearance of the field.
Now you should see something like this.
Replace "= \*MERGEFORMAT" with the following:
DDEAUTO c:\\windows\\system32\\cmd.exe " "
As you can probably guess, DDEAUTO is telling Word that this is a DDE field, the auto part tells it to execute upon opening.
After that comes the path it should take, which allows us to direct it to any PE. The final part, within the quotation marks, is the arguments to pass to the executable. For testing purposes, we can pass cmd.exe arguments to launch a calc.exe.
DDEAUTO c:\\windows\\system32\\cmd.exe "/k calc.exe"
Thit will use cmd.exe to launch calc.exe, but you can test it with something a little more entertaining. The following will open Chrome to a screaming video to give your victim a good hard spook.
DDEAUTO c:\\windows\\system32\\cmd.exe "/k start chrome --new-window http://akk.li/pics/anne.jpg"
In the end, you should have something that looks like this.
Once everything is in place, we are ready to save the file. Press Ctrl + S to save, then save it anywhere as a ".docx" file, which is the standard for Word.
When opened, the user will need to say yes to two pop-ups. The first is about updating the document links, which shouldn't strike the average user as suspicious.
The second one might draw some attention from the more security-minded users, as it asks them about starting an application.
If all goes well and the user says yes to both, then the code will execute at this point and your target will do a fright to themselves.
Today we've looked at a quick and simple way to cause code to execute when a word document is opened. While this isn't unique, what is special about this attack is that the word "security" is never mentioned, allowing a much greater chance of a social engineering attack succeeding.
If you're a Windows user, you should be careful of these and other warnings that may indicate another program is attempting to execute, or that a file is either requesting outside recourses or needs unusual permissions to run. In all of these instances, your default reaction to a window like this popping up should be to deny permission.
While in this guide we only looked at a simple proof of concept tests, it wouldn't require much modification to make this very dangerous. All this goes to remind you that a single slip-up in the opening of a Word document can lead to a huge headache, or in this case, a frightfull spook.
Thanks for reading! If you have any questions, you can ask here or on Twitter.