McAfee Avert Labs has of late seen numerous submissions of executable files embedded within Rich Text Files as OLE objects. These executable files usually have the icons of a trusted file type–for example, DOC, PDF, or TXT–and have a convincing message to entice victims into executing it.
Few would click on an embedded executable within a document file, but if the same executable were to have the file extension of a trusted or harmless file type, there would be more takers for this bait. By default if one were to drag and drop an executable into WordPad, it would display the full filename and extension as follows:
Changing the label of the embedded file is a trivial thing involving a couple of mouse clicks and Wordpad will run the embedded file just fine when executed. The sequence of steps to make this change will not be revealed in this blog for obvious reasons.
So I asked myself, why are the bad guys using such an old technique in these times of zero-day exploits? The answer is startling. Most antivirus software is unable to parse the rich text file format! As a trial, I submitted the antivirus test file EICAR.COM and an embedded copy of the same in rich text format to VirusTotal–a public antivirus scanning service.
Every single scanner detected the antivirus test file EICAR.COM, but only 16 out of 30 scanners were able to detect it embedded inside a rich text file. In layman’s terms, one could take an already detected malware and embed it inside a rich text file and half the antivirus software on the market would not detect this type of threat. A perfect foil for virus authors to use in phishing and spam runs.
Given that the bad guys rigorously QA their creations against antivirus software before releasing into wild, it comes as no surprise why we are seeing an increase in this type of threat. Only time will tell how effective this technique is, both at the software and social-engineering level. It will be interesting to watch how the field plays out.
May 29th, 2007 at 06:37
But every scanner’s on-access module will block the eicar file when you extract it from the RTF. RTF may get known malware passed the email scanner, but not the on-access or reat-time scanner. This is really FUD. Scanning through RTF does not increase user secuirty. Blocking executable threats does. The threat is not executable until extracted from the RTF. It is no different than putting a k nown threat inside of an archive file that McAfee doesn’t know. As soon as the user extracts the file it is detected.
Cheers,
Randy
May 29th, 2007 at 13:28
most, if not all virus scanners do not scan files executed directly into memory; they must be run from the hard drive to be detected. This was a problem with IE 5, Outlook Express 5, and Outlook 2000 until Microsoft patched it.
So, if Wordpad executes its attachment straight into memory, from within the .rtf already running in memory, then any virus infected process won’t be noticed until it tries to write infected code to the hard drive.
my 1 1/3 cents
May 29th, 2007 at 13:33
>This was a problem with IE 5, Outlook Express 5, and Outlook
>2000 until Microsoft patched it.
self edit: this was a problem because IE & OE would execute files directly into memory, therefore no virus scanner would get a chance to scan it first.
September 3rd, 2008 at 14:20
rtf is an open standard markup language and has no need to transfer executable code to satisfy its basic mapping function: font,upper-lower case, etc..
Why do such WPML + executable code programs such as MSWord not simply refuse to remap executable code from a default rtf-A standard.