Dangerous document formats and social engineering

Published: 2007-03-28
Last Updated: 2007-03-28 06:00:12 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)
If you’ve been reading our diaries for last couple of months, no doubt that you are aware of the huge number of exploits directed toward various Office applications, mainly Microsoft Word and PowerPoint. For quite some time a lot of administrators (us included) told people to convert documents to other (safer) formats, one of them being RTF (Rich Text Format). Although this format is proprietary, the specification is publicly available so a lot of word processors support this format.
Our reader Mike Armstrong reported a phishing e-mail he received from the Better Business Bureau. The e-mail contained a link to a site which hosted an RTF document. As this immediately looked suspicious (a completely unrelated web site hosted just the RTF document, nothing else), I decided to spend more time analyzing this. The file was located on http:// www. nightcrossings.com/[REMOVED].

Embedding everything

As you all know, complexity and security don’t go good together. Nevertheless, lately we can see a trend of embedding everything in anything which leads to increased complexity as well. Microsoft Word documents that carry images and videos are completely normal now.
While RTF is a more human readable format (it is a plain, ASCII file at the end), this does not prevent it from embedding objects that can be very dangerous, as we will see.
So, the picture below shows how Microsoft word will open the file Mike submitted:


As you can see, this will work in any version of Microsoft Office (I used the latest and greatest Office 2007). The text and the icon shown on the screen shot are all part of a single object that is embedded in this document. This is a fine example of a social engineering attack – the attacker tried to lead the victim into thinking that an error occurred in Microsoft Word and that the file (the object) should be double clicked to fix this.
Luckily, Microsoft added at least another layer of protection here (although, to be honest, why would anyone allow a text based format to drop a file and execute it is beyond me). If our trigger happy user double clicked on the object, he would be greeted with the following alert:


I will not go into the discussion if this would prevent him from starting the file or not, but at this point in time, his last (and only) defense is the Anti-virus program (more about that below).

Malware analysis

It is relatively easy to extract embedded objects from an RTF file. Microsoft Word comes with an application called Object Packager. This application can be accessed for every embedded object and all you have to do is right click on the object and start it. You can see below what it reports for this document:


Object Packager was actually used by the attacker as well – first the file was attached and then the appearance was modified. Same way as it was attached it also allows us to save it so we can analyze what’s inside.
If you know of an external utility that can analyze RTF files please let us know – ideally it would be a perl script (some perl modules exist for parsing RTF files but I haven’t found a nice utility that allows extraction of embedded objects such as this one in one step).
The dropped file is (you can probably guess) a downloader. Once executed it downloads http:// www. nightcrossings.com /[REMOVED]/inv.exe which looks like a spamming tool (it’s a big 1.5MB download of an executable written in Delphi that I haven’t thoroughly analyzed).

AV protection and file parsing difficulties

Distributing innocent looking files with embedded malware sounds very interesting for attackers. Once I extracted the dropper and downloaded the second stage binary, I ran all of them through Virus Total to see what (if any) detection is. The results were pretty bad and showed that a lot of anti-virus products either had problems with parsing RTF or couldn’t parse them at all which caused them to miss the dropper (some AV programs would hopefully catch it once the user executed the file).
The images below show VT results from scanning the RTF document and the dropper that is embedded in it (after it has been extracted as a standalone file):

The dropper itself was detected as:

Finally, the second stage binary was undetected by almost all AV vendors – hopefully they’ll add detection for this soon:
This was another example of why complex file formats should be avoided. Even if you do scan all files on your e-mail gateway (or web filtering server), as you can see most AV programs would miss this as they would scan only the RTF document. One more time we see how important defense in depth is – in this case you would depend on user’s awareness and ultimately on his desktop AV product.
0 comment(s)


Diary Archives