Spawning Agents

Use Case

Throughout operations, many operators will need to spawn new callbacks or generate new payloads for things like lateral movement, process injection, or persistence. To accomplish this, Apfell needs to know a few things ahead of time about the commands being used.

Command Configuration

In the Payload Management section, a command needs to have the Generates additional payloads flag set to true. This tells apfell that when new tasking comes in with this command, there will need to be additional processing to generate a new payload.

Required Command Parameters

There are two required parameters for a command that spawns new agents. There can be additional information and parameters specific to the command, but at a minimum, the following two are required:

1. host - This indicates where this new payload will go. If this parameter is empty or not present, then the host of the callback where this task is issued will be used

2. template - This indicates the template for creating the new payload. This is selected from a list of currently generated payloads (that were created via the Create Components menu). If this value is empty or not present, then the payload associated with the callback where the task is issued will be used. Specifically, this template is necessary because it includes the following information:

   1. List of c2 profiles for the new agent

   2. Configurations of those profiles (if any parameters are listed as randomized, they will be re-randomized in the new payload)

   3. Payload Type selection

   4. Configuration of that payload type (such as create_transforms and those options

   5. Selected commands in the payload

The template parameter must be of type Payload List (as compared to type String or Boolean) so that when an operator types their command without parameters and hits enter, the popup dialog box can know to populate that field with a list of template options (i.e. previously generated payloads).

Benefits from auto-generating payloads

One of the benefits from generating payloads this way is that Apfell can track which callbacks generated which payloads and thus caused which new callbacks. This is slightly different information than a connection callback graph (the flow of messages and connections between callbacks) because it allows operators to know why they just got a new callback (i.e. Bob issued task 5 on callback 3 that generated a the payload that spawned callbacks 4, 5, 6, 7, 8).

Additional Metadata storage

The reason the host and template fields are important is because they're used similar to tracking staging information for new callbacks. If Apfell tracks that there's a new payload that's potentially executing (or not) on this new host, it can provide that information back to an operator when they're trying to remotely connect to it (such as with a bind peer-to-peer connection).

This allows Apfell to track potential new callbacks before there has been any connection and staging to actually establish a new callback in the user interface. This also comes in handy for certain peer-to-peer protocols where you need to know specific information about the remote payload that's executing (such as a TCP port or Named Pipe) before you have an actual callback to query.