Much has been done in the offensive security space for creating new and interesting payloads. So much so that operators may even be spoiled for choice. But how do you manage the different requirements for these payloads? Payloads use all manner of programming languages, build toolchains, and external resources such that keeping a clean working environment presents a challenge. Docker, and more generally containers, represent a compelling choice for bundling the requirements for a piece of software – or malware – into a single, well, container. This is the basis for the tool we are releasing today, PDCD. PDCD is a command-line tool designed to generate payloads by running single-purpose Docker containers either locally or remotely.
Repo link: https://github.com/SecurityRiskAdvisors/pdcd
At its core, PDCD works similarly to a CI/CD pipeline and it was designed to support two types of use:
- Generate more than a few payloads at once
- Generate a payload(s) that requires a complex build process
Here at Security Risk Advisors, we use PDCD to assist in preparing payloads for use in purple team exercises. In these exercises we run a number of different attack techniques and variations of those attacks, with a fair amount of them requiring specific payloads/utilities.
PDCD takes a YAML document as input that defines which container images to run, their command-line arguments, and which artifacts to extract from the completed jobs. Jobs can be wholly standalone as well as depend on previous jobs. As it is designed primarily for offensive security operators, it also has connectors for command-and-control servers, namely Cobalt Strike and Mythic, that allow for automated shellcode retrieval.
Note: While it can be used for running individual jobs, it would likely be more time efficient for an operator to simply run the job directly with the Docker command-line.
The following example demonstrates how PDCD can be used to download Cobalt Strike shellcode from a teamserver, encode it with SGN, then create a JScript payload from that shellcode using SharpShooter.
Note: This example also assumes both the “sgn” and “sharpshooter” container images exist locally and that both take the standard command-line argument for their respective tools.
file_dirsets the mount path and output directory,
cleanupsets whether to delete job containers, and
workerssets the number of parallel workers (where possible)
- The first payload uses the
sgncontainer image. The command-line follows the standard command-line for SGN with the exception of PDCD-specific functionality, denoted by the
@artifactinstructs the tool that the next token is an artifact and should be pulled from the container when the job completes.
@cobaltstrikeinstructs the tool to pass the next token to the connector named “cobaltstrike” for processing. Finally, the
storekey tells the tool that the artifact path should be stored under the provided key for use by other jobs.
- The second payload uses SharpShooter to create a JScript payload from that newly encoded shellcode.
@filesis used to instruct the tool to replace the token with the value stored under the key “shellcode”. This also creates a dependency on the job that created that stored value. The tool will first run that parent job before any jobs that depend on it.
connectorssection contains configurations for supported connectors. In this example, the configuration is using the Cobalt Strike connector, which triggers the tool to reach out to the specified command-and-control teamserver and retrieve shellcode based on the provided CLI token (Stageless, x64, listener named “HTTPS”).
- For more detailed documentation, refer to the documentation in the repository.
After running the tool, we are provided with our two desired artifacts, the shellcode and the JScript payload:
And we can verify that the payload works by running it on a Windows target using cscript.exe. It should trigger a callback to the command-and-control server:
PDCD also supports running the job containers remotely against a build server. If a system meets the following criteria, it can be used for PDCD jobs:
- Running the Docker daemon, bound to TCP (localhost works)
- Running an SMB server
- Running the AWS SSM agent
Remote job execution works by creating a local port forward to the Docker and SMB ports on the target system using the AWS SSM service. The AWS SSM service bypasses the need for the operator to have a direct connection to the build server since the connection uses the AWS control plane.
From the operator perspective, there is no difference in execution when using the remote mode. The operator only needs to modify their configuration/connectors file to add the “remote” connector settings and configure their AWS credentials.
The primary benefits of a remote build server are:
- All operators using it will share container images, allowing for operational consistency
- Removes the need to have images stored locally, saving space in VMs as well as reducing the requirements when creating a fresh environment
- Updates to images are performed once and for all operators
- Cross-OS builds
Of particular note is the last item. Normally, if you want to use Windows-specific tooling on Linux, you are rather limited. Some tooling allows for cross-platform payload development, such as MingW and Mono. However, if you are interested in functionality like Office COM objects for Office payload creation, you are better off with a Windows system. A remote build server can alleviate this class of issue by providing a remote system of the desired platform.
The PDCD repository can be found here: https://github.com/SecurityRiskAdvisors/pdcd. Refer to the documentation in the repository for more information. For questions/concerns, feel free to open an issue on the repo or reach out to me directly @2xxeformyshirt.
Evan specializes in technical security assessments including network penetration tests, purple teams, red teams, and cloud security. He has experience in a variety of industries including telecommunications, financial services, pharmaceuticals, and healthcare.
Evan maintains the internal SRA standards and methodologies for purple team projects.
Evan is a member of SRA’s internal Research and Innovation team where he works to research novel approaches to security problems as well as develop security tools and resources.