Adventures in Fileless Malware, Part V: More DDE and COM Scriplets

In this series of post, we’ve been exploring attack techniques that involve minimal efforts on the part of hackers. With the lazy code-free approach I introduced last time, it’s even possible to slip in a teeny payload into a DDE field within Microsoft Word. And by opening the document attached to a phish mail, the unwary user lets the attacker gain a foothold on her laptop. To bring the story up to date, Microsoft ultimately closed the door on DDE attacks with a security patch late last year.

The patch adds a registry entry that disables DDE functionality within Word by default. If you still absolutely need this capability, you’re free to update the setting to bring the old DDE capabilities back to the way it was.

However, the original patch only covered Microsoft Word. Are there DDE capabilities in other Microsoft Office products than can be exploited in code-free style?

Yes, indeed. You can also find them in Excel.

Night of the Living DDE

Before you start shouting into your browser, I’m aware that I left you on the edge of your seat in the previous post describing COM scriptlets. I’ll get to them further below.

Let’s continue with the evil side of DDE, the Excel version.

Just as with Word, Excel’s somewhat hidden DDE capabilities allow you to execute a bit of shell code without breaking a sweat. As a long-suffering Word user, I was familiar with fields and knew a little about DDE functions.

In Excel, I was a little surprised to learn I can execute a command shell from within a cell, as demonstrated in the following:

This ability to run a Windows shell comes to us courtesy of DDE. (And yes there are other apps to which you can connect using Excel’s embedded DDE features.)

Are you thinking what I’m thinking?

Have the cmd shell in the cell launch a PowerShell session that then downloads and executes a remote string — the trick we’ve been using all along. Like I did below:

You would, of course, need to explicitly enter the cell to execute this Excel formula.

So how could a hacker force this DDE command to be executed?

When the worksheet is opened, and if not otherwise configured, Excel will try to refresh these DDE links. There have long been options — buried in Trust Center — to either disable or prompt on updating links to external data sources or other workbooks.

Microsoft initially advised companies last year to disable automatic updates to prevent this DDE-based hack from being so easily pulled off in Excel.

These were mitigations, of course, but Microsoft was reluctant to go the same route as they did for Word, which was to provide a registry entry that would disable DDE all together.

But in January, they bit the bullet and provided patches for Excel 2007, 2010, and 2013 that also turn off DDE by default. This article (h/t Computerworld) nicely covers the details of the patch.

Let’s Go to the Event Logs

In short, Microsoft has cut the power on DDE for MS Word and Excel — if you’ve incorporated their patches —  finally deciding that DDE is more like a bug than, clearing throat, a feature.

If you’ve not, for whatever reason, included these patches in your environment, then you can still reduce the risk of a DDE-based attack by disabling automatic updates or enabling the options that prompt users to refresh links when the document or spreadsheets are opened.

And now an important question: if you’re a victim of this style of attack, would the PowerShell sessions launched by, either fields in Word or a shell command in the Excel cell, show up in the log?

In my obfuscation series, I discussed how PowerShell logging has been greatly improved in recent versions of Windows. So I took a peek at the log (above), and can confirm that even when you’re launching PowerShell sessions directly from a cell function —rather than as a macro — Windows will log the event.

I’m not saying it would be easy for IT security to connect all the dots between the PowerShell session, an Excel document, and a phish mail and decide that this is indeed the beginning of the attack. I’ll discuss the consequences of malware-free or fileless hacking techniques in my final post in this never-ending series.

Enter the COM Scriptlet

In the previous post, I took on the subject of COM scriptlets. On their own, they are, I suppose, a neat feature that allows you to pass around code, say, JScript, as just another COM object.

But then hackers discovered scriptlets, and at a minimum, it allows them to keep a very low profile on a victim’s computer — “living off the land”.  This Derbycon video demos a few resident Windows tools that take remote scriptlets as arguments — regsrv32, rundll32 — and let hackers essentially conduct their attack malware-free. As I showed last time, you can easily launch PowerShell commands using a JScript-based scriptlet.

As it turns out, a very smart security researcher discovered a way to run a COM scriptlet within an Excel document. He found that something called Package is inserted into an Excel cell formula when you try to link to a document or graphic. And Package will accept a remote scriptlet (below).

After doing low-level code inspection, the researcher learned that this is actually a bug in the Package software. It wasn’t meant to instantiate a COM scriptlet, just file objects.

I’m not sure whether there’s a patch for this yet. In my own exploration in a virtual Amazon WorkSpaces desktop with Office 2010, I was able to reproduce his results. When I tried again the other day, I had no success.

As we finish up this series, I hope I left you with the feeling that there’s a lot of uncertainty in what hackers can do in your environment. Even if you accept all the recent Microsoft Office patches, they still have relatively low-effort techniques, through the VBA macros I initially presented, to embed a malware payload into Word or Excel.

And if you’ve not done your patch homework, you’ve made it even easier for them to gain a foothold with code-free hacking and then perform stealthy post-exploitation.

I’ll talk about what this all means for mounting a reasonable security defense in — I promise — my final post in this saga.