The last couple of months, we’ve seen several new waves of Dridex banking malware, a new RTF 0-day vulnerability was successfully exploited and used against millions of targets, mainly in Australia, as spotted in the wild. The primary objective of Dridex malware is to steal banking information from users of infected machines to immediately launch fraudulent transactions. Bank […]
The last couple of months, we’ve seen several new waves of Dridex banking malware, a new RTF 0-day vulnerability was successfully exploited and used against millions of targets, mainly in Australia, as spotted in the wild.
The primary objective of Dridex malware is to steal banking information from users of infected machines to immediately launch fraudulent transactions. Bank information for the software installs a keyboard listener and performs injection attacks. During 2015, theft caused by this software were estimated at £20 million in the United Kingdom and $10 million in the United States. By 2015, Dridex attacks had been detected in more than 20 countries. In early September 2016, researchers spotted initial support for targeting crypto-currency wallets.
The infection was done using a file, with leveraging a logical bug in Microsoft Word where a special OLE object is being embedded.
Embedding OLE objects in RTF
As described in the RTF specification, OLE objects can be easily embedded, utilizing a pre-installed piece of software, linking container document with additional functionality.
You can find below useful keywords for such embedded objects.
RTF Specification from http://latex2rtf.sourceforge.net/RTF-Spec-1.0.txt
Dridex embedded malicious OLE object
We gathered a sample of the 0-day and ran it through Votiro’s research lab analysis, approving that this is indeed a new attack method, bypassing most of the security defenses today including Sandboxes and all endpoint memory based mitigation techniques.
As you can see in the snippet below, the offending OLE object is marked in yellow.
The Logical Bug
As originally reported by and acknowledged by Microsoft, the bug is a logical issue in Microsoft Word and the Mshta.exe component.
Mshta.exe is responsible for handling the Content-Type “application/hta,” parsing the content, and executing the script. Winword.exe parses the OLE object instruction, queries a remote server for an external content where the server returns an “application/hta” that eventually invokes to execute mshta.exe. Mshta.exe then executes any code that is embedded in the malicious HTA document. The interesting thing in the bug that it’s purely logical and none of the memory based endpoint mitigations cannot detect it, as it does not involve any memory corruption or overrun.
The right approach is to disable RTF files from being loaded by setting the following registry keys, as offered by @ryHanson, by setting: Software\Microsoft\Office\15.0\Word\Security\FileBlock\RtfFiles to 2 and OpenInProtectedView to 0.
Another approach to mitigate those kinds of attacks is to perform an of document formats such as RTF. Using Advanced CDR image module, that supports RTF and many other document formats, the OLE objects are carefully examined as the document is being re-built from scratch, eliminating any non-standard or documented attributes, values, and OLE objects without requiring any signature or learning.
I’ve used API (api.portal.votiro.com) and uploaded the same CVE-2017-0199 sample to Votiro’s service. The safe document was retrieved in less than a second and as expected, the faulty OLE object was removed automatically as expected.