Logging keystrokes

Malicious hackers love keyloggers. See for yourself how X is susceptible to them, and why Wayland defends against them.

One of the most insidious types of malware is a keylogger. Sitting there silently, often invisibly, in the background, it records all your keystrokes and may also keep track of which apps or windows they are being sent to. This data is then exfiltrated to a server under the control of the attacker, where it is scoured for passwords or other sensitive information. Besides keystrokes, keyloggers may also periodically take screenshots, or inject their own keystrokes. Nasty stuff. We’ll touch on mobile security at the very end of this feature, but for now, be aware that many nefarious apps masquerading as fancy on-screen keyboards are in fact keyloggers.

Back on desktop, one of the main shortcomings of the old X display server was that any app could spy on keystrokes being sent to another, making it trivially easy to implement a keylogger there. Security guru Matthew Garrett did so back in 2016, even from within the supposed confinement of a Snap application. If you’re still running X (for example, on Mint or Pop!_OS), you don’t even need a keylogger to see the problem in action. Just install Xinput and run xinput list to find your keyboard device (ours was called AT Translated Set 2 Keyboard), then run xinput test , substituting your device’s ID number. You should see keypresses (and key releases) no matter which application you are typing them into. Our default install of Kali (with the Xfce desktop) is susceptible to this, too.

Wayland obviates this problem to some extent, providing true per-application confinement. However, non-Wayland apps can still be spied upon this way via the XWayland layer. If you search on the internet, you’ll find a modicum of FUD (fear, uncertainty and distrust) around this topic. For example, if you have root access to a system, then you can (for example) overwrite key environment variables ($PATH and $LD_PRELOAD)

so that the programs of your choosing are run through a malicious bit of privileged code that sidesteps Wayland’s compartmentalisation. This isn’t really a Wayland problem – if someone (other than you or your benevolent systems administrator) has root access to your machine, they can probably do a lot worse than install a keylogger.

You can find a simple multi-platform keylogger at https://github.com/GiacomoLaw/Keylogger. We’re assuming you’re still using Kali, but this should work on any X-based desktop (or for apps using XWayland). Clone that repo with:

$ https://github.com/GiacomoLaw/Keylogger.git

We’re only interested in the Linux side of things, so let’s set that up with:

$ cd Keylogger/linux

$ pip install -r requirements.txt

The instructions say to run the keylogger with the nohup (no hangup) command and in conjunction with the background operator (&), so let’s obey:

$ nohup python keylogger.py &

This tells us the process ID of our nefarious program, which would be handy if you only had remote access to the system. Open another terminal tab, or a browser, text editor or anything that accepts input, and type until you get bored. Then return to the tab where you started the keylogger and type fg to bring it back to the foreground. Since we’re running locally, we can kill this with Ctrl+C. This particular script sometimes gets a little confused with modifier keys, so its log file might end up looking a little messy, and you may have to use a text editor (rather than the cat command) to view it. Oh, and don’t be misled by the message about ‘nohup. out’ when we started the script. The actual log file is the date and time (separated by a | which we have to escape) at which the script was run, for example:

$ nano 01-03-2024\|09:00.log

Slightly disconcerting, we think you’ll agree.

Oh dear, the keylogger captured our password. Note the odd control characters at the end of the file.