I was chatting with a friend recently and the claim came up that "writing a keylogger is easy." I've heard this one for years — forums, Discord servers, that one guy at every meetup. And after spending an evening actually digging into how they work, I've landed on a verdict: they're right, and they're also completely, embarrassingly wrong.
Both things are true at the same time, and the gap between them is where all the interesting stuff lives.
The part that's genuinely easy
Let's get the uncomfortable truth out of the way first: reading keystrokes off a computer is trivially simple, because operating systems are designed to hand you keystrokes. That's their job.
On Linux, every keyboard shows up as a file — /dev/input/eventX — and reading keypresses is literally opening that file and reading structs out of it in a loop. The kernel hands you a tidy little input_event for every press and release: here's the keycode, here's whether it went down or up, have a nice day. The core of a keylogger on Linux is maybe twenty lines of C. I'm not being poetic. Twenty lines.
Windows is somehow even more accommodating. There's a documented, legitimate API called SetWindowsHookEx — pass it WH_KEYBOARD_LL and a callback function, and the OS will now call you every time anyone presses a key, system-wide. You don't even have to poll. Windows taps you on the shoulder and delivers each keystroke like a butler. There's an even dumber alternative — polling GetAsyncKeyState() in a loop — which is the "hold my beer" version of the same idea.
Neither of these are exotic dark-web techniques. They're in textbooks. SetWindowsHookEx exists for accessibility tools, macro recorders, and hotkey managers. Linux's input event interface exists so your window manager knows you typed something. The OS isn't being circumvented here — it's being used exactly as documented. That's the part that bends people's brains.
So yes: "a keylogger," in the toy sense, is an afternoon project for anyone with basic C and a free Saturday.
The 95% nobody mentions
Here's what the "it's easy" crowd leaves out: capturing keystrokes is about 5% of what an actual malicious keylogger does. The rest is a completely different sport.
Getting execution in the first place. Your twenty-line masterpiece needs to actually run on someone else's machine. That's the real intrusion — phishing, exploitation, social engineering. The keylogger is cargo; the delivery is the crime.
Not getting caught. This is where the tutorial ends and the arms race begins. Modern endpoint detection isn't scanning for "keylogger.exe" — it's watching behavior. MITRE has an entire published detection strategy (DET0089, if you want the bedtime reading) built around flagging exactly these patterns: a process calling SetWindowsHookEx, polling GetAsyncKeyState in a tight loop, non-UI processes suddenly very interested in keyboard input. EDR vendors specifically advertise catching low-level keyboard hook abuse even when the malware is obfuscated. Your weekend project is the "hello world" of behavioral signatures. It has been seen. A billion times.
Persistence and exfiltration. Surviving a reboot without being obvious, then getting the logs off the machine quietly — logs sitting on the victim's disk are worthless, and every outbound connection is another chance to get flagged. Small encrypted transmissions to unknown endpoints are literally the kind of thing network monitoring exists to catch.
The unglamorous messiness. This one's my favorite. Keyboard layouts. Shift and AltGr state. Unicode. Dead keys. Toy keyloggers famously produce garbage like HELDLO WORLLD because properly reconstructing typed text from raw key events is genuinely fiddly. Turns out "record what they typed" and "reconstruct what they meant" are different problems.
It's like saying "making a knife is easy, it's just sharp metal." Technically true. The metallurgy, the balance, the not-stabbing-yourself — that's the craft.
The plot twist: the hardware ones laugh at your EDR
Just when I thought I had the taxonomy down — user-mode hooks, kernel-mode drivers, form grabbers, clipboard snoops — I stumbled onto the genuinely creepy corner of this world: physical keyloggers.
These are little passthrough devices that sit between the keyboard and the machine, presenting themselves to the OS as a perfectly ordinary USB HID keyboard. And here's the kicker, per some fairly sobering research NVISO published this spring: they are completely invisible to endpoint security. Not "hard to detect." Invisible. There's no process to flag, no API call to hook, no registry edit, no network exfiltration through the system at all. From the OS's perspective, your keystrokes arrive exactly as they always have. The device is just... listening, like someone standing behind your chair.
Every layer of modern defense I described above — behavioral EDR, MITRE detection strategies, network monitoring — assumes the threat interacts with the operating system. Hardware keyloggers don't. The investigation suddenly stops being about logs and processes and becomes about access control records, camera footage, and who touched the hardware. That's a different department. For a lot of organizations, it's a department that isn't watching.
The lesson isn't "panic about USB dongles." It's that every security model has an assumed shape for the threat, and anything outside that shape walks straight through.
Why I find the defense side more interesting anyway
Going into this rabbit hole, I expected the offense to be the cool part. It isn't — the offense is a tutorial. The defense is the art.
Think about what a good detection engineer has to do here. SetWindowsHookEx is used by legitimate software constantly, so you can't just ban it. You have to reason about context: is this process one that should ever care about keyboard input? Does it also beacon out to a weird endpoint? Did it appear right after a suspicious driver load? The state of the art is deception frameworks that hook the keylogger's own hooks and feed it fabricated keystrokes — fake input polluting the attacker's logs. That's not security software, that's counterintelligence. I love it.
So, is making a keylogger easy? Sure — the same way making a bump key is easy if someone hands you a file and a blank. The people saying it aren't wrong about the mechanism; they're wrong about what the mechanism is. Capturing keystrokes is reading data the OS hands you. Everything that makes it a threat — stealth, persistence, exfiltration, evading an industry whose full-time job is spotting you — is the part nobody calls easy.
If you want to actually learn something from this corner of security, skip writing one and go learn to detect one. Read DET0089. Set up Sysmon in a lab and watch what a keyboard hook looks like from the defender's chair. The offense takes an afternoon. The defense will keep you busy for a career — and it's the side that's hiring.
