2.4 Software Keyboard Spies
161
processing WM_KEYDOWN with the help of TranslateMessage). If such message
is identified, it is possible to determine the code of the key pressed and transfer it
to the logging and analysis system (step 4). After that, control is returned to the
application (step 5), which is unaware of the presence of the hook.
Such keyboard spy is extremely dangerous due to the following reasons:
– It cannot be detected by standard keylogger detection methods;
– The hook can be introduced based on specific conditions and thus infect only
specific GUI processes (e.g., browser processes and applications like WebMoney);
– Screen keyboards and other anti-keylogger measures are useless against it;
– In addition to interception of functions PeekMessage and GetMessage, the hook
can also intercept data copying functions during work with the clipboard (OpenClipboard, CloseClipboard, GetClipboardData, and SetClipboardData), functions
of keyboard state polling (GetKeyState, GetAsyncKeyState, and GetKeyboardState), and other functions of user32.dll, which elevates the danger posed by the
keylogger, while interception of functions like CreateWindow helps track creation
of windows.
2.4.2.8 Rootkit-Based Keylogger in Kernel Mode
The operating algorithm of the spy is fairly simple. The application calls the user32.dll
library function (step 1; for example, let us consider a PeekMessage call). The
PeekMessage function in user32.dll is essentially an adapter; ultimately, the kernel
function will be called using SYSCALL in Windows XP or INT 2E in Windows NT
and Windows 2000 (step 2). This call will be intercepted by the spy (hook position
depends on the interception method).
Even though we are going to consider rootkit technologies in detail in the next
sections, let us take a brief look at the principle of their action. It is similar to user
mode, but in this case one or several functions of win32k.sys are intercepted. As with
user mode, the keylogger is mostly interested in the PeekMessage and its analogs,
since they allow it to monitor and modify absolutely all messages received by the
program without installing a hook or a filter.
The hook in Fig. 2.16 is only conventional, since there are various methods of its
installation, in particular:
– Interception of SYSCALL and INT 2E;
– Function interception with substitution of the address in the corresponding cell
of the table KeServiceDescriptorTableShadow. The only difficulty for the creator
of such keylogger is to find such table that is not exported by the kernel and
documented. However, there are known ways to deal with this issue, and the
required means can be found on the Internet;
– Modification of the machine code win32k.sys. It also requires search of the
table KeServiceDescriptorTableShadow. In this case, an interesting situation is
possible: the function can be already intercepted (for example, by anti-keylogger),
161
processing WM_KEYDOWN with the help of TranslateMessage). If such message
is identified, it is possible to determine the code of the key pressed and transfer it
to the logging and analysis system (step 4). After that, control is returned to the
application (step 5), which is unaware of the presence of the hook.
Such keyboard spy is extremely dangerous due to the following reasons:
– It cannot be detected by standard keylogger detection methods;
– The hook can be introduced based on specific conditions and thus infect only
specific GUI processes (e.g., browser processes and applications like WebMoney);
– Screen keyboards and other anti-keylogger measures are useless against it;
– In addition to interception of functions PeekMessage and GetMessage, the hook
can also intercept data copying functions during work with the clipboard (OpenClipboard, CloseClipboard, GetClipboardData, and SetClipboardData), functions
of keyboard state polling (GetKeyState, GetAsyncKeyState, and GetKeyboardState), and other functions of user32.dll, which elevates the danger posed by the
keylogger, while interception of functions like CreateWindow helps track creation
of windows.
2.4.2.8 Rootkit-Based Keylogger in Kernel Mode
The operating algorithm of the spy is fairly simple. The application calls the user32.dll
library function (step 1; for example, let us consider a PeekMessage call). The
PeekMessage function in user32.dll is essentially an adapter; ultimately, the kernel
function will be called using SYSCALL in Windows XP or INT 2E in Windows NT
and Windows 2000 (step 2). This call will be intercepted by the spy (hook position
depends on the interception method).
Even though we are going to consider rootkit technologies in detail in the next
sections, let us take a brief look at the principle of their action. It is similar to user
mode, but in this case one or several functions of win32k.sys are intercepted. As with
user mode, the keylogger is mostly interested in the PeekMessage and its analogs,
since they allow it to monitor and modify absolutely all messages received by the
program without installing a hook or a filter.
The hook in Fig. 2.16 is only conventional, since there are various methods of its
installation, in particular:
– Interception of SYSCALL and INT 2E;
– Function interception with substitution of the address in the corresponding cell
of the table KeServiceDescriptorTableShadow. The only difficulty for the creator
of such keylogger is to find such table that is not exported by the kernel and
documented. However, there are known ways to deal with this issue, and the
required means can be found on the Internet;
– Modification of the machine code win32k.sys. It also requires search of the
table KeServiceDescriptorTableShadow. In this case, an interesting situation is
possible: the function can be already intercepted (for example, by anti-keylogger),