During a recent conversation, a friend had mentioned that they saw Cobalt Strike as a post-exploitation only tool. This strikes me as a little odd. Cobalt Strike has always had all the features necessary to execute a full attack chain.
The system profiler, spear phishing tool, and user-driven attacks support a social engineering process designed to get a foothold into a modern enterprise.
The Beacon payload integrates well with the above tools. It stages over HTTP, HTTPS, and DNS TXT records. Once the payload is in memory, Beacon can download its tasks over DNS A records, DNS TXT records, HTTP, and HTTPS.
Once on a target, Beacon’s post-exploitation capability gives you seamless access to PowerShell, mimikatz, and a slew of other organic capability. These tools are enough to exfiltrate data, capture user activity, and explore options for privilege escalation.
Beacon is also quite adept at target discovery. Beacon has a port scanner that deploys to the agent as a Reflective DLL. This port scanner runs on target and reports intermediate results during each check-in. Beacon also provides organic equivalents for many net commands building on the Windows Network Management API. I also tend to favor the use of PowerView to understand large environments.
What about lateral movement? Beacon has automation for this too. The psexec, psexec_psh, winrm, and wmi commands are present. Like other Cobalt Strike features, these tools run in the Beacon agent. Don’t worry, the ability to leverage different trusts is present. Beacon can steal tokens, use credentials, pass-the-hash, and leverage Kerberos tickets.
If you’re at a loss about how this is possible, without the Metasploit Framework, take a look at this talk:
What about pivoting? Cobalt Strike can pivot too. Which option makes sense depends on your definition of pivoting. If you would like to control your Beacon agents through a foothold Beacon, you can do that. Beacon uses Windows named pipes to control Beacons through another Beacon. You can chain multiple accesses together this way without any problems. This feature is ideal for privilege escalation; you don’t have to worry about egress for the elevated session. This feature is also beautiful for lateral movement; named pipe communication is encapsulated in the SMB protocol. It blends in well. Many of my customers rave about this particular feature and how easy it is with Cobalt Strike 3.0 and later.
Chaining Beacons together is one thing, what about tunneling tools through Beacon? Cobalt Strike has you covered here too. You can use SOCKS pivoting to tunnel tools through Beacon. You can also setup reverse port forwards that ride backwards through your Beacon communication path too.
When I look at the above capability, I ask: how is this post-exploitation only? Cobalt Strike has the tools to get a foothold with a targeted phishing attack, operate through that foothold, expand access, pivot, and exfiltrate data.
Now, let’s shift the question: Where is the tool to scan for vulnerabilities in web applications? Why doesn’t Cobalt Strike import vulnerability scan results? Where are the remote memory corruption exploits to verify vulnerability scan results? Why can’t you run NMap from Cobalt Strike? Cobalt Strike doesn’t do these things. Cobalt Strike is not a toolset for vulnerability verification. It never was. It never will be.
What is Cobalt Strike for then? It’s for red team operations and adversary simulations. These services require the ability to work quietly as a remote actor in a customer’s network. This problem set and the features it requires are different from the features needed in a vulnerability verification tool.
The Advanced Threat Tactics course covers these topics in depth.