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…

Share this :)

Comments are closed.