CobaltStrike is a powerful comprehensive framework for penetration testing and deployment of cyber decoys.
1517 
CobaltStrike is a powerful tool that not only allows you to perform penetration testing, but also provides convenient tools for effective data management during the process. With its advanced data management features, CobaltStrike facilitates the collection, analysis and use of information to ensure the highest level of security. One of the key aspects of data management in CobaltStrike is the ability to collect and aggregate information from various sources and sources of data collection. This includes logging activity, intercepting network traffic, recording keystrokes, and other activities that help identify potential threats and vulnerabilities.
In addition, CobaltStrike offers convenient tools for analyzing the collected data. This includes the ability to search, filter and visualize information to help you find key relationships and draw informed conclusions. Such analysis allows you to find weak points in systems, identify potential threats and take the necessary measures to ensure security. In addition, CobaltStrike provides the ability to effectively manage the collected data, including storing it, exporting it in various formats and making it accessible to teams for further analysis and development of protection strategies. This enables the creation of valuable reports and recommendations based on the collected information, helping to improve security and respond to potential threats. Using CobaltStrike to manage data during penetration testing allows cybersecurity experts to collect, analyze, and use information to effectively detect threats and provide robust protection. This functionality makes CobaltStrike an indispensable tool for professionals who seek to increase the level of security of information systems.
Cobalt Strike’s C&C Server is a broker for information collected by Cobalt Strike during your employment. Cobalt Strike analyzes the data received from the Beacon to extract targets, services and credentials. If you want to export Cobalt Strike data, you can do so using Reporting -> Export Data. Cobalt Strike provides the ability to export data to TSV and XML files. Cobalt Strike’s client data export feature aggregates data from all C&C servers you are currently connected to and exports it to TSV and XML files with data from the Cobalt Strike data model.
Goal
You can interact with Cobalt Strike target information using View -> targets. This tab displays the same information as in the graphical display of targets.
Click the Import button to import the target information file. Cobalt Strike accepts flat text files with one host per line. It also accepts XML files generated by Nmap (with the -oX option).
Click Add to add new targets to the Cobalt Strike data model.
This dialog allows you to add multiple hosts to the Cobalt Strike database. Specify a range of IP addresses or use CIDR notation in the Address field to add multiple hosts at once. Hold down Shift and click Save to add the hosts to the data model and leave this dialog open.
Select one or more hosts and right-click on them to open a menu. In this menu, you can change the description of hosts, specify information about their operating system, or delete hosts from the data model.
In the list of targets, right-click the host and select Services. The Cobalt Strike Service Explorer will open. From here, you can view services, annotate them, and delete service entries.
Account data
Go to View -> Credentials to interact with Cobalt Strike’s credential model.
Click the Add button to add a record to the credential model. You can also hold Shift and click Save to keep the window open and make it easier to add new credentials to the model. Click the Copy button to copy the selected entries to the clipboard. Use Export to export credentials in PWDump format.
The Cobalt Strike data model stores state and state metadata in the data/ folder. This folder is located in the folder from which you started the Cobalt Strike C&C server.
To clear the Cobalt Strike data model: Stop the C&C server, delete the data folder/ folder and its contents. Cobalt Strike will re-create the data folder / the next time the C&C server starts.
If you want to back up the data model, stop the C&C server and use your favorite program to save the data/ folder and its files to another location. To restore the data model, stop the C&C server and restore the old contents of the data/ folder. Reporting -> Reset Data resets the Cobalt Strike data model without restarting the C&C server.
The first step in any interaction is to create an infrastructure. In the case of Cobalt Strike, the infrastructure consists of one or more C&C servers, redirectors, and DNS records that point to your C&C servers and redirectors. Once the C&C server is up and running, you’ll want to connect to it and configure it to accept connections from compromised systems. Listeners are the mechanism in Cobalt Strike that allows you to do this.
The listener is both information about the configuration of the payload and an indication to create a Cobalt Strike server to accept connections from this payload. A listener consists of a user-defined name, a payload type, and several options specific to the payload
Management of Listeners
To manage Cobalt Strike Listeners, go to Cobalt Strike -> Listeners.
A tab will open with a list of all configured payloads and Listeners.
Click the Add button to create a new handler. The new Listeners panel will appear
Use the Payload drop-down list to select one of the available payload / payload types to configure.
To edit a Lestener, highlight it and click the Edit button. Removal
Lestener, highlight it and click the Uninstall button.
Most often, you tune listeners to the Cobalt Strike beacon. A beacon is a payload for simulating the actions of attackers. Use it to transfer data over the network via HTTP, HTTPS, or DNS. It is also possible to set a node disconnection limit by managing peer beacons through named Windows pipes and TCP sockets.
Beacon is flexible and supports asynchronous and interactive communication. Asynchronous communication is low and slow (“low and slow” communication scheme). Beacon will contact the C&C server, download its tasks and stop network activity. Interactive communication takes place in real time.
Beacon network indicators are subject to change. Redefine Beacon interaction with Cobalt Strike’s Malleable C2 language. This will allow you to disguise beacon activity to look like other malware or blend in with legitimate traffic.
There is one topic that deserves to be mentioned as a benchmark – this is the staged payload. Many attack frameworks separate the attack itself from what it does. What the attack accomplishes is called the payload. The payload is often divided into two parts: the stage payload and the trainee payload. A stager is typically a small, hand-optimized assembly language program that loads the stage payload, injects it into memory, and passes it on for execution. This process is known as staging.
Staging is required for some attacks. Many attacks have hard limits on the amount of data they can load into memory and execute after successful exploitation. This severely limits the post-op capabilities unless you deliver the post-op payload in stages.
Cobalt Strike uses staging in its user-driven attacks. This is most of the points in the Payload and Attack sections. The stagers used there depend on the payload associated with the attack. For example, an HTTP beacon has an HTTP stager. DNS Beacon has a stage of DNS TXT records. Not all payloads have staging options. A payload without a stander cannot be delivered using these attack options.
If you don’t need the intermediate payload, you can disable it. Set the host_stage parameter in the Malleable C2 profile to false. This will prevent Cobalt Strike from hosting payload stages on its web servers and DNS servers. This is a big advantage for OPSEC. With staging enabled, anyone can connect to your server, request a payload, and analyze its contents to find information in your payload configuration.
In Cobalt Strike 4.0 and later, post-exploitation and lateral movement activities dispense with staging devices and use the full payload where possible. When turning off the installation of the payload, you should not notice it, being ready for post-operation.
DNS Beacon is a favorite feature of Cobalt Strike. This payload uses DNS queries to communicate. These DNS queries are lookups for domains that your C&C server is important to.
The DNS response tells the beacon that it needs to stop or contact you to download jobs. The DNS response also tells Beacon how to download tasks from your C&C server.
In Cobalt Strike 4.0 and later, the DNS Beacon is a DNS-only payload. This payload has no HTTP communication mode. This is unlike previous versions of the product.
Information data channels
Today, a DNS Beacon can upload tasks via DNS TXT, DNS AAAA, or B. This payload can switch between these data channels while it is at the target. Use the mode command to change the current data channel. Mode dns is an A-record data transfer channel. DNS6 operating mode – record of AAAA channel. And the dns-txt mode is a channel of a given TXT record. By default, the data channel of the TXT record is used.
Note that the DNS beacon is not registered until work is available. Use the register command to request DNS beacon registration the next time you access the server.
Configuring the DNS Listener
To create a DNS beacon handler, select Cobalt Strike -> from the main menu
Listeners and click the Add button at the bottom of the Listeners tab.
The New Listener panel will appear.
Select Beacon DNS in the Payload field and set the Listener to Name. Necessarily
give the new listener a memorable name, as that’s what you’ll refer to it with Cobalt Strike commands and workflows.
Parameters
DNS Hosts – Click [+] to add one or more beacon domains. Your Cobalt Strike C&C server must be authoritative for the domains you specify. Create a DNS A record and forward it to the Cobalt Strike command server. Use NS records to delegate multiple C&C A record domains or subdomains.
The list of beacon hosts is limited to 255 characters. It includes an arbitrarily assigned URI for each host and a separator between each list item. If the length is exceeded, hosts will be dropped from the end of the list until it fits in the space provided. Messages about rejected hosts will appear in the C&C server logs
Host Rotation Strategy – This value configures the behavior of beacons when selecting a host(s) from a list to use when establishing a connection. Select one of the options below.
Circle Area: Select to circle the list of hostnames in the order in which they appear. Each host is used for one connection.
random: Select to randomly select a hostname from the list each time you try to connect.
failover-xx: Choose to use the working host as long as possible. Use each host in the list until they reach the number of consecutive failures (x) or time period (m, h, d), then use the next host.
rotate-xx: select to use each host for a certain period of time. Use each host in the list for the specified duration (m,h,d) and then use the next host.
Max Retry Stategy – configures the behavior of beacons to exit after several consecutive unsuccessful attempts to connect to the C&C server. There are several default options or you can create your own list using the LISTENER_MAX_RETRY_ STRATEGIES function.
none: Select to prevent the beacon from turning off due to failed connection attempts.
exit-xxx: These options use the syntax exit-[maximum_attempts]- [attempts_to_increase]-[duration][m,h,e]. maximum_attempts – the number of consecutive failed attempts, after which the Beacon will exit. Attempts_to_increase is the number of consecutive failed attempts to increase sleep time. Duration is the number of minutes, hours, or days for the new sleep duration.
The sleep time will not be updated if the current sleep time is greater than the new set value. Sleep time is affected by the current jitter value. On any successful connection, the failed attempt counter is reset to zero and the sleep time is reset to its previous value.
DNS Host (Stager) – the stager of DNS TXT Beacon records is configured here. This stage is only used with Cobalt Strike features that require it. Your C&C server must be authoritative for this domain.
Profile – Allows you to customize the beacon using the Malleable C2 profile.
DNS Port (Binding) – This field specifies the port to which your beacon DNS server will be bound. This option is useful if you want to configure a forwarder that changes the port, such as a forwarder that accepts connections on port 53 but forwards them to the C&C server on a different port.
DNS Resolver – Allows you to resolve a DNS service using a specific DNS resolver instead of the default DNS resolver for the target server. Specify the IP address of the desired resolver, this DNS resolver is not used by the beacon’s DNS server.
Check
To check your DNS configuration, open a terminal and type nslookup jibberish.beacon domain. If you get a response with an A record of 0.0.0.0, then your DNS is configured correctly. If you do not receive a response, it means that your DNS configuration is incorrect and the DNS beacon is not contacting you.
Notes
Make sure that the DNS records point to the primary address of the network interface. The DNS server will always send responses from the primary address of your network interface. DNS resolvers typically drop responses when they request information from one server and receive a response from another.
If you are using a NAT device, make sure you use your public IP address for the DNS server record and configure your firewall to forward UDP traffic on port 53 to your system. Cobalt Strike includes a DNS server for beacon management
To configure network traffic indicators for your DNS beacons.
HTTP and HTTPS beacons download tasks using an HTTP GET request. Data beacons send data back using an HTTP POST request. This is the default setting. You have impressive control over the behavior and performance of this payload with the Malleable C2.
Configuring the HTTP(S) Listener
To create an HTTP Handler or HTTPS Beacon, select Cobalt Strike -> Listeners from the main menu and click the Add button at the bottom of the Listeners tab screen.
The New Listener panel will open.
Select Beacon HTTP or Beacon HTTPS in the Payload field and set the Listener with the Name field. Be sure to give the new listener a memorable name, as this is the name you will use to resolve it with Cobalt Strike commands and workflows.
Parameters
HTTPS(S) Hosts – Click [+] to add one or more hosts to be accessed via HTTP Beacon. Press [-] to remove one or more hosts. Press [X] to clear the current hosts. If you have multiple hosts, you can paste a comma-separated list of hosts into this window.
The beacon host list is limited to 255 characters in length. It includes an arbitrarily assigned URI for each host and a separator between each list item. If the length is exceeded, the hosts will be dropped from the end of the list until they fit in the space provided. Messages about rejected hosts will appear in the C&C server logs.
Host Rotation Strategy – This value configures the behavior of beacons when selecting a host(s) from a list to use when establishing a connection. Select one of the options below.
Circle Area: Select to circle the list of hostnames in the order in which they appear. Each host is used for one connection.
random: Select to randomly select a hostname from the list each time you try to connect.
failover-xx: Choose to use the working host as long as possible. Use each host in the list until they reach the number of consecutive failures (x) or time period (m, h, d), then use the next host.
rotate-xx: select to use each host for a certain period of time. Use each host in the list for the specified duration (m,h,d) and then use the next host.
Max Retry Stategy – configures the behavior of beacons to exit after several consecutive unsuccessful attempts to connect to the C&C server. There are several default options or you can create your own list using the LISTENER_MAX_RETRY_ STRATEGIES function.
none: Select to prevent the beacon from turning off due to failed connection attempts.
exit-xxx: These options use the syntax exit-[maximum_attempts]- [attempts_to_increase]-[duration][m,h,e]. maximum_attempts – the number of consecutive failed attempts, after which the Beacon will exit. Attempts_to_increase is the number of consecutive failed attempts to increase sleep time. Duration is the number of minutes, hours, or days for the new sleep duration. The sleep time will not be updated if the current sleep time is greater than the new set value. Sleep time is affected by the current jitter value. On any successful connection, the failed attempt counter is reset and the sleep time is reset to its previous value.
HTTP Host (Stager) – This parameter controls the HTTP stager host for the HTTP beacon. This value is only used if you combine this payload with an attack that requires an explicit trainee.
Profile – this field specifies the variant of the flexible profile C2. A variation is a way to specify multiple variations of a profile in a single file. For options, each configured HTTP or HTTPS handler can have different network indicators.
HTTP Port (C2) – This field specifies the port that the HTTP beacon will access.
HTTP Port (Bind) – This field specifies the port to which your HTTP Beacon web server will bind. This option is useful if you want to configure a redirector that changes the port (for example, a redirector that accepts connections on ports 80 or 443 but directs them to a server command on a different port).
HTTP Host Header – If specified, this value is passed to your HTTP handlers and through your HTTP connections. This option makes it easier to take advantage of domain fronting with Cobalt Strike.
HTTP Proxy – Click the … button to specify a specific proxy configuration for this payload.
Manual HTTP proxy configuration
The Manual Proxy Options dialog box offers several options to control the proxy configuration for HTTP and HTTPS Beacon requests. The default behavior of the beacon is to use the Internet Explorer proxy configuration for the current process/user context.
In the Type field, the type of proxy server is configured. The Host and Port fields tell the beacon where the proxy server is located. The Username and Password fields are optional. These fields define the credentials Beacon uses to authenticate to the proxy server.
Select Ignore proxy settings; use a direct connection to force the beacon to try HTTP and HTTPS requests without going through a proxy server.
Click the Install button to update the Beacon dialog with the required proxy settings. Click the Reset button to return the proxy configuration to its default behavior.
NOTE. Manual proxy configuration only affects the HTTP and HTTPS beacon stage. This does not apply to stages.
Redirection
A redirect is a system that sits between your target’s network and your command server. Any connections that come to the redirector are forwarded to your C&C server for processing. Redirection is a way to allow multiple hosts to access your beacon. Redirection also improves security by making it harder to track the true location of your C&C server.
Lestener Cobalt Strike controls support the use of redirects. Simply specify your redirectors when configuring the HTTP Listener or HTTPS Beacon.
Cobalt Strike does not verify this information. If the specified host is not related to the current host, Cobalt Strike assumes it is a redirector. One simple way to turn a server into a redprop is to use socat. Here is the socat syntax to forward all connections on port 80 to the C&C server at 192.168.12.100 on port 80:
socat TCP4-LISTEN:80,вилка TCP4:192.168.12.100:80
SMB Beacon uses named pipes to communicate through the parent beacon. This peer-to-peer communication works with beacons on the same host. It also works over the network. Windows encapsulates named pipe communication in the Server Message Block (SMB) protocol. Hence the name – SMB Beacon.
Configuring the SMB handler
To create an SMB beacon, select Cobalt Strike -> Listeners from the main menu and click the Add button at the bottom of the Listeners tab screen.
The New Listener panel will open.
Select Beacon SMB in the Payload field and set the Name field to Listener. Be sure to give the new listener a memorable name, as this is the name you will use to refer to it with Cobalt Strike commands and workflows.
The only parameter related to SMB Beacon is Pipename (C2). You can specify a specific named pipe or accept the default. The SMB Beacon is compatible with most Cobalt Strike actions generated by Payload. The exception is user-directed attacks that require explicit actors.
Cobalt Strike’s post-exploitation and lateral movement actions that generate the payload will attempt to take control (communicate) of the SMB beacon for you. If you’re running an SMB beacon manually, you’ll need to associate it with a parent beacon.
In the Beacon console, use the link command to associate the current beacon with the SMB beacon listening for the connection. When the current beacon is registered, its associated beacons are also registered.
To merge with normal traffic, linked beacons use named Windows channels for communication. This traffic is encapsulated in the SMB protocol. There are several caveats to this approach:
Hosts with SMB Beacon must accept connections on port 445.
You can only link beacons controlled by the same instance of Cobalt Strike.
If you get error 5 (Access Denied) after trying to bind a beacon: Steal the domain user’s token or use make_token with password DOMAIN\USER to populate the current token with valid credentials for the target. Try binding the beacon again.
To break a connection to a beacon, use disconnect [ip] [session PID] on the parent or child beacon. The [session PID] argument is the Beacon process ID to disable. This value allows you to specify a specific beacon to disable when there are several child beacons.
When you disable an SMB beacon, it is not disabled or removed. Instead, it enters a state waiting for a connection from another beacon. You can use the link command to regain control of the SMB beacon from another beacon later.
It’s hard to go unnoticed when so many compromised systems are hitting the Internet. Use peer-to-peer communication to solve this problem. This function allows you to link beacons with each other. Linked beacons upload tasks and send results through their parent beacon. Use smb mode to make a beacon a peer waiting for another beacon to connect.
Use link [ip-address] to link the current beacon to the node that is waiting for a connection. When the current beacon is registered, its associated beacon will also be registered. Connected beacons are used to merge with normal traffic for communication.
SMB channels. There are several caveats to this approach:
Beacon peer hosts must accept connections on port 445.
You can only link beacons controlled by the same instance of Cobalt Strike.
If you get error 5 (Access Denied) when trying to bind a beacon: steal the domain user token or use the net use \\host /U:DOMAIN\user password shell to establish a session with the host. This does not require an administrator. Any existing domain user will do. After setting up the session, try to connect to the beacon again.
To unlink a beacon, use the unlink [ip-address] command on the parent or child beacon. You can later link the disconnected beacon again (or link it to another beacon).
Once a beacon becomes a peer, it is impossible to force it to transmit data again via HTTP or DNS. If you want to destroy a peer beacon, use the exit command. If you want the beacon to transmit data over HTTP or DNS, ask the peer beacon to provide you with another beacon session.
A peer beacon as a payload
Some systems cannot connect to the Internet. In these cases, it’s good to have a way to deliver the plugin’s beacon so you can connect to it. Use [host] -> Login -> psexec or [host] -> Login – > psexec (psh) with beacon (connect to target) Listener. This will allow you to run a peer-to-peer beacon on a host without needing an internet connection to stage.
You can also configure the listener to deliver a peer beacon. Create a handler for windows/beacon_smb/reverse_tcp. This listener will form your peer beacon. Once installed, you will still need to link it to another beacon.
If staging takes a long time, you can ask Cobalt Strike to export a fully finished peer beacon as an executable, DLL, PowerShell script, or raw block of shellcode. Go to Payloads -> Windows Stageless Payload and select SMB Beacon.
A TCP beacon uses a TCP socket to exchange data through its parent beacon. This peer-to-peer communication works with beacons on the same host or across a network.
TCP Listener settings
To create a TCP beacon handler, select Cobalt Strike -> Listeners from the main menu and click the Add button at the bottom of the Listeners tab screen.
The New Listener panel will open.
Select Beacon TCP in the Payload field and set the Name field to the listener. Be sure to give the new listener a memorable name, as this is the name you will use to refer to it with Cobalt Strike commands and workflows.
A TCP beacon configured in this way is a binding payload. A payload binding is a payload that is waiting for a connection from its control component (in this case, another beacon session).
Parameters
Port (C2) – This parameter controls the port on which the TCP beacon will listen for connections.
Bind to localhost only – Set the TCP beacon to bind to 127.0.0.1 when it listens for connections. This is a good option if you are using TCP Beacon for localhost only activity.
TCP Beacon is compatible with most Cobalt Strike operations that generate payloads. The exception is, as with SMB Beacon, user-directed attacks that require explicit stagers.
After the operation and lateral movement, the Cobalt Strike waiting for the payload will try to take control (connect) to the SMB beacon for you. If you start a TCP beacon manually, you will need to connect to it from the parent beacon.
Connection and disconnection
In the beacon console, use the connect [ip address] [port] command to connect the current session to the TCP beacon that is waiting for a connection. When the current session is logged, its associated beacons will also be logged. To destroy the connection to the beacon, use the unlink [ip-address] [session-PID] command in the console of the parent or child session. Later, you can reconnect to the TCP beacon from the same host (or a different host).
External C2 is a concept that allows third-party applications to act as a communication layer for the Cobalt Strike payload. These third-party applications connect to Cobalt Strike to read their intended data and write data with payload results that are similarly managed.
The C2 external server is what these third-party applications use to communicate with your Cobalt Strike command server.
Setting the external listener C2
To create an External C2 Beacon Listener, select Cobalt Strike -> Listeners
in the main menu and click the Add button at the bottom of the Listeners tab screen.
The New Listener panel will open.
Go to Cobalt Strike -> Listeners, click the Add button and select External C2 as payload.
Select External C2 in the Payload field and set the Listener Name field. Be sure to give the new listener a memorable name, as this is the name you will use to refer to it with Cobalt Strike commands and workflows.
Port (Bind) – Specify the port on which the external C2 server listens for connections.
Bind to localhost only – set the external C2 server to local only.
NOTE. The C2 external listeners are unlike other Cobalt Strike listeners. You can’t target them with Cobalt Strike’s post-op. In this option, there is only the possibility to configure the interface itself.
Specification
The external C2 interface is described in the External C2 specification.
External specification C2
extc2example.c
If you want to adapt an example (Appendix B) from the specification for use in a third-party C2, you can use the 3-clause BSD license for the code contained in the specification.
Third party materials
Here is a list of third-party projects and publications that reference, use, or build on external C2:
Custom Command and Control (C3) from F-Secure Labs. A framework for rapid prototyping of custom C2 channels.
external_c2_framework Джонатана Ечаваррії. A Python framework for creating external C2 clients and servers.
ExternalC2 Library from Ryan Hanson Бібліотека .NET с Web APi, WebSockets and direct outlet. Includes unit tests and comments.
Завдання Office 365 для Cobalt Strike C2 from MWR Labs.Discussion and demonstration
Office 365 C2 for Cobalt Strike.
Cobalt Strike supports the concept of third-party listeners. These are aliases for x86 payload handlers hosted by the Metasploit framework or other instances of Cobalt Strike. To transfer a Windows HTTPS Meterpreter session to another user using msfconsole, configure the Foreign HTTPS payload and specify the Host and Port values for the appropriate handler. You can use third-party listeners wherever you use Cobalt Strike’s x86 Listener.
Setting up a third-party listener
To create a third-party beacon handler, select Cobalt Strike -> Listeners and click the Add button at the bottom of the Listeners tab screen.
The New Listener panel will open.
Select Foreign HTTP or Foreign HTTPS in the Payload field and set the Listener’y to the Name field. Be sure to give the new listener a memorable name, as this is the name you will use to refer to it with Cobalt Strike commands and workflows.
Parameters
HTTP(S) Host (Stager) – This field specifies the name of the server that hosts your third-party listener.
HTTP(S) Port (Stager) – This field specifies the server port on which your third-party listener listens for connections.
The Cobalt Strike model for distributed operations involves creating a separate C&C server for each stage of your work. For example, it makes sense to separate the infrastructure for post-operation and consolidation. If you find – There are post-op measures and you don’t want callbacks to get you back online when you get your infrastructure back up.
Some stages of the operation require the use of several redirects and communication channels. Cobalt Strike 4.0 is friendly towards this.
You can bind multiple HTTP, HTTPS and DNS listeners to a single Cobalt Strike C&C server. The payload also supports port binding in its configuration. This allows you to use a common port for your channel (80,443 or 53) in on-redirect and C2 constructs, but bind these Listeners to different ports to avoid port conflicts on your C&C server.
To diversify network performance, C2 Cobalt Strike compliant profiles can contain several options. A variant is a way to add different versions of the current profile to a single profile file. You can specify a profile option when defining each HTTP handler or HTTPS beacon.
Alternatively, you can define multiple TCP and SMB beacons on the same command server, each with different channel and port configurations. Any source beacon from the same C&C server can control any TCP or SMB beacon once deployed in the target environment.
Safety features of the payload
Cobalt Strike takes steps to secure beacon communication and ensure that Beacons can only receive tasks from and send results to their C&C server.
When you configure Beacon for the first time, Cobalt Strike generates a public/private key pair that is unique to your C&C server. The public key of the C&C server is embedded in the payload of the Beacon stage. Beacon uses the C&C server’s public key to encrypt the session metadata it sends to the C&C server.
A beacon must always send session metadata before the C&C server can issue tasks and retrieve beacon session results. This metadata contains the random session key generated by this beacon. The C&C server uses each beacon’s session key to encrypt tasks and decrypt results.
Each beacon and data channel implementation uses the same scheme. You have the same security when using an A-record data channel in a hybrid HTTP and DNS beacon as when using an HTTPS beacon.
Please note that all of the above applies to the beacon once it has been placed. Due to their size, payload standers have no built-in safety features.
Thanks to various open source guides.
1517 
1102 
1077 
1013 
967 
774 
1047