This is a LOLbinish 2-stage persistence trick. One where we add startup items to point to OS  binaries, and – while they will be ignored by many users and security solutions (at least at first glance) – they will be launching the second stage of the persistence mechanism for us…

Many people who use win7-win10 know that the Werfault.exe process is all over the place. It’s a process ‘repairer’ or ‘fixer’ that handles crashes or other unpleasant activities of other processes. It turns out you can launch werfault.exe with a number of specific command line arguments. One of these modes is called ‘reflective debugger’ and is very interesting to us. To launch werfault in this mode we need to provide the following parameters:

• werfault.exe -pr <somevalue>

And  how does it load the debugger?

By reading:

• HKLM\Software\Microsoft\Windows\
  Windows Error Reporting\Hangs\ReflectDebugger=
  <path>

and… executing it.

That’s it.

So if we add a Run key like this:

– it will in the end launch our program of choice when the user logs on.

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 🙂