Contributing Best Practices
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 adhere to the following best practices and style guide when submitting a payload.
Naming Conventions
Please give your payload a unique and descriptive name. Do not use spaces in payload 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.
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.
Comments
Payloads should begin with comments specifying at the very least the name of the payload and author. Additional information such as a brief description, the target, any dependencies / prerequisites and the LED status used is helpful.
Configuration Options
Configurable options should be specified in variables at the top of the payload.txt file
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.
Stages and States
Stages should be documented with comments
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.
Last updated