APIs with Trojaning Issues

Some functions, when used incorrectly, could lead to an application loading unintended code. Admittedly, this does mean the attacker has loaded malicious data on the computer being attacked, so you should consider this section as good hygiene and one concerned with defense in depth.

CreateProcess(NULL, ), CreateProcessAsUser, and CreateProcessWithLogon

The first argument is the application path; the second is the command line. If the first argument is null and the second argument has white space in the application path, unintended applications could be executed. For example, if the argument is c:\Program Files\MyApp\MyApp.exe, c:\Program.exe could be executed. A workaround is to specify the application path in the first argument or to double-quote the application path in the second argument.

WinExec and ShellExecute

These functions behave like CreateProcess(NULL, ) and should be used with extreme caution.

LoadLibrary, LoadLibraryEx, and SearchPath

On many versions of the Windows operating system, the current directory is searched first when loading files. If you attempt to load a DLL by using a non-fully-qualified path (for example, file.dll rather than c:\dir\dir\file.dll), the code will look in the current directory first for the code, and if there's a malicious file in the . directory it is loaded first. It's recommended that you always use a full path when using these functions.

Suggestions: If your DLLs are installed with the rest of your application, store your installation directory in the registry and use this to specify a full path to the DLL. If the DLL is stored in a directory owned by the operating system, use GetWindowsDirectory to find the correct DLL. Note issues with systems running Terminal Services.

These are a nonissue in Windows XP SP1 and later and Microsoft Windows .NET Server 2003 because the path is searched differently. The system directories are searched first, followed by the current directory.