Cobalt Strike 3.0 is coming in a few weeks. This upcoming release is the result of a large engineering effort that paralleled my existing efforts to maintain Cobalt Strike 2.x. One of the big motivators for this parallel effort was to take a fresh look at logging and reporting.
Today’s Cobalt Strike produces reports that are run-of-the-mill for penetration testing tools (*yawwwwwwwwn*). That’s too bad. Cobalt Strike’s reporting engine has a lot of potential. It generates high quality PDF and editable Word Documents. The fidelity between the two is incredible. Cobalt Strike is also unique in its ability to connect to multiple team servers and merge data from all of these servers into one data model before it generates a report. This is important as any red team worth its salt operates from distributed infrastructure. No one server has the whole story.
So, here’s the question that drove this work: what do red teams and adversary simulation operators need in terms of reports? These operators are not trying to enumerate all vulnerabilities in a large enterprise. They’re working to train and exercise incident response.
If the debriefs from red team operations and adversary simulations don’t focus on vulnerabilities, what do they focus on? They focus on red team actions, the indicators these actions leave behind, and the exact timeline of the red team’s activity. This insight is where I started my re-think of Cobalt Strike 3.0’s reporting capability.
Cobalt Strike 2.x’s Hosts and Social Engineering Reports will come over to Cobalt Strike 3.0 mostly as-is. Cobalt Strike 3.0 has several new reports. Here they are:
Indicators of Compromise
Most threat intelligence report includes an Indicators of Compromise appendix at the end. These reports document hashes, IP addresses, and samples of malware command and control traffic. These appendices are a familiar format for security operations staff to consume.
Cobalt Strike 3.0 generates its own Indicators of Compromise Appendix, based on your activity. This report pulls data from all of the team servers you’re currently connected to.
This report generates and displays a traffic sample from each team server’s Malleable C2 profile.
It summarizes the MD5 hashes of files uploaded through a Beacon.
It also summarizes IP addresses and domains affiliated with your different listeners.
Like most Threat Intelligence reports, this appendix documents indicators with little context. I see this report as something you can provide mid-engagement when the Detect part of the Detection and Response game is taking longer than it should. It provides enough information to give security operations staff a start for hunting red team activity.
The (New) Activity Timeline
The Activity Report is a timeline of all red team activity that occurred during the engagement. Cobalt Strike 3.0’s Activity Report is a drastic improvement over the Activity Report in Cobalt Strike 2.x. Cobalt Strike 3.0’s asynchronous model of offense requires most actions to deploy to and execute from a Beacon. This makes it easier to summarize what happened and where it happened in a way that’s meaningful to a blue operator.
This report becomes far more interesting when you take into account the fact that Cobalt Strike 3.0 merges timelines and data from all team servers you’re connected to before it generates a report.
The Sessions Report
At the end of a security-operations focused assessment, the network defense staff is going to want to know what they should have seen and when. This information will allow them correlate your activity with their sensors and allow them to look into what they should have caught (but didn’t) or what they did catch, but didn’t understand and attribute properly. This is important information to provide and every red team I’ve worked with struggles to pull this together for their blue peers. Cobalt Strike 3.0 takes a stab at this problem with its sessions report.
The sessions report is a timeline of red team activity on a session-by-session basis. This report also summarizes the MD5 hashes of all files uploaded during that session. It pulls out miscellaneous indicators that the team may have observed (right now, services created by Cobalt Strike’s automation [e.g., getsystem]).
This report also documents the communication path each compromised system took to reach you, the attacker. This is especially important to help blue teams understand the complex pivoting red team operators tend to execute.
Custom Reports (Cobalt Strike 3.1?)
Cobalt Strike 3.0’s Reporting Engine uses a Domain Specific Language to specify reports without exposing the intermediate markup I generate PDFs and Word Documents from. I will eventually expose this DSL and allow Cobalt Strike’s users to build custom reports and tailor the existing ones to their needs.
I hope you’ve enjoyed this preview of Cobalt Strike 3.0’s reports for Red Team Operations and Adversary Simulations. I expect to ship Cobalt Strike 3.0 by the end of this month.