Adventures in Fileless Malware, Part IV: DDE and Word Fields

For this next post, I was all ready to dive into a more complicated fileless attack scenario involving multiple stages and persistence. Then I came across an incredibly simple code-free attack — no Word or Excel macro required! — that far more effectively proves the underlying premise in this series: it ain’t that hard to get past the perimeter.

The first attack I’ll describe is based on a Microsoft Word vulnerability involving the archaic Dynamic Data Exchange (DDE) protocol. It was only very recently patched. The second one leverages a more general vulnerability with Microsoft COM and its object passing capabilities.

Back to the DDE Future

Does anyone remember DDE? Probably not. It was an early inter-process communication protocol that allowed apps and devices to pass data.

I’m a little familiar with it because I used to review and test telecom gear – well, someone had to do it. At the time, DDE let caller ids pass to CRM apps that would ultimately pop-up a customer contact record for a call center agents. Yeah, you had to connect an RS-232 cable between the phone and the computer. Those were the days!

As it turns out, at this late date, Microsoft Word still supports DDE.

What makes this attack effectively code-free is that you can access the DDE protocol directly from Windows field codes. (Hat tip to SensePost for researching and writing about it.)

Field codes are another ancient MS Word feature that lets you add dynamic text and a bit of programming into a document The most obvious example of this is the  page numbers, which can be inserted into a footer using this field code {PAGE \*MERGEFORMAT}. It allows page numbers to be magically generated.

I remember first discovering this Word feature as a young lad and being amazed.

Until the patch disabled it, Word supported a DDE field option. The idea was that DDE would let Word communicate with an app and then embed the output in the document. This was an early version of an idea –communicating with external apps — that was later taken over by COM, which will get to below.

Anyway, hackers realized that the DDE app can be, wait for it, a vanilla command shell! The command shell, of course, launches PowerShell and from there hackers can do just about anything.

In the screenshot below, you can see how I used the stealthy technique introduced a few posts back: the teeny PowerShell script in the DDE field downloads more PowerShell, which then starts the second phase of the attack.

The preferred method is to use a variant, the DDEAUTO field, which automatically launches the script when the Word document is opened.

Let’s step back.

As a beginning hacker, you can send a scary phish mail, pretending to be from the IRS, and embed a DDEAUTO field with a teeny first-stage PS script. You don’t have to do any real coding with the MS macro library, as I did in the last post.

The CEO opens the Word doc, the embedded script is activated, and the hacker is effectively inside the laptop. In my case, the remote PS script pops up a message, but it could just as easily have launched a PS Empire client that would grant shell access.

And before you can say Macedonia, the hackers are the wealthiest teenagers in their village.

It’s so easy!

DDE and Fields

After some prodding, Microsoft disabled DDE in Word, but at first they said that the feature was just being misused. Their reluctance is somewhat understandable.

From what I can see (based on a sample of one data security company) field updating on opening a document is enabled and Word macros are disabled (with notification) by IT groups. By the way, you can find the relevant configuration settings in the Options section of Word.

However, even when field updating is enabled, Microsoft Word additionally prompts the user when a field is accessing remote data, as is the case with DDE (see above). Microsoft does indeed warn you.

But as we know from Dr. Zinaida Benenson, users will click away and ultimately activate the field update.

This is a roundabout way of thanking Microsoft for disabling the dangerous DDE feature.

How difficult is it to find an unpatched Windows environment?

For my own testing, I used AWS Workspaces to access a virtual desktop. And it was pretty easy to obtain an unpatched VM with MS Office that let me insert a DDEAUTO field.

No doubt there are, cough, more than a few corporate sites that still haven’t added the security patch.

The Mystery of Objects

Even if you have added their patch, there are other security holes in MS Office that let hackers accomplish something very similar to what we did with Word. In this next scenario, we’ll learn how to leverage Excel as the phish bait in a code-free attack.

To first understand this next scenario, let’s step a back a little to consider Microsoft Component Object Model or COM.

COM has been around since the 1990s and is described as a “language neutral, object-oriented component model” based on remote procedure calls. Read this StackOverflow post for basic COM definitions and terminology.

Generally, you can think of a COM app as Excel or Word or some other running binary executable.

As with all things more Microsoft, it’s more complicated than that.  It turns out that a COM app can also be a script—JScript or VBScript. Technically, it’s called a scriptlet. You may have seen the .sct extension for a Windows file, which is the official suffix for scriptlets. These scriptlets are essentially scripting code encased in XML (below).

<?XML version="1.0"?>

<scriptlet>
<registration
description="test"
progid="test"
version="1.00"
classid="{BBBB4444-0000-0000-0000-0000FAADACDC}"
remotable="true">
</registration>
<script language="JScript">
<![CDATA[

var r = new ActiveXObject("WScript.Shell").Run("cmd /k powershell -c Write-Host You have been scripted!");

]]>
</script>
</scriptlet>

Hacker and pen testers discovered that there are Windows utilities and apps that accept COM objects and, by extension, these user-crafted COM scriptlets.

Let’s call it a day!

Your homework is to watch this Derbycon video from 2016, which explains how hackers and pen testers have taken advantage of scriptlets. And also read this post on scriptlets and something called monikers.

To get ahead of the story, I can pass a scriptlet to a Windows utility, written in VBS, known as pubprn, which is buried in C:\Windows\system32\Printing_Admin_Scripts. By the way, there are other Windows utilities that take objects as parameters; we’ll just look at this particular one first.

For my own testing I crafted a simple remote scriptlet that launches a shell and prints a “boo” message. Effectively, pubprn instantiates the scriptlet object thereby allowing the VBScript code to launch a shell.

This technique provides obvious advantages to hackers who want to “live off the land” and lurk in your system undetected

In the next post, I’ll explain how COM scriptlets can be exploited by hackers within an Excel spreadsheet.