You are browsing the archive for Archaeology.

Two old-school download/exfil methods

May 25, 2018 in Anti-Forensics, Archaeology, Code Injection, Compromise Detection

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.

Beyond good ol’ Run key, Part 71

January 28, 2018 in Anti-*, Anti-Forensics, Archaeology, Autostart (Persistence), Forensic Analysis, Incident Response, Malware Analysis

Today I will describe a persistence mechanism that doesn’t seem to work. The reason why I still include it is because it may save you some time if you come across this registry key and want to research it. It may also trigger some research that will make it work, so who knows… Perhaps still worth monitoring changes to the registry key described below.

The alg.exe process is used in conjunction with other services to deliver Application Layer Gateway mechanism to Windows OS. The wikipedia describes what it does in detail, so I’ll focus only on so-called Application Layer Gateway (ALG) Plugins.

I am not the first to stumble upon this – there is a programmer who in 2009 tried to develop one such plug-in but couldn’t make it work.

So… here’s the theory.

The alg.exe process is a service process. On Windows XP the ALG service is launched when you e.g. enable Windows Firewall.

Anytime it runs it is supposed to load the ALG plugins and keep an eye (monitors change via notification) on the following registry key:

  • HKLM\SOFTWARE\Microsoft\ALG\ISV

Any changes to this node will force the alg.exe process to re-load ALG Plug-ins.

The only plug-in that is present in a standard installation of Windows is {6E590D61-F6BC-4dad-AC21-7DC40D304059} that handles the ‘FTP Client/Server Protocol’. Numerous posts online talk about modifying this key properties to enable passive FTP protocol and troubleshoot FTP protocol issues in general.

That’s the theory.

After discovering this mechanism I of course tried to develop my own plugin and force it to load, but was unsuccessful. I then found the aforementioned post from 2009 and decided to publish my findings.

I kinda know what it doesn’t work. Despite being able to force the alg.exe to enumerate the HKLM\SOFTWARE\Microsoft\ALG\ISV key nothing happened (what should happen is the COM instantiation).

Looking briefly at the code related to plug-in refresh I noticed there seem to be a lot of check if the loaded plugin is actually the default ‘FTP Client/Server Protocol’ plug-in. It’s possible it is the only plug-in that can be loaded as is… whitelisted via hardcoded checks.

I guess it’s one of these projects that one has to put on a back burner…