HTTP Beacon and HTTPS Beacon
The HTTP and HTTPS beacons download tasks with an HTTP GET request. These beacons send data back with an HTTP POST request. This is the default. You have incredible control over the behavior and indicators in this payload via Malleable C2.
HTTP(S) Listener Setup
To create a HTTP or HTTPS Beacon listener select Cobalt Strike -> Listeners on the main menu and press the Add button at the bottom of the Listeners tab display.
The New Listener panel displays.
figure 28 - HTTP Beacon Options
Select Beacon HTTP or Beacon HTTPS as the Payload type and give the listener a Name. Make sure to give the new listener a memorable name as this name is how you will refer to this listener through Cobalt Strike’s commands and workflows.
HTTP(S) Hosts - Press [+] to add one or more hosts for the HTTP Beacon to call home to. Press [-] to remove one or more hosts. Press [X] to clear the current hosts. If you have multiple hosts, you can still paste a comma-separated list of callback hosts into this dialog.
The length of the beacon host list in beacon payload is limited to 255 characters. This includes a randomly assigned URI for each host and delimiters between each item in the list. If the length is exceeded, hosts will be dropped from the end of the list until it fits in the space. There will be messages in the team server log for dropped hosts.
After a beacon is started, you can add/remove/update hosts with the "beacon_config host ..." console command or bbeacon_config aggressor script function.
Host Rotation Strategy - This value configures the beacons behavior for choosing which host(s) from the list to use for egress. Select one of the following:
To counter hosts that are failing to connect, hosts that fail will be held by the beacon until all other hosts have failed then they will all be released and used again.
random: Select to randomly select a host name from the list each time a connection is attempted.
To counter hosts that are failing to connect, hosts that fail will be held by the beacon until all other hosts have failed then they will all be released and used again.
failover-xx: Select to use a working host as long as possible. Use each host in the list until they reach a consecutive failover count (x) or duration time period (m,h,d), then use the next host.
rotate-xx: Select to use each host for a period of time. Use each host in the list for the specified duration (m,h,d), then use the next host.
Max Retry Stategy - This configures the beacons behavior for exiting after a number of consecutive failed connection attempts to the Team Server. There are several default options to choose from or you can create your own list with the LISTENER_MAX_RETRY_STRATEGIES hook. See LISTENER_MAX_RETRY_STRATEGIES.
none: Select to ensure beacon will not exit because of failed connection attempts.
exit-xxx: These settings use the syntax of exit-[max_attempts]-[increase_attempts]-[duration][m,h,d]. The max_attempt value is the number of consecutive failed attempts before beacon will exit. The increase_attempts is the number of consecutive failed attempts before increasing the sleep time. The duration value is the number of minutes, hours, or days to set the new sleep time.
The sleep time will not be updated if the current sleep time is greater than the newly specified duration value. The sleep time will be affected by the current jitter value. On any successful connection the failed attempts count will be reset to zero and the sleep time will be reset to the prior value.
HTTP Host (Stager) - This controls the host of the HTTP Stager for the HTTP Beacon. This value is only used if you pair this payload with an attack that requires an explicit stager.
Profile - This is where you select a Malleable C2 profile variant. A variant is a way of specifying multiple profile variations in one file. With variants, each HTTP or HTTPS listener you setup can have different network indicators.
HTTP Port (C2) - This field sets the port your HTTP Beacon will phone home to.
HTTP Port (Bind) - This field specifies the port your HTTP Beacon payload web server will bind to. These options are useful if you want to setup port bending redirectors (e.g., a redirector that accepts connections on port 80 or 443 but routes the connection to your team server on another port).
HTTP Host Header -This value, if specified, is propagated to your HTTP stagers and through your HTTP communication. This option makes it easier to take advantage of domain fronting with Cobalt Strike.
HTTP Proxy - Press the … button to specify an explicit proxy configuration for this payload.
Guardrails - Beacon Guardrails allows the user to create a way to restrict the targets that the beacon can execute on. Once configured, these values will be the default guardrail for the Stageless or Windows Stageless Payload Generators.
Press the ... button to open the Guardrails Settings:
figure 29 - Guardrail Settings
IP Address: Enter a specific IP Address or generic wildcard of the right most segments. For example:
- 123.123.123.123
- 123.123.123.*
- 123.123.*.*
- 123.*.*.*
User Name: Enter a specific name, or a value that:
- "starts with" supported by "*" wildcard character on the right side
-
"ends with" supported by "*" wildcard character on the left side
The guard is case-insensitive.
Server Name: Enter a specific computer name, or a value that:
- "starts with" supported by "*" wildcard character on the right side
-
"ends with" supported by "*" wildcard character on the left side
The guard is case-insensitive
Domain: Enter a specific domain, or a value that:
- "starts with" supported by "*" wildcard character on the right side
-
"ends with" supported by "*" wildcard character on the left side
The guard is case-insensitive
Manual HTTP Proxy Configuration
The (Manual) Proxy Settings dialog offers several options to control the proxy configuration for Beacon’s HTTP and HTTPS requests. The default behavior of Beacon is to use the Internet Explorer proxy configuration for the current process/user context.
figure 30 - Manual Proxy Settings
The Type field configures the type of proxy. The Host and Port fields tell Beacon where the proxy lives. The Username and Password fields are optional. These fields specify the credentials Beacon uses to authenticate to the proxy.
Check the Ignore proxy settings; use direct connection box to force Beacon to attempt its HTTP and HTTPS requests without going through a proxy.
Press Set to update the Beacon dialog with the desired proxy settings. Press Reset to set the proxy configuration back to the default behavior.
The manual proxy configuration affects the HTTP and HTTPS Beacon payload stages only. It does not propagate to the payload stagers.
Redirectors
A redirector is a system that sits between your target’s network and your team server. Any connections that come to the redirector are forwarded to your team server to process. A redirector is a way to provide multiple hosts for your Beacon payloads to call home to. A redirector also aids operational security as it makes it harder to trace the true location of your team server.
Cobalt Strike’s listener management features support the use of redirectors. Simply specify your redirector hosts when you setup an HTTP or HTTPS Beacon listener. Cobalt Strike does not validate this information. If the host you provide is not affiliated with the current host, Cobalt Strike assumes it’s a redirector. One simple way to turn a server into a redirector is to use socat.
Here’s the socat syntax to forward all connections on port 80 to the team server at 192.168.12.100 on port 80:
socat TCP4-LISTEN:80,fork TCP4:192.168.12.100:80
Beacon Runtime Configuration
In Cobalt Strike 4.10, round robin and random rotation strategies will temporarily stop using hosts that have failed until all listed hosts have failed connections, then all hosts will be re-enabled again. This should help stabilize beacons hosts that cannot connect. Some additional tools have been provided reconfigure beacon settings of a running beacon.
From the beacon console (and with similar aggressor script commands), you can get runtime information about beacon callback host connections that failover and change some of the attributes of a running beacon.
You can configure beacons to return host failover information when a connection can be re-established with "beacon_config failover_notification ....".
-
To see the current status of the option (disabled by default):
beacon_config failover_notification
-
To enable the option:
beacon_config failover_notification true
-
To disable the option:
beacon_config failover_notification false
You can view and update beacon configuration attributes with "beacon_config host ..."
-
To get information about the current beacon hosts:
beacon_config host info
- To add additional hosts to the beacon host list:
- Maximum of 32 hosts allowed
The uri must be known by the Team Server.
beacon_config host add [host] [uri]
-
To change a host and/or the hosts assigned uri:
beacon_config host update [from-host] [to-host]
beacon_config host update [from-host] [to-host] [to-uri]
-
To remove a host from the beacon host list:
beacon_config host remove [host]
-
To see the Host Profiles that the beacon has been pre-configured with:
beacon_config host profiles
NOTE:Host Profiles are only initially configured. They cannot be added/updated/removed in running beacons.
-
To hold a host from being used (random and round-robin only):
beacon_config host hold [host]
NOTE:All held hosts are automatically released when all hosts have been held.
-
To release a held host (random and round-robin only):
beacon_config host release [host]
-
To reset the held status (release) and/or statistics shown with the "info" command for all hosts or a named host:
beacon_config host reset
[all|status|statistics]beacon_config host reset
[all|status|statistics] [host]
For additional information see the beacon command help for beacon_config host.
See the corresponding aggressor function bbeacon_config for automation of this.