When I work on a project, I like to define a broad problem statement. This is the project’s intended mark on the world. I don’t have enough hubris to claim a solution for all cases. To make my project’s tractable, I define assumptions. These assumptions bound the problem statement and keep the work under control. I tend to live within my assumptions until I feel the project has outgrown them. When this happens, I look for an opportunity to redefine my work under a new problem statement or at least, new assumptions.
In this blog post, I’ll take you through the problem statements and assumptions that define Armitage and Cobalt Strike. It’s fitting that I write this now, because I’m re- examining Cobalt Strike’s problem statement and assumptions.
Armitage is a scriptable user interface for the Metasploit Framework that allows red teams to collaborate. Armitage has a broad problem statement: how do I help red teams collaborate?
Armitage lives under a set of assumptions.
First, I had to define a use case for this project. I opted to scope Armitage’s use case to exercise red teams, particularly red teams for the Collegiate Cyber Defense Competitions, which I had a lot of volunteer involvement with.
Next, I scoped Armitage to the Metasploit Framework only. I had zero intention of building the one collaboration framework to rule them all. I wanted to explore some ideas within the context of the Metasploit Framework and what it offers. This meant I would not integrate third-party hacking tools with Armitage and I would not build new hacking capability into it. These assumptions gave me suitable constraints to build and reason about Armitage.
This weekend, Armitage will celebrate its fourth birthday. I continue to maintain this project, but Armitage was successful in its original efforts a long time ago. Today, most penetration testing and red team platforms have collaboration features. Armitage is a familiar face at events where hackers have to work together with the Metasploit Framework. We now have good practices [1, 2, 3, 4] to organize red teams in cyber defense exercises.
I used to work on a red team support contract. Stealth and evasion mattered a great deal. I ran into the limitations of available tools. I saw a need for penetration testing tools to challenge harder targets. My work on these problems became Cobalt Strike. I define Cobalt Strike’s problem set as closing the gap between penetration testing tools and so-called advanced threat capabilities. It’s in my logo even! “Advanced Threat Tactics for Penetration Testers”.
Like Armitage, Cobalt Strike lives under a set of assumptions too.
Every feature I build into Cobalt Strike requires synergy with a stock instance of the Metasploit Framework. This assumption led to a collection of tools very focused on the Windows attack surface. Some of Cobalt Strike’s concepts would be right at home with a MacOS X target, but there’s too little opportunity for synergy with the Metasploit Framework, so I haven’t looked in this direction. My emphasis on 32-bit payloads, also comes from this assumption.
Second, Cobalt Strike is made for a hypothetical internal red team for a large corporate or government enterprise. This assumption has had major influences on my product. It defines the problems I care about and the things I ignore. Let’s use browser pivoting as an example. This technology was made to meet a need for a segment of users. These users care about Internet Explorer, not Google Chrome or Firefox. Hence, browser pivoting was made for Internet Explorer.
Third, Cobalt Strike is built for a remote operations use case. This influences the problems I work on as well. I assume that my user is a remote actor. This is why I provide covert communication options and focus on ways to evade egress restrictions. Under my assumptions, if a user can’t get out, they can’t use the rest of the toolset. This assumption also limits the features I build and the workflows I support. If a tactic isn’t practical for a remote actor, I ignore it.
My last assumption relates to what Cobalt Strike does. Cobalt Strike executes targeted attacks and replicates advanced threats. That statement is marketing speak for sends phishing emails and focuses on post exploitation. I wrote the last sentence, tongue-in-cheek, but there’s a reality to it. My tool supports a process: setup a client-side attack, phish to get a foothold, abuse trusts for lateral movement, and conduct post exploitation to achieve some objective/demonstrate risk. I focus on this process and work to make this tool better support it. Few engagements execute this process end-to-end, so I make sure to decouple these pieces from each other. That said, this clear definition of what Cobalt Strike does helps guide my development efforts.
Cobalt Strike has nearly two and a half years on the market and it’s had a lot of updates in that time. I still have work to do within Cobalt Strike’s problem set, but I feel it’s a good product for its stated use cases.
I’m thinking a lot about Cobalt Strike’s next iteration. At this time, I’m revisiting Cobalt Strike’s problem statement and assumptions. As I think about what’s coming next, here are a few things at the top of my mind:
First, I believe there’s a “good enough” level for hacker capability. After a point, better malware and capability will only take a red team so far. I see several needs that I categorize as features to support assessors with growing accountability and story telling requirements. This is a sign that some security programs are maturing and these customers expect more detail from us. I think there’s a need to put equal effort into these requirements.
I also believe we’re witnessing the emergence of a service that most penetration testers and red teams will soon offer. These are assessments that assume compromise and focus on an organization’s post-compromise security posture. Particularly, the organization’s ability to detect and remediate a sophisticated intruder. I wrote about this in a previous blog post.
Finally, I believe the deprecation of Windows XP was the end of an era. There are ideas and concepts in our tools and services that date back to the beginning of this era. I think some of these things are holding us back.
I’m not ready to speak specifics on these things yet, but I’m closely examining my tradecraft, process, and tools. I’m asking the hard questions: what’s historic baggage? What makes sense for the red team and adversary simulation use cases going forward?
