-
Notifications
You must be signed in to change notification settings - Fork 52
Implant Templates
Implant templates are a named configuration which will be used when a particular stager is triggered. Once you have created an implant template F2 will create the relevent stager options in the implant stager page.
If a stager is executed numerous times each time the implant will be regenerated, if the operator has configured the implant template with any level of obfuscation the implant will be unique each time.
Below is a highlight of each of the options, and their impact on the resulting implant:
This is the base name of the implant template. If a stager is triggered the active implant will use this name plus a 6 digit unique string will be appended for identification purposes.
This is the either an IP address or domain name that the implant will attempt to beacon back to using one of the associate network profile (see below).
A simple description visible to operator, normally used to highlight the implant templates purpose, such as the configuration or the target it will be used on.
This is the initial delay prior to the implant starting it's regular beaconing activity, in seconds. It should be noted that this delay will then be followed by the beacon delay set by the operator. I.e.:
500 second initial delay + 500 seconds beacon = ~950-1050 seconds first beacon
The range is the result of a 10% jitter applied to the beacon time.
This is the time in between the implant beaconing back to the operators F2 server. It is important to note that FudgeC2 implants treat beacon differently to normal implants.
FudgeC2 beacons onces to obtain a command, and will then wait for the full beacon time before responding with the command result, unlike other C2 frameworks which responded immediately after command execution. A beacon of 3600 seconds will result in the response to a command taking approximately double that time.
One of FudgeC2s operational goals is to create an implant with varying levels of obfuscation. The logic behind this decision is to help us develop an understanding of SoC/blueteam/defenders knowledge of RE'ing & identifying key functionality of Powershell implants.
Operators can use the active implants page to get a copy of the implant which was delivered to the target. This can then be sent to the defenders if they're looking for a copy of the payload.
This is a wrapper for the final, active payload. The implant is encrypted using AES-256 CBC, the IV and KEY to decrypted and then embedded into the wrapper to decrypt the payload upon execution. Obviously, this is trivially bypassed by anyone who has experience with Powershell and it's decryption routines, however, it raises the technical bar.
This is an operationally important feature which allows operators to kill the implant, stopping it from beaconing back to C2 infrastructure after a specified time and date. This feature uses the compromised system time, as such your implant may kill itself early or later than expected.
The FudgeC2 server comes with network profiles, and any F2 implant can have a number of network profiles installed. Network profiles are unique communication techniques (such as tunneling over DNS/DoH) designed to blend into the target environments traffic (or maybe designed to stick out if you're getting louder to find your detection point).
if an operator creates an implant template with more than one network profile F2 will randomly select which profile to use for each beacon. Below is a simple example of this idea:
pickup: Server <= HTTP:80 <= F2: whoami
cmd response: Server <= HTTPS:443 <= F2: workstation\bob.dole
pickup: Server <= HTTP:80 <= F2: :: sys_info
cmd response: Server <= DNS:53 <= F2: :: sys_info response
pickup: Server <= HTTPS:443 <= F2: :: enable_persistence
cmd response: Server <= DoH:442 <= F2: persistence success
pickup: Server <= HTTP:8080 <= F2: :: load_module powerup.ps1
cmd response: Server <= HTTPS:443 <= F2: module loaded successful