sharkjack-payloads/README.md

17 KiB

Payload Library for the Shark Jack by Hak5

This repository contains payloads and extensions for the Hak5 Shark Jack. 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 Shark Jack. Hak5 does NOT guarantee payload functionality. See Legal and Disclaimers

     


View Featured Shark Jack 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 Shark Jack

Hotplug attack, meet LAN. The Shark Jack is a portable network attack tool optimized for social engineering and opportunistic wired network auditing that makes network reconnaissance, exfiltration and automation quick and easy.

Shark Jack Cable
AT THE READY
Perfect for physical engagements. Keep this opportunistic wired network attack platform at the ready for intel & recon at a moments notice.

Even get live results and instant access to a Linux shell on the LAN with the Cable edition as shown.
Shark Jack Cable
SIMPLE SCRIPTING
The simple scripting language lets you quickly develop payloads using bash and familiar Linux network tools so you can automate any attack.
Shark Jack Battery
LINUX UNDER THE HOOD
Root access with all the fixings and find familiar command line network utilities at the ready.

Just SSH in, or even drop into a shell over USB-C serial with the Cable edition. Widely supported by Android OTG + Windows, Mac & Linux.

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

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... 
        #!/bin/bash
	# CONFIGURATION
	# REQUIRED - Provide URL used for Example
	MY_TARGET_URL="example.com"
	nmap $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
	#!/bin/bash
	# Title: Example Payload
	# Author: Korben Dallas
	# Description: scans target with nmap
	# 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
NMAP_OPTIONS="-sP --host-timeout 30s --max-retries 3"
LOOT_DIR=/root/loot/nmap

LED

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

# Initialization
LED SETUP
mkdir -p $LOOT_DIR
COUNT=$(($(ls -l $LOOT_DIR/*.txt | wc -l)+1))
NETMODE DHCP_CLIENTLED ATTACK
LED ATTACK
nmap $NMAP_OPTIONS $SUBNET -oN $LOOT_DIR/nmap-scan_$COUNT.txt
LED FINISH

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.

Shark Jack 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. Shark Jack 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.