You are browsing the archive for Archaeology.

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:


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…

Beyond good ol’ Run key, Part 70

December 30, 2017 in Anti-*, Anti-Forensics, Archaeology, Autostart (Persistence), Forensic Analysis, Incident Response, Malware Analysis

Back in early 2000s shell extensions and desktop enhancers were very popular. Some of these ideas survived till today and even now one can either use pre-installed ones, or install new deskbands on the system.

There are many coders who already did a great job explaining what desk bands are and how to implement them, so instead of pretending that I know what I am talking about, I will just suggest that you read this great article ‘Shell Extensibility – Explorer Desk Band, Tray Notification Icon et al.‘ by Alex Blekhman. When you run the Calendar.exe that is attached to the article you will then have an option to make the calendar present as a Deskband

Interestingly enough, as far as I can tell Autoruns still doesn’t detect them.

To find out where the information about deskbands and other Explorer extension bars is stored in Registry you can read this article.

If you are in a hurry, just need to enumerate Registry and look for all CLSIDs with the Implemented Categories\ key with the following deskband identifiers set:





Implemented Categories\{00021492-0000-0000-C000-000000000046}

Additionally, it may be worth checking the following key:

Discardable\PostSetup\Component Categories\...\Enum

This is where Explorer stores cached information about explorer bar objects.