Category Archives: Autostart (Persistence)

Beyond good ol’ Run key, Part 84

Posted on by

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 🙂

Beyond good ol’ Run key, Part 83

Posted on by

If you ever downloaded a file using IE, Firefox, Chrome, Thunderbird you might have seen messages from these programs telling you that the files being downloaded are being scanned by the antivirus program. The way the scanning works on Windows is quie simple: the programs use IOfficeAntiVirus and IAttachmentExecute interfaces. These in turn rely on a Registry entries for COM objects that implement the ‘antivirus’ category and advertise it by adding ‘tags’ under their respective CLSID entries.

The ‘tag’ for IOfficeAntiVirus is a GUID 56FFCC30-D398-11D0-B2AE-00A0C908FA49). For example, ‘Windows Defender IOfficeAntiVirus implementation’ has the following Registry entry:

  • HKCR\CLSID\{2781761E-28E0-4109-99FE-B9D127C57AFE}
    • (Default) = Windows Defender IOfficeAntiVirus implementation
    • …
    • Implemented Categories
      • {56FFCC30-D398-11D0-B2AE-00A0C908FA49}

When IOfficeAntiVirus::Scan method is called by the programs (or internally via IAttachmentExecute) the system enumerates the Registry, collects info about all components implementing IOfficeAntiVirus, and stores them inside the following location:

  • HKCU\Software\Microsoft\Windows\
    CurrentVersion\Explorer\Discardable\
    PostSetup\Component Categories\
    {56FFCC30-D398-11D0-B2AE-00A0C908FA49}\
    Enum

and its 64-bit version equivalent:

  • HKCU\Software\Microsoft\Windows\
    CurrentVersion\Explorer\Discardable\
    PostSetup\Component Categories64\
    {56FFCC30-D398-11D0-B2AE-00A0C908FA49}\
    Enum

It then instantiates them, and calls the Scan method one by one. The Registry enumeration is quite slow so the caching mechanism (obviously) speeds things up (as a result, any new component added should always delete this cache to ensure it is properly loaded next time the Scan method is called).

The topic is very old, and there are tones of descriptions, discussions, and actual sample code snippets available online, but it’s always worth documenting possible persistence mechanisms.

References:

  • A source code showing on how to implement IOfficeAntiVirus component can be found here.
  • A good discussion about both interfaces (IOfficeAntiVirus and IAttachmentExecute) with regards to Firefox can be found here.
  • A source code of Firefox using these interfaces can be found here.
  • A good discussion about the interfaces, their internals and their impact on Chrome development can be found here.

And in case it’s not obvious yet, a custom component implementing IOfficeAntiVirus interface could act as a very persistent ‘antivirus’ 🙂