PROPagate follow-up #2 – Some more Shattering Attack Potentials

February 4, 2018 in Anti-*, Code Injection, Compromise Detection, EDR, Incident Response, Malware Analysis

A few months back I discovered a new code injection technique that I named PROPagate. Using a subclass of a well-known shatter attack one can modify the callback function pointers inside other processes by using Windows APIs like SetProp, and potentially others. After pointing out a few ideas I put it on a back burner for a while, but I knew I will want to explore some more possibilities in the future.

In particular, I was curious what are the chances one could force the remote process to indirectly call the ‘prohibited’ functions like SetWindowLong, SetClassLong (or their newer alternatives SetWindowLongPtr and SetClassLongPtr), but with the arguments that we control (i.e. from a remote process). These API are ‘prohibited’ because they can only be called in a context of a process that owns them, so we can’t directly call them and target windows that belong to other processes.

It turns out his may be possible!

If there is one common way of using the SetWindowLong API it is to set up pointers, and/or filling-in window-specific memory areas (allocated per window instance) with some values that are initialized immediately after the window is created. The same thing happens when the window is destroyed – during the latter these memory areas are usually freed and set to zeroes, and callbacks are discarded.

These two actions are associated with two very specific window messages:

  • WM_NCCREATE
  • WM_NCDESTROY

In fact, many ‘native’ windows kick off their existence by setting some callbacks in their message handling routines during processing of these two messages.

With that in mind, I started looking at existing processes and got some interesting findings. Here is a snippet of a routine I found inside Windows Explorer that could be potentially abused by a remote process:

Or, it’s disassembly equivalent (in response to WM_NCCREATE message):

So… since we can still freely send messages between windows it would seem that there is a lot of things that can be done here. One could send a specially crafted WM_NCCREATE message to a window that owns this routine and achieve a controlled code execution inside another process (the lParam needs to pass the checks and include pointer to memory area that includes a callback that will be executed afterwards – this callback could point to malicious code). I may be of course wrong, but need to explore it further when I find more time.

The other interesting thing I noticed is that some existing windows procedures are already written in a way that makes it harder to exploit this issue. They check if the window-specific data was set, and only if it was NOT they allow to call the SetWindowLong function. That is, they avoid executing the same initialization code twice.

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…