Cobalt Strike's Beacon Payload
Most commonly, you will configure listeners for Cobalt Strike’s Beacon payload. Beacon is Cobalt Strike’s payload to model advanced attackers. Use Beacon to egress a network over HTTP, HTTPS, or DNS. You may also limit which hosts egress a network by controlling peer- topeer Beacons over Windows named pipes and TCP sockets.
Beacon is flexible and supports asynchronous and interactive communication. Asynchronous communication is low and slow. Beacon will phone home, download its tasks, and go to sleep. Interactive communication happens in real-time.
Beacon’s network indicators are malleable. Redefine Beacon’s communication with Cobalt Strike’s malleable C2 language. This allows you to cloak Beacon activity to look like other malware or blend-in as legitimate traffic.
System Calls
The Beacon payload has implemented the ability to use system calls instead of the standard Windows API functions. Currently Beacon supports a limited set of functions for this capability.
The following functions support the use of system calls:
When you generate a stageless beacon payload from the Cobalt Strike UI or a supported aggressor function, you can choose which system call method will be used at execution time.
System Call Methods:
1) None -> Use the standard Windows API function
2) Direct -> Use the Nt* version of the function
3) Indirect -> Jump to the appropriate instruction within the Nt* version of the function
There are some commands and workflows that inject or spawn a new beacon that do not allow you to set the initial system call method. In these cases, setting the ‘stage.syscall_method’ setting in the profile will allow you to control the initial method used at execution time.
The following commands and workflows use the stage.syscall_method setting:
Use the syscall-method [method] command to modify which method will be used for subsequent commands. In addition, syscall-method without any arguments will query the current method.
Payload Security Features
Cobalt Strike takes steps to protect Beacons communication and to ensure that a Beacon can only receive tasks from and send output to its team server.
When you setup the Beacon payload for the first time, Cobalt Strike will generate a public/private key pair that is unique to your team server. The team server’s public key is embedded into Beacon’s payload stage. Beacon uses the team server’s public key to encrypt session metadata that it sends to the team server.
Beacon must always send session metadata before the team server can issue tasks and receive output from the Beacon session. This metadata contains a random session key generated by that Beacon. The team server uses each Beacon’s session key to encrypt tasks and to decrypt output.
Each Beacon implementation and data channel uses this same scheme. You have the same security with the A record data channel in the Hybrid HTTP and DNS Beacon as you do with the HTTPS Beacon.
Be aware that the above applies to Beacon once it is staged. The payload stagers, due to their size, do not have built-in security features.
Last updated