Tuesday, October 23, 2012

Hacking KeyLoggers

By Mike Spohn and Brad Antoniewicz.

Our forensics investigations often result in us having to identify odd devices left over by attackers. So when we recently had to investigate a suspicious USB device connected between the keyboard and USB port on the rear chassis of a senior executive’s desktop computer, my job (I chose to accept it) was to discover what the device was and if it was evil.

Identifying the Device

The device was a very non-descript in appearance. It measured exactly 1” in length from the rear edge to the beginning of the male connector. The edges were beveled and the universal USB symbol was imprinted on the top and bottom. There were evenly spaced vertical striations on the sides. Here's an image of a keylogger from a competitor's site that resembled the device we were investigating.



Being the suspicious sort I am, this device and I did not become instant friends. A colleague scoured the Internet and notified me he found a very similar device manufactured by a company who specializes in hardware keystroke loggers. Since the device was relatively cheap (< $80), I ordered one for experimentation in the forensic lab. I'm intentionally not disclosing the actual manufacturer of the device so that they won't figure out a way to protect themselves against our attacks described below.

When the keylog device arrived, I visually compared it with the suspicious device provided by the client. They appeared identical. I next used an ohmmeter to measure the electrical properties of each device. Measuring the resistance between the front and rear USB pins determined both devices had the exact same electrical properties. The ohmmeter also indicated the devices had resistive/capacitive (RC) characteristics due the obvious RC time constant resistance behavior. At this point, I knew the device was not passive – it has an electronic brain.

The Unlock Code

Reading the documentation for the keylog device I learned it had a simple, elegant design. When the device is plugged into a computer and the O/S interrogates the device via Plug-N-Play (PNP), the device does not respond. Instead, the device goes into keyboard capture mode and logs every keystroke to a simple text file. All keystrokes are then passed on to the computer.

To retrieve a keystroke log from the keylog device, the owner must enter a three-key combination of keystrokes. The three keys must be alpha-numeric and must be pressed at the same time. For example, if the unlock key combination is ‘ABC,’ the owner must press the ‘A’ ‘B’ abd ‘C’ keys at the same time. Case does not matter. The unlock code can be changed from the default by placing a config.ini file on the device with a “Password=” entry.

Once the correct unlock key combination is entered, the device will send a PNP signal to the O/S. The device will advertise itself as a removable disk device, and the O/S will mount it. Once mounted, the owner can retrieve the keystroke log.

I attempted to unlock the clients’ device using the ‘default’ unlock code and it did not mount. If this was, in fact, a keylog device, the owner changed the unlock code. My challenge now was - how do I unlock the device?

The solution seemed obvious. Figure out a way to emulate a USB keyboard and send all combinations of three-key codes to the device until the right combination is sent. Simple – right? Not so fast Sherlock. Remember, you have to send the unlock code to the rear (keyboard) side of the device, not from the host computer.

USB Keyboard Emulation

The first thing that came to mind was a Teensy. This device, about the size of a postage stamp, provides a complete development environment for emulating a USB device and USB keyboard emulation. Even better, the device costs $16 US.

Once I had a Teensy 2.0 in the lab, I wrote a quick test program in C and transferred it to the device. After some experimentation, I had a complete program that would send all three-key alpha-numeric key combinations out the mini-usb port of the Teensy device. To crack the keylog unlock code I had to perform three steps:
  1. Burn my key-crack application on the Teensy device
  2. Connect the keylog device to a computer
  3. Connect the Teensy device to the rear connector of the keylog device

Using The Teensy 2.0 To Brute Force The Unlock Key

You'll have to configure your system if you've never used the Teensy before. Our test system will be using Backtrack 5 R3. Windows was used originally, but once Windows 7 couldn't find the driver for my USB keyboard I jumped over to Linux. In the end the OS doesn't make much of a difference because once you identify the unlock code, it automatically mounts itself as a storage device accessible by all modern operating systems.

First up, we'll need to install our prerequisites:

 root@bt:~# apt-get install gcc-avr binutils-avr avr-libc



You can flash the Teensy a variety of ways, here we'll do it using the Teensy Loader CLI utility:

 root@bt:~# wget http://www.pjrc.com/teensy/teensy_loader_cli.2.0.tar.gz
 root@bt:~# tar -zxvf teensy_loader_cli.2.0.tar.gz
 root@bt:~# wget http://www.pjrc.com/teensy/hid_listen_1.01.zip
 root@bt:~# unzip hid_listen_1.01.zip



The Makefile included in the repository will perform the flash, which we'll go over in a couple of steps. For now, it's just important that the loader is on your system and decompressed. Next will grab a copy of the repository:

 root@bt:~# git clone https://github.com/OpenSecurityResearch/usb-keylog-crack.git
 root@bt:~# cd usb-keylog-crack



Edit the Makefile and set TEENSY_LOADER_CLI with the path to the teensy_loader_cli binary. By default it's set to ../teensy_loader_cli/teensy_loader_cli:

 root@bt:~/usb-keylog-crack# grep "TEENSY_LOADER_CLI " Makefile
# Be sure to set TEENSY_LOADER_CLI variable below
TEENSY_LOADER_CLI = ../teensy_loader_cli/teensy_loader_cli



With the appropriate values set, you can build the cracker:

 root@bt:~/usb-keylog-crack# make all



To flash, insert the Teensy and press the "Reset" button, this will put it into it's HalfKay bootloader. Now we can flash the usb-keylog-crack code:

  root@bt:~/usb-keylog-crack# make program
../teensy_loader_cli/teensy_loader_cli -mmcu=atmega32u4         -v usb_keylog_crack.hex
Teensy Loader, Command Line, Version 2.0
Read "usb_keylog_crack.hex": 5008 bytes, 15.5% usage
Found HalfKay Bootloader
Programming........................................
Booting
root@bt:~/usb-keylog-crack#



usb-keylog-crack uses the Teensy's USB debugging functionality to provide information during the cracking. We'll use the hid_listen utility to grab this debugging info:

 root@bt:~/usb-keylog-crack# cd ~/ 
 root@bt:~# wget http://www.pjrc.com/teensy/hid_listen_1.01.zip
 root@bt:~# unzip hid_listen_1.01.zip
 root@bt:~# cd hid_listen
 root@bt:~/hid_listen# make
 root@bt:~/hid_listen# ./hid_listen
Waiting for device:...



Now we're ready - Insert the Teensy 2.0 into the Keylogger, then insert the Keylogger into the computer. Sit back and relax, after a few minutes you should see the banner and brute force attempts:

 root@bt:~/hid_listen# ./hid_listen
Waiting for device:...
Listening:
Keylog crack application
Written by Michael G. Spohn
June 3, 2012
0001) Trying: QWQ (0014 001A 0014)
0002) Trying: QWE (0014 001A 0008)
0003) Trying: QWR (0014 001A 0015)
0004) Trying: QWT (0014 001A 0017)
0005) Trying: QWY (0014 001A 001C)
0006) Trying: QWU (0014 001A 0018)
0007) Trying: QWI (0014 001A 000C)
0008) Trying: QWO (0014 001A 0012)
0009) Trying: QWP (0014 001A 0013)
000A) Trying: QWA (0014 001A 0004)
000B) Trying: QWS (0014 001A 0016)
000C) Trying: QWD (0014 001A 0007)
000D) Trying: QWF (0014 001A 0009)
000E) Trying: QWG (0014 001A 000A)
000F) Trying: QWH (0014 001A 000B)
0010) Trying: QWJ (0014 001A 000D)
0011) Trying: QWK (0014 001A 000E)
0012) Trying: QWL (0014 001A 000F)
0013) Trying: QWZ (0014 001A 001D)
0014) Trying: QWX (0014 001A 001B)



I threw everything together in a quick video:



Attacking the Attacker

I tested my key-crack rig against the R&D device. It worked - but it was inconsistent. Occasionally, the test keylog device would mount after successfully guessing the unlock keycode, but the keystroke log file was gone. In fact, it appeared the device had been wiped.

More experimentation determined there was an ‘undocumented’ feature of the device. A specific three-key unlock code had been assigned by the manufacturer as a ‘reset’ code. This is used in the event someone forgets their unlock keycode. Whenever my Teensy sent this combination down the wire – the keylog device was wiped. I modified my key-crack app to bypass the unlock code. After some more thorough testing, I was confident my Teensy would unlock the clients’ keylog device.



It took less than 30 seconds. The clients’ keylog device mounted and I was able to retrieve the keystroke log file and the config.ini file. Since the keystroke log has no concept of time, the client had to review the file content and correlate how much sensitive data might be somewhere it does not belong. Needless to say, providing this keystroke log file to the client was a truly valuable service.

Final Thoughts

These types of engagements always remind me of the importance of the physical security component of any security program. The keystroke log bandit who placed the device on the clients’ computer had to have physical access to it.

You read a lot these days about businesses and governments trying to re-invent themselves by focusing on innovation and ingenuity. This also applies to the digital security incident response universe. Innovation and adaptation to the constantly changing environment during a hot incident is essential. To all my fellow white-hats out there – never ever give up the good fight. If we do, we all lose.

Hack the planet.

48 comments:

  1. Good thing you managed to track down another device for testing. Else, the reset combination would have wiped the data from the target.

    ReplyDelete
    Replies
    1. Hi Austin,

      You are so right! That is exactly why we set up a test device to make sure we knew what we were doing. We knew we only had one chance to get it right when we went to crack the clients' device. If we did it wrong - we would have destroyed valuable evidence.

      Test, test, then test some more.

      Mike Spohn

      Delete
  2. Based on dissections of other USB devices, I'd lay $5 on the device containing a MicroSD card that you could have physically extracted and then analyzed without fear of destroying the data.

    ReplyDelete
    Replies
    1. Hi Tim,

      The keylog device is completely sealed. We know there is no MicroSD card in play here because in our research we found information from a source who cut one of these devices open and determined the guts contain a MCU that controls the device. No MicroSD card is used. The keystroke log is stored in flash memory.

      Why would a maker of these devices include a MicroSD if the idea is to be as discrete as possible and only allow the device owner to retrieve the keystroke log?

      Mike Spohn

      Delete
    2. Mike,

      Because MicroSD cards are cheaper and easier than rolling your own flash memory. I don't think Tim was suggesting it would be user-removable (without dissecting the device).

      Tom

      Delete
    3. Tom, I have to disagree. I've written code for many small embedded systems such as this one and MicroSD is expensive and complicated to support in many of them. It is far easier and cheaper to use the built in flash memory of the micro controller (unless of course you want to store GBs of data, but typically keyloggers only support KBs of data). Being built into the Micro also means you can't just suck out the data without using equipment such as an electronic microscope.

      Delete
  3. So, the wipe-content-combination-thingy was not changed by the attacker?

    ReplyDelete
    Replies
    1. The device reset key combination is hard-coded in the device and cannot be changed by the user. I doubt the owner of the device even knew about it. (It is not documented by the manufacturer).

      Mike Spohn

      Delete
  4. Just curious - did you try data recovery on the wiped device?

    ReplyDelete
    Replies
    1. Yes, I was able to analyze the wiped file system with my forensic tools. The file system on the device is FAT-12. The deleted log file was easily recovered.

      Very good question.

      Mike Spohn

      Delete
  5. Great job, but I am not buying your justification for not releasing the keylog manufacturer's name. Because:
    - If you tracked it down, someone would track it down as well.
    - If you were so concerned that they implement a counter measure to prevent brute-force, you shouldn't have published this.

    I think releasing the name of the manufacturer would've served better for the forensics community.

    ReplyDelete
  6. Fun project but not of much value. What are the odds of finding anything on the device other that the target's keystrokes, which the target would already be familiar with. No clues are revealed about how many times the key logs have been retrieved in the past.

    It really doesn't matter if the device manufacturer knows of this project or not as they would not be concerned. The 3 key code is a way for the attacker to operate the device not a method to protect a blown attack.

    ReplyDelete
    Replies
    1. Good questions. You can control the amount of logging done bye the device via a setting in the .ini file. For example, you can have the device log all the special characters types such as , etc. The device also logs when it is unlocked with the proper keycode. This provides a mechanism to roughly determine how many times the user accessed the device.

      This, of course, depends on whether or not the user deletes the log file after he/she access the device.

      Mike Spohn

      Delete
  7. Can you take the device apart, to see where the data is stored?
    If it has an attached Nand Flash chip, then a secondary mode of attack would be a strip down and dump of the Nand flash, just incase the manufacturer modified the login system.

    ReplyDelete
    Replies
    1. I was dying to try this, but I was reluctant to trash my $80 investment. I am quite certain this device had a NAND flash chip onboard. To get to it, I would have to cut open the device.

      Mike Spohn

      Delete
    2. I'm surprised you haven't. It would kill me not to. :p

      Delete
    3. Ok - Brad agrees. (He also could not contain his curiosity.) He is going to disassemble the keylogger and catalog its internals.

      Stay tuned.

      Mike Spohn

      Delete
  8. Great job. What prompted the look at the keyboard port anyway?

    ReplyDelete
    Replies
    1. Hi John,

      Great question. As is quite typical, an IT guy doing maintenance on the box found it.

      Mike Spohn

      Delete
  9. Awesome! I'm curious, how long did the entire process take? From the initial engagement to provided the log file to the client. Was the laptop left untouched with the device plug-in during the time?

    ReplyDelete
    Replies
    1. Another great question. The device was removed from the host as soon as it was discovered. Chicken-and-egg dilemma. Do you leave it in place risking the owner might retrieve it? Or do you take custody of it risking the owner will know you are on to him/her.

      It would have been really interesting if the client left it in place and set up a video surveillance camera.

      It took about a week to get a test keylog device and teensy delivered to the lab. Then we spent another week writing the code and testing it thoroughly before we tried to unlock the suspect device.

      Mike Spohn

      Delete
    2. Actually the cameras would do the job anyway, since the owner had no way to know if the device was discovered without going under the desk.

      Delete
  10. You could have struck back and maybe collected identifying info by replacing the keystroke file with misleading honeypot style data or placing an autorun worm on the volume. You never know how dumb the attacker is, maybe they'll click ok to autorun or chase a honeypot url from the dummy keystroke data.

    ReplyDelete
    Replies
    1. Unfortunately we are often contacted after the client has completed their initial investigation as in this case. If we were in early enough, we would have considered doing what you suggest.

      Thanks for the post.

      Mike Spohn

      Delete
  11. nicely done and for anyone who is trying to find this it took me all 2min to find the hardware and more so whats the big deal if they didn't reveal the manufacturer but here is a hint if you still need a hand lol lmgtfy.com

    ps. hardware is based on atmel 32bit risc mcu

    ReplyDelete
  12. What are the forensic tools you use to recover deleted files. I have bought a couple programs in the past and used a couple open source tools also. A tools link would be cool.

    ReplyDelete
    Replies
    1. Hi John,

      I used EnCase (www.encase.com)to obtain a forensic image from the mounted keylogger filesystem. You can also you FTK Imager (www.accessdata.com). They have a free version that is awesome. Don't forget the Sleuthkit. www.sleuthkit.org.

      Mike Spohn

      Delete
  13. I hope the company and you handled the logger with gloves to preserve any fingerprints the person who installed it may have left on it.

    ReplyDelete
    Replies
    1. Unfortunately, that was not the case. Initially, the client did not really know what the device was. They had some suspicion, but relied on us to convince them this device was evil.

      Mike Spohn

      Delete
  14. The ohmmeter also indicated the devices had resistive/capacitive (RC) characteristics due the obvious RC time constant resistance behavior. At this point, I knew the device was not passive – it has an electronic brain.

    WOW! A Capacitor for a brain! C’mon Watson, how do you deduce that?
    I *almost* quit reading the OSR report at this point!

    ReplyDelete
    Replies
    1. Probably measured between the +5V and GND lines and saw the values changing. This indicates a supply bypass cap, a quite good glue that there is something fancy inside.

      Delete
    2. I did not intend to insult your intelligence. JPA is exactly right. I suspected a filtering capacitor was present which meant the device had an electronic circuit.

      You have to realize the client initially believed this device was a passive USB extender. The RC behavior was a hint that this was not the case.

      Mike Spohn

      Delete
  15. Did you try file carving the mounted filesystem? That might have saved you if you accidentally hit the reset code on the real device (assuming secure deletion was not performed).

    ReplyDelete
    Replies
    1. Hi Andrew,

      We sure did and it proved very helpful. When the device is powered up for the very first time, some keyboard mapping files are created. The MAC times from these files gave us a pretty good idea of when the device was put in service.

      There were deleted files in unallocated space that also gave us some good timeline information. The rest of unallocated space was all zeros.

      Mike Spohn

      Delete
  16. Is there a valid time stamp when the config file was modified? This should give you a basic time frame of when the device was set up by the perp.
    What is the Capacity ? I am seeing a 2gb and 8gb capacities from a similar product, also notes that it has a disable logging mode and an Encryption setting.

    Would it be best to place the empty/disabled logger back but put a security cam and record who placed it, as someone mentioned?
    or various other CSI type of things :)
    Removal Alarm, UV dust, etc :P

    ReplyDelete
    Replies
    1. These are all great ideas. You can see from my response to a previous post we were able to determine when the device was put in service by the owner. This device is 8GB. Logging was not disabled. Encryption was disabled.

      What is so interesting about this case is that it involved electronic as well as physical security issues. We suggested to the client that they consider additional investigative steps similar to what you are suggesting.

      Thanks for the post.

      Mike Spohn

      Delete
  17. Interesting read! This reminds me of something I have done a couple of years ago. I also brute forced such a hardware keystroke logger, only mine was PS/2. The nice part is that the PS/2 standard allows for data going BOTH ways. So I could actually send keystrokes back to the keyboard (via the logger). The thing is, Linux does not take it very well if you write directly to the keyboard registers, it upsets the kernel quite a bit. I ended up modifying the Linux keyboard kernel driver to perform the brute forcing on a certain key press. I also made a function to write garbage to the keyboard to obscure what was actually typed in, for fun and giggles.

    ReplyDelete
    Replies
    1. Hi Yuri,

      Your creativity and innovation to solve the problem you were dealing with is awesome. Determination to overcome obstacles is also required as you found out with the keyboard driver.

      This is the stuff that makes forensic investigations so interesting to us. In fact, it is just plain fun.

      Mike Spohn

      Delete
  18. If I may add something.. not that it matters much, but one cannot hold the same key twice at a given moment. There's just one Q on the keyboard, so from the tweakers point of view this can be enhanced quite a bit =).

    Nicely done Mike, and kudos for the article.

    ReplyDelete
    Replies
    1. The fact you point out made it much easier for us to crack the unlock key code. It dramatically reduces the number of key combinations that can be used.

      Thanks for the post.

      Mike Spohn

      Delete
  19. This was a cool read.

    Do you have any suggestions on getting my feet wet with hardware hacking like this?

    Also, was forensics performed on the senior executive’s computer?

    Was there any evidence from the keylogger or other malicious use found on his computer, or other computers?

    Any who-done-it interviews with suspects?

    Thanks,
    Adam

    ReplyDelete
  20. did you find out the attacker's id? (I don't need to know; just wondering?)

    ReplyDelete
  21. If the attacker never cleared the log of the device since the original time of installation, you could search through the log to find every occurrence the unlock code was entered, if I'm not mistaken. That would help identify what information was gathered by the attacker, instead of just assuming anything on the device was compromised data.

    ReplyDelete
  22. This comment has been removed by a blog administrator.

    ReplyDelete
  23. What was the reset key combination?

    ReplyDelete
    Replies
    1. Never mind, I found it by looking through your sorcecode on github. Incidentally my device has the same reset code.

      I also found that you don't have to press the 3-key combination to enable flashdrive mode, several seconds as the manual says. I tried randomly mashing keys and hit the combination. This led me to the conclusion that "horizontal" combinations are easy to randomly hit, whereas "vertical" combinations are harder.

      What I mean by this is: Let's say the combination is SLV. Because the fingers naturally align in a lenghtwise manner on the keyboard it is much easier to accidentally hit SLV, whereas QAZ is really hard to hit by accident because you have to confine your fingere into a smaller vertical area.

      Just my thoughts... Great blog!

      Delete
    2. Hey MIKE: I FOUND A PS/2 KEYLOGGER IN MY STORE THE QUESTION IS IF I USE SAME CODES THAT YOU USED FOR THE USB IS GOING TO WORK

      Delete