Detecting and Mitigating Input Injection (MITRE ATT&CK T1674)

Input Injection (T1674) is an Execution technique. Adversaries simulate keystrokes on a victim's computer to take actions as the user. MITRE lists Windows, macOS and Linux as platforms.

How attackers use it

The simulated keystrokes can do almost anything a person could do at the keyboard. MITRE gives examples such as launching a command interpreter through keyboard shortcuts, typing an inline script to run, or interacting with a graphical application.

The actions can be preprogrammed into adversary tooling or delivered by physical Human Interface Devices (HIDs), which are devices that present themselves to the computer as a keyboard.

MITRE describes two documented uses:

• Tooling that watches the Windows message loop for a visit to bank-specific URLs. When it sees one, it simulates keystrokes to open the developer console or select the address bar, pastes malicious JavaScript from the clipboard, and runs it. This can change page content, such as swapping bank account numbers during a transaction.
• Malicious USB devices that emulate keystrokes to launch PowerShell, which then downloads and runs malware from an adversary-controlled server. A named group has used this approach.

Because a keyboard is trusted by design, the operating system may not question it.

How to detect it

MITRE's detection strategy looks at the device and at what follows:

• Windows. Suspicious USB HID enumeration and keystroke injection patterns, such as rapid input with no user context, scripts executed through simulated keystrokes, and rogue devices that present as keyboards.
• Linux. USB HID enumeration under /sys/bus/usb/devices/, followed by rapid keystroke injection that leads to commands such as bash or Python scripts running without interactive user activity.
• macOS. Abnormal HID enumeration visible through the I/O Registry (for example ioreg -p IOUSB), and keystroke injection aimed at AppleScript, osascript or PowerShell equivalents. Correlate new USB device connections with rapid script execution.

The shared tell is speed. A human does not open a shell and paste a long command in a fraction of a second after a new device is plugged in.

How to reduce the risk

1. Limit Hardware Installation. Limit the use of USB devices and removable media on your network.
2. Execution Prevention. Denylist scripting and use application control where appropriate. MITRE's example is PowerShell Constrained Language mode, which restricts sensitive language elements such as Add-Type.

Check your own environment

• Does your endpoint tool log new USB device connections, including the device class?
• Can any user plug in an unknown keyboard on a managed laptop, and would anyone notice?
• Is PowerShell logging turned on, and do you have a rule for a shell started right after a USB connection?
• Do public or shared machines need open USB ports at all?

On macOS, this read-only command lists connected USB devices:

ioreg -p IOUSB

Quick check

Sources

• MITRE ATT&CK, Input Injection (T1674): https://attack.mitre.org/techniques/T1674