Search the Community

In order to provide a PoC that non-administrative access still can result in huge data breaches I present to you The Hidden PP Attack A one liner PoSh command that can be executed from a Teensy/Rubber Ducky which leaves the machine open to injections of PoSh code remotely. Quite happy with this project so I thought id drop it here. Ive lurked remotely without an account for some time without contributing, so... here you are https://simpleinfosec.com/2018/01/09/the-hidden-pp-attack-a-non-administrative-remote-shell-for-data-exfiltration/ https://github.com/secsi/HIDdenPPAttack

Hi, I got a teensy 2++ and i use it as bad usb, by plugging it with the usb connector, the question is: Can i put the 5 usb wires on the teensy pins and make it work by connecting directly to them ? (I'm a little newbie in electronic ..)

Hi there, Can I use teensy 2++ to use BadUSB exploit like a rubber ducky ?

I have recently found an article by Samy Kamkar regarding HID exploitation and was wondering which is better. (i understand preference but im more interested in the speed and flexibility aspect of the two as well as ease of deployment) Also, i was wondering if there was a way to turn a teensy into a faux Rubber ducky in regards to making it possible to use the Rubber Ducky coding language on a teensy?

Hi! i'm about to buy a usb teensy and I got an idea about pranking other students about changing the wallpaper image and redirect to a youtube video. I have seen a guy mentioning darrens wallpaper idea but i want to change from an online image

I created a sort of converter, that converts simple scripting commands to teensy C source. I've decided to write in Python since its cross-platform, and most *unix/Linux machines come with it installed. I have decided to do this because some people may already own a teensy, and want what a teensy can do, but sadly dont have the C experience that others may have. Heres a little screenshot of what gets outputted: I did not implement a default delay yet, so you have to be a tad bit more careful when executing multiple 'commands' one after the other. What do you guys think, any questions? I wanted to say, I know alot of people have done something like this. so dont be too mad since I decided to do it also :P I wasnt planning on sharing due to that fact, but I just felt like I had too.

I am wanting to get a USB Rubber Ducky but unfortunately, i cannot afford it at the moment. I was wondering though, would i be able to get a teensy 2.0, put a SD card reader on it, and put a USB male to male adapter to kind of make my own, cheaper Rubber Ducky? I was searching around on the internet and i came across the Community Edition Encoder and Firmware on the ducky website, and i was wondering if i could put this on the Teensy and make it into a rubber ducky? Or am i misunderstanding what the Community Edition encoder and firmware actually is? If one is able to do this, could you explain how you would do it? Do you put it on the SD Card? What do you do? I am just a little lost when it comes to the whole thing, but I am trying to learn and after a lot of googling, i could not find anything so i figured i'd ask here. Any help is greatly appreciated. Thanks.

Hello hackers, coders and imagineers, I don't know if the Rubber Ducky is looking for an upgrade anytime soon, but if so I have a few ideas based on a recent project of mine, which uses the Teensy 3.1. Firstly, the one way nature of the device makes it difficult to acquire information from the host system. I see you have solved this by suggesting that a USB drive is used in parallel with the Rubber Ducky. Whilst this is a solution, it would be nice if the device could imitate a hub and provide the functionality of both the Rubber Ducky and a USB drive. Though, this will increase the hardware requirements and cost, so may not be ideal. In my project I simply used the onboard EEPROM to store data, which removes the need for two USB sticks, but severely limits the amount of non-volatile memory available. So, the addition of some non-volatile memory that can be written to and then read from at a later time would be nice to see on the Rubber Ducky. Secondly, although there is non-volatile memory available on the Teensy, this doesn't solve the problem of feedback: How do you get the data mined from the host system back on to the device? This is difficult since the device is pretending to be a keyboard and keyboards generally don't require feedback. In my project I utilised the fact that whilst the Teensy emulated a keyboard it could simultaneously run a serial connection. In this way I could get the Teensy to find the relevant information and then send it to itself via an open serial link. This opens up the use of the available non-volatile memory as mentioned above, but also many other things that weren't possible without feedback. For example, in my project I mess with the "networksetup" command in terminal, which, in most cases requires the user to specify the hardware port in question. As such, the first thing I do is to get a list of all the ports on the host system. This is then fed back in to the Teensy, which searches for the hardware port related to the WiFi. Then this information can be used to send commands to turn the WiFi card off, change the AP to which the host system is associated or just gather more information. This could be a huge advantage if implemented on the Rubber Ducky. Lastly, with most keystroke injection attacks commands have to be sent and then there's a delay whilst the host system executes the command. However, these delays can vary wildly making them very difficult to predict. In my project I added a debug mode option, which allows the user to step through chunks of code so that the variable delays can be controlled by the user. Additionally, these types of attacks are unreliable, since a program may not start as expected or a pop up gets in the way. For this reason I also added a reset button, so that if the attack fails it can quickly be reset and start again without having to unplug and replug in the device. These can be very useful in practise, however they both require the addition of a button, which could make the Rubber Ducky look less like a legitimate USB drive. As a side note, another thing I found useful was an LED indicating when the program was complete. It's especially convenient when you are unable to see the screen of the host system. If anyone is interested this is the link to my project called the WiFi Pixie: http://www.instructables.com/id/WiFi-Pixie/ There's code there as well, which is the most interesting part of this project. The Teensy platform is good if anyone wants to get very hands on with this type of pen testing tool. It uses the Arduino IDE and will require some knowledge of C. But if you're more familiar with scripting languages and you want an easy device to plug-and-play with, then the Rubber Ducky is probably a better option. I would also be interested to hear of any other ideas people have for this kind of device... Hack on!