Secumania Security and Vulnerability Research Lab

On Windows operating systems, most of the times people should only blame theirselves for getting infected by malware, because they are not cautious when the operating system warns them about eg. opening "sexy-pictures.exe" and similar, received by e-mail and instant messengers.. Not only can these malwares steal sensitive data and give the creator(s) remote access and at times make the computer a "zombie" of a botnet but also make the infection obvious by hijacking the webbrowser and the user´s desktop. In the case of hijacking the desktop they usually display porn banners, sometimes they put a message telling the user needs to purchase a specific Antivirus software to get rid of malware installed on the computer as well, so that they are able to steal money and credit card information.

Not satisfied in making the infection obvious, malware creators also like to add a startup entry to popular registry locations such as the :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

In the "Shell" string value they append data so it will be set to something like this : "Explorer.exe malware.exe" and then they place the file "malware.exe" in the system directory and it will be started by Windows Explorer on every boot. As these malwares can, for instance, hijack the desktop, nothing more fair than hijacking them as a reward, right?

Well, sure! By abusing the creators lack of knowledge or lack of patience to write code properly/safely, we can hijack their execution in case they edit the above entry (which is widely used by malwares) without even touching the registry and without even having administrative privileges, on Windows XP, 2000, 2003 Server. All we have to do is place an executable called "malware.exe" in the current logged on user´s base directory (%userprofile%). Because Windows Explorer on the above versions of Windows starts in the user´s base directory and malware writers usually don´t provide a full path to their malware we are able to successfully hijack the execution of it, rendering it "dead" in the system in case of course it didnt add additional startup entries. This issue happens because of a common vulnerability in Windows OS : Relative paths! This rised security problems in the past and is also the cause for another vulnerability I posted in march of 2010, in the HTML Help Control´s (hhctrl.ocx) function "HTMLHelpA()" that loads CHM help files from the same directory where the program invoking help starts in, and was the source for the "Remote DLL Loading Hijack" mess.