Below is a graphic that enumerates some methods of password pilfering, which serves as an introduction to the matter discussed:

1. Introduction

In this article, we will be discussing mainly software keyloggers and user-mode ones in particular and the different techniques they embody. We start with a brief analysis of some common traits and miscellaneous information about keyloggers and have provided some statistics, followed by a summary of the pros and cons of the different types of keyloggers, and then we discuss three types of user-mode or user-space keyloggers. Furthermore, we have provided a pseudocode for all three of them that sheds light on the code behind this predominantly malicious software. Lastly, we discuss the different types of hooks for Windows.

  1. Non-reprehensible usages:

    To start with, keyloggers may have several benevolent usages – such as parental control, employee monitoring, or personal information and password retrieval (this is the case when you want your data to be recorded on the keylogger so that, in case of a system crash, you can retrieve all the lost information on your machine via the keylogger).

  2. The most popular methods of creating or constructing keyloggers:
  • The most widely used method for creating keyloggers is by using the SetWindowsHook API function. The system hook intercepts keypress notifications and is installed using the abovementioned API function for messages transmitted by the Window procedure. It is most commonly made in C.
  • The second most common method is through the WinAPI’s GetKeyboardState and Get(Async)Keystate, which involves requesting cyclical information from the keyboard. It is frequently created using the Visual Basic programming language and less frequently using Borland Delphi.
  • Тhe third method, in terms of usage pervasiveness, is by utilizing a filter driver (kernel-based keyloggers) – such keyloggers require expert knowledge from their authors and they are created using the C programming language.

1.3 Statistics


According to Webroot’s SpyAudit, 15% of all corporate machines that were tested had a functioning keylogger installed. British security company Sophos asserted that the number of keyloggers has tripled in the period of 12 months. Nonetheless, Webroot showed a less vigorous increase in keyloggers – they claimed the prevalence of keyloggers on computers has only been doubled—from around 8% in 2004 to 15% in 2005.

  1. Source of the statistics: Gregg Keizer, “Keyloggers Foiled In Attempted $423 Million Bank Heist.” Available at:


    The chart below shows the percentage of distribution of the three most commonly used keylogger structures:

    Source of the statistics: Nikolay Grebennikov, “Keyloggers: How They Work and How to Detect Them (Part 1)”. Available at:

    According to George Waller, most studies indicate that the number of US firms invaded by keyloggers and other malware is around 60% each year.

2. Pros and Cons of the Various Types of Keyloggers

  1. Disadvantages and advantages of kernel/driver keyloggers


  • Kernel/driver keyloggers cannot take hold of autocomplete passwords, since those are dealt with by the application layer.
  • They are challenging to create.
  • They require knowledge of how keyboards function.


  • They are quite difficult to detect and remove, especially by user-space applications.
  • They have an opportunity to get access to all keyboard data as it travels to the OS.
  • Activity logs may be accessed remotely over the Internet, from a safe distance.
  • They collect information directly from the peripheral (most commonly, the keyboard).
  • It is possible to make them practically undetectable by exploiting the fact that they are executed upon boot, in advance of all user-mode applications.
  • As they substitute for the software in charge of interpreting keystrokes, stemming also from the previous point, they are hardly detectable by user-mode applications, which further makes them challenging to combat.
  1. Advantages and disadvantages of user-mode keyloggers:


  • Activity logs may be accessed remotely over the Internet.
  • They are relatively easy to create


  • They are easily detectable.
  • They can sometimes provide duplicate keypresses or miss a keypress.
  • Some techniques of user-mode keyloggers are noticeable by the user himself because they overload the system.
  1. Advantages and disadvantages of hardware-based keyloggers:


  • Installation is fast and simple.
  • No application or process is visible on the victim’s machine.
  • They capture events before they have reached the target application.


  • An extra part is inserted into the machine, which might be noticed by some computer users but, in general, they go undetected because of their small size.
  • They can store only a limited amount of data.
  • The keylogging initiator must have physical access to the place/room where the victim’s machine is located and be able to go there once to set up the keylogger and once to retrieve it along with the collected data.
  • Activity logs cannot be accessed remotely over the Internet.

3. User-Space Software Keyloggers

First off, we will start with the different techniques on which user-space software keyloggers may be based. User-space keyloggers are considered the simplest type of keyloggers to create, but their detection is also not problematic because they take advantage of acknowledged and well-known Win32 API functions to capture keypress and mouse events.

There are three techniques that are not dependent on concrete applications and can be used for creating user-space keyloggers. These are polling, event copying, and event monitoring; we are going to discuss each of these below.

  1. Polling Keyloggers

    Polling involves checking frequently and repetitively for user input. Generally, polling can be considered as an anti-social action because the process of carrying it out involves the loss of otherwise fruitful computing time but, for script kiddies and black-hats, this is a reasonable cost for reaping results.
    Such keyloggers do not make any straightforward query to the hardware but are calling an API function that is in charge of returning the keyboard state in an array. It is not mandatory for the keyboard state to coincide with the physical keys located on the keyboard; rather, the keyboard state corresponds to virtual keys, although there is often some connection between the physical and the virtual keys. These virtual keys are immaterial and their aim is to offset different keyboards as keyboards around the world differ from country to country. The may differ because of 1. Keyboard localization for the particular language in the country; 2. Keyboard using somewhat different keys; or 3. Different keyboard layouts (such as using Dvorak or Colemak instead of QWERTY).

    The state returned for the virtual keys would comprise no less than one bit, which serves to pinpoint whether you are currently pressing the key. To illustrate, 1 may signify a pressed key whereas 0 signifies a key that is not pressed. If the keyboard state is polled repeatedly and sufficiently often, the keylogger would record the user’s keyboard input.

    There is no single definition of what “sufficiently often” and it is a complete engineering compromise, in general, it depends on the typing speed of the victim. This compromise is crucial for the proper functioning of the keylogger because, if it polls too often, it would not only use up too much CPU time (and there is great chance that this will make the computer sluggish enough for the victim to become aware of the malware) but it will also wrongly provide duplicates of the pressed keys, while polling insufficiently often may lead to keys that are actually typed by the victim being left out of the recording. The keylogger may show duplicate keypresses if the polling is not well-adjusted because the victim may be taking his time to release the key, making his speed too slow for the polling interval that is set.

    Below is pseudocode illustrating some characteristics of event-monitoring keyloggers. Note that what is shown in the illustration may not accurately present the way event-monitoring keyloggers work and their source code.

    Click to Enlarge

    Click to Enlarge

  2. Event-Copying Keylogger

    In any GUI, each action is signified by events. Pressing a key, moving the mouse, and resizing windows are all considered events. GUI applications are formed as a loop called an event loop that awaits new events, defines the nature of the event, and reacts to it via an action. Typical GUI applications collect events for their own windows, but they do not collect events for windows pertaining to other applications.

    Event-copying keyloggers apply API calls to demand that events from any targeted window(s) be replicated and sent to the keylogger as well, which enables the keylogger and its holder to be informed of any new events in the window(s) of interest.

    Below is pseudocode illustrating some characteristics of event-monitoring keyloggers. Note that what is shown in the illustration may not accurately present the way event-monitoring keyloggers work and their source code.

    Click to Enlarge

    Click to Enlarge

  3. Event-Monitoring Keyloggers

    With regard to systems based on GUI, event monitoring is usually applied when the keylogger is able to directly identify events connected with key pressing. There is one main difference between event-monitoring and event-copying keyloggers; event-monitoring keyloggers have the ability to access new events before the targeted application can access them. Furthermore, it can be deduced that an event-monitoring keylogger may easily remove any event it wishes without the targeted application ever being made aware of the existence of these events.

    The pseudocode example given below is almost the same as the pseudocode for an event-copying keylogger, the difference being that the events have to be propagated in a clearly expressed manner.

    Click to Enlarge

    Click to Enlarge

    Despite the fact that event-monitoring keyloggers look like a petty variation of event-copying keyloggers, they are worth mentioning because they are instruments of user-space keylogging in the Windows OS. It is possible to hook some events, including keyboard events, through the API function SetWindowsHookEx. The SetWindowsHookEx function registers a hook procedure and, each time a keypress event occurs, the function will be called. Furthermore, it is possible for numerous hook procedures to be registered, which leads to new hook procedures being inserted in the beginning of a hook chain (a hook chain being a listing of hook procedures that are consecutively called for every single keyboard event). Also, what determines whether the event will be propagated to additional hook procedures and the targeted application depends on the return value of the hook procedure.

  4. Keyboard Hooks & Initializing Hooks for Keypress Events

    The Windows OS has a number of types of hooks; every single one of them grants access to a concrete part of the mechanism of messaging.

    Below is a table which enumerates some of the hooks preferred by black-hats and script kiddies for the creation of keyloggers (although possibly all hooks are of interest for these groups of people) along with a brief description of the hook

    Name of the hook Description
    WH_KEYBOARD_LL The hook allows keyboard input events about to be posted in a thread input queue to be monitored
    WH_KEYBOARD This hook allows the message traffic for messages from WM_KEYDOWN* and WM_KEYUP* that are about to be returned by means of the GetMessage** or PeekMessage** function to be monitored by an application. Hence, WH_KEYBOARD can be utilized for monitoring keypress events posted to a message queue.

    *WM_KEYDOWN and *WM_KEYUP are being posted to the window in which the keypress event occurred. They are used for non-system keystrokes (system keystrokes are the keys that are pressed while holding ALT). The difference between them is that WM_KEYDOWN is posted to the window when a key is pressed while WM_KEYUP is posted when it is released. Actually, Windows sends to the window a sequence of WM_KEYDOWN messages followed by one WM_KEYUP message after the key has been released.

    ** The GetMessage function retrieves messages from the calling thread’s message queue as it dispatches sent messages that are incoming in anticipation of the availability of the posted message for retrieval. The difference between the GetMessage and the PeekMessage function is that the PeekMessage one would not await the message to be posted before returning.WH_GETMESSAGEUsed to intercept events from the thread event queue.WH_CBTThis hook can be used to intercept numerous events, including but not limited to remote keypress events from the victim’s system hardware input queue.

    The system would call this hook procedure on a variety of occasions such as destroying, minimizing or maximizing, resizing or moving a window, as well as before erasing a mouse/keyboard event from the message queue and before adjusting the input focus. The hook procedure’s value decides if the system would allow or disallow such operations.WH_JOURNALRECORDThis hook allows one both to monitor and to record input events. It is a global hook, barring one from using it in a particular thread. Generally, it is used in conjunction with WH_JOURNALPLAYBACK because the latter allows playback of recorded sequences of mouse and keyboard input.WH_JOURNALPLAYBACKAllows messages to be added to the message queue of the system by an application. The hook may also be used to play back sequences of mouse/keyboard input.

    “Hooking” is a technique for capturing events through various functions in Windows; these events include user mouse/keyboard input. Some functions might be able to react to the events they intercept and avail themselves of the ability to change or remove events on their discretion. SetWindowsHookEx is the most widely used method for creating keyloggers. Thanks to this API function, the keylogger may initialize a global hook for each keypress event and for all threads within the system. Functions that get event notifications are named filter functions; they can be differentiated by the types of events they have the ability to intercept. To call a filter function in Windows, it is necessary for the function to be bound to a hook (mouse/keyboard, etc.). When you bind several filter functions to a hook, you are setting the hook. Applications may resort to the Win32 API SetWindowsHookEx and UnhookWindowsHookEx functions whenever the filter functions have to be erased or set and hooks can be global or thread-specific.

    Windows has implemented a function queue to circumvent conflicts when a number of functions are bound to only one hook. This function queue can be described as follows:

    • At the very start of the queue will be placed the function that has been most recently bound to the hook, while the first function that was bound to the hook will be placed at the end of the queue. Notably, Windows handles the function filter queue itself.

    If multiple filter functions are bound to a hook, there is an event occurring, and the hook is activated, what happens is the following:

    • 1. Windows will call the first function from the filter function queue.
    • 2. Windows’ responsibility ends and the filter function becomes in charge of calling the next function in the hook chain.
    • 3. The CallNextHookEx function takes the role of calling the next function in the hook chain.

    The hook filter function is situated in a separate dynamic library that is going to be injected into every single process in the system and these two characteristics constitute a few of the disadvantages of initializing hooks for keypress events. To clarify, not only does the dynamic library file have to be separate, but its injection into all system processes makes it easy to detect the keylogger and get rid of it


It can be deduced from the context of the discussion that the diverse types of keyloggers have differing results. While one is suitable for a particular goal (such as fast profit aimed at a worldwide dispersal to Internet users vs. targeted attack), another is not. It can further be deduced that keyloggers are pervasive and that user-space keyloggers mechanisms vary along with the fruits they bear for cyber crooks.


1. John Aycock, “Spyware and Adware,” 2011 (Springer International Series on ADVANCES IN INFORMATION SECURITY)

2. Microsoft’s Developer Network, “Operator Precedence and Associativity.” Available at:

3. Windows Dev Center, “Hooks Overview.” Available at:

4. Nikolay Grebennikov, “Keyloggers: Implementing keyloggers in Windows. Part Two.” Available at:

  1. Windows Dev Center, “WM_KEYDOWN message.” Available at:
  2. Windows Dev Center, “WM_KEYUP message.” Available at:
  3. Windows Dev Center, “GetMessage function.” Available at:
  4. Windows Dev Center, “SetWindowsHookEx function.” Available at:
  6. Wikipedia, “Keystroke logging.” Available at:
  7. Nikolay Grebennikov, “Keyloggers: How they work and how to detect them (Part 1).” Available at:
  8. REFOG, “Benefits of Keylogger for Windows 7/8.” Available at:
  9. Gregg Keizer, “Keyloggers Foiled In Attempted $423 Million Bank Heist.” Available at: