Beyond good ol’ Run key, Part 78

Here’s a quick persistence mechanism for you: we all know that you can change the HKCR settings for file extensions to introduce a malicious proxy executable that can then launch the appropriate file. Changes to HKCR’s .exe, .txt, handlers are as old as Windows malware itself.

It turns out that you can apply the same trick to folders, and you can do so with an extra twist. To do so, just add these Registry entries:

  • HKCR\Folder\shell\(default)=test
  • HKCR\Folder\shell\test\command
    @=”notepad.exe”

And from now on, anytime you open any folder in Windows Explorer the notepad.exe will launch. And for the twist –  note that we are introducing a new ‘verb’ called ‘test’ for Shell and not modifying the ‘open’ command; spotting this may be much harder as you need the security solution to read what the default verb is first, then read its settings from the Registry. You can leverage this trick to modify shell’s behavior for any file type.

Obviously, such changes may ruin the user’s folder browsing experience, but Notepad is now a folder parasite and is here to stay…

If you wanted to be a bit more sneaky, and apply it to specific folders only, e.g. Recycle Bin, you just need to add (in this case we modify the ‘open’ verb settings, for simplicity):

HKCR\CLSID\{645FF040-5081-101B-9F08-00AA002F954E}\shell\open\command
@=”c:\\windows\\system32\\calc.exe”

Where the 645FF040-5081-101B-9F08-00AA002F954E CLSID refers to Recycle Bin folder. Same goes for other special folders (as long as they are supported on your Windows version – win8/10 changes a lot here as they introduce that awful AOLish Start Menu).

 

Two old-school download/exfil methods

Sending and receiving network data is always tricky.

With AV, EDR, and dozen of other agents that are installed on the system nowadays it is getting harder and harder to transfer data, because security applications may be actively monitoring specific system/API calls, or just following strict network rules with regards to non-approved apps. Often, if the app is not on the whitelist no connection out can be made.

There are numerous known ways to bypass it, of course; here, I re-discover two very, very and I mean it… very, very old-school techniques that rely on IE browser and its support of Dynamic Data Exchange (DDE) and Microsoft Active Accessibility (MSAA) functionalities. They have most likely only a historical meaning today: new versions of Windows are shipped with Microsoft Edge and the tabbed interface adds additional complexity…

As I mentioned, these two methods are almost completely forgotten. One of them was actively used by old malware (10+ years ago), the other was successfully leveraged by various IE Spies that helped to look at the source code of blocked/inaccessible IE windows + any application that was relying on the HTML-based user interface (it was very prevalent back in early 2000s e.g. think of Norton products from that era).

The first method is DDE/WWW_OpenURL command. As long as IE is open you can send it a DDE command WWW_OpenURL with the URL of your choice. Sending data out this way is trivial (although limited in length), receiving requires either accessing the IE instance, or just enumerating the TIF directory. The method is not clean per se as it was designed long time ago and was not prepared for the tabbed interface. It may affect the user’s browsing experience.

The second one is more esoteric. You can enumerate all windows classes and find windows with a class ‘Internet Explorer_Server’ (Old IE web browser container, prior to Edge; also note: you cnn always launch new instance of IE as well, and make it a hidden window). Once such window is identified, you can send it a very specific message called WM_HTML_GETOBJECT, and process the result using a ObjectFromLresult function. The result will give you an access to a IHTMLDocument2 pointer for that IE instance. With that pointer, you can walk through a couple of COM queries and retrieve the IWebBrowser2 interface of the Web control container. And with that, you can access an active instance of IE browser from your program and manipulate it freely to download and send out whatever you want. Unless security solution monitors these requests specifically you may not be able to spot the bad guy…

I did say that these methods have most likely only a historical meaning today as new versions of Windows are shipped with Microsoft Edge and the tabbed interface adds additional complexity, but… as this thread suggests, perhaps the support for MSAA implemented by modern browsers still offers some interesting possibilities? And probably here it is a good time to remind you of my old post talking about using the accessibility APIs to develop keylogging functionality w/o using any typical well-known keylogging APIs.

And last, but not least. At some stage I was looking at the possibility of using the DDE and WM_HTML_GETOBJECT tricks to develop a new code injection technique. Since we can access the browser’s process via other means than a regular WriteProcessMemory it definitely may come handy. And the simplicity of the idea relies on the fact that we can actually forget the shellcodes for a moment, and the code injection can rely on… JavaScript code.