Skip to content

Basics of payloads

Commencing with version 0.2, the architecture for generating payloads has been enhanced to adopt a plugin-based approach. This development significantly simplifies the incorporation of new payload types. Furthermore, the revamped payload generation system now supports the inclusion of supplementary configuration parameters during the creation of payloads. This enhancement broadens the scope of customization available to users, offering them expanded versatility in payload creation. Accompanying these improvements are modifications to the fundamental logic governing payload requests.

Previously, the procedure for requesting payloads involved sending a GET request to the server, specifying both the desired payload type and the identifier (ID) of the listener designated for payload communication. The updated process, however, entails the following steps:

  1. Payload creation is initiated through a POST request. This request must include the payload template ID, the listener's ID with which the payload is intended to communicate, and any additional configuration settings. In response, the server provides the ID of the payload that has been requested.
  2. Subsequently, this payload ID can be utilized to retrieve the generated payload via a GET request.

These changes are designed to streamline the payload management process, offering a more structured and flexible approach to payload generation and retrieval.

Custom payload templates

Payload template directories are configured per payload plugin with the custom-payload-template-dir plugin setting. If an override for a built-in template is not present, the plugin falls back to its bundled template. In the default Windows plugin, place a file with the same name as a bundled template in the configured directory to override that template. Relative file: directories are resolved from the server process's working directory.

The commercial Windows, Linux, BSD, and macOS payload configurations also accept a customTemplate value. Use either a filename or relative path beneath that plugin's configured template directory, or a direct http: or https: URL. A local customTemplate cannot be used until custom-payload-template-dir is configured for the corresponding plugin; other remote URI schemes are not supported. See the server configuration example.