Tag: hacking tools

Hacker-Tool Hump-Day – Kali Nethunter on Nexus 10 tablet

Last week, my Nexus 10 tablet arrived in the mail. I ordered this tablet with a few purposes in mind, but foremost was my intention to run Kali Nethunter on it. I chose this particular tablet, because the forums seemed to indicate few issues with this device, the screen size is quite nice (for a tablet,) and it doesn’t have cell phone capabilities. I specifically wanted a tablet that only worked with local wifi, and not cellular networks. I chose the 32 gig version, because there is no documented way to increase the local storage.

The package arrived, and my wife texted me that it looked a bit beat up. When she showed me a picture of the package, my first thought was the opening scene from Ace Ventura. The device itself was okay, thankfully, so I placed an order for a tablet case/cover with keyboard, and began prepping the tablet for its new function in life.

The first evening, I allowed the tablet to update as far as it could, then went into the System Updates and selected updates manually until it went from Android 4.2.2 to 5.1.1. After each major update, I powered the tablet off and turned it back on. This took most of the evening, so I installed Netflix on it, and my wife and I curled up to watch the last episode of Blacklist available on the streaming service before going to sleep.

The next day, I downloaded the tools to my linux laptop for dealing with unlocking and rooting the device. The table of supported devices at the Kali Nethunter page said that Android 5.1.1 would be sufficient, but that the device would need to be unlocked and rooted, so that was the goal.

I downloaded android-studio-ide-145.3360264-linux.zip from https://developer.android.com/studio/index.html and extracted the zip file. Then I changed directories to android-studio/bin and ran “./studio.sh” to set up the initial installation. Unfortunately, this wasn’t what I needed or wanted, but I didn’t know that at the time. Once I figured out why things weren’t looking the way I expected, I went back to the developer site and found out that you need to scroll way down the page to get the actual file needed. I went up a directory and removed the files from this initial bad download.

I downloaded android-sdk_r24.4.1-linux.tgz this time, and extracted the tarball. I changed directories to Changed directories to android-sdk-linux and ran tools/android. I went through the GUI but it was having issues with updating, so I went to “Selected Tools => Options” and checked the “Force https//… sources to use http://…” check box to deal with the “peer not authenticated” errors. I assumed these were caused by our corporate gateway that cracks open SSL for inspection, and turning this on did indeed work.

From there, I went to the “Packages” list and selected the “Android 5.1.1(API 22)” packages. I selected all of these, and told it to install the packages, accepted the license, and then hit “install.” I exited the SDK GUI, but had to come back to this and do this step again after connecting to the tablet later down. This step only installed two items, and there were well more than two needed before I was through.

On the tablet, I swiped down twice to click the settings gear, went ot “About tablet” and tapped the “Build number LMY49J” seven times to put the tablet into developer’s mode. It indicated as much with “You are now a developer.” I went back one screen and selected “Developer Options” which was now available, and turned on “USB debugging.” At this point, I plugged the tablet into the computer using the USB cable supplied with the tablet.

I ran a “dmesg” on the laptop to confirm it was seen as a new device, then ran “platform-tools/adb devices” to verify it was seen by the developer tools suite.

At this point, I re-ran the GUI tool “tools/android” and selected the rest of the files that were missing for my tablet. Once they were all installed, I was able to do the “platform-tools/adb devices” command again.

To put the device into fastboot mode, I ran “platform-tools/adb reboot bootloader” and while the tablet was at the fastboot menu, I ran the following command from the laptop to unlock the device:

platform-tools/fastboot devices
sudo platform-tools/fastboot oem unlock

If the first command (fastboot devices) doesn’t show your device, even if adb devices does, something is wrong and more troubleshooting is needed. Otherwise, go ahead and do the fastboot oem unlock at this point.

My table rebooted and seemed to be stuck in a boot loop. The graphic with the four swirley colorful dots never seemed to stop, so I did some online research and found that this device is known for getting in a boot loop after the unlock. The solution is to go back to fastboot mode by holding down both volume up and volume down as well as the power button (all three) until it reboots. Once it is back in fastboot mode, use the volume buttons until the menu says “RECOVERY MODE.” Push the power button again, and let it “recover.”

Because it took me some time to figure out how to get it out of the boot loop, I spent the rest of that evening letting it recover from the online backup it had made, then headed to bed with my wife.

On day three, I set up all of the developer tools again, put the tablet back into “Developer mode,” and hooked it up to the computer. I downloaded nethunter-manta-lollipop-3.0.zip via https://www.offensive-security.com/kali-linux-nethunter-download/ to my laptop. I also downloaded TWRP (Team Win Recovery Project) from https://twrp.me/site/update/2016/04/05/twrp-3.0.2-0-released.html per the recommendations on the Nethunter Wiki. The file was twrp-3.0.2-0-manta.img in case you’re following along.

In order to install twrp, I changed directories to the android-sdk-linux/platform-tools directory from the day before, and ran:

adb reboot bootloader
sudo fastboot recover twrp-3.0.2-0-manta.img

I installed via the menu options, then pushed the nethunter image across with:
adb push nethunter-manta-lollipop-3.0.zip /data/local/tmp/nethunter-manta-lollipop-3.0.zip

Back on the tablet, I navigated up, then back down to the appropriate location data => local => tmp.

I selected the ZIP file and told it to install, answered the questions presented, and rebooted.

Unfortunately, something went wrong with the installation using this method. Some more research, and I found that I could repair this by uninstalling the individual nethunter applications and then installing the latest “APK” file, instead. This meant I needed to get the latest.apk. I also needed to install SuperSU, which was an option that was unchecked by default in the ZIP install menu.

I went to Google Play to install SuperSU, then continued with the APK installation as below.

I opened chrome and selected the following URL to get the APK needed:
https://images.offensive-security.com/latest.apk

I then installed that by selecting it through the downloads folder, and it installed better. I’m not sure it installed perfectly, yet, but it at least has the nethunter app, now.

I then had to set Nethunter to be allowed with super user privileges by SuperSU.

Unfortunately, it says there’s no busybox, and I’m not sure if that got missed by the APK, or if something else is going on. TWRP wants to install a BusyBox app, but it’s not the one built into the Nethunter suite. I may go ahead and install that one, but I’d rather have the one provided by Nethunter.

Due to the extreme hecticness of this holiday season, I haven’t had an opportunity to really play with this, yet, but I will go through and work with it some more so that I can do a decent write up of some of its features, before I’m through. In the mean time, I’ll return to covering the Hak5 LAN Turtle modules next week.

Thanks for reading!

Hacker-Tool Hump-Day – OpenSSL

We’re skipping the LAN Turtle module that would have been show cased this week in favor of a short post. On the bright side, I got 1804 words written for my first day of NaNoWriMo 2016. On the less than shiny side, I’m oncall this week at work, and I’m short on time for the Wednesday post. So let’s get to it.

Today’s topic is a tool that some people may not realize can be used in the same vein as telnet, netcat, and socat for connecting to ports and testing them with manual manipulation of whatever the plain text protocol might be (such as HTTP or IRC, for example.) It can also be used to stand up a temporary SSL enabled service for testing how clients behave, similarly to how a netcat listener might be used.

To test connectivity, use the “s_client” module with the “-connect” flag. The target of the -connect flag should be an IP or hostname with a port, and separated by a colon. For example:
openssl s_client -connect google.com:443

Once you connect, you should see some information about the certificate along with a status code to indicate what the problem is if the certificate doesn’t meet expectations. It will then sit and wait for you to send whatever commands you might like just like a telnet or netcat connection would do. It handles the actual SSL handshake for you.

The listening option is the “s_server” module with the “-accept” flag. The target of the -accept flag is just a port number. Of course, the listening service should probably also be given a certificate to use for the listening connection, so use the “-cert” flag to pass a certificate to this command for use on the listening socket. You can set up a listening socket without a cert by using the “-nocert” flag, but this is kind of pointless.

Again, the primary focus of this for most people will be the s_client module, so that SSL enabled ports can be probed for banners and such. Alternatively, shell scripts can be written that call this in order to automate certain kinds of connections with intentionally malformed requests to test how the server behaves, or to pass known vulnerable requests to the server, and so on.

Of course, it can also be used to look at the server’s certificate and settings in case there is a vulnerability there, such as a weak cipher list, for example. Perhaps the certificate is due to expire, soon. A man in the middle situation might be easier to set up during that window between certificate expiration and certificate renewal if the site owner allows the cert to fully expire before renewing. Possibilities are almost endless.

That’s all for now. Thanks for reading!

Hacker-Tool Hump-Day – Lan Turtle Module – autossh

Today, we’ll go over one of the simplest modules provide for the Hak5 LAN Turtle. The “autossh” module is used to create an ssh session from the Turtle out to a pre-designated target server, and use the SSH proxying features to present a port for logging back into the Turtle over this tunneled proxy connection. This can be used in an environment that allows outbound SSH connections to create a connection into the internal LAN via some outside listening system. While there might be legitimate uses for this, make sure you follow corporate policy on such things before taking advantage of this feature on your work network.

To set this up, go to the Turtle shell (menu) and select:
Modules => autossh => CONFIGURE.

There are three fields that need to be filled in. The first is the “User@Host” field, where you put the target user and the target hostname or IP address for logging into the remote system. In order to make that outbound connection, the Turtle needs to know who to login as, and where to login at. This is how you tell it that.

The second field is the “Remote Port” field, and defaults to 2222. This is the port that will get established for the “dial back in via the proxy” tunnel.

The last field is the “Local Port” field, which defaults to port 22 and is fine to leave as is.

After you configure the ports, you can try to use it right away by telling it to “start,” but I generated a key pair and pushed the public key out to the target system from the command line when I tested this. I don’t think it will work without setting up a key manually, first. The Turtle does include “ssh-copy-id” if you prefer to push your key that way, and “ssh-keygen” to generate that key, but the key type should be RSA and use the “id_rsa” default naming scheme. This appears to be hard coded within the module. If you prefer a different key type, you’ll need to modify the module script to call a different key. The script is at /etc/turtle/modules/autossh if you’re looking to customize this.

After you’ve pushed your key and set up the “config” options, you can go back to the Turtle shell (menu) and select the module again, then select “START” instead of “CONFIGURE” to test it. Log into your remote target machine and see if you have a listening port per your “Remote Port” setting (default 2222.) If you do, you can try logging into the Turtle from that machine by doing “ssh -p 2222 root@localhost” (replace 2222 with whatever port number you chose to use if you overrode this default value.) You should be able to connect. If it works as expected, you can go back to the Turtle shell (menu) and select the module one more time, this time to “ENABLE” it. This will make it autossh every time the Turtle is rebooted (or powered on.)

This is equivalent to using the -R flag discussed on Monday.

Disable it when you’re not intending to use it, though. If you’re not getting the expected connection back into the Turtle, make sure there’s not a conflicting service using that “Remote Port” option you chose. If there is, change it to a port that’s not in use. Also check that firewalls aren’t blocking that port per standard troubleshooting techniques (netstat, telnet, etc.)

That’s it for this week, folks. We’ll probably cover another module next week, but with the new kids, the schedule might change without warning.

Thanks for reading!

Hacker-Tool Hump-Day – john the ripper

Another quickie today. Before we get to the technical goods, I thought I’d share an update on the family situation. We have both “bonus” children home safe and sound, and everyone is settling in just fine. The hectic nature of the trip, and post-trip excitement has reduced the time I have to work on a good detailed post this week, so I apologize in advance for the lack of substance I may be about to present. I will review this post, and possibly do a more in-depth review of this tool to flesh out the details another day. On to the spotlight!

John the Ripper is a staple tool for cracking passwords. If you can get your hands on a set of hashed passwords, you can use this tool to make an attempt at cracking them. It does a fair job on any standard system, but some people build elaborate rigs to throw as much computing power at the tool (or a modified version of it for distributed cracking) to reduce the time it takes to crack some of the more complex passwords a user might set.

You can feed it a dictionary file, tell it to try different permutations of each word, and even brute force all characters in a set using various flags. Different people have different routines for running it, but my general work flow is to kick it off on one machine with a dictionary of common words, and on another machine with a brute force crack, and just let it hum. I don’t have an elaborate rig, and I’ve never tried to crack a password I wasn’t asked to crack for work purposes (outside of my own lab/gear, of course.) It can take a while to crack some passwords, but if you have the time and / or horse power, you can crack most password hash schemes. It can handle simple hashes such as what you might generate with OpenSSL, as well as Windows hashes such as NTLM.

Oddly enough, during my SANS Sec504 class, the one hash scheme I had trouble with was md5. I used another tool (Cain/Abel) on a Windows machine to crack that while john sat and choked on it. I think it was because of the version of john that was provided with the class materials.

Just a reminder that John is used for brute forcing / dictionary attacking an already retrieved set of password hashes. Other tools are often used to brute force passwords as actual login attempts to a machine. This is a better tool if you can get the hashes, because it doesn’t actually attempt to log into anything, and thus doesn’t lock out any accounts due to too many failures, or leave a bunch of failed login attempts in a log file somewhere.

And after all of that, I’m not showing any examples for this command for today’s post. I think I will definitely do a follow up article for that, instead.

Until next time, go hug a family member. Or a friend. Your imaginary one, if noone else will do.

Hacker-Tool Hump-Day – netcat

I was planning to do a continuation of the LAN Turtle exploration and experimentation today, but I’ve had several delays on getting my posts written. Friday’s post will explain a bit more on that. To keep things somewhat short and sweet, I decided to cover one of the Swiss Army knife tools in a hacker and/or a sysadmin’s pocket: netcat.

There are several versions of this program available, and they all have varying degrees of functionality, but for the most part you can expect that it will allow for at least a “one connection” listening socket function, and at least a “one connection” talking sending socket function. In other words, you can open a listening socket to receive one stream of information, or to send one stream of information. Usually this is terminated by an EOF (end of file) character. Some versions will keep the listening socket (when acting as a server) open. Some versions need to be placed inside a while loop to re-open that listening socket for persistence. Some versions allow for binding the output to a specific command, while others require some effort of juggling file descriptors to achieve the same kind of goal. Whatever version you have, it’s a handy tool for both troubleshooting, and swift involuntary copying of data (exfiltration.)

The command may be called “netcat,” “ncat,” or “nc,” depending on the version. To my knowledge, all versions have a “-l” flag for listening as a service, so the easiest example is to create a listening service on a port on one host, and then connect to that port from another host to send some information.
On host 1 (host1):
netcat -l 1234
On host 2 (host2):
cat somefile.txt | nc host1 1234

This will send the contents of “somefile.txt” to the standard out of the listening service on host1. You can redirect the output on that listening service to a file, if you like. Once the EOF is reached, the listening service will terminate.

If you have a version that has the “-k” flag, you can use this flag to keep the service open to receive more data even when the “client” has finished sending and terminates its connection.

netcat -k -l 1234

If you want to send or receive UDP packets instead of TCP, you can use the “-u” flag.

If you want to bind it to a process (usually a shell) and the flag is available, you would use “-e” for this.

netcat -k -l -e /bin/bash 1234

You won’t get a full login session doing it this way, so no prompt or any other indicators that you have a shell once you connect. You’ll have to learn to get used to this, but it’s not bad.

When the -e flag isn’t available, you can do something similar using redirects and a FIFO (also known as a named pipe.)

mkfifo /tmp/namedpipe
nc -k -l 1234 0/tmp/namedpipe

I will most likely go more in depth on this command later (especially when I get to the netcat module in the LAN Turtle,) but for now, this covers most of the basics a person might want.

I will also cover netcat’s beefier brother “socat” at some point down the road.

If you enjoyed this, leave a comment or hit me up on Twitter @stefanrjohnson

Hacker-Tool Hump-Day – Hak5 LAN Turtle Part 1

I’m going to spend a few days covering the Hak5 LAN Turtle. I may or may not break these up with some other Hacker-Tool Hump-Day topics, but for today, we’re just going to cover the initial set up of a brand new Turtle.

The first time you plug it into a USB port, you’ll need to wait a moment for it to initialize and present an IP to the host machine. Once an IP has been obtained (in the 172.16.84.x range,) bring up your favorite SSH client (such as PuTTY) and connect to 172.16.84.1 as root. The initial default password is “sh3llz” and the first time you log in you should see a screen prompting you to set a new root password.

Enter the password of your choosing. It will prompt you to repeat the password. Do so, and it will either say it didn’t succeed and start the prompt sequence over, or it will say the password was changed successfully. Hit enter to select “Okay” and move on.

The first thing you should do after setting that initial root password is to check for updates and update the device. It’s a good idea to check for updates regularly, even if they aren’t released often. Select “Config” and hit enter. At the new menu, you can see that you can change the password you just set, change the WAN or the LAN MAC addresses, disable the Turtle Shell, and Check for updates. Use the arrow keys to move down to “Check for updates,” and hit enter. If you don’t have the ethernet side plugged into a switch that has internet access, this will fail. Don’t forget to plug that cable in.

If an update is available, it will download and verify the update files, update the LAN Turtle with a warning that it could take about 5 minutes, and a note that the Turtle will reboot after updates. It will then kick you out of the SSH session. Just wait for it to update, and keep an eye on the yellow flashy light.

Once it’s been updated, you can restart your session. The HOST keys will have changed, so you should get a warning about that if you aren’t suppressing those, and after you accept the new keys, you will need to login with the default sh3llz again. It will prompt you to change that password (again) so do so at this time. If you go back through the “Config” and “Check” menus again, you should see that there are now no new updates at this time.

I don’t recommend Disabling the turtle shell unless and until you have things set up the way you want, but if you do, you can always get back to the turtle menu by calling “turtle” from the command line.

The next step is to back out to the main menu and pick your modules through the “Module configuration” menu option. The first time you go into this menu, the only option you can select is the “Module Manager.” Select this and choose “Configure.” The next menu should let you choose which modules you’d like to install (“Directory”) or which ones to delete (“Delete”) as well as updating all installed modules via “Update.” Just like the initial update of the Turtle itself, these actions require an internet capable connection to be plugged into the Ethernet side of the Turtle.

We will go over each of the modules over time, but for now you know where this is at and you can select any you would like to play with. The “Cron” module is not necessary for the “at” command, as that appears to be installed already by default.

After you’ve selected all of the modules you want (and you can select all of them… at the time of this writing, they all fit with some space to spare…) install them and then back out of the menu to the Main menu again. Now select “Exit” to drop to the command line.

The Module Manager from the Turtle menu shell is good for pre-packaged installation and configuration of stuff, but you can also install packages that may not be part of a module from the command line. The LAN Turtle is a MIPS based OpenWRT build, and thus any packages compiled for that platform -should- work for the Turtle, assuming the binary fits in the limited file system space provided. The device appears to have 40 megs total, 30 of which are assigned to /tmp as a tmpfs file system. This means 30 megs are volatile. This still shouldn’t be a problem if you select your packages carefully.

The package type for OpenWRT devices is a “.ipk” file, and you manage the packages from the command line using the “opkg” command. The “opkg list” command claims to list available packages, but seems to list installed ones instead. The “opkg list-installed” is supposed to list installed packages, but returns nothing. To fix this, you need to run an initial “opkg update” first, which will grab the repository lists and update the local opkg database with the installed information. The “opkg search” command works as advertised with or without that initial update, so you can find out what command belongs to what package. For example, “opkg search ‘*ps'” returns “busybox – ” which means ps is part of the busybox package. If you’re a fan of multiplexers, there is a package for both “screen” and “tmux.” The “tmux” binary is slightly smaller than the “screen” one and is actually my preferred multiplexer. Alas, there was no package for “dsh.” I may choose to attempt a build of this down the road, because this is an incredibly useful tool. If I do this, I’ll document the process here as well as document turning it into an official Turtle module that could be selected from the Module Manager in the Turtle menu shell.

From a Systems Administration perspective, this device does a few things. It provides a handy USB ethernet adapter if all modules are turned off. It also provides a slimmed down linux environment reminiscent of a Raspberry Pi, BeagleBone Black, or similar, with a smaller form factor, but at the cost of losing some computing power. This is good for providing a quick environment where a VM would be overkill and you’re stuck with a Windows machine as your workstation. Just be aware that your Corporate Security team may take exception to you using such a device, even if no hostile modules are installed. Make sure you are transparent and work things out with them before plugging a “rogue” device into the network in a corporate environment.

Some of the more useful SysAdmin related tools in the Module Manager are “autossh,” “sshfs,” “clomac (if the network is locked down by MAC,)” and “cron” for obvious reasons. I’ll cover each module available over time, and explain the “Configure,” “Start/Stop,” and “Enable/Disable” menu options for each in their own articles. This way each gets the right amount of focus.

Thanks for reading, and if you like this kind of thing, check out the forums at Hak5 to see the latest discussion.

Hacker-Tool Hump-Day – nping

Last week, we looked at a physical device that is usually used in pentests for social engineering (by dropping it in hopes than a curious random person will pick it up, plug it in, and deliver the unexpected payload.) I also showed how it could be used “for good” by a SysAdmin for normal, every day tasks.

This week, we’re going to look at a purely software tool; nping. The nping program is provided by the good folks at the http://nmap.org/ and http://sectools.org/ websites. It is provided by the nmap package, and is often overlooked by the SysAdmin community. Most companies restrict the use of nmap to the corporate security teams, and exclude use of the tool from the daily Unix SysAdmin teams. This is understandable, but if you’re in that situation, you might still find “nping” useful, and your corporate security team might be more willing to sign off on its use for troubleshooting network issues.

Many people make the mistake of thinking that ICMP Pings are great for testing latency. The truth is, they often give a false sense of how much latency exists between one system and another talking TCP for their connections. Many routers and firewalls have QoS settings that can add artificial latency based on protocol, and where ICMP might be blazing fast, TCP might be slow as dirt, and leave you scratching your head as to why. If you use a tool like nping to test your latency instead, you get a truer view of the latency involved.

How does this work?

The nping command will make a handshake request to a given port at a given IP/DNS name a given number of attempts, and then show statistics about the latency from there. There are options that let you change what kind of flags get sent for the handshake, just like with nmap, so you may have to write a wrapper script to get approval from your corporate security team, but as long as you always use the “tcp connect” option, it should do a full blown standard TCP handshake, which would prevent it from setting off any IDS/IPS alarms they may be concerned with.

nping -c 1 –tcp-connect -p 80 server_b.example.com

In the above example, we’re telling nping to make a tcp connect handshake (–tcp) to port 80 (-p 80) at server_b.example.com. We want it to stop after 1 attemp (-c 1.) This will print the time to send the packet, receive the response packet, and the max, min, and average round trip time of all packets:
SENT (0.0031s) Starting TCP Handshake > server_b.example.com:22 (127.0.0.1:22)
RECV (0.0032s) Handshake with server_b.example.com:22 (127.0.0.1:22) completed

Max rtt: 0.053ms | Min rtt: 0.053s | Avg rtt: 0.053s

Since we sent only one handshake attempt, all three “rtt” values will be the same. If we allowed more than one to be sent, we’d see different numbers there.

After the “rtt” values, it tells you how may TCP connection attempts were made, how many were successful, and how many failed.
TCP connection attempts: 1 | Successful connections: 1 | Failed: 0 (0.00%)

I usually like to send 4 to 10 packets and then check the average RTT when troubleshooting latency. Do that in a loop over several minutes (4 to 10 per iteration of the loop) and you start to see how the network is behaving over time. It’s a good tool for every SysAdmin toolbox, so don’t overlook it.

I know that there are some other tools that do similar things, such as Hping2 and Hping3, but nping is pretty straight forward.

If you have tools you’d like to see covered, leave a comment!

Hacker-Tool Hump-Day – USB Rubber Ducky

Every Wednesday (Hump Day) I intend to cover some topic related to hacking, penetration testing, making things do things they maybe weren’t meant to do in general, and so on. Eventually, Mondays will be more like what I envision “Blue Team” mindset should be, and Wednesdays will be more on what I envision “Red Team” mindset should look like. Since I’ve never had the opportunity to be on either kind of team at the place I’ve worked, I won’t say “this is how it is.” So if I use “Red Team/Blue Team” labels, understand this is from my perspective of how I understand them to be, from the outside looking in. I’ve mostly been in a Blue Team type of position (systems administration) but I’ve always tried to look at how to make things work in ways they maybe weren’t meant to work. This has helped me to be sure the stuff I run is run more securely. Any time I come up with a way to bypass, break, or otherwise torture a configuration, I look for ways to plug that hole.

Anyway, on to today’s topic. I’m a fan of Hak5 and the tools they create. Some people take a negative attitude toward them, but I think they’ve helped create some really nice tools for not only aggressive mentalities, but also for defensive ones.

Recently they held a sale in their Hak5 shop in celebration of one of their tools being shown on the show Mr. Robot. The tool in question is the USB Rubber Ducky. I bought one of these last year, and it has been useful from a SysAdmin perspective, so I thought I’d present it as my first topic. I bought one of their zippered kits during the sale, and it should be here by the time the next one of these posts goes live, so I might be covering other items from the kit at that point. I haven’t decided yet. The Ducky is available at the Hak5 shop, at this link:

USB Rubber Ducky Deluxe

So… the USB Rubber Ducky is a device that by default with stock firmware provided by the good folks at Hak5 simply emulates a USB keyboard device when you plug it in. It comes in a case with a swivel key chain piece, and you can take this apart to get to the Ducky internals. You need to do this, to do anything useful with it. The reason is simply this: the device has a microSD card that it reads a payload file from for the purposes of knowing what to “type.” The stock payload isn’t useful for anything more than amusement. You will need to be able to access this microSD card inside to put a useful payload on it. The default firmware doesn’t present a USB storage device for accessing the card, so you will have to take it apart to get that card out.

Take the swivel off, then use a large paperclip or a jewelers/glasses screwdriver to pop the two plastic pieces of the casing apart. There is a hole in the back opposite the USB connector. Just stick it in, give it a light twist, and it should come apart. The microSD card is sometimes stuck pretty good, so you may want a tool to catch the lip of the drive to get leverage for popping it out. It’s not glued in, I promise. The one that came with my first Ducky was 128 meg, so it’s not really useful for much more than keeping a payload on. The Ducky also came with a very small microSD card reader so that you can move your card to it and not have to buy a reader separately to get your payload onto the device. It’s formatted as vFAT, but I’m not sure if it can read the payload from an NTFS formatted card. I intend to test this.

There are alternative firmwares available. The only other one(s) I’ve tried are the Composite ones available as of the time of this writing, and upon initial testing, both seemed to behave identically as far as I could tell. The Composite firmware(s) present the Ducky as both a HID (keyboard) and a USB storage device. There used to be a version that would automatically launch the payload after a set amount of time, but the ones I tested seemed to have that functionality stripped. The version that has “4Cap” in the name lets you hit Caps Lock four times in a row to trigger the payload launch.

I tried the Composite firmware that had “Cap” in the name, expecting the payload to launch. I was disappointed. The only method that worked was actually pushing the button on the Ducky device itself to launch the payload.

I hopped onto the forums to ask about this, and after a few responses from forum members “winter_soldier” and “bored369” I was able to determine that the 4Cap hex file does indeed work as expected… on a Windows workstation. Another hearty “thanks” to winter_soldier and bored369 for the helpful responses on the forums. All of my testing had been done from Linux Mint, and only a press of the button on the Ducky would send the payload, there. I’ll research what the differences are to see if there’s a reason for this difference in behavior. The Mint laptop is a Lenovo ThinkPad W520, and the Windows laptop is a Lenovo Z50. I also noticed that if I do the caps lock key sequence to trigger this on Windows, it works the first time, but then starts flashing red on a second attempt without pulling it and plugging it back in. I can send the payload multiple times from one plug in if I use the button on the Ducky, instead. The button on the Ducky stops working if you use caps sequence to send the payload and it causes the flashing red light. I suspect this may be an error in the logic loop for handling the two different cases. Maybe the source is available for review. I’ll go looking to see if I can find it.

I also intend to try a case mod by drilling two holes into one side of the case. If I put a rod down in the hole to press the button, I won’t need to take the case apart, and if I use a small snip of strand from a novelty toy like the “glowing Christmas trees” you sometimes see on sale during the holidays, I can have a fiber to run down to the indicator light so I can see if it’s working (green) or if something went wrong (red) also without taking it apart.

So besides the actual USB Rubber Ducky, you also need to have a workstation to compile your payloads on, and update the firmware if needed. There are lots of examples of this on the Forums for Windows workstations, but I do my work from a Linux Mint workstation. I grabbed the encoder.jar from:
https://github.com/hak5darren/USB-Rubber-Ducky/tree/master/Encoder

This encoder lets you specify a keyboard layout along with the Ducky Script file. Speaking of the Ducky Script file, you need to write your payload in Ducky Script, then use the encoder to compile it into a binary file that the Ducky reads upon start up. The specific file name should be “inject.bin” for the Ducky to read it. The version of java used to call the encoder should be 7 or higher.

An example test Ducky Script might look like this:

DELAY 1000
STRING #this is a test of my first payload
ENTER

The “DELAY” is in milliseconds, so 1000 is “1 second.” You want a delay of 3 seconds or more with the stock firmware, most likely. Since I already had my Composite firmware in place, and it doesn’t launch until I push the button on the Ducky, I lowered my DELAY.

The “STRING” is the actual typed text that will get sent by the Ducky upon payload execution. Since the return key is a special key, the ENTER directive is needed to emulate that keypress. There are other meta keys that can be emulated. Review the documentation for what all are available, and visit the Forums if you’re having trouble with any of them. I seem to recall seeing a reported known bug about GUI vs. WINDOWS there a while back.

To encode a Ducky Script named “test.ducky” run the following:

java -jar encoder.jar -i ./test.duck -o inject.bin -l us

After you have your payload, copy it to the microSD card, slap the card back into the Ducky, and the next time you plug it in, it should type whatever you told it to type in your script.

If you are bold enough to try out one of the alternative firmwares, visit the Wiki page below for instructions. I used the dfu-programmer software provided as a link from that site from my Mint workstation, and my instructions for getting it compiled will follow.
https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Flashing-ducky

I had to install two development libraries first, since configure complained about them being missing:
sudo apt-get install libusb-dev libusb-1.0.0-dev

I still had problems compiling after this, so a little digging around on the internet using the might of my Google-FU, I came across instructions for “fixing” some broken code.

After installing the missing libraries, unpack the tarball:
tar xvfz ./dfu-programmer-0.5.4.tar.gz
cd dfu-programmer-0.5.4

Modify the configure.ac file to change all references of “LDFLAGS” to “LIBS” instead:
sed -i.bak -e ‘s/LDFLAGS/LIBS/g’ ./configure.ac

Run configure:
./configure

Before running make, modify the Makefile in the src directory to move the -lusb flags from LDFLAGS down to LIBS instead. If this sed statement is confusing, ask in the comments and I’ll explain all the pieces, but today’s topic is the Ducky, not “sed.”

sed -i.bak -ne ‘/^LDFLAGS =/{h;s/LDFLAGS = \(.*\)/LIBS = \1/;x;s/LDFLAGS =.*/LDFLAGS =/};/^LIBS = .*/{x;};p’

Now that you’ve “fixed” the problem children, run “make” per normal, and you should have a file “dfu-programmer” in your src directory.

You can grab one of the .hex firmware files from the github wiki links above, and use the following steps to update it.

Take the Ducky out of its case if you haven’t already (or if you haven’t modified the case as I described earlier.)
In order to put the Ducky into “DFU” mode, hold the button down, then insert it into the USB port. If you aren’t holding it down while you insert it, it’ll be in payload mode and will try to type the payload script. Wait a few moments for the Ducky to be recognized by the system, then use the dfu-programmer software to update the firmware as below:

This step isn’t necessary, but the wiki mentions it, so if you want to make a backup of the existing firmware, do this:
sudo ./dfu-programmer at32uc3b1256 dump >dump.bin

Before flashing a new firmware hex file to the Ducky, you need to erase it:
sudo ./dfu-programmer at32uc3b1256 erase

To drop your new firmware in place, use the “flash” command as shown below. I tried both versions of the Composite firmware, so both of these are shown, but you only run it against ONE .hex file. Pick your firmware and flash only that.
sudo ./dfu-programmer at32uc3b1256 flash –suppress-bootloader-mem Composite_Duck_S003.hex
sudo ./dfu-programmer at32uc3b1256 flash –suppress-bootloader-mem Composite_Duck_4cap.hex

Finally, you have to remember to reset the Ducky after a firmware update in order to make it run payloads again.
sudo ./dfu-programmer at32uc3b1256 reset

That’s it. After the firmware is updated, you should be able to remove the Ducky and reinsert it to test functionality. Remember that if you used a firmware like the Composite versions above that requires a push of the Ducky button, you won’t see the payload until you push the button. I recommend using a test payload that doesn’t press a bunch of meta keys, first. Open a text editor, then insert the Ducky. Press the button if needed, but watch that the payload actually gets sent to the text document to verify it is functioning properly.

Hak5 touts this as a device for social engineering by virtue of curiosity. Put your malicious payload on the Ducky, then drop it in a parking lot and wait. Your payload might call up a bunch of commands to offload a Windows password dump to a remote web server, for example. So how does this tool have any kind of legitimate use in a SysAdmin tool kit?

The answer is simple. There are two scenarios where I have personally already found this tool useful from an everyday SysAdmin perspective. The first is when dealing with a console session to a remote server, and the console does not allow copy/paste. When you are dealing with a blind console that doesn’t allow pasting commands into the terminal, you have to be meticulous in your typing. If you know all of the steps you need to get the task accomplished, you can carefully craft that out into a Ducky Script, compile it, and then make that console your focused window before plugging the Ducky in for your “I’m pasting my commands anyway, so take that!” workload.

The other scenario has to do with a long ssh private key passphrase that needed to be stored into an IAM solution, and people were present who should not see this passphrase. Instead of having to start over multiple times, because the laws of nature demand that I mistype the phrase at least four times before getting it right, I was able to put the passphrase into a Ducky Script, take the Ducky to the conference room where the IAM software was being configured, set the focus on the passphrase field in the software, then plug the Ducky in. Or at least, I would have if I’d had the Ducky with me that day. Instead I had to type it out. Multiple times. Because things. Since that was the “development” environment, I’ll be doing the “production” environment with the Ducky next time.

Thanks for reading this, and if you have any ideas on other legitimate uses of the USB Rubber Ducky as an every day SysAdmin tool, share in the comments!