A possible extension of Extra Window Memory Injection (EWMI) Via SetWindowLong

This is just a note with regards a question I sent to Endgame.

While reading their excellent post ‘Ten Process Injection Techniques‘ it crossed my mind that the technique they refer to as ‘Extra Window Memory Injection (EWMI) Via SetWindowLong’ and which was previously used by Gapz and PowerLoader could be potentially extended to make it undetectable (at least temporarily).

How?

The technique relies on ‘talking’ to the ‘Shell_TrayWnd’ window.

Nowadays it’s not uncommon to have multi-monitor setups where users have two taskbars. The taskbar on the primary screen is still using the ‘Shell_TrayWnd’ class while other displays use a different class name called ‘Shell_SecondaryTrayWnd’. So, given the functionality is almost identical there is a high possibility the trick could work on the secondary tray window class. I have not tested it, but I would expect it to work.

Will update the post when I hear more/test it myself.

Beyond good ol’ Run key, Part 84

This is just a blurb to include this particular technique in the series. It’s not new at all, and it has been covered in the past by others e.g. recent ‘Windows Operating System Archaeology’ preso by @enigma0x3 and @subTee. IMHO it’s still worth documenting it anyway.

COM Objects are created when the program calls one of the instantiation APIs e.g. CoCreateInstance. The API takes the CLSID, finds its entry in the Registry (under CLSID node) and loads the DLL or EXE associated with it (it’s a bit more complex than that, but that’s the gist of it).

Now, if the CLSID  entry contains the key ‘TreatAs’ the instantiation process will change – the API will pick up a CLSID that ‘TreatAs’ points to and instantiate this object instead. This allows anyone to hook all the instantiation events of a particular COM object and as a result load anytime that object is istantiated. Which sounds like a nice persistence trick…

This is actually a documented feature and it’s described on MSDN in a help for the CoTreatAsClass API and the TreatAs key itself; the internals were also described in this Microsoft blog post.

So… anytime you see ‘TreatAs’ key, ensure it’s not a COM hijack 🙂