MITRE ATT&CK T1674 Input Injection Guide

MITRE ATT&CK T1674 Input Injection describes adversaries simulating keystrokes so that a computer runs commands as if the logged-on user had typed them. The input can come from a rogue USB device that announces itself as a keyboard, or from malware already on the host that synthesises key presses into a browser or a command prompt. Either way, the operating system sees ordinary user input, so controls that only look at files or network traffic can miss it. This guide covers how the technique works in defensive terms, the telemetry that separates injected input from a real person, prevention on Windows, macOS and Linux, and how to roll the controls out. It is written for detection engineers, endpoint teams and SOC analysts. Physical USB drop handling and wider device control policy are covered in separate guides linked below; this page stays on the technique itself.

Key takeaways

Two delivery routes, one outcome. T1674 covers both hardware keystroke injection (a device enumerating as a keyboard) and software simulation of keystrokes by code already running on the host.
The keystrokes are not the payload. Injected input almost always launches a script interpreter such as PowerShell, bash or osascript, so interpreter controls and logging do most of the defensive work.
Timing is the strongest signal. A new keyboard enumerating and a shell starting within seconds, with no prior user activity, is the core pattern in MITRE's detection strategy.
Device installation policy closes the hardware route. Windows Device Installation Restrictions, USBGuard on Linux and accessory approval on Apple silicon Macs let you decide which input devices may attach.
Application control limits the damage. PowerShell Constrained Language mode under App Control for Business or AppLocker, which MITRE lists as a mitigation, removes much of what an injected one-liner relies on.

What T1674 describes

ATT&CK v20 places Input Injection (T1674) in the Execution tactic for Windows, macOS and Linux. MITRE defines it as adversaries simulating keystrokes "to perform any type of action on behalf of the user", including opening a command interpreter with keyboard shortcuts, typing an inline script, or driving a graphical application directly. The keystrokes can be built into adversary tooling or delivered by physical Human Interface Devices (HIDs).

MITRE records two reference cases:

Software injection (BackSwap): ATT&CK describes tooling that monitored the Windows message loop to detect visits to bank-specific URLs, then simulated keystrokes to open the browser developer console or select the address bar, pasted malicious JavaScript from the clipboard and executed it, so that content in the browser, such as bank account numbers in transactions, could be replaced.
Hardware injection (FIN7): ATT&CK records FIN7 using malicious USB devices that emulated keystrokes to launch PowerShell, which then downloaded and executed malware from the adversary's server, citing an FBI flash alert. MITRE links FIN7 to T1674 on that basis.

How it differs from related techniques

Technique	What it is	How it relates to T1674
T1200 Hardware Additions	Introducing hardware into a system or network for access	Covers the physical device as an initial access route; T1674 is the execution step when that device types commands
T1059 Command and Scripting Interpreter	Abusing interpreters such as PowerShell or bash	Almost always the next step: injected keystrokes exist to start an interpreter
T1185 Browser Session Hijacking	Abusing a user's browser session to act as them	BackSwap-style injection achieves a similar result inside the browser by typing script into it
T1056 Input Capture	Recording what the user types	The reverse direction: capture reads input, injection writes it

See the ATT&CK Execution Tactic Guide for where T1674 sits among the other execution techniques.

Signals that separate injected input from a person

MITRE's detection strategy for Input Injection (published with ATT&CK v20) describes per-platform analytics. They share one idea: correlate the arrival of an input source with script execution that follows too quickly, or too mechanically, to be human. The table summarises the log sources MITRE names, with the event IDs we use to build them.

Platform	Device signal	Execution signal	Tuning inputs MITRE suggests
Windows	System log Event ID 2003 (the device event MITRE names); Security Event ID 6416 "A new external device was recognized" (needs Audit PNP Activity)	Security Event ID 4688 process creation; PowerShell Event IDs 4103 and 4104 (module and script block logging)	Authorised USB vendor and product IDs; expected parent processes for interpreters; time window
Linux	syslog or kernel messages showing a new HID device of type keyboard	auditd execve where bash or python starts without interactive activity	Unapproved vendor IDs; script execution within a short threshold, MITRE gives less than 10 seconds as an example
macOS	Unified log entries for a new IOUSB keyboard or HID device	osascript, AppleScript or Python launched immediately after the connection	Allowed AppleScripts; time between connection and execution

Practical features that strengthen these analytics:

Device identity mismatch: a device whose description or class says keyboard while its hardware IDs belong to a development board, or a composite device presenting storage and keyboard at once. Event 6416 records Class Name, Class ID, hardware IDs and compatible IDs, so this can be checked at ingest.
Second keyboard on a laptop: a new keyboard class device on a machine that already has one, outside a docking station's known IDs.
Run dialog and shell parentage: an interpreter whose parent is explorer.exe (Win+R or a search box) seconds after a new HID, especially with an encoded or download command line.
Inhuman command arrival: PowerShell script block content that arrives as a complete long command with no typing errors, immediately followed by window hiding or console close.
Software injection on the host: for the BackSwap pattern, a non-browser process repeatedly bringing the browser to the foreground, writing to the clipboard and then the browser executing script from its console or a javascript: URL. EDR telemetry for synthetic input APIs, where your product exposes it, is the most direct signal.
Browser preference tampering: software injection may involve changing browser settings to allow script to run. Our recommendation: Writes to browser preference files by non-browser processes are worth alerting on.

Prevention controls

Control	Platform	What to configure	Route it addresses
Device Installation Restrictions	Windows	Group Policy under Computer Configuration, Administrative Templates, System, Device Installation, Device Installation Restrictions: Allow and Prevent by device ID, instance ID or setup class, plus "Apply layered order of evaluation"	Hardware
USB device authorisation	Linux	USBGuard allow and block rules by device attributes, enforced by its daemon using the kernel's USB authorisation feature	Hardware
Accessory approval	macOS on Apple silicon laptops	System Settings, Privacy & Security, "Allow accessories to connect", managed on supervised Macs	Hardware (confirm which accessory classes it covers in Apple's documentation)
Constrained Language mode	Windows	App Control for Business or AppLocker policy so untrusted scripts run in ConstrainedLanguage; System Lockdown so it cannot be bypassed	Both: limits what injected PowerShell can do
Application control	All	Allowlist interpreters and block script hosts users do not need	Both
UAC secure desktop	Windows	Keep "User Account Control: Switch to the secure desktop when prompting for elevation" enabled (the default) and standard user accounts for daily work	Both: injected input cannot silently approve elevation
Screen lock	All	Short idle lock and lock on device removal where supported	Hardware: a locked session gives typed commands nowhere to go

Device installation policy on Windows: practical notes

Specificity order: with "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" enabled, Microsoft documents the order as device instance IDs, then device IDs, then setup class, then removable devices. Without it, every Prevent policy beats every Allow policy.
Keep the input path: Microsoft warns that blocking USB classes on desktops can cut off keyboards and mice, and lists host controller and root hub IDs (for example USB\ROOT_HUB30) that should stay allowed.
Retroactive blocking: each Prevent policy has "Also apply to matching devices that are already installed". Use it only after testing, because it can disable devices in use.
Administrator override: "Allow administrators to override Device Installation Restriction policies" exempts local Administrators. Leave it off where users hold local admin, or the control is easily sidestepped.

A strict keyboard allowlist is realistic for kiosks, point-of-sale terminals, reception PCs and privileged access workstations. For general laptops, where users bring their own keyboards, rely more on detection, interpreter controls and screen lock. See the Removable Media and USB Control Guide for device control policy design and the USB Drop Attacks Guide for found-device handling and awareness.

Where identity fits

Injected keystrokes run with the identity of whoever is logged on. On an administrator's workstation or a jump host that means administrator rights, cached tokens and any secrets the session can reach. Three identity controls cut the impact: use separate, non-privileged accounts for email and browsing; do privileged work only from hardened privileged access workstations with strict device policy; and keep service account and automation credentials off interactive desktops. A kiosk or shared terminal that auto-logs on under a service account is a high-value target for a planted keyboard device, so give it the strictest device allowlist you run.

How to implement

Inventory input devices (weeks 1 to 2). Turn on Audit PNP Activity so Event ID 6416 is generated, forward it with Event ID 2003, and collect Linux and macOS device events. Build a baseline of keyboard and HID vendor and product IDs per device class.
Turn on interpreter logging. Enable PowerShell script block and module logging (4104, 4103) and process creation with command line (4688 or EDR equivalent); on Linux, auditd execve rules; on macOS, unified log collection for osascript.
Build the correlation. Alert when a new HID keyboard is followed within your chosen window by an interpreter start under the same session. Start with a 30 second window (our suggestion), then tighten using your baseline.
Pilot device restrictions on fixed-function machines. Apply Allow-by-ID policies with layered evaluation to kiosks, point-of-sale and privileged access workstations first. Test with the exact keyboards, scanners and docks in use.
Deploy Constrained Language mode. Run App Control for Business in audit mode, review blocked scripts, then enforce, so untrusted PowerShell runs in ConstrainedLanguage.
Test with an authorised device. Under a written test plan, use a red team or test keystroke device on pilot machines to confirm the alert fires and the policy blocks enumeration.
Roll back cleanly. Keep device policies in a dedicated GPO or Intune profile that can be unlinked; keep a break-glass procedure for a locked-out keyboard, such as a known allowed spare or remote management access.

Decision guidance

Allowlist or detect: allowlist where the device set is fixed (kiosks, privileged workstations, OT HMIs); detect and constrain interpreters where users change peripherals often.
Small organisations: start with screen lock, standard user accounts, PowerShell logging and a rule that found USB devices go to IT. Device allowlisting can wait for high-risk machines.
Large organisations: run the HID-to-interpreter correlation centrally, manage device policy per device class, and include keystroke injection in red team scope.
Software injection focus: if banking or finance staff are the main concern, invest in EDR coverage for synthetic input and browser tampering, and in application control on finance workstations, rather than in device policy.

Detection and measurement

HID telemetry coverage: percentage of endpoints sending device connection events (6416 or equivalent) to the SIEM.
Allowlisted estate: percentage of kiosks, point-of-sale and privileged workstations with keyboard allowlisting enforced.
Constrained Language coverage: percentage of Windows endpoints where untrusted scripts run in ConstrainedLanguage.
Test detection rate: share of authorised keystroke injection tests that raised an alert within your target time.
Unknown HID rate: new keyboard devices per week outside the baseline, and time to review each.

Framework mapping

Framework	Item	Relevance
MITRE ATT&CK	T1674 Input Injection; mitigations Limit Hardware Installation and Execution Prevention	The technique and MITRE's listed mitigations
MITRE D3FEND	D3-IOPR IO Port Restriction; D3-IDA Input Device Analysis; D3-EAL Executable Allowlisting; D3-PSA Process Spawn Analysis	Port control, input analysis, interpreter control, parent and child process analytics
NIST SP 800-53 Rev. 5	SC-41 Port and I/O Device Access; CM-7(5) Authorized Software, Allow-by-exception; SI-4 System Monitoring; AU-12 Audit Record Generation	Device restriction, allowlisting, monitoring and logging
NIST CSF 2.0	PR.PS-05; DE.CM-09	Preventing unauthorised software execution; monitoring hardware and software

Common failure patterns

Storage-only USB policy: blocking USB mass storage while allowing any keyboard class device, which leaves keystroke devices untouched.
Administrator override left on: device restrictions that local administrators can bypass, on machines where users are local administrators.
Logging without correlation: 6416 and 4104 both collected, but never joined by session and time, so the pattern is never seen.
Constrained Language set by hand: relying on setting the language mode in a profile or session, which Microsoft says is only useful for experimenting; it must come from application control policy.
Unlocked shared terminals: kiosks and reception PCs that stay logged on and unattended, giving a planted device an open session.
Treating it as user error only: handling a malicious USB as an awareness issue without checking which commands ran and what the session could reach.

Practitioner checklist

Enable Audit PNP Activity and forward Event IDs 6416 and 2003, plus Linux and macOS device events.
Enable PowerShell script block and module logging and process creation command lines.
Deploy a new-HID-to-interpreter correlation rule with a tested time window.
Enforce keyboard allowlisting on kiosks, point-of-sale and privileged access workstations.
Turn off the administrator override for device installation restrictions where users are local administrators.
Enforce PowerShell Constrained Language mode through App Control for Business or AppLocker.
Keep UAC prompting on the secure desktop and short screen lock timeouts.
Alert on non-browser processes writing browser preference files.
Run an authorised keystroke injection test at least yearly and record the detection time.

MITRE ATT&CK T1674 Input Injection: Detecting Malicious Execution