You are browsing the archive for Forensic Analysis.

Beyond good ol’ Run key, Part 72

February 9, 2018 in Anti-*, Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Incident Response, Malware Analysis

In my old post I described a simple trick that shows how to set up a hot key that can be assigned to execute shortcuts (.LNK files) placed on a Desktop or in a Start Menu. This action survives reboots and logon/logoffs so it’s a nice, and somehow accidental persistence mechanism.

Turns out there is one more variant of this trick that relies on using the .URL files.

Placing a .URL files containing the following data:

[InternetShortcut]
URL=file:///c:/windows/system32/calc.exe
HotKey=768

on a Desktop will assign CTRL+SHIFT sequence to an action that will trigger the execution of the calculator.

The Hotkey can be assigned either manually (via properties):

– in such case you won’t be able to assign the more trickier combinations like CTRL+SHIFT. Or we can do it manually, and in such case all the hotkey tricks are available. All you have to do is to assign a proper value to the HotKey parameter inside the .url file.

You can find out what values represent what codes or by experimenting… or… you can cheat and read this old guide: An Unofficial Guide to the URL File Format.

 

 

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…