SY0-701 · Threats, Vulnerabilities, and Mitigations · Updated July 25, 2026
Keyloggers: How Keystroke-Logging Malware Works
A keylogger is malware — or a small piece of hardware — that records every keystroke a user types and delivers that log to an attacker. Because so much sensitive data enters a computer through the keyboard, a keylogger captures usernames, passwords, credit card numbers, messages, and search queries without needing to break any encryption: it grabs the data before it’s encrypted, at the moment of input. On the Security+ SY0-701 exam, keyloggers sit in the malware taxonomy as a form of spyware whose defining trait is keystroke capture for credential and data theft.
What a keylogger is (and where it fits in the malware family)
Keystroke logging is a capability, and it shows up in several packages. A standalone keylogger does nothing but record input. More often, keystroke capture is one module inside a larger threat: remote access Trojans (RATs), banking Trojans, and commercial “stalkerware” almost always include one. The umbrella category is spyware — software that covertly monitors user activity — with the keylogger being the variant specifically focused on input.
Not every keylogger arrives as an infection. Employers and parents have installed monitoring software deliberately, and attackers with brief physical access can plant a hardware device. The exam cares less about who installed it than about recognizing the behavior: everything typed is being recorded and collected.
How software keyloggers work
A software keylogger has to get between the keyboard and the applications receiving the input. On a modern operating system there are several places to do that, from shallow to deep:
- API hooking. The logger registers for keyboard events through legitimate OS interfaces (for example, Windows’
SetWindowsHookExlow-level keyboard hook). Every keypress event is copied to the logger before or while the target application receives it. This is the most common technique because it needs no special drivers. - Kernel-mode drivers. A malicious or trojanized keyboard filter driver sits in the input stack itself. Loggers at this depth are far harder for user-mode security tools to see, and are typically bundled with rootkit functionality to hide their files and processes.
- Form grabbing. Rather than raw keystrokes, the malware hooks the browser and copies form fields at submission time — catching autofilled and pasted values that never touched the keyboard. Banking Trojans favor this because it captures exactly the fields worth stealing, already labeled.
- Screen and clipboard capture. Many “keyloggers” also snapshot the screen on click and monitor the clipboard, defeating on-screen keyboards and copy-pasted passwords.
Captured logs are staged locally, then exfiltrated — commonly over HTTPS to a command-and-control server, by email, or by periodic upload — so the theft blends into normal outbound traffic.
Hardware keyloggers
The hardware version is a small inline device plugged between the keyboard cable and the USB port (or hidden inside a keyboard). It stores keystrokes in onboard memory; some models add Wi-Fi so the attacker never has to return for pickup. A related radio-frequency attack sniffs the transmissions of poorly encrypted wireless keyboards — one more entry in a device’s wireless, wired, and Bluetooth attack surfaces.
Hardware keyloggers matter on the exam for one sharp reason: no software on the computer can detect them. They draw no CPU, install no drivers, and look to the OS like an ordinary keyboard. Detection is physical inspection; prevention is physical security — locked equipment, port controls, and user awareness of unfamiliar dongles. The same wariness of untrusted USB connections applies to public charging stations — see juice jacking.
| Software keylogger | Hardware keylogger | |
|---|---|---|
| Installed via | Phishing, drive-by download, bundled malware | Brief physical access to the machine |
| Where it captures | OS input APIs, kernel driver, or browser | Inline between keyboard and computer |
| Detectable by AV/EDR | Yes (hooks, processes, drivers, C2 traffic) | No — invisible to the operating system |
| Exfiltration | Network (C2, email, upload) | Retrieved physically or via built-in Wi-Fi |
| Primary defense | Endpoint protection, patching, least privilege | Physical security and visual inspection |
Defenses that work — and one that half-works
- Endpoint detection and response (EDR) / anti-malware catch known logger binaries and flag hooking behavior, driver loads, and suspicious beaconing; host-based intrusion prevention goes further and blocks the hook or driver install outright.
- Multi-factor authentication (MFA) is the great damage-limiter: a captured password alone no longer opens the account. Note the nuance — a keylogger can still capture a typed one-time code, but the code expires before reuse; phishing-resistant methods (security keys, passkeys) give the logger nothing replayable at all.
- Least privilege and application allow-listing block the installation paths, especially for kernel-level loggers that need admin rights to load a driver.
- Password managers that autofill credentials reduce keystrokes to capture — but form grabbing and clipboard monitoring can still catch the values, so this is mitigation, not immunity. The same caveat applies to on-screen keyboards.
- User behavior clues: unexplained new processes or drivers, and periodic outbound transfers to unfamiliar hosts, are the indicators a scenario will hand you.
Because a keylogger’s stolen credentials are usually step one of a larger intrusion, it pairs naturally with account takeover and lateral movement — see privilege escalation for what attackers do after they’re in.
How the SY0-701 exam tests this
- Definition-by-behavior. A question describes malware that records everything typed to capture credentials and card numbers, and asks for the malware type. Among options like worm, ransomware, logic bomb, and Trojan, the recording-keystrokes trait points to keylogger (or spyware, if keylogger isn’t offered).
- Indicator analysis. A user reports nothing, but logs show a process hooking keyboard input and making regular small HTTPS uploads to an unknown host. You’re asked the most likely explanation — keystroke logger exfiltrating captures.
- The physical-access twist. After a visit from an “outside technician,” credentials leak from a machine whose AV scans are clean. The clean-scan detail is the discriminator: suspect a hardware keylogger, and the response is physical inspection.
- Best mitigating control. Given that keystroke capture may already be happening, which control most limits credential theft damage? MFA — it devalues the captured password rather than trying to prevent the capture.
The clean-scan hardware twist catches almost everyone once — better to meet it in SY0-701 practice questions than on exam day.
Quick reference
- Keylogger = spyware variant that records keystrokes to steal credentials, card numbers, and other typed input.
- Capture happens at input time — encryption of traffic or disks doesn’t protect data the moment it’s typed.
- Software loggers hook OS keyboard APIs, load kernel drivers, or grab browser form fields; many also capture screen and clipboard.
- Hardware loggers sit inline on the keyboard connection and are invisible to all software — physical inspection is the only detection.
- Stolen logs leave via C2/HTTPS uploads; small periodic outbound transfers are a classic indicator.
- MFA (especially phishing-resistant MFA) is the highest-value mitigation; EDR, least privilege, and allow-listing block installation.
- Clean malware scans + physical access in the scenario = think hardware keylogger.