Incorrect detection for 46. Explorer Context Menu Hijacking ?

[AlexandruGabriel02]

Hi, nice work on the project!

I was looking at some detections and noticed that 46. Explorer Context Menu Hijacking might have incorrect detection logic. The following is stated:

DLLs in the (Default) property of the "HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers{B7CDF620-DB73-44C0-8611-832B261A0107} key are run when the user right clicks any explorer Window

However, I don't think that this is what's really happening, and here's why (feel free to correct me if you think that anything is wrong):

First and foremost, the GUID (hardcoded in the registry key) is custom so it’s not necessarily unique, it depends on the implementation for the Shell Extension used (which is just a custom COM object that Explorer can use), and, as such, we can’t be sure that this subkey is the right one to look for. My point is that it might as well just have a different GUID when you think how COM objects are created and registered, so there can be cases where looking for this exact hardcoded subkey is useless even though a malicious Shell Extension for the context menu is created.

Second, the DLL is registered as an in-proc server and its path should be found in a key that resembles the following: *\CLSID\{GUID}\InProcServer32 in the (Default) property. As far as I understand, The key HKCR\AllFilesystemObjects\shellex\ContextMenuHandlers is only used to tell Explorer what context menu extensions to look for, but this is done just by using the GUID (either as the subkey name like in the example above, or inside the (Default) value for a subkey with any name), not the actual DLL path.

These would make the detection pretty much useless, as the registry key we are looking for might be different, and, even if it is the right one, the DLL path would be found in a different entry in the registry.

As far as detection goes, the way the registry is being searched should obviously be refactored (first extract the extension GUID, then find the corresponding DLL), but the arising issue here is that we don't know exactly what the GUID for a possible malicious extension is, so all of them should be investigated. Autoruns does a pretty good job at showing shell extensions in general (not specifically for context menu) and can be used as reference for all the registry entries that should be investigated.
Also, the article referenced states that

This technique can be easily detected from the thread stack of explorer.exe or just simply from the registry with Cm kernel callbacks for example

so another idea could be to enumerate the modules loaded by explorer and filter the suspicious ones (for example not in a Windows directory or not signed), but again, this would be a more general approach, not specifically tied to context menu hijacking, which may be a good thing actually:)