Now, before we roll up our sleeves, we need to understand how to communicate with the Team Server ExternalC2 interface.įirst, we need to tell Cobalt Strike to start ExternalC2. Here we can see that our custom C2 channel is transmitted between the Third-Party Controller and the Third-Party Client, both of which we can develop and control. Using the diagram from CS’s documentation, we can see just how this all fits together: SMB Beacon - The standard beacon which will be executed on the victim host.Third-Party Client - Responsible for communicating with the Third-Party Controller using a custom C2 channel, and relaying commands to the SMB Beacon.Third-Party Controller - Responsible for creating a connection to the Cobalt Strike TeamServer, and communicating with a Third-Party Client on the target host using a custom C2 channel.The full specification can be downloaded here.Įssentially this works by allowing the user to develop a number of components: ExternalC2ĮxternalC2 is a specification/framework introduced by Cobalt Strike, which allows hackers to extend the default HTTP(S)/DNS/SMB C2 communication channels offered. So, I wanted to look at some alternate routes to achieve C2 communication and with this, I came across Cobalt Strike’s ExternalC2 framework. OK, maybe I exaggerated that a bit, but it’s certainly becoming harder. Whether because of egress firewall rules or process restrictions, the simple days of reverse shells and reverse HTTP C2 channels are quickly coming to an end. Tagged in redteam, cobaltstrike, externalc2Īs many testers will know, achieving C2 communication can sometimes be a pain.
« Back to home Exploring Cobalt Strike's ExternalC2 framework
0 kommentar(er)
