Using HID Tricks To Drop Malicious Files

[Nikhil] has been experimenting with human interface devices (HID) in relation to security. We’ve seen in the past how HID can be exploited using inexpensive equipment. [Nikhil] has built his own simple device to drop malicious files onto target computers using HID technology.

The system runs on a Teensy 3.0. The Teensy is like a very small version of Arduino that has built-in functionality for emulating human interface devices, such as keyboards. This means that you can trick a computer into believing the Teensy is a keyboard. The computer will treat it as such, and the Teensy can enter keystrokes into the computer as though it were a human typing them. You can see how this might be a security problem.

[Nikhil’s] device uses a very simple trick to install files on a target machine. It simply opens up Powershell and runs a one-liner command. Generally, this commend will create a file based on input received from a web site controlled by the attacker. The script might download a trojan virus, or it might create a shortcut on the user’s desktop which will run a malicious script. The device can also create hot keys that will run a specific script every time the user presses that key.

Protecting from this type off attack can be difficult. Your primary option would be to strictly control USB devices, but this can be difficult to manage, especially in large organizations. Web filtering would also help in this specific case, since the attack relies on downloading files from the web. Your best bet might be to train users to not plug in any old USB device they find lying around. Regardless of the methodology, it’s important to know that this stuff is out there in the wild.

38 thoughts on “Using HID Tricks To Drop Malicious Files

  1. Way easier to deliver the code as if it were a driver. Many examples exist to show you how to include the driver on the device. Same concept, different binary transferred. This is the hard way to do it , it seems.

      1. Since Win8 I believe all drivers must be signed by default, but can be disabled with a non trivial configuration. 7 is pretty strict, will present you with an unsigned driver dialog of which the user has to agree to.
        The only real vector for the attack in this article would be to somehow fool the user into believing something like the Teensy is just a normal pendrive, possible I suppose, not likely.
        If there’s a standard policy to lock workstations when users are away in your organisation (should be!), be it automatic or manual, this attack is pretty much totally foiled before it gets off the ground.
        Nah, I ‘prefer’ the USB hack involving rewriting the firmware of an existing Pendrive to act as multiple devices with timed payload delivery, much much more sneaky!

  2. I work with many organizations that cannot accept USB sticks. Even from trusted vendors.

    Using HID certainly means that systems that prohibit usb drives can still be controlled.

    My company has a policy that any unknown source for USB has to be sent to security for analysis.

    Interesting attack vector, similar to others.

  3. “Your primary option would be to strictly control USB devices, but this can be difficult to manage, especially in large organizations.” assuming you know the model of keyboard used(for desktop), there is not much you can do, right? Or is there any unique ID for the keyboard that you have to copy as well?

        1. Brian didn’t include a link to the page in the HaD store selling Teensy 3.1. Wouldn’t an intentional “campaign to promote the Teensy” would at least try to sell the ones HaD has in their own store?

          Full disclosure: I’m the creator of Teensy, so of course assume everything I write is a campaign to promote the Teensy!

    1. Calling it a campaign makes it sound like there’s something bad going on. I think there are just a lot of us who really appreciate PJRC products for good reasons: high quality, low prices, small form factors, high performance, incredible support, tons of contribution back to the community, compatibility and almost no advertising by PJRC–unless you count Hackaday-worthy projects as advertising.

    2. It’s a pretty sweet chip at a decent price. Tiny, plenty of horsepower and supports HID. Paul’s support is also really excellent… you mention the teensy on a forum somewhere and he just shows up. There are similar products out there (eg trinket, somewhat less capable for somewhat less cost), but I think the large number of teensy projects being reported is representative of actual adoption. I know it’s my go-to for quick prototyping now.

    3. Well…. HaD did have a recent contest promoting the Teensy, and a lot of people thought it was a good time to get started with one… So…. maybe there is a surge in projects that use the Teensy to report?

      -Obvious-san

  4. One weakness I can see with this would be the requirement of a public Internet connection. Not all organizations allow the entire Internet through. This is easily bypassed, though by modifying the attack to enter machine code directly and run it.

    1. I assume these days the windows shell has at least the ability to add bytes to a binary file from the prompt (yes?no?yes?no???? Dunnu, haven’t seen a windows machine since Vista). But assuming that you could, I think the only limitation is the memory on the Teensy which you could also expand for this purpose.

      1. This was my thought as well. Just hang a bunch of flash on the teensy, and you’re good to go. As for copying the data, you can do something like:
        echo [data] >> file
        I’m not 100% sure that will work for binary data, but I don’t see why not.

        1. On any *nix environment this would be trivial, but it used to be very tricky to bypass the ascii-ness in CMD or dos without some special tool, which leaves you with a boot-strap problem regarding this hack. Again, I don’t know if powershell has caught up with 2000’ish sane command prompt paradigms!

          1. Powershell has the byte array. you can load data into it like this:
            $bin = [byte[]]@(65,66,67,68,69,70,71,128) # ABCDEFG€

            Then store in in a file
            $bin | set-content file.txt -Encoding byte

            So you can type in just about anything you’d like, but with lousy overhead.

            if you have a malicous file, you can get the data in text form this way:
            $bin = get-content malicous.exe -encoding byte
            $code = ‘$text=[byte[]]@(‘
            $bin | foreach { $code+=”$_,”}
            $code=$code.Substring(0,$code.length-2)+”)”
            $code | set-content malicious-code.txt -encoding ANSI

            malicious-code.txt will hold the decimal encoded binary of malicous.exe like:
            $text=[byte[]]@(36,117,…)
            which you can include in the payload.

          2. Seeing as the goal is to create an executable binary directly from the HID device, the first example looks like it could work if there is no practical line limit, which I believe there isn’t.

            So in theory storing a binary in a HID and punching it out via powershell, subsequently executing it should be pretty easy to do.

            I’ll have a crack at it (although I do not like the looks of powershell.. it feels dirty)

  5. Hmm…wouldn’t it be possible to store a text file that could be typed and then converted to a binary file on the machine? Or a variety of powershell scripts that don’t need Internet access? There are other things than powershell available as attack vectors with this.

    1. Storing the data is easy, however communicating each byte via a keyboard HID is not as straight forward. You need to be able to generate the first 31 bytes and 128 to 255 as well as the common 32 to 127 bytes that are easily produced by a HID. Then you also have to make sure that the method you are using to generate the file does not assume ascii-ness like carriage returns, line feeds or end of transmission.

      Does powershell have a dec2bin feature or something similar? If it does, we’d be halfway there.

  6. There would be a simple way around that.

    If the system already has a keyboard connected, do NOT accept any input from a second keyboard device unless the user authorizes it by input through the already active keyboard.

    ‘New keyboard connected, enter to allow it to be used. If the device you just connected is not a keyboard, this might be a hacking attempt!’ with the PIN random and generated for each occasion.

    If the user has a real second keyboard plugged in, no problem. If that pops up when inserting something else, well…

    1. This solution would still be vulnerable to social engineering. All you had to do is deploy a couple of rigged keyboards with the malicious bit in, say, a company and wait for them to get utilized. one well executed privilege elevating exploit should be enough to own a network.

  7. Protection actually doesn’t seem really hard, when you are sitting at your computer you would notice if someone inserted device and it started typing, for the rest of the time windows+l will lock your system, then it won’t work to type unless you first know the password and have that pre-programmed.

    But if you have a place where people leave computers unattended, then why not simply type things by hand as attacker?

    But let’s say you have a computer, leave it unattended, and are worried about this attack, how about renaming powershell? Or intercept the shortcut key to open a command window..

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.