Updated 20 October: Added a note regarding enabling full command line logging for process creation events; added a note clarifying that "Creator Process Name" is only recorded in Windows 10 and Windows Server 2016. Older versions of Windows record the creator process ID but not the process name; added references to a variety of exploitation techniques found by other researchers or seen in the wild.
Updated 11 October: I originally wrote that this exploit technique bypassed both disabled macros, and Protected View. That is incorrect: this technique will work if macros are disabled, but the code does not trigger while in Protected View. Thanks to Matt Nelson (@enigma0x3) for pointing out my mistake.
I love reading exploit techniques that rely on native features of the operating system or common applications. As an attacker, I find it diabolically clever to abuse features the target fully expects to be used and cannot turn off without disrupting business. As a defender, I am intrigued by the challenge of detecting malicious use of perfectly legitimate features.
Researchers Etienne Stalmans and Saif El-Shereisuch of Sensepost wrote of a slick way to execute code on a target computer using Microsoft Word - but without the macros or buffer overflows usually exploited to this end. Instead, they use dynamic data exchange, or DDE - an older technology once used for coding and automation within MS Office applications. This is particularly clever because it works even with macros disabled - because it's not using the macro subsystem.
There are no "security" warnings for the user, as such, although there is a prompt asking if the user wants to start the application specified in the command. The authors suggest is is possible to tweak the command syntax to suppress this popup.
Edit: Several researchers have demonstrated not eliminating the popup, but rather changing the text to seem less suspicious:
{ DDEAUTO c:\\windows\\system32\\cmd.exe "/c calc.exe" }After saving the file, merely opening the file triggers the above two pop-up notices, then launches the Microsoft Calculator app. Of course, Calculator is not malicious - it merely demonstrates the exploit. I could put anything else I wanted in the command instead.
But I'm a defender. I'm not one to stop at popping calc. I want to detect it too.
Microsoft Office with its default settings keeps a record of popup messages in the Windows Event Log. In Windows Event Viewer, in the Applications and Services Logs folder, in the Microsoft Office Alerts channel, there is now an event 300. The message body contains the text "Do you want to start the application c:\windows\system32\cmd.exe" - a dead giveaway that an Office application launched something.
While there are legitimate reasons for Office apps to launch other programs (custom-built business apps, for example), those can generally be cataloged; anything outside that catalog of legitimate Office-based applications is suspicious.
But back to my earlier point: the authors said it is possible to adjust command syntax to eliminate this popup alert. No popup means no alert to record in the Microsoft Office Alerts channel.
Ahh, but a program still started. As Austin "malware archeologist" Michael Gough is fond of saying, malware can hide - but it must run. His website has a set of fantastic "cheat sheets" that belong in every Windows administrator's back pocket.
Windows has optional features to keep a detailed log of every program or process that ever starts - but only if you take the time to set up process auditing. Microsoft published a guide to enabling process auditing using Group Policy Objects, a handy feature of Active Directory environments that makes it easy (well, easier) to apply configurations to an entire enterprise at one time.
But not every small business or home office uses Active Directory. In fact, the system that I tested this scenario on runs Windows 10 Home, which doesn't even have the graphical policy editor for managing policy settings. But it still has the underlying features.
To enable detailed tracking of process creation, including the complete command line with parameters, on any Windows system not managed by an Active Directory domain, run the following commands in a Windows command prompt running with administrator rights:
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit /f /t REG_SZ /v ProcessCreationIncludeCmdLine_Enabled=1
auditpol /set /Category:"Detailed Tracking" /subcategory:"Process Creation" /success:enable /failure:enable
reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f
The first command inserts a registry value that tells Windows to track the complete command line including any parameters; the second command enables process creation tracking. The third modifies process creation tracking to record the complete command line, rather than just the executable name. Note that the latter is only effective on Windows 7, windows 8, Windows Server 2008, and Windows Server 2012 if KB3004375 is installed (which it should, if you have Windows Updates turned on); Windows 8.1, Windows 10, and Windows Server 2016 have this feature out of the box.
With these commands run, Windows will now add an event 4688 to the Security log every time a new process or program starts. Yes, it's a bit noisy, but it's not something you have to look at every day. And when you do need it, it's a life saver.
With process auditing turned on, opening the demonstration Word document above creates the following event in the Security channel:
Again, "Creator Process Name: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE" is a dead giveaway that Microsoft Word launched some external program, an event that should be a red flag for your investigators.
A side note pointed out by Belgian security consultant CERASUS: Only Windows 10 and Windows Server 2016 include the Creator Process Name field. Earlier versions of Windows show the new process name and ID, but only show the process ID for the creator process. That can make automated detection a bit of a challenge.
In the week+ since the original Sensepost article, researchers and hackers have come up with ever more clever ways to trigger exploitation, and both The Hacker News and Internet Storm Center have seen botnets have begun using the technique to spread ransomware and other malware. Outlook uses Word as its default message editor, making possible exploitation without requiring opening an attachment. One of the most ingenious approaches I've seen was tweeted by David Thompson:
Word opens attachments and documents from risky locations in Protected View, which does not immediately run the embedded code. Not all Office products use Protected View however, as Matt Nelson points out:
One final note: after I published this article, fellow Austin security pro Brian Boettcher mentioned a very simple trick to stop this exploit dead in its tracks: disabling the "update automatic links at open" option in Word.
