Registry is the large database where Windows stores all the system, security and software specific settings. It is a tree like structure, which can be viewed or modified using the standard windows utilities such as Regedit.
In addition to all system settings, Registry also contains various startup entries for processes and services that are started when Windows starts. For example, all Windows services are stored under the following Registry key,
'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services'.
Similarly the startup process entries can be found in the following Registry keys,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\explorer\Run
Rootkits generally modifies these entry points to start their own processes, services or drivers. So it's important for the Rootkit to hide these registry entries to prevent its detection from various system-monitoring tools such as Autoruns, HijackThis, etc.
Rootkits can employ various methods to hide their registry infiltration. One of the most commonly used techniques is hooking the registry API functions such as RegOpenKey, RegEnumKey, RegEnumValue etc. To be more effective, Rootkits typically hook NT version of these functions namely NtOpenKey, NtEnumerateKey and NtEnumerateValueKey. So when any one calls these registry functions, hooked function will return the filtered results there by hiding its presence.
Most common detection mechanism used in these cases is the cross-view comparison method. In this method initially, high level registry API functions (such as RegEnumKey, RegEnumValue) are used to enumerate the keys and values. Next the lower level methods are used to enumerate same registry keys. Then the both results are compared to determine the hidden Rootkit entries.
Many such lower level techniques exist to enumerate keys. Here we will be discussing about two such prominent methods in detail.
As mentioned previously, Rootkits hide their registry entries by hooking the lower level NT functions. In order to effectively detect these entries, one can directly invoke those NT functions rather than using API functions. Every NT function in Windows is uniquely identified through its service number (For NtEnumerateKey its 0x47). So instead of calling these NT functions, one can directly call these functions by using INT 2E (for Windows 2K) or Sysenter (Windows XP onwards) instruction by passing the respective service number.
Here is the direct implementation of NtEnumerateKey and NtEnumerateValueKey function, which can be directly called to bypass any API level hooks put by the Rootkits.
//For Windows XP, for other platforms only service number will differ
_declspec(naked)
NTSTATUS __stdcall DirectNtEnumerateKey(
IN HANDLE KeyHandle,
IN ULONG Index,
IN KEY_INFORMATION_CLASS KeyInformationClass,
OUT PVOID KeyInformation,
IN ULONG KeyInformationLength,
OUT PULONG ResultLength )
{
__asm
{
mov eax, 0x47
call DirectCall_XP
ret 0x18
DirectCall_XP:
mov edx, esp
sysenter
}
}//For Windows XP, for other platforms only service number will differ
_declspec(naked)
NTSTATUS __stdcall DirectNtEnumerateValueKey(
IN HANDLE KeyHandle,
IN ULONG Index,
IN KEY_VALUE_INFORMATION_CLASS KeyValueInformationClass,
OUT PVOID KeyValueInformation,
IN ULONG KeyValueInformationLength,
OUT PULONG ResultLength )
{
__asm
{
mov eax, 0x49
call DirectCall_XP
ret 0x18
DirectCall_XP:
mov edx, esp
sysenter
}
}Rootkits may also hook the NtOpenKey function to prevent any hidden key from being opened. So it will become useless even if one is able to discover the key name. In such case, one can use direct NtOpenKey function as shown below...
//For Windows XP, for other platforms only service number will differ
_declspec(naked)
NTSTATUS __stdcall DirectNtOpenKey(
OUT PHANDLE KeyHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes )
{
__asm
{
mov eax, 0x77
call DirectCall_XP
ret 0x0C
DirectCall_XP:
mov edx, esp
sysenter
}
}Though Rootkits can bypass this technique by hooking the above-mentioned NT functions in the kernel, it presents simple but very effective mechanism to detect any hidden Rootkit registry entries in user land.
Entire Windows registry is stored in the different files called Hives in a standard format. A different portion of registry is stored in respective hive files such as SYSTEM, SOFTWARE, SECURITY, SAM, etc. in the 'C:\Windows\System32\Config' folder. Though the internal format of these registry hive file is undocumented, lot of code samples and good amount of documentation can be found on the net.
While these hive files cannot be accessed while Windows is running as they are locked, one can use the API function RegSaveKey or equivalent NT function NtSaveKey to save the registry data to the chosen file. Then this saved file can be manually traversed to get the low level view of the registry entries. Detailed code sample to traverse the hive file can be found in the article [1] 'How to avoid the detection of hidden regkey by hooking RegSaveKeyA' written by EiNSTeiN_. Also the whitepaper [2] 'Detection of Rootkits in Windows registry' by miel-labs explains in detail the complete structure of registry hive file.
Once the registry entries are obtained by traversing the hive file, it is compared against the high level view got through normal registry API functions such as RegEnumKey, RegEnumValue etc. During this process, any additional entries discovered will be marked as hidden rootkit registry entries.
Though this method involves using undocumented registry hive traversal method, it can even uncover the registry entries hidden through kernel land SSDT hooks.
The techniques described here are from the userland perspective and Rootkits operating in Kernel land can bypass these techniques. Nevertheless these methods present very simple and powerful methods to detect any registry entries hidden by userland Rootkits.
Spy DLL Remover
Tools-SpyDLLRemover
Rootkit Analytics
Hidden Process Detection
Tools-Elfstat
Spy DLL Remover32264
Elfstat1054
KsiD670
SHC504
dwtf415
