I love Windows Explorer. It offers so many opportunities for persistence.

In my older post I described how you can modify the HCKR shell entries by adding a new verb and changing the default behavior of Windows Explorer to use that verb when it enters folders.

Here’s another trick you can pull off.

There is a way to add cascading menus for different file types – it enables everyone to enrich the GUI experience, and of course, can be abused.

Say… we want to change the handling of .txt files to ‘default’ to our own Cascading menu which we call, well… ‘Open’ and make it look like this:

I bet users seeing such change will still go for the ‘bold’ default action and Launch the Notepad.

Except it will launch Calculator.

How did we get there?

All we have to do is:

• Introduce a cascading menu for .txt files
  • HKCR\txtfile\shell\submenu
    • “MUIVerb”=”Open”
    • “SubCommands”=”Windows.testverb”
    • “Position”=”Top”
• The above ensures the new cascading menu goes on the top of the list + is called ‘Open’ + when it launches it calls the verb ‘Windows.testverb’
• Define the ‘Windows.testverb’ verb under
  HKLM\SOFTWARE\Microsoft\Windows\
  CurrentVersion\Explorer\CommandStore\
  shell\Windows.testverb
  • MUIVerb=Notepad
  • command
    • (Default)=@=”c:\\windows\\system32\\calc.exe”
• The above defines the verb as one that is called ‘Notepad’ and that launches a calculator when the verb is triggered

It’s pretty simple and may fool some users.

Then there is an additional bonus entry. As if there was not enough confusion yet…

It looks like there is another way to add cascading menus – via ExtendedSubCommandsKey.

Again, it’s documented, but I couldn’t make it work at first, until I started toying around with the existing entries in Registry – they used ‘ExtendedSubCommandsKey’ not as a key, but as a value.

This is how it works…

And this is how to set it up:

• Add HKCR\txtfile\shell\extsub
  • MUIVerb=Open
  • ExtendedSubCommandsKey=txtfile\\shell\\extsub
  • Position=Top
• Add HKCR\txtfile\shell\extsub\Shell\Notepad, and underneath
  • command
    • @=”c:\\windows\\system32\\calc.exe”

So.. the ‘ExtendedSubCommandsKey’ key tells Shell where to look for the definition of the cascading menu – note the nested ‘shell\extsub\shell\notepad\command’ key (case insensitive) vs ‘shell\open\command’:

And because of that… there is more.

Instead of dropping the definition of the cascading menu under the obvious location ‘txtfile’, one could define it like this:

• Add HKCR\txtfile\shell\extsub
  • MUIVerb=Open
  • ExtendedSubCommandsKey=foofile
  • Position=Top
• Add HKCR\foofile\Shell\Notepad
  • command
  • @=”c:\\windows\\system32\\calc.exe”

So… the malware could add a new ‘filetype’ called ‘foofile’ and use it as a definition for the cascading menu that is referenced by the ‘ExtendedSubCommandsKey’ entry.

I think you might have noticed that the demos show the multiple ‘Open’ entries on the menu. One could remove the definition of the ‘Open’ verb from the respective keys, but while it’s easy, it could trigger some EDR/AV alerts. I may be a bit too optimistic, but I bet many people will still follow the ‘bold’ menu item first, despite menu item duplications (‘it’s Windows, after all’).

And yes, there is more…

Shell uses at least 2 more mechanisms to add menus or redefine how the verbs are used on the selected items in Windows Explorer.

• There is a documented IExplorerCommand interface
• There are special entries under the HKCR that can be used to modify the behavior of the respective menu items
  • DefaultAppliesTo
  • AppliesTo

I am not describing the first one (you need to develop a COM DLL), but the second one deserves some attention.

Turns out that there is a way to implement conditional menu items for Windows Explorer. Yup. Windows Explorer understands a language called Advanced Query Syntax. There are not too many practical examples of its usage online, the best (practical) information I could find is in this post. Plus, there are default Windows 10 Registry settings we can explore.

Have a look at these keys:

• HKCR\*\shell\UpdateEncryptionSettingsWork

The AppliesTo includes this query:

System.StorageProviderId:<>"network" AND 
System.StorageProviderProtectionMode:<>1 AND 
System.StorageProviderProtectionMode:<>2

• HKCR\DeviceDisplayObject\AllItems\Shell\Microsoft.DxpOpen

System.Devices.LaunchDeviceStageFromExplorer:=
System.StructuredQueryType.Boolean#True

• HKCR\Drive\shell\change-passphrase\command

(
System.Volume.BitLockerProtection:=
System.Volume.BitLockerProtection#On OR 
System.Volume.BitLockerProtection:=
System.Volume.BitLockerProtection#Encrypting OR
System.Volume.BitLockerProtection:=
System.Volume.BitLockerProtection#Suspended
)
AND 
System.Volume.BitLockerCanChangePassphraseByProxy:=
System.StructuredQueryType.Boolean#True

and others… (just search for ‘AppliesTo’ under HKCR).

Every single one that is ‘predefined’ (command is set) can be modified and help to establish yet another persistence mechanism that is triggered only when conditions are met (e.g. as per the above – when drive is encrypted malware could be launched when the user tries to change the passphrase).

I guess it’s yet another not-so-much-explored area in case you are looking for forensics/malware topics for your final thesis 🙂