The SMB Beacon uses named pipes to communicate through a parent Beacon. This peer-to-peer communication works with Beacons on the same host. It also works across the network. Windows encapsulates named pipe communication within the SMB protocol. Hence, the name, SMB Beacon.
To configure an SMB Beacon payload, go to Cobalt Strike -> Listeners. Press Add. Choose Beacon SMB as your payload option.
The only option associated with the SMB Beacon is the pipename. You can set an explicit pipename or accept the default option.
The SMB Beacon is compatible with most actions in Cobalt Strike that spawn a payload. The exception to this are the user-driven attacks (e.g., Attacks -> Packages, Attacks -> Web Drive-by) that require explicit stagers.
Cobalt Strike post-exploitation and lateral movement actions that spawn a payload will attempt to assume control of (link) to the SMB Beacon payload for you. If you run the SMB Beacon manually, you will need to link to it from a parent Beacon.
From the Beacon console, use link [host] [pipe] to link the current Beacon to an SMB Beacon that is waiting for a connection. When the current Beacon checks in, its linked peers will check in too.
To blend in with normal traffic, linked Beacons use Windows named pipes to communicate. This traffic is encapsulated in the SMB protocol. There are a few caveats to this approach:
If you get an error 5 (access denied) after you try to link to a Beacon: steal a domain user’s token or use make_token DOMAIN\user password to populate your current token with valid credentials for the target. Try to link to the Beacon again.
To destroy a Beacon link use unlink [ip address] [session PID] in the parent or child. The [session PID] argument is the process ID of the Beacon to unlink. This value is how you specify a specific Beacon to de-link when there are multiple childn Beacons.
When you de-link an SMB Beacon, it does not exit and go away. Instead, it goes into a state where it waits for a connection from another Beacon. You may use the link command to resume control of the SMB Beacon from another Beacon in the future.
The Pivot Graph shows your Beacon chains in a natural way. Go to Cobalt Strike -> Visualization -> Pivot Graph to enable this view.
Each Beacon session has an icon. As with the sessions table: the icon for each host indicates its operating system. If the icon is red with lightning bolts, the Beacon is running in a process with administrator privileges. A darker icon indicates that the Beacon session was asked to exit and it acknowledged this command.
The firewall icon represents the egress point of your Beacon payload. A dashed green line indicates the use of beaconing HTTP or HTTPS connections to leave the network. A yellow dashed line indicates the use of DNS to leave the network.
An arrow connecting one Beacon session to another represents a link between two Beacons. Cobalt Strike’s Beacon uses Windows named pipes and TCP sockets to control Beacons in this peer-to-peer fashion. An orange arrow is a named pipe channel. SSH sessions use an orange arrow as well. A blue arrow is a TCP socket channel. A red (named pipe) or purple (TCP) arrow indicates that a Beacon link is broken.
Click a Beacon to select it. You may select multiple Beacons by clicking and dragging a box over the desired hosts. Press Ctrl and Shift and click to select or unselect an individual Beacon.
Right-click a Beacon to bring up a menu with available post-exploitation options.
Right-click the Pivot Graph with no selected Beacons to configure the layout of this graph.