Input Capture

Input capture sits in the Collection and Credential Access tactics, which means it is rarely the opening move. By the time a keylogging script executes, the attacker already has code running on the host, usually from a macro-laced document, a trojanized installer, or an already-resident stealer, and is looking for a lower-effort way to harvest credentials than dumping LSASS or hunting for saved browser passwords. Keylogging is patient collection: it waits for the user to type something valuable rather than extracting what is already stored, which makes it especially effective against services that use hardware tokens or short-lived session cookies where a static credential dump would come up empty.

The tooling lineage matters for detection. Both the SigmaHQ and Elastic rules cited above trace back to Empire's Get-Keystrokes.ps1 collection module and the Atomic Red Team emulation of it, a widely reused open-source pattern that shows up repackaged inside commodity crimeware as often as in red-team engagements, which is why VirusTotal-submitted samples referenced in the Elastic rule share the same IsKeyDown/GetAsyncKeyState fingerprint as the original offensive tool. Once keystrokes are captured, the next step is almost always credential reuse or direct theft: a harvested webmail or VPN password feeds further lateral movement, while a captured wallet passphrase or exchange login goes straight to account takeover, which is the pattern the free SOCSimulator StealC room walks an analyst through end to end.

The APIs behind keylogging are also behind a lot of legitimate software. Accessibility tools and screen readers hook the keyboard to provide alternative input methods. Hotkey managers like AutoHotkey, gaming overlays, and streaming software poll key state to trigger macros or push-to-talk. Remote-support and kiosk applications hook input so they can intercept and forward it. PowerShell developers debugging their own scripts sometimes trip the same signatures, which is why Elastic's rule explicitly excludes script blocks that pair a hook or key-state call with Set-PSBreakpoint, a recognizable debugging workflow rather than credential theft.

The tuning move is to require recurrence and context rather than suppressing on the API name alone. Allow-list the specific signed binaries, script paths, and user/host pairings your accessibility, hotkey, and remote-support tools legitimately run from, and require that same pairing to show up across prior alerts before you write an exception; a first-time hit from an unfamiliar script path or an account with no history of that workflow should still escalate even if it superficially resembles known-good tooling. Keep SYSTEM deprioritized rather than fully excluded, since a keylogger running under a compromised service account is designed to look exactly like routine background automation.

The first question is whether the script content shows active intent or is just an inert reference to the API names, something that happens in documentation, training material, and security-tool signature databases. Pull the full script by reconstructing every fragment sharing the same ScriptBlockId, since script block logging can split one script across multiple 4104 events and the polling loop, the window-labeling call, and the output path often land in separate fragments. Then recover the process launch chain: what spawned PowerShell, whether it came from a document, browser, or scheduled task, and whether the account and host pairing has a legitimate reason to run input-capture code.

If the script pairs hook registration or key-state polling with window labeling, writes to a hidden log path, or is followed by an archive and an outbound connection, treat it as confirmed collection rather than a maintenance false positive, and move fast: keystroke capture implies whatever the user typed next, including a password reset or a wallet unlock, is already compromised. Preserve the reconstructed script, the written log or archive artifacts, and any destination IP or domain before doing anything destructive. Reset credentials for the affected account as a precaution rather than waiting for confirmation of reuse, hunt for the same script-block fingerprint or file pattern on other hosts, and isolate the endpoint if there is evidence the captured data already left the network.