Svchost.exe is a generic host process for services that run from DLLs, and Windows systems often have many instances of svchost.exe running at once. Each instance of svchost.exe contains a group of services that makes development, testing, and service group management easier. The groups are defined at the following registry location (each value represents a different group):
. The difference is obvious: the trojanized version jumps to another location.jmp
back to the original DllEntryPoint
method.DLL load-order hijacking is a simple, covert technique that allows malware authors to create persistent, malicious DLLs without the need for a registry entry or trojanized binary. This technique does not even require a separate malicious loader, as it capitalizes on the way DLLs are loaded by Windows.
The default search order for loading DLLs on Windows XP is as follows:
The directory from which the application loaded
The current directory
The system directory (the GetSystemDirectory
function is used to get the path, such as .../Windows/System32/)
The 16-bit system directory (such as .../Windows/System/)
The Windows directory (the GetWindowsDirectory
function is used to get the path, such as .../Windows/)
The directories listed in the PATH
environment variable
Under Windows XP, the DLL loading process can be skipped by utilizing the KnownDLLs
registry key, which contains a list of specific DLL locations, typically located in .../Windows/System32/. The KnownDLLs
mechanism is designed to improve security (malicious DLLs can’t be placed higher in the load order) and speed (Windows does not need to conduct the default search in the preceding list), but it contains only a short list of the most important DLLs.
DLL load-order hijacking can be used on binaries in directories other than /System32 that load DLLs in /System32 that are not protected by KnownDLLs
. For example, explorer.exe in the /Windows directory loads ntshrui.dll found in /System32. Because ntshrui.dll is not a known DLL, the default search is followed, and the /Windows directory is checked before /System32. If a malicious DLL named ntshrui.dll is placed in /Windows, it will be loaded in place of the legitimate DLL. The malicious DLL can then load the real DLL to ensure that the system continues to run properly.
Any startup binary not found in /System32 is vulnerable to this attack, and explorer.exe has roughly 50 vulnerable DLLs. Additionally, known DLLs are not fully protected due to recursive imports, and because many DLLs load other DLLs, which follow the default search order.