You are browsing the archive for Code Injection.

← Previous Entries

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.

Comments Off on Two old-school download/exfil methods

PROPagate follow-up #2 – Some more Shattering Attack Potentials

February 4, 2018 in Anti-*, Code Injection, Compromise Detection, EDR, Incident Response, Malware Analysis

A few months back I discovered a new code injection technique that I named PROPagate. Using a subclass of a well-known shatter attack one can modify the callback function pointers inside other processes by using Windows APIs like SetProp, and potentially others. After pointing out a few ideas I put it on a back burner for a while, but I knew I will want to explore some more possibilities in the future.

In particular, I was curious what are the chances one could force the remote process to indirectly call the ‘prohibited’ functions like SetWindowLong, SetClassLong (or their newer alternatives SetWindowLongPtr and SetClassLongPtr), but with the arguments that we control (i.e. from a remote process). These API are ‘prohibited’ because they can only be called in a context of a process that owns them, so we can’t directly call them and target windows that belong to other processes.

It turns out his may be possible!

If there is one common way of using the SetWindowLong API it is to set up pointers, and/or filling-in window-specific memory areas (allocated per window instance) with some values that are initialized immediately after the window is created. The same thing happens when the window is destroyed – during the latter these memory areas are usually freed and set to zeroes, and callbacks are discarded.

These two actions are associated with two very specific window messages:

  • WM_NCCREATE
  • WM_NCDESTROY

In fact, many ‘native’ windows kick off their existence by setting some callbacks in their message handling routines during processing of these two messages.

With that in mind, I started looking at existing processes and got some interesting findings. Here is a snippet of a routine I found inside Windows Explorer that could be potentially abused by a remote process:

Or, it’s disassembly equivalent (in response to WM_NCCREATE message):

So… since we can still freely send messages between windows it would seem that there is a lot of things that can be done here. One could send a specially crafted WM_NCCREATE message to a window that owns this routine and achieve a controlled code execution inside another process (the lParam needs to pass the checks and include pointer to memory area that includes a callback that will be executed afterwards – this callback could point to malicious code). I may be of course wrong, but need to explore it further when I find more time.

The other interesting thing I noticed is that some existing windows procedures are already written in a way that makes it harder to exploit this issue. They check if the window-specific data was set, and only if it was NOT they allow to call the SetWindowLong function. That is, they avoid executing the same initialization code twice.

Comments Off on PROPagate follow-up #2 – Some more Shattering Attack Potentials

← Previous Entries