rtfdump's Find Option, (Sat, Oct 22nd)


Due to the nature of the RTF language, malicious RTF files can be very obfuscated.

To the point that my tool rtfdump.py and Philippe‘s tool rtfobj don’t find embedded objects:

To analyze a heavily obfuscated RTF maldoc like this one (1c8cfccd2e45ea898125a62686ee97a1e923dfbbc8652889027d46b04aa5dc75), one needs to use rtfdump.py’s different options to select the most suspicious items and try to decode them.

To try to automate part of this manual process, I implemented option -F:

With option -F, rtfdump searches through all items with hexadecimal strings, tries to decode them (combining -H and -S) looking for OLE files (files that start with D0CF11E0).

You can direct rtfdump to search for other types of files by using option –findcutexpression:

But here, with option -F, one ole file was found. Let’s pipe it into oledump.py:

It contains one stream. Let’s use option –storages to view the storages, and option -E “%CLSID% %CLSIDDESC%” to view the class ids:

It’s an equation stream. Let’s take a look at the content of the stream:

01 is a line record (IIRC) and 08 is a font record. That’s where the exploit starts:

Let’s extract the complete content of this stream, write it to disk, and have scdbg analyze this 32-bit shellcode:

The downloaded file is a PE file: Formbook.

Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Photo Credit:

14 February 2006 (original upload date)
Source Skript Regelungstechnik und Flugregler [1]
Author Jörg J. Buchhol
GNU head Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later

Reposted from SANS. View original.

Alex Post