Publications Details

We (Netragard) recently completed an engagement for a client with a rather restricted scope. The scope included a single IP address bound to a firewall that offered no services what so ever. It also excluded the use of social attack vectors based on social networks, telephone, or email and disallowed any physical access to the campus and surrounding areas. With all of these limitations in place, we were tasked with penetrating into the network from the perspective of a remote threat, and succeeded.

The first method of attack that people might think of when faced with a challenge like this is the use of the traditional autorun malware on a USB stick. Just mail a bunch of sticks to different people within the target company and wait for someone to plug it in; when they do its game over, they’re infected. That trick worked great back in the day but not so much any more. The first issue is that most people are well aware of the USB stick threat due to the many published articles about the subject. The second is that more and more companies are pushing out group policies that disable the autorun feature in Windows systems. Those two things don’t eliminate the USB stick threat, but they certainly have a significant impact on its level of success and we wanted something more reliable.

Enter PRION, the evil HID.


A prion is an infectious agent composed of a protein in a misfolded form. In our case the prion isn’t composed of proteins but instead is composed of electronics which include a teensy microcontroller, a micro USB hub (small one from RadioShack), a mini USB cable (we needed the ends) a micro flash drive (made from one of our Netragard USB Streamers), some home-grown malware (certainly not designed to be destructive), and a USB device like a mouse, missile turret, dancing stripper, chameleon, or whatever else someone might be tempted to plug in. When they do plug it in, they will be infected by our custom malware and we will use that point of infection to compromise the rest of the network.

For the purposes of this engagement we choose to use a fancy USB logitech mouse as our Hacker Interface Device / Attack Platform. To turn our logitech Human Interface Device into a Hacker Interface Device, we had to make some modifications. The first step of course was to remove the screw from the bottom of the mouse and pop it open. Once we did that we disconnected the USB cable from the circuit board in the mouse and put that to the side. Then we proceed to use a drummel tool to shave away the extra plastic on the inside cover of the mouse. (There were all sorts of tabs that we could sacrifice). The removal of the plastic tabs was to make room for the new hardware.

Once the top of the mouse was gutted and all the unnecessary parts removed we began to focus on the USB hub. The first thing we had to do was to extract the board from the hub. Doing that is a lot harder than it sounds because the hub that we chose was glued together and we didn’t want to risk breaking the internals by being too rough. After about 15 minutes of prying with a small screwdriver (and repeated accidental hand stabbing) we were able to pull the board out from the plastic housing. We then proceeded to strip the female USB connectors off of the board by heating their respective pins to melt the solder (careful not to burn the board). Once those were extracted we were left with a naked USB hub circuit board that measured about half an inch long and was no wider than a small bic lighter.

With the mouse and the USB board prepared we began the process of soldering. The first thing that we did was to take the mini USB cable, cut one of the ends off leaving about 1 inch of wire near the connector. Then we stripped all plastic off of the connector and stripped a small amount of wire from the 4 internal wires. We soldered those four wires to the USB board making sure to follow the right pinout pattern. This is the cable that will plug into the teensy mini USB port when we insert the teensy microcontroller.

Once that was finished we took the USB cable that came with the mouse and cut the circuit board connector off of the end leaving 2 inchs of wire attached. We stripped the tips of the 4 wires still attached to the connector and soldered those to the USB hub making sure to follow the right pinout patterns mentioned above. This is an important cable as its the one that connects the USB hub to the mouse. If this cable is not soldered properly and the connections fail, then the mouse will not work. We then took the other piece of the mouse cable (the longer part) and soldered that to the USB board. This is the cable that will connect the mouse to the USB port on the computer.

At this point we have three cables soldered to the USB hub. Just to recap those cables are the mouse connector cable, the cable that goes from the mouse to the computer, and the mini USB adapter cable for the teensy device. The next and most challenging part of this is to solder the USB flash drive to the USB hub. This is important because the USB flash drive is where we store our malware. If the drive isn’t soldered on properly then we won’t be able to store our malware on the drive and the the attack would be mostly moot. ( We say mostly because we could still instruct the mouse to fetch the malware from a website, but that’s not covert.)

To solder the flash drive to the USB hub we cut about 2 inches of cable from the mini USB connector that we stole the end from previously. We stripped the ends of the wires in the cable and carefully soldered the ends to the correct points on the flash drive. Once that was done we soldered the other ends of the cable to the USB hub. At that point we had everything soldered together and had to fit it all back into the mouse. Assembly was pretty easy because we were careful to use as little material as possible while still giving us the flexibility that we needed. We wrapped the boards and wires in single layers of electrical tape as to avoid any shorts. Once everything was we plugged in we tested the devices. The USB drive mounted, the teensy card was programmable, and the mouse worked.

Time to give prion the ability to infect…

We learned that the client was using Mcafee as their antivirus solution because one of their employees was complaining about it on Facebook. Remember, we weren’t allowed to use social networks for social engineering but we certainly were allowed to do reconnaissance against social networks. With Mcafee in our sights we set out to create custom malware for the client (as we do for any client and their respective antivirus solution when needed). We wanted our malware to be able to connect back to Metasploit because we love the functionality, we also wanted the capabilities provided by meterpreter, but we needed more than that. We needed our malware to be fully undetectable and to subvert the “Do you want to allow this connection” dialogue box entirely. You can’t do that with encoding…

To make this happen we created a meterpreter C array with the windows/meterpreter/reverse_tcp_dns payload. We then took that C array, chopped it up and injected it into our own wrapper of sorts. The wrapper used an undocumented (0-day) technique to completely subvert the dialogue box and to evade detection by Mcafee. When we ran our tests on a machine running Mcafee, the malware ran without a hitch. We should point out that our ability to evade Mcafee isn’t any indication of quality and that we can evade any Antivirus solution using similar custom attack methodologies. After all, its impossible to detect something if you don’t know what it is that you are looking for (It also helps to have a team of researchers at our disposal).

Once we had our malware built we loaded it onto the flash drive that we soldered into our mouse. Then we wrote some code for the teensy microcontroller to launch the malware 60 seconds after the start of user activity. Much of the code was taken from Adrian Crenshaw’s website who deserves credit for giving us this idea in the first place. After a little bit of debugging, our evil mouse named prion was working flawlessly.

Usage: Plug mouse into computer, get pwned.

The last and final step here was to ship the mouse to our customer. One of the most important aspects of this was to repack the mouse in its original package so that it appeared unopened. Then we used Jigsaw to purchase a list of our client’s employees. We did a bit of reconnaissance on each employee and found a target that looked ideal. We packaged the mouse and made it look like a promotional gadget, added fake marketing flyers, etc. then shipped the mouse. Sure enough, three days later the mouse called home.


  1. Awesome! I like the way you avoided having to do anything clandestine to introduce an unwitting MITM attack. I might suggest though that you could have avoided all the teardown/soldering by using a highly affordable USB enabled microcontroller to begin with. An ArduinoProMini + an FTDI breakout adapter for instance. The coding would have been much quicker with it too. A small in-line connector from Mouser and you would have only needed to solder a few wires to the FTDI breakout board connected to the Arduino through a soldered on pin-header.
    I have heard of this being done with USB speakers as well. With something small like the ArduinoProMini (18mm x 33mm x 0.8mm), I imagine that it would be easy to engineer and produce a delivery package through Ponoko or another small manufacturing shop, that looked like and included an inexpensive USB thumb type drive.
    Anyway…thanks for the information. I will pass it on to our Security group for policy evaluation purposes.

  2. 0day exploit = ipoverdns or some dns based shell?
    I doubt the anti-virus would notice that

    1. No, that’s not the 0-day technique ues. Metasploit supports a shell over dns with the windows/meterpreter/reverse_tcp_dns shell. Most AV does detect that these days, they pop the “Do you want to allow” box. So again, no the reverse coms over DNS is not 0-day, its very well docimented.

  3. So with no idea which computer systems the employee is going to use you send them a malware ridden mouse they could have quite easily plugged into a critical server and taken offline?
    Do you not think the reason your client gave you a single IP address was because they did not want you targetting their other systems? This all sounds very unprofessional – if you had to create an advert for not using your company then this would be it.

    1. I love comments like these!
      When our customers hire us, their intention is to identify the various ways that a real threat can penetrate into their IT infrastructure. They choose to activate certain “threat modules” during our scoping process and those modules produce varying levels of threat. They also authorize certain target classes based on the threat modules that they activate. When using a device like our PRION device, they are made well aware of where it might be plugged in.
      Something that you seem to be overlooking is that we create the malware. As such, we design it to be covert, highly stable, very light weight, and to be non-damaging. As mentioned in the blog post the malware is based on Metasploit’s Meterpreter which is a de facto standard professional-grade tool for Penetration Testers around the world. The difference between our malware and meterpreter (as described in the blog) is that we’ve customized it.
      So, the mouse is not a “malware ridden mouse” and it truly is a surgical weapon designed to give our team access to the target network with no collateral damage, or any damage for that matter. Because of the nature of the mouse, and the nature of the malware on the mouse, there’s little to no chance of the mouse causing an outage on any system that it is pluged into. More importantly, I’m not sure about your customers, but most of ours don’t plug random devices that they receive in the mail into critical systems. if a customer were to pug a PRION device into a critical system then that in and of its self would be a finding, would it not?
      In closing, I can say that in the history of Netragard we have never taken a single system off-line accidentally. The reason being is that we don’t scan our customers generating a lot of noise and useless connections and risking hitting an unstable system. Instead, our tests are very surgical and driven by researchers. Who would you rather have testing your network, someome who understands the attacks and technology that they are using or someone who buys that technology off of others and doesn’t fully understand it?

  4. I would suggest reloading this hack with a keyboard, but embed a 2G modem inside it and a more powerful micro-controller like the mbed. Then you can own the network and users password, at night you can roam the network at your leisure.

    1. That idea has just been added to the project list…

  5. If the company had disabled autorun via policy, would this exploit have worked? Or were you depending on the user to explore to the new USB storage and run a trojan manually?
    It seems all you did was hide a usb stick inside a mouse, thus tricking the user into plugging it in where they might not have plugged in a promo usb stick.
    Using a different USB gadget that uses only USB power (cup warmer, can cooler, hula dancer…) would have eliminated the need for a hub but might have raised suspicion about “auto-installing drivers” if the user were paying attention.

    1. Yes, the attack will work and does not rely on autorun what so ever. The attack works because we embed a teensy microcontoller in the mouse. That controller is programmed to launch our malware. If you read the entire blog entry you’ll understand more clearly.

  6. So the malware got out because the company was allowing endpoints to query DNS servers directly on the internet and not use a a central internal DNS server that did the lookups for them?
    Or did they simply have an any-any-outbound-accept rule?

    1. They had minimally restricted outbound connections, DNS was one of the services allowed “out”.

  7. If DNS is only allowed out, would I be correct in assuming you could not “send” commands to your “infected” host.
    Did you have your malware constantly poll your DNS server for new commands in order for it to “fetch” new commands?

    1. Again, we used the meterpreter reverse_tcp_dns payload. If you understand how that works then that should suffice to answer the question. Not all networks are the same by the way, some should be more restricted than they are, others are possibly too restricted.

  8. […] a detailed blog post on the website of his firm, Netragard, Desautels describes a recent assignment: to find security […]

  9. And the outbound session to port 51557 was one of those outbound connections that was allowed?

    1. Yes, the outbound connection was allowed and as used the reverse_tcp_dns payload from meterpreter, different port… where did you get 51557 from?

  10. I Think that you did a fine job within the restricted boundaries provided.
    I can envision a world we’re the hack is not directed at the target itself but at his suppliers.
    Offcourse equipment is checked before shipping ..or is it not-:)

  11. Actually, you stated social engineering was out of scope, yet you social engineered an employee into pluging in your trojan mouse.
    While it’s a cool hack, I sure wouldn’t be hiring you if you can’t stick to the rules of engagement.

    1. The customer doesn’t agree with you in this case since the customer approved this specific attack.

  12. […] the Netragard blog The last and final step here was to ship the mouse to our customer. One of the most important […]

  13. It’s about time someone finally used this “in the wild”! And kudos for giving credit where it’s due; Irongeek’s been talking about this for years and I’m delighted to see it getting some real press. El Reg, no less!
    It’s also acutely amusing to watch software guys do hardware. As cool as the outcome is, the execution just screams “we need to hire someone who solders for a hobby!”. 😉 I’m delighted that you tried it, and encouraged that you and other pen-test groups will be more likely to do this sort of stuff in the future.
    Agree with Bob, I’ve been using various RF modems for remote admin since the days of Ricochet. Wrapping it in an innocuous-looking case, and sneaking it in somewhere, is only advisable if you’ve got the appropriate relationship with the target, of course! With such hardware getting smaller all the time, burying one inside a mouse or hub seems not only practical but obvious. Hint: For a remote shell, plain old GSM modules offer plenty of bandwidth, and the’re small and cheap. 🙂

  14. Aaron Stone — the Teensy is arduino-a-like. They very likely programmed it using the arduino software.

  15. […] a blog post on the company’s website, NetraGard founder Adriel Desautels explained that his company was hired to test the security of a […]

  16. There’s a thousand ways malware can get into any company. The trick is to keep it from getting out and most avenues can be handled or handled enough that the malware’s probing trying to get out will show up in the logs. If you’re logging and if you’re looking, that is. 🙂
    Not to take anything away from your handiwork, which is pretty clever, but the attack worked because an ages-old practice of not controlling outbound traffic was still in use. Personally, I would have taken the mouse home. 🙂

    1. If you had taken the mouse home then we would have owned your home computer and looked for a way to get from there to your office. (Assuming we were authorized to do that).

  17. […] Hacking a network with an infected mouse (Netragard) […]

  18. This is brilliant! Scary, but brilliant! I wish people would read the entire blog before saying anything was done out-of-scope…

  19. Uhhh, this was all done between irongeek and the social-engineer toolkit a long time ago: How is this their HID device?

    1. James, hence why we gave credit to Adrian @ If you read the entire article you’d have seen the reference. We certainly do not claim credit for being the first to develop this technique, but we most certainly are among the first to use it with success and to write about it. Raising awareness is important.

  20. […] firm Netragard has described an attack during which a modified computer mouse was used to infiltrate a client’s corporate […]

  21. […] firm Netragard has described an attack during which a modified computer mouse was used to infiltrate a client’s corporate […]

  22. Hello,
    is there any sourcecode available ?

    1. You can get most of the source code from Adrian at Our own code won’t be shared.

  23. […] Die Mausemaus […]

  24. “If you had taken the mouse home then we would have owned your home computer and looked for a way to get from there to your office. (Assuming we were authorized to do that).”
    That indeed would be an interesting twist. So the lesson here is “Beware of geeks bearing mice.”

  25. Thanks for the mention and the link 🙂

    1. Its our pleasure man! You did some solid work and we thought that you should be recogonized for your innovation. No need to thank us, its us who should be thanking you! Keep it up and if you ever need assistance let us know.

  26. Sweet, using Adrian’s trick you snuck into a new server install before it was even joined to the domain or likely given any sort of protection against malware.
    I guess that’s proof enough that the Phukd mouse works.

  27. @Aaron Stone : waht advantages exactly would they have gained by using the ArduinoProMini (ATmega 168) vs the Teensy (ATmega32) ??? They both use the same development tools, is there some advantage to the extra memory that would have made the coding quicker?
    With the teensy they don’t need the FTDI breakout because the USB plug is already on it.
    To each their own which arduino platform you pick, but I don’t see your point about how it would have been any easier or quicker with that one vs the one they chose.

  28. Already done this several years ago, except my vector was slightly different.
    Used the USB-Nand flash stick controller from Cypress. (hay look mom they GIVE you the full platform 8051 source for implementing USB & a Nand-Flash stick)
    Then buried the exploit inside the microprocessor control code and a hidden area on the nand-flash memory. (not as auto runcrap)
    To all intents and purposes the Nand-flash stick looked empty(and can be used as a standard Usb-stick device), but after a number of uses the microprocessor code injects the payload from the ‘hidden’ Nand-flash block area over the USB.
    You do not need to get all complex on this, just find a suitable Nand-flash stick and re-program the integral controller, if you are real lucky there is minimum/no soldering.
    This is a Highly surgical attack vector, all the code is hidden inside the Nand-flash chip & the embedded CPU, plus if it is disassembled /x-rayed it LOOKS like a usb-stick, pay loads can be block loaded into the ‘payload’ section.
    No the code is NOT available…., far too dangerous.

  29. Great modus operandi but the article doesn’t describe what the malware did…Getting it on a target system is only the first step, I guess you then have to control it remotely and stealthily, as well as receive whatever data it creates or gathers? Also how did you make sure you it would get installed on a target machine which is used by admins or VIP?
    Thanks for the ideas nontheless!

  30. Taking this discussion up one level:
    This excellent article illustrates the near impossibility of securing a network staffed by human beings. Unlike machines which can be (should be) given strict limits on what they can do, humans are expected to use tools they don’t really understand (computers) to manage projects whose boundaries and parameters change constantly. In this case, no one at the target company even conceived that this hack was possible, and employees were not trained to think “malicious hacker” upon receiving some freebie in the mail. In the case of our clients, I get significant pushback (laughter, eyes roll, etc.) whenever I talk about security best practices with regular staff– they don’t understand it, don’t want to understand it, literally can’t understand it (in some cases) and surely don’t want to waste their time trying to remember it all.
    I hate to sound pessimistic, but is this kind of attitude going to change anytime soon? In fact, is keeping data secure always going to be a losing battle until this “weakest link” problem is solved?

  31. Quick question: instead of a USB hub, why not use the guts of one of the USB sticks that has USB pass-through, or even one that contains a mini-hub? (I’m looking at one on my desk that plugs in, gives you a 2GB flash, and a Y-split into two more ports. I use it for installing *NIX on servers with only one USB port – it gives me a place for a keyboard and mouse if needed.)

  32. “You should be ashamed of yourself for demonstrating the vulnerability of a client’s network to them,” is what it seems like some here are saying. What idiot admin would have only one IP in their network audited for security? That’s like locking up your house and then telling a security researcher to try breaking in, but only using the kitchen window. What possible use is a test like that?

  33. […] as promotional freebies. If you are feeling really devious you could try something like this…. Netragard’s Hacker Interface Device (HID). | Netragard's SNOsoft Research Team "Strange women lying in ponds distributing swords is no basis for a system of government. […]

  34. […] thousand years later and Trojan horses still work. Check out here what Netragard did for a client pen test. LikeBe the first to like this […]

  35. […] In a blog post on the company’s web­site, Netra­Gard founder Adriel Desau­tels explained that his com­pany was hired to test the secu­rity of a client’s net­work while adher­ing to some very strin­gent restric­tions: The Netra­Gard team could tar­get only one IP address, offer­ing no ser­vices, bound to a fire­wall. Fur­ther, the team couldn’t even use social engi­neer­ing tac­tics, such as dup­ing an employee to reveal infor­ma­tion over the phone or via email. They couldn’t even phys­i­cally access the client’s campus. […]

  36. […] an informal standpoint, there’s the case of the Trojan Mouse. Asked to test a company’s security without relying on e-mail or other traditional malware […]

  37. Does this rely on the same vector, namely autorun being enabled?

  38. Oh, I see that it doesn’t and you already answered that, sorry.

Comments are closed.