You are browsing the archive for Malware Analysis.

Hunting for additional PE timestamps

January 4, 2019 in Batch Analysis, Clustering, File Formats ZOO, Malware Analysis, Reversing

Over the years I published a number of posts about file timestamps. Not the file system timestamps, but timestamps hidden inside the actual file content.

I wrote that there is a way to ‘heuristically’ carve timestamps from binary files. I have also provided some compilation timestamps stats for PE files, and discussed less-known Java folder timestamps. And when we talk about the PE files specifically, there is an PE compilation timestamp discussion in a context of timestomping. There is also a bit of rambling about the infamous Borland/Delphi resource timestamp.

Anyone who ever looked at the PE file specification or various PE Dump reports knows there are possibly more timestamps hidden inside these executable files.

For starters, we can look for timestamps sometimes present in additional PE file areas e.g. hidden inside a debug section, or even file’s signature – if they exist. There is an information about a compiler / linker version, Rich Header, .NET version, imported and exported APIs, imported DLLs, etc. All of them may help to narrow down the timeframe when the file was created. The DiE tool does a good job in helping with extraction of some of this information.

We can do a lot of guesswork based on the information available inside the metadata as well, for example by simply looking at file’s Version information block, or manifest. Then there are good old strings: if we are lucky the unencrypted strings embedded in a main file/configuration/update can get us an immediate answer. We may also rely on indirect references to time e.g. by looking at versions of statically compiled libraries (sometimes you can see actual version strings), sometimes bugs in code, and debug / verbosity logs that have not been stripped off from the release version; sometimes dates are included in the PDB string itself, and then sometimes there is a never-shown usage info, or even dead code that may include a dated ‘copyright’ note from the malicious author. These may be also included as comments inside the scripts, in case the binary file is a host to an interpreted code (this happens pretty often with older malware based on AHK, VBE, etc.). Advanced malware analysts can often deduce the version / rough time period of protector layers by just looking at the code (they can, because they write decrypters for this mess and often adjust code, even on daily basis).

Now, all of these can be modified, or fixed because they are very well-known. But there are more timestamps we can look at.

When we read the PE file documentation we can notice that it is rich in descriptions of all these additional timetstamp fields available.

The problem is… most of the time they are always zeroed.

But…

It is actually not always the case!

I was reading the description of the VS_FIXEDFILEINFO structure, and I realized that I never seriously looked at the two timestamp fields it includes:

dwFileDateMS Type: DWORD

The most significant 32 bits of the file’s 64-bit binary creation date and time stamp.

dwFileDateLS Type: DWORD

The least significant 32 bits of the file’s 64-bit binary creation date and time stamp.

So, I wrote a quick parser to search my PE metadata logs for samples where the values of these fields are not zero. And if not zero, must be within a certain, reasonable timestamp range (compiled between year 2000, Jan 1st, and today).

To my surprise, the script started spitting out names of samples that had these fields populated. Very often the values would be identical with a PE Compilation timestamp, but in some cases would be off by a few minutes, sometimes days and months. Since such cases provide a range between the version info compilation and actual PE file compilation it could provide an additional information about the timeframe of active development of the sample.

An example of such file can be found here.

An obvious question appears: which compilers/linkers produce these correctly compiled executables?

I don’t know at this stage. Also, despite some good results I need to emphasize that most of samples do not include a valid timestamp. Still… when it’s available… why shouldn’t we be extracting it?

Propagate – yet another follow-up (hypothetical clipboard execution version)

November 19, 2018 in Anti-*, Code Injection, Compromise Detection, EDR, Incident Response, Malware Analysis, Sandboxing

I’ve been thinking of tricking the Windows Clipboard to execute code inside other processes for a while now. It perhaps sounds crazy, but I thought there may be _some_ way to do it. The below is just a pure speculation based on some cursory analysis of 2 popular Windows APIs.

So dunno if it works. Still, I will just jot it down here, and if anyone has time and mood to test it in practice — feel free to do so, and share the results.

Accessing clipboard via Windows API is very straightforward – refer to the MSDN for details. The only thing that matters is that data using typical data formats can be placed in a clipboard via SetClipboardData API. We could potentially use it to inject data to any process that deals with the clipboard, and somehow make it execute before the user changes the clipboard content? Possibly, who knows… Since I couldn’t come up with any trick to make it happen I looked at other clipboard functions. My attention was drawn to the concept of sharing non-standard clipboard data formats between processes. How does the clipboard works with these? The SetClipboardData is not enough – we need to use the OleSetClipboard API.

As far as I can tell, the implementation details of this API are not covered anywhere. At least I couldn’t find it. A very good high-level description of the OLE Clipboard can be found in the excerpts from the ‘Programming Windows with MFC’ book by Jeff Prosise that was published in 1999 (I don’t include links as the sites look dodgy). The Windows documentation simply says that the function ‘places a pointer to a specific data object onto the clipboard. This makes the data object accessible to the OleGetClipboard function.’.

This is a very curious statement. How can you place a pointer onto the clipboard?

I immediately started looking at these two APIs. It turns out that lots of applications use OleGetClipboard API to access the clipboard. If we use the OleSetClipboard and make it point to our IDataObject interface, some application will sooner or later retrieve the pointer in their own process space. It will then start calling the IDataObject methods to access the OLE Clipboard. Due to internal working of COM the interface pointer returned inside the remote process is not something we can directly control (as far as I can tell) and we can’t get a code execution this way.

Are there any other options?

I mentioned the internal working of OleSetClipboard and OleGetClipboard that are a bit of a mystery. And they are actually far more complex that I imagined. The simple bit is that Ole32 library that implements these functions registers a window class named ‘CLIPBRDWNDCLASS’. And surprise, surprise, when we run OleSetClipboard API the IDataObject data pointer we pass to this API… will be stored as a window property of this OLE clipboard window!

Sounds familiar?

Yup. You may recall the Propagate technique I described last year – it relies on a fact that certain windows properties can be modified by external programs. That is, if we can find the CLIPBRDWNDCLASS window, we can probably modify some of its clipboard-related properties?

After checking the code of the OleSetClipboard API we can quickly discover a number of interesting windows properties:

  • OLEClipPackgeOwner
  • OleClipProcessOwner
  • ClipboardDataObjectInterface
  • ClipboardRootDataObjectInterface
  • ClipboardDataObjectInterfaceMTA

If it has an ‘interface’ in the name, it is obviously _very_ interesting.

The ‘ClipboardDataObjectInterface’ property is where the IDataObject pointer is stored. What about the other two ‘interface’ properties? The ‘MTA’ in the name of one of them suggests ‘Multi Thread Apartment’, the ‘root’ one stores the source IDataObject – both seem to be used internally by CClipboardBroker::SetClipboard method only.

After browsing through the references to these properties I noticed that in some cases the pointer retrieved from the window is not being marshalled. As far as I can tell, such are the cases when:

  • the pointer retrieved via the GetProp API is used inside the same process that owns the CLIPBRDWNDCLASS window
  • when OleFlushClipboard is called
  • same thing happens when the OLE clipboard is destroyed. e.g. in reaction to CLIPBRDWNDCLASS window receiving a WM_DESTROYCLIPBOARD message.

I guess this part of code was written with an assumption that the message will never be received from an external application(?). The important bit is that during this clipboard destruction process, and before the RemoveProp API is called for all these ‘interface’ clipboard properties, the Release method of the IDataObject retrieved from the ClipboardDataObjectInterface (and other interfaces) will be called as well.

If the hypothesis is right,

  • changing the¬†CLIPBRDWNDCLASS window property ‘ClipboardDataObjectInterface’ to point to a controlled memory region storing pointer to a dummy IDataObject object pointing in return to a malicious code (with the callback registered under Release method); other ‘interface’ properties can be used too
  • then sending a WM_DESTROYCLIPBOARD message to the CLIPBRDWNDCLASS window

should end up with a code execution…