Geekly Articles each Day
📜 ⬆️ ⬇️

The Adventures of the Elusive Malvari, Part IV: DDE and the Word Document Fields



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


In this article, I was going to dive into an even more complex multi-step script without a file attack with a pin in the system. But then I came across an incredibly simple attack without a code - no Word or Excel macros are required! And this much more effectively proves my initial hypothesis underlying this series of articles: to overcome the external perimeter of any organization is quite an easy task.

The first attack, which I will describe, exploits a Microsoft Word vulnerability that is based on an obsolete Dynamic Data Exchange Protocol (DDE) . It has already been fixed . The second exploits a more general vulnerability in Microsoft COM and object transfer capabilities.
')

Back to the future with DDE


Does anyone else remember DDE? Probably a few. It was one of the first interprocess communication protocols that allowed applications and devices to transfer data .

I myself am a little familiar with it, because earlier I checked and tested the telecom equipment. At that time, DDE allowed, for example, to transfer a caller ID to call center operators in a CRM application that eventually opened a 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 turned out, Microsoft Word still supports DDE.

What makes this attack effective without code is that you can access the DDE protocol directly from the automatic fields of a Word document (I take off my hat to SensePost for researching and publishing about it).

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


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

I remember that when I first discovered this feature in Word, I was amazed. And until the patch disconnected it, Word maintained the DDE field parameter setting. The idea was that DDE would allow Word to communicate with the application directly, so that it could then transfer the output of the program to a document. It was a very young technology at that time - supporting data exchange with external applications. Later it was developed in the COM technology, which we will also consider below.

As a result, the hackers realized that this DDE application could be a command shell, which, of course, launches PowerShell, and from there the hackers can do whatever they want.
The screenshot below shows how I used this secretive technique: a small PowerShell script (hereinafter - PS) from the DDE field loads another PS script that launches the second phase of the attack.


Thanks to Windows for the pop-up warning that the built-in DDEAUTO field secretly tries to launch the shell.

The preferred method of exploiting the vulnerability is to use a variant with the DDEAUTO field, which automatically runs the script when opening a Word document.
Let's think about what can be done about it.

As a novice hacker, you can, for example, send a phishing email, pretending that you are from the FTS, and embed the DDEAUTO field with the PS script for the first stage (the dropper is essentially). And you do not even need to do any real coding of macros, etc., as I did in the previous article.
The victim opens your document, the embedded script is activated, and the hacker is inside the computer. In my case, the remote PS script only prints a message, but it can also easily run the PS Empire client, which will provide remote access to the shell.
And before the victim has time to say at least something, hackers will be the richest teenagers in the village.


The shell was run without any coding. Even a child can do it!

DDE and fields


Later, Microsoft still turned off DDE in Word, but before that the company stated that this feature was simply misused. Their unwillingness to change something is understandable. From my own experience, I myself witnessed such an example that updating the fields when opening a document was turned on, but the Word macros were turned off by the IT service (but with the notification shown). By the way, you can find the corresponding parameters in the Word settings section.

However, even if the field update is enabled, Microsoft Word also notifies the user when the field requests access to remote data, as is the case with DDE above. Microsoft is really warning you.

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

How hard is it to find a non-patched Windows system today?

For this test, I used AWS Workspaces to access the virtual desktop. So I got a non-patched MS Office virtual machine, which allowed me to insert the DDEAUTO field. I have no doubt that in the same way you can find other companies that have not yet installed the necessary security patches.

Mystery 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 how to use Excel as bait for a phishing attack without writing code.

To understand this scenario, let's recall the Microsoft Component Object Model , or abbreviated as COM (Component Object Model) .

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

By and large, you can present a COM application as an Excel or Word executable file, or some other binary executable.

It turns out that a COM application can also run a script — JavaScript or VBScript. Technically, this is called a scriptlet . You may have encountered the .ct extension for files in Windows - this is the official extension for scripts. In fact, they are the script code enclosed 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 discovered that there are separate utilities and applications in Windows that accept COM objects and, accordingly, scriptlets too.

I can pass the scriptlet to a Windows utility written on VBS, known as pubprn. It is located in the depths of C: \ Windows \ system32 \ Printing_Admin_Scripts. By the way, there are other Windows utilities that take objects as parameters. To begin, consider this example.


It is quite natural that the shell can be run even from a print script. Go, Microsoft!

As a test, I created a simple remote scriptlet that launches a shell and prints a funny message “You have just been scripted!”. Essentially, pubprn creates an instance of a scriptlet object, allowing VBScript code to run a shell. This method provides clear advantages for hackers who want to quietly penetrate and hide in your system.

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

To you as homework - watch this video from Derbycon 2016, which explains exactly how hackers used scriptlets. And also read this article about scriptlets and some moniker.

Source: https://habr.com/ru/post/460521/

More articles:


All Articles