You are browsing the archive for Code Injection.

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…

Two old-school download/exfil methods

May 25, 2018 in Anti-Forensics, Archaeology, Code Injection, Compromise Detection

Sending and receiving network data is always tricky.

With AV, EDR, and dozen of other agents that are installed on the system nowadays it is getting harder and harder to transfer data, because security applications may be actively monitoring specific system/API calls, or just following strict network rules with regards to non-approved apps. Often, if the app is not on the whitelist no connection out can be made.

There are numerous known ways to bypass it, of course; here, I re-discover two very, very and I mean it… very, very old-school techniques that rely on IE browser and its support of Dynamic Data Exchange (DDE) and Microsoft Active Accessibility (MSAA) functionalities. They have most likely only a historical meaning today: new versions of Windows are shipped with Microsoft Edge and the tabbed interface adds additional complexity…

As I mentioned, these two methods are almost completely forgotten. One of them was actively used by old malware (10+ years ago), the other was successfully leveraged by various IE Spies that helped to look at the source code of blocked/inaccessible IE windows + any application that was relying on the HTML-based user interface (it was very prevalent back in early 2000s e.g. think of Norton products from that era).

The first method is DDE/WWW_OpenURL command. As long as IE is open you can send it a DDE command WWW_OpenURL with the URL of your choice. Sending data out this way is trivial (although limited in length), receiving requires either accessing the IE instance, or just enumerating the TIF directory. The method is not clean per se as it was designed long time ago and was not prepared for the tabbed interface. It may affect the user’s browsing experience.

The second one is more esoteric. You can enumerate all windows classes and find windows with a class ‘Internet Explorer_Server’ (Old IE web browser container, prior to Edge; also note: you cnn always launch new instance of IE as well, and make it a hidden window). Once such window is identified, you can send it a very specific message called WM_HTML_GETOBJECT, and process the result using a ObjectFromLresult function. The result will give you an access to a IHTMLDocument2 pointer for that IE instance. With that pointer, you can walk through a couple of COM queries and retrieve the IWebBrowser2 interface of the Web control container. And with that, you can access an active instance of IE browser from your program and manipulate it freely to download and send out whatever you want. Unless security solution monitors these requests specifically you may not be able to spot the bad guy…

I did say that these methods have most likely only a historical meaning today as new versions of Windows are shipped with Microsoft Edge and the tabbed interface adds additional complexity, but… as this thread suggests, perhaps the support for MSAA implemented by modern browsers still offers some interesting possibilities? And probably here it is a good time to remind you of my old post talking about using the accessibility APIs to develop keylogging functionality w/o using any typical well-known keylogging APIs.

And last, but not least. At some stage I was looking at the possibility of using the DDE and WM_HTML_GETOBJECT tricks to develop a new code injection technique. Since we can access the browser’s process via other means than a regular WriteProcessMemory it definitely may come handy. And the simplicity of the idea relies on the fact that we can actually forget the shellcodes for a moment, and the code injection can rely on… JavaScript code.