How to Detect a Keylogger: 6-Step Guide for Sysadmins 2026

Ever get that weird feeling that your keyboard is… being watched? I know, it sounds a little paranoid. But stick with me. A few months back I had a workstation that started typing on its own. The cursor drifted across the screen at 2 AM. Accounts dropped out of nowhere. The user swore the laptop was practically new. So I asked the obvious question — is the hardware dying, or is something else going on? The deeper I dug, the more I realized: most people don’t have a clue where to start when it comes to how to detect a keylogger on your computer.

So I decided to write down everything I actually do when I suspect a machine has been compromised. If you’re a sysadmin, or you hold access to anything you don’t want stolen, this one’s for you.

Here’s the thing that surprised me the most during all this: keyloggers aren’t some exotic spyware reserved for government targets. A keylogger is software or hardware that silently records every keystroke you type — passwords, OTP tokens you punch in by hand, chat messages, even SSH credentials if you happen to be a sysadmin. And that last one is what keeps me up at night. Because a keylogger on an admin’s workstation isn’t just a personal problem. It’s a potential gateway into every server that workstation can reach. One compromised laptop, and an attacker could capture the credentials to your entire production fleet. So no, this isn’t paranoia. This is basic security hygiene.

Now, the part that bugs me the most: most people only realize they have a keylogger after something’s already been breached. By then you’re doing damage control, not detection. So let’s look at the signals first, then get into the actual methods.

What does a keylogger actually look like from the outside? Honestly? Sometimes it looks like absolutely nothing. The well-made ones are designed to blend in perfectly with normal system processes. But there are usually a few telltale signs if you know where to look: the cursor moving on its own, sessions logging out unexpectedly, unexplained CPU or RAM spikes while the machine sits idle, and processes you’ve never seen before showing up in the task manager. None of these alone proves anything — but two or three together? That’s worth an investigation. And that’s exactly what we’re going to do, step by step, on both Windows and Linux.

First, a Quick Anatomy Lesson: How Do Keyloggers Get In?

Before we start poking around, it helps to understand how these things land on a machine in the first place. Because honestly, once you understand the entry points, the detection becomes a lot less guessy. Most software keyloggers get in through three common doors: phishing emails with malicious attachments or links, cracked or pirated software that comes bundled with surprise extras, and drive-by downloads from compromised websites. There’s also the old-fashioned way — someone with physical access plugs in a USB stick, runs the installer once, and it’s done. Physical access is the scariest one, because no amount of web hygiene protects you from it.

Once installed, a keylogger needs two things to be useful to the attacker: it needs to survive reboots, so it hooks into the startup chain somewhere, and it needs to phone home with the stolen data. Those two needs — persistence and network communication — are exactly the two things we’re going to hunt for. That’s the whole trick. Detect the persistence, or detect the communication, and you’ve found your keylogger.

Method 1: Watch the Process List Like a Hawk

First stop: the process list. A keylogger has to keep running to keep recording, which means it has to show up as a process. There’s no way around it. Whether it’s Windows or Linux, this is the fastest first check you can do.

On Windows

Hit Ctrl+Shift+Esc to open Task Manager, then look at the Processes tab. Pay attention to names you’ve never seen before, processes eating CPU for no reason, and anything that just looks… off. For a deeper look, open a Command Prompt:

tasklist /V

The output is long, so dump it to a file and go through it at your own pace:

tasklist /V > C:\tmp\processes.txt

Here’s the pattern I look for most: process names that look like system processes but have a subtle typo. svchost.exe is a real thing; svchosst.exe is not. winlogon.exe is real; winlogone.exe isn’t. Cheap keyloggers forget to rename themselves, and that typo is your giveaway.

On Linux

On Linux, open a terminal and run:

ps aux --sort=-%cpu | head -30

That gives you the top 30 processes by CPU usage. Something running with a weird name, or something owned by a normal user but pegging the CPU? Write it down. If you prefer something interactive, install htop:

sudo apt install htop && htop

Here’s a snippet from a case I worked on once — see if you can spot the problem:

USER       PID %CPU %MEM    VSZ   RSS TTY  STAT START   TIME COMMAND
 denny     4321 87.3  4.2 205486 89040 ?    S    08:12   4:32 /tmp/.X19/keylog
 denny     4430  0.2  1.1  90120 22104 ?    S    08:12   0:02 /usr/lib/systemd/systemd-logind

Look at PID 4321. The command is literally named keylog, it’s running from /tmp/.X19/, and it’s chewing 87% CPU permanently. Meanwhile systemd-logind right below it sits at a healthy 0.2%. That gap is exactly what you want to notice. It’s rare that things are this obvious, but when they are, you don’t need a forensic lab to figure it out. For more on reading processes on servers, check out checking for weird processes on a Linux server.

Method 2: Audit Every Startup Entry

A keylogger that runs once is useless to an attacker. They want it running again after every reboot. That means it has to bury itself in the startup chain somewhere. And that’s where it becomes findable.

On Windows

Fastest check: Task Manager, Startup tab, and look at what’s enabled. But the real hunting grounds are the registry keys that get processed at login:

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"
 reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
 reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"

Read every line. Anything pointing to %TEMP% or to a random-looking filename like randomhash.exe deserves a second look. Legitimate startup entries usually point into Program Files or a folder you recognize. If you find something suspicious here, you’re not done yet — this is just the beginning of the checklist.

On Linux

Linux has more entry points, which makes it more annoying to audit but also means the persistence has to live somewhere you can find it. The usual suspects: shell profile files, systemd services, and cron jobs.

cat ~/.bashrc
 systemctl --user list-unit-files --state=enabled
 systemctl list-unit-files --state=enabled
 crontab -l
 ls -la /etc/cron.d/ /etc/cron.daily/

Don’t forget /etc/profile.d/ and ~/.config/autostart/ — those two are quietly popular spots to hide a startup entry. Open the files and actually read them. A service or script you don’t remember installing? Note it down before touching anything.

Method 3: Sniff the Network Connections

This is the one I get most excited about, because a keylogger has a fundamental weakness: it has to send data somewhere. That outbound connection is its fingerprint. Every second the malware sits quiet on your machine, it’s still one missed call away from being exposed.

On Windows

Open Command Prompt as administrator:

netstat -anob | findstr ESTABLISHED

The -b flag shows you which executable owns each connection, but it needs admin rights. If you’re not an admin, use:

netstat -ano

…and match the PID in the last column against tasklist. What you’re looking for: connections to foreign IPs, weird ports like 4444 or 31337, or random high ports commonly used for command-and-control. And here’s the kicker — if the suspicious process from Method 1 also owns an outbound connection to an unknown IP, you’ve basically got your answer.

On Linux

Check current connections with:

ss -tunap

Or go deeper with lsof:

sudo lsof -i -P -n | grep ESTABLISHED

Compare the destination IPs against what you normally reach. Beaconing keyloggers connect on a regular schedule — every 30 seconds, every minute, like clockwork. Here’s a pattern I’ve actually seen:

denny    4567  denny  4u  IPv4 123456  TCP 192.168.1.20:54210->203.0.113.77:8080 (ESTABLISHED)

203.0.113.77 isn’t a host you know, and the connection is held by the very process we suspected earlier. That’s a strong piece of evidence. Two independent signals pointing at the same thing beat any single one. If you want to sharpen your log-reading skills, auditing user logins on Linux is a great next read.

Method 4: Go Hunting for Files and Drivers

Keyloggers leave files behind. The trick is they hide them somewhere people don’t usually look, or disguise them to look like system files.

On Windows

The two favorite dumping grounds are the temp folder and the appdata folder:

dir /s /b %TEMP%
 dir /s /b %APPDATA%

Sort by last-modified date and look for recent files you can’t explain. A folder with a random name containing a single small executable? Suspicious. Drivers are also a common disguise, so list them:

driverquery -v

Look for drivers with unfamiliar names or vendors. Take your time with this one — false alarms are common, so compare against what looks normal before you draw conclusions.

On Linux

One technique attackers love on Linux is injecting a library via LD_PRELOAD. Check your environment first:

echo $LD_PRELOAD
 env | grep -i preload

Then look for executables sitting in places that shouldn’t have any:

ls -la /tmp /dev/shm /var/tmp

And here’s a genuinely clever one: find processes that are still running even though their files have been deleted:

sudo lsof +L1

Why is this interesting? Attackers delete the binary after it loads so a regular file scan won’t find it. A running process whose file no longer exists is almost always worth investigating.

Method 5: Bring in the Detection Tools

If the manual checks are clean but you’re still not convinced, there are dedicated tools that do a much deeper sweep. On Windows, I trust the Sysinternals suite — Autoruns for a brutally thorough startup audit, and Process Explorer for picking apart running processes. Kaspersky TDSSKiller is good for rootkit-style infections, and an offline Windows Defender scan catches a lot of the rest.

On Linux, the classics still work:

sudo apt install chkrootkit rkhunter clamav
 sudo chkrootkit
 sudo rkhunter --check

And you can point ClamAV at the suspicious areas:

sudo clamscan -r /tmp /var/tmp

These tools are a complement to manual analysis, not a replacement. Manual analysis finds the things tools miss, and tools catch the things manual analysis can’t see. Use both. And if you’re running exposed servers, securing SSH against brute force with fail2ban should be on your list too.

Method 6: Don’t Forget Physical Keyloggers

Here’s a scenario most people never think about: what if the keylogger isn’t software at all? Hardware keyloggers are small USB adapters that sit between the keyboard and the PC, or modified keyboards with a hidden chip. They’re rare, but they happen — especially in environments with loose physical access control.

On Windows, open Device Manager and look through the Universal Serial Bus devices. Anything you don’t recognize? Note it. On Linux:

lsusb

Compare the list against what should actually be connected. Easiest trick: plug in your own keyboard and see which device pops up. An extra USB device you can’t explain is worth investigating.

Here’s the safe order of operations for removing a suspicious process. On Windows, verify the process identity first:

wmic process where processid=4321 get name,executablepath,commandline

If it’s genuinely a suspicious process and not part of the system, then terminate it:

taskkill /PID 4321 /F

On Linux, verify first:

ps -p 4321 -o pid,comm,args

Then kill once you’re sure:

kill -9 4321

And one more thing that people skip: removing the keylogger is only half the job. Every password you ever typed on that machine is now suspect. Change them all, enable 2FA where you haven’t, and figure out how the infection got in so it doesn’t happen again. If you ever logged into a server from that workstation, treat those credentials as compromised too.

Quick Comparison of Keylogger Detection Methods

Method	Platform	Time	What It Catches
Process check	Windows & Linux	5 min	Software keyloggers visible in tasklist/ps
Startup audit	Windows & Linux	10 min	Keyloggers with persistence mechanisms
Network sniffing	Windows & Linux	15 min	Keyloggers sending data to a C2 server
File & driver check	Windows & Linux	15 min	Hidden binaries, LD_PRELOAD, odd files
Detection tools	Windows & Linux	20-40 min	Rootkits and advanced keyloggers
Physical check	Hardware	5 min	USB dongles and modified keyboards

How to Keep Keyloggers Off in the First Place

Detection is half the battle. Prevention is the other half — and honestly, it’s easier. Rule one: never install pirated software. It’s the single biggest delivery vehicle for keyloggers on Windows. Rule two: keep your OS and antivirus up to date. Rule three: don’t click links or open attachments you can’t vouch for. Rule four, if you’re a sysadmin: don’t log into production servers from a workstation you don’t fully trust, especially one used for casual browsing. Rule five: separate your admin account from your daily driver account. These five habits block the vast majority of keylogger infections out there.

So that’s the whole investigation playbook. The next time your cursor drifts on its own or a process you’ve never seen appears out of nowhere, you won’t have to wonder — you’ll know exactly where to look. If you’ve found a detection method that I missed, drop it in the comments. I’m genuinely curious what’s working for other people. Happy hunting, and keep those keystrokes yours.