Elusive Malware Adventures Part IV: DDE and Word Document Margins

This article is part of the Fileless Malware series. All other parts of the series:

• Adventures of the Elusive Malvari, Part I
• Elusive Malware Adventures Part II: Hidden VBA Scripts
• Elusive Malware Adventures Part III: Obfuscated VBA Scripts for Fun and Profit
• Elusive Malware Adventures, Part IV: DDE and Word Document Fields (we're here)

In this article, I was going to dive into an even more complex, multi-stage, fileless, sticky attack scenario. But then I stumbled upon an incredibly simple no-code attack - no Word or Excel macros required! And it proves much more effectively my original hypothesis at the heart of this series of articles: breaking the outer perimeter of any organization is not a difficult task at all.

The first attack I will describe exploits a vulnerability in Microsoft Word that is based on obsolete dynamic data exchange protocol (DDE). She was already fixed. The second exploits a more general vulnerability in Microsoft COM and object passing capabilities.

Back to the Future with DDE

Anyone else remember DDE? Probably few. It was one of the first inter-process communication protocols that allowed applications and devices to communicate.

I myself am a little familiar with it, because I used to check and test telecom equipment. At that time, DDE allowed, for example, for call center operators to transfer the caller ID to the CRM application, which ultimately opened the customer card. To do this, you had to connect an RS-232 cable between the phone and the computer. Those were the days!

As it turns out, Microsoft Word is still supports the DDE.

What makes this attack effective without code is that you can access the DDE protocol directly from automatic margins in a Word document (hats off to SensePost for research and publications about it).

Field codes is another ancient MS Word feature that allows you to add dynamic text and a bit of programming to your document. The most obvious example is the "page number" field, which can be inserted into the footer using the value {PAGE *MERGEFORMAT}. This allows you to automatically generate page numbers.

Hint: you can find the menu item Field (Field) in the section Insert (Insert)

I remember when I first discovered this feature in Word, I was amazed. And until the patch turned it off, Word still supported the DDE fields parameter. The idea was that DDE would allow Word to communicate directly with the application so that it could then pass the program's output to the document. It was a very young technology at that time - support for exchanging data with external applications. It was later developed into COM technology, which we will also discuss below.

Eventually, the hackers figured out that this DDE application could be a command shell, which of course runs PowerShell, and from there the hackers can do whatever they want.
The screenshot below shows how I used this sneaky technique: a small PowerShell script (hereinafter referred to as PS) from the DDE field loads another PS script that launches the second phase of the attack.

Thanks to Windows for popping up a warning that the built-in DDEAUTO field is stealthily trying to start a shell

The preferred method of exploiting the vulnerability is to use the DDEAUTO option, which automatically runs the script when opened word document.
Let's think about what we can do about it.

As a novice hacker, you can, for example, send a phishing email pretending to be from the Federal Tax Service and embed the DDEAUTO field with the PS script for the first stage (essentially a dropper). And you don't even have to do any real macro coding, etc., as I did in previous article.
The victim opens your document, the embedded script is activated, and the hacker is inside the computer. In my case, the PS remote script only prints a message, but it could just as easily launch the PS Empire client, which will provide remote shell access.
And before the victim can say anything, the hackers will be the richest teenagers in the village.

The shell was launched without the slightest coding. Even a child can do it!

DDE and fields

Later, Microsoft did disable DDE in Word, but before that, the company said that this feature was simply misused. Their reluctance to change is understandable. From my own experience, I myself have observed such an example that updating fields on opening a document was enabled, but Word macros were disabled by IT (but with a notification). By the way, you can find the corresponding options in the Word settings section.

However, even if field refresh is enabled, Microsoft Word additionally notifies the user when a field requests access to remote data, as is the case with DDE above. Microsoft is indeed warning you.

But most likely, users will still skip this warning and activate field refresh in Word. This is one of the rare opportunities to thank Microsoft for disabling the dangerous DDE feature.

How difficult is it today to find an unpatched Windows system?

For this testing, I used AWS Workspaces to access the virtual desktop. This way I got an unpatched MS Office VM that allowed me to insert a DDEAUTO field. I have no doubt that in a similar way you can find other companies that have not yet installed the necessary security patches.

Mystery of Items

Even if you installed this patch, there are other security holes in MS Office that allow hackers to do something very similar to what we did with Word. In the next scenario, we will learn use Excel as bait for a phishing attack without writing any code.

To understand this scenario, let's remember the Microsoft Component Object Model, or for short COM (Component Object Model).

COM has been around since the 1990s, and is defined as a "programming language-neutral object-oriented component model" based on RPC remote procedure calls. For a general understanding of COM terminology, read this post on StackOverflow.

Basically, you can think of a COM application as an Excel or Word executable, or some other executable binary.

It turns out that a COM application can also run scenario - JavaScript or VBScript. Technically it's called scriptlet. You may have seen the .sct extension for files in Windows - this is the official extension for scriptlets. In fact, they are script code wrapped in an XML wrapper:

<?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>

Hackers and pentesters have discovered that there are separate utilities and applications on Windows that accept COM objects and, by extension, scriptlets too.

I can pass the scriptlet to a Windows utility written in VBS known as pubprn. It is located in the bowels of C:Windowssystem32Printing_Admin_Scripts. By the way, there are other Windows utilities that accept objects as parameters. First, let's look at this example.

It is only natural that a shell can be launched even from a print script. Go Microsoft!

As a test, I created a simple remote scriptlet that launches a shell and prints a funny "You just got scripted!" message. Essentially, pubprn instantiates a scriptlet object, allowing the VBScript code to run the shell. This method provides clear advantages for hackers who want to sneak in and hide on your system without being noticed.

In the next post, I will explain how COM scriptlets can be exploited by hackers using Excel spreadsheets.

For you as homework - see This Video from Derbycon 2016, which explains exactly how the hackers used scriptlets. And also read this article about scriptlets and some kind of moniker.

Source: habr.com