Key Stroke Injection
This document describes Keystroke Injection and it's different usecases. It lists a selection of tools and how to protect a system against such attacks.
Keystroke Injection describes the act of simulating keystrokes by a real person. In fact the keystrokes are generated by a script or other software. Thus wantet and unwanted inputs can be entered very fast. This works over the HID protocol (human interface device), with which every common keyboard works. Because computers trust human input in the form of keystrokes.
To show the actual danger by Keystroke Injection attacks, mostly done with rogue USB flash drives, the paper Users Really Do Plug in USB Drives They Find got published on IEEE in May 2016. It shows that 45-98% of the users plug in a found USB flash drive, mostly with the intention to find the drive's owner.
The ability to type over 9000 characters per minute opens a few use cases. Ethical correct ones and also not. Beside the probably best-known use as attack vector, also the automation of tasks benefits from this feature.
Even simple tasks like adding network shares or printers are much faster over commandline than over a GUI. Maybe these could also be typed manually, the benefit kicks in thinking of larger scripts to be automatically executed on single computers.
Penetration Testing is more or less the same use case as Hacking but with another purpose. Instead of really attacking a system you show and document open vulnerabilities.
The most famous use case for Keystroke Injection is to attack systems over command line. With the command line all sorts of attacks are possible. From running a simple script, over downloading and running an exe file, up to opening a reverse shell and many more. Attackers can just collect valuable informations or exploit the access. Enough examples can be found online.
There are a few different hardware tools, mostly disguised as simple USB falsh drives, also called BadUSB. They are in some sort programmable or loadable with a specific payload to execute.
A well known example is the USB Rubberducky. A detailed description is available in the Elvis Wiki: USB_Rubber_Ducky.
Pocket Admin is an open source variant of Rubber Ducky to build by yourself. It states that it's cheaper and that it has a extended functionality. The projects description and manual can be found here.
USB Ninja is a more expensive variant of BadUSB. It features different modules lika a bluetooth expansion and can also be built into normal keyboards. An overview is available here.
Bash Bunny is something like Rubber Duckys big brother. Its more expensive but also offers more tools like nmap, responder, impacket and metasploit, additional to the known Ducky Script. It's a small Linux machine on a USB drive mimicking multiple trusted devices. A full description can be found here.
An emerging trend is to not use special hardware, but to built in keystroke injection hardware/software in common peripheral devices. Imagine a standard HP office mouse, nobody would expect any threat from it. Examples and manuals can be found online.
An other tool is USB Guard. It's an open source software project in which you can write own USB device authorization policies.
The probably best protection against Keystroke Injection, is to block all unknwon USB devices and allow specific known devices only. This can be achieved by Group Policies by denying installation of removeable devices and only allow devices with a specific serial ID. But this approach has two disadvantages. Thinking of enterprise solutions, it's a very high effort to allow the good devices and also the serial ID can be faked or surpressed by such attacking devices.
A possible software solution is surprisingly Windows Defender ATP, an enterprise endpoint security platform.
A open source solution would be Duckhunt. This script rezognizes the average typing speed and blocks key strokes that are too fast. It even has a "Sneaky" mode to not let the attacker know, his attack has been blocked.
- M. Tischer et al., "Users Really Do Plug in USB Drives They Find," 2016 IEEE Symposium on Security and Privacy (SP), San Jose, CA, 2016, pp. 306-319, doi: 10.1109/SP.2016.26.