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:
host
- This indicateswhere
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 usedtemplate
- This indicates the template for creating the new payload. This is selected from a list of currently generated payloads (that were created via theCreate 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:List of c2 profiles for the new agent
Configurations of those profiles (if any parameters are listed as
randomized
, they will be re-randomized in the new payload)Payload Type selection
Configuration of that payload type (such as
create_transforms
and those optionsSelected 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.
Last updated