Maldoc 15ee2c2f3f01eda532b91dff9f4bcc53 is a malicious RTF document with an exploit for an old vulnerability (CVE-2010-3333).

If you open this document in a sandbox, you will not see malicious activity. That's because the shellcode it contains, triggered by the exploit, is nonfunctional. A static analysis is required to know more about this maldoc.

A static analysis is not too difficult. It's an RTF document, and can thus be analyzed with rtfdump.py:

There are not many items, and we can see that item 11 contains many hexadecimal characters (h=938).

This can be decoded with the following command:

From the anti-virus alerts on VirusTotal, we know that there is an exploit in this document. String AAAA... is often used to overflow buffers.

 And at the end we see a small command. If you pay close attention to the dump, you might even reconstruct the string urlmon.

So this is very likely shellcode, probably a downloader. But where is the URL?

Let's write this binary data to disk and analyze it with NASM's disassembler:

This is not shellcode, but if we look after the buffer overflow string AAA... (0x41 0x41 0x41...), we see a jump instruction, and more importantly, a reference to FS 0x30.

On Windows 32-bit, the FS segment register is used to access the Thread Information Block. And offset 0x30 gives access to the Process Environment Block. These data structures are often accessed by shellcode to lookup Win32 API addresses.

Hence, it's very likely that address 0xEF is the entrypoint of the shellcode. We can try that out with the shellcode emulator scdbg: it has an option to provide the entrypoint (-foff). We'll let the emulation start from address EF:

This is indeed shellcode and 0xEF is the entrypoint: this shellcode downloads a payload, writes it to disk as a.exe and then executes it. But we see no URL.

Let's grep for URLDownloadToFile and see what gets written on the stack (option -vv increases the verboseness to a level where we see the registry values for each instruction emulation):

Register edi contains the address of the URL: 0x004011D5. What do we find at this address? Nothing:

This shellcode can't download anything, because the malware author made a mistake and did not include the URL.

If you really want to be shure that this shellcode is a downloader, and that the only thing missing is the URL, you can add your own URL to the shellcode and emulate it. This can be done with option -spoke (string poke): this option allows you to write a string to memory before the shellcode gets emulated. Let's write a URL at address 0x4011D5 like this:

This confirms it: the emulated shellcode now downlaods from the URL we provided.

It doesn't happen often, but you can be in a position that you have to analyze non-working malware. Here, our analysis could not reveal the payload, simply because the URL is missing.

There are functional variants of this exploits on VirusTotal, like this one.

You can even find a sample on GitHub.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com