The Challenges of Cobalt Strike Server Fingerprinting
By Jason Reaves and Joshua Platt
The misuse of legitimate security tools by criminals and state-sponsored actors has been a dilemma for close to two decades. Penetration-testing software and red-teaming frameworks were built for the purpose of testing the defenses of enterprise networks, but that hasn’t stopped individuals and collectives with malicious intent from pirating or hacking these tools and using them to nefarious ends.
Cobalt Strike is one such tool that is being widely abused, and if your organization has not engaged with a penetration-testing or red-teaming firm, it’s crucial that network security specialists learn how to detect potentially illicit traffic and understand the steps threat actors are taking to bypass detection.
One thing is certain: there’s more than one way to skin this cat.
Identifying Cobalt Strike a Defender’s Imperative
Cobalt Strike was built and is distributed by Strategic Cyber LLC of Washington, D.C., founded in 2012 by Raphael Mudge. The platform was built for red teams and allows them to simulate the actions of adversaries. The tool can be used, for example, to identify vulnerabilities present in network resources, launch attacks exploiting those flaws, and issue further commands. Clearly in the hands of someone with ill intent, Cobalt Strike, like Metasploit, Mimikatz and numerous other testing tools, can be a dangerous implement.
Strategic Cyber LLC tries to address the risk by limiting distribution of Cobalt Strike to security teams engaged only in ethical pen-testing or red-teaming. The company says it screens and performs a risk assessment on all trial requests and sales, degrades functionality in trial distributions, and adds identifiers to licensed products to identify users.
Determined threat actors, however, usually find a way. Pirated or hacked versions of Cobalt Strike are in the wild and targeting organizations, making it imperative that defenders track and detect this type of activity within their network.
There are many means by which to fingerprint Cobalt Strike team server traffic, which controls what is known as the Beacon, or payload. The Beacon will communicate with the team server through DNS request lookups. The DNS response will instruct the beacon how and when to download additional commands from the team server.
The behavior of its Beacon can be customized using Cobalt Strike’s Malleable C2 (command-and-control) profiles, which enable users to change their network indicators and emulate the tactics, techniques, and procedures (TTPs) of threat actors in the wild. There are a number of methods for identifying Cobalt Strike servers, many of which have been publicly documented by researchers and vendors, including Strategic Cyber LLC. Most of these methods employ server fingerprinting techniques based on Cobalt Strike’s default settings, which can be easily changed using a Malleable C2 profile.
The Power of Malleable C2 Profiles
Cobalt Strike servers come preconfigured with various default settings that, if left unchanged, can be used to identify and fingerprint them. It is important to note that the functionality of Cobalt Strike’s Malleable C2 profiles makes it relatively easy to change these default settings, so they are not present on—and thus cannot be used to identify or fingerprint—every Cobalt Strike server.
One such setting—an extraneous space in an HTTP response header—was being used by researchers for 18 months to identify Cobalt Strike team servers. Strategic Cyber LLC removed the space in version 3.13 of Cobalt Strike in January, and it can no longer be used to identify team servers.
This also demonstrates the power of Cobalt Strike’s Malleable C2 profiles, which allow users to transform data, store it in a transaction, and also extract and recover data from transactions, according to Strategic Cyber LLC. Threat actors may just as easily use them to bypass detection and make a team server difficult to fingerprint. For example, they could use a Malleable C2 profile to change default HTTP response headers to change server parameters, or replace default TLS/SSL certificates, or switch administrator ports.
Given the prevalence and popularity of Cobalt Strike for legitimate and malicious purposes, it is critical to be able to identify as many Cobalt Strike servers as possible. Although there are a number of well-documented methods for identifying these servers, most rely on server fingerprinting based on Cobalt Strike’s default settings, which can be easily changed. No single method for identifying Cobalt Strike servers is foolproof.
Principal Threat Researcher
Jason Reaves is a Principal Threat Researcher at Flashpoint who specializes in malware reverse-engineering. He has spent the majority of his career tracking threats in the Crimeware domain, including reverse-engineering data structures and algorithms found in malware in order to create automated frameworks for harvesting configuration and botnet data. Previously, he worked as a software developer and unix administrator in the financial industry and also spent six years in the U.S. Army. Jason holds multiple certifications related to reverse-engineering and application exploitation and has published numerous papers on topics such as writing malware scripts pretending to be a bot, unpackers, configuration data harvesters and covert channel utilities. He enjoys long walks in IDA and staring at RFCs for hours.
Principal Threat Researcher
Joshua Platt is a Principal Threat Researcher at Flashpoint who specializes in investigating complex financial crimeware families. As a former network security engineer, he first began reversing malware while working in the financial services industry nearly 10 years ago. Joshua graduated from the University of North Texas with a B.S. in criminal justice and has earned multiple certifications within the security industry related to reverse engineering and penetration testing.