Skip to content

Formats and Compatibility

An ExecUnit's role, binary format, and execution context describe different parts of its compatibility. Use this page to distinguish what an agent supports from the artifacts available for a particular command or listener.

Compatibility has several dimensions

An ExecUnit must match the operating system, processor architecture, execution context, and runtime dependencies of its host. It must also implement the communication role that the agent expects: command and listener ExecUnits have different responsibilities even when their binaries use the same format.

A native command built into an agent is a separate category from a native-library ExecUnit. Similarly, a listener-owned command remains a command ExecUnit; its location within a listener plugin does not change its communication role.

Agent support

The following table describes the current commercial agent implementation. A custom payload needs to define and accurately report its own supported combinations.

Platform Current agent architectures ExecUnit format families Execution contexts
Windows x86, x86_64 Shellcode, .NET executable, .NET dynamic-link library (DLL), native DLL Self supports these families; new-process and existing-process contexts support shellcode
Linux x86_64 Native Executable and Linkable Format (ELF) shared object Self
FreeBSD amd64 Native ELF shared object built for FreeBSD Self
macOS x86_64, arm64 Native Mach-O dynamic library Self

Here, self means the agent's own process. A context describes where code runs; it does not determine whether the code is a command or a listener. The formats used to distribute the agent itself are also separate from the ExecUnit formats it accepts.

Available command and listener artifacts

Agent support is only one part of the decision. The plugin must supply a compatible artifact for its role and platform.

Artifact group Windows Linux and FreeBSD macOS
Default command ExecUnits Managed artifacts and native DLLs where implemented; availability varies by command Native shared objects for the supported command subset Native dynamic libraries for the supported command subset
Simple Hypertext Transfer Protocol (HTTP), Transmission Control Protocol (TCP), and Domain Name System (DNS) listener ExecUnits Managed artifacts and native DLLs Native shared objects Native dynamic libraries
TCP bind and TCP reverse listener ExecUnits Managed artifacts Native shared objects Native dynamic libraries
TCP listener-owned command ExecUnits Managed artifacts Native shared objects Native dynamic libraries
Server Message Block (SMB) listener and its owned command ExecUnit Managed artifacts Unavailable Unavailable

In this table, managed artifacts include .NET executables, .NET DLLs, and shellcode packaged from the managed implementation. Packaging does not make the underlying implementation a native implementation or remove its runtime requirements. The Windows relay listeners and their owned commands currently have no native DLL variants.

Format selection

When dispatching a command, Command and Control (C2) matches the plugin's available ExecUnit types with the agent's capabilities and reported preferences for the chosen execution context. See Agent capability matching for the established selection behavior. The availability and support tables above describe the inputs to that decision; neither table alone determines the selected format.

Binary and dependency compatibility

Linux and FreeBSD both use ELF, but their libraries target different operating-system interfaces and are not interchangeable. macOS uses Mach-O and supplies separate x86_64 and arm64 artifacts. Windows native DLLs likewise have distinct processor architectures; an operating system capable of running both 32-bit and 64-bit applications does not make those libraries interchangeable within a process.

The default Windows managed projects target .NET Framework 4.6.2. Native artifacts can depend on platform libraries and minimum operating-system or runtime versions. Build baselines and dependencies can differ between agents, commands, and listeners, so successful use of one component does not establish compatibility for every other component.

Artifact names identify intended roles and formats, but their suffixes are not a complete compatibility check. Keep the binary's actual target, dependencies, and the selected agent's supported combinations together when assessing a release.