If you’re doing Incident Response you probably have had one or more incidents involving Cobalt Strike in the past year(s). Nowadays, it feels like almost every incident has a Cobalt Strike component. Most of the major ransomware groups adopted Cobalt Strike as part of their operations. There are lots of blogs out there about how Cobalt Strike works and how you can detect Cobalt Strike in your environment. However we haven’t seen many blogs on Cobalt Strike from an incident response perspective. That’s why we have decided to write a blog series on how you can respond to Cobalt Strike attacks.
- The first part contains an introduction to Cobalt Strike and how you can leverage Open Source Intelligence (OSINT) & Threat Intelligence for Cobalt Strike identification and analysis;
- In the next post we will discuss host based methods for Cobalt Strike identification and analysis;
- For now we will keep the topic of the final post a secret, be sure to follow our LinkedIn page for updates and news!
As mentioned, in this blog post we’ll show you various methods that will help you assess whether you’re dealing with Cobalt Strike during an incident. Using Open Source Intelligence (OSINT) and Threat Intelligence. Before we dive in let us start with a quick introduction of Cobalt Strike.
Cobalt Strike introduction
According to the official website
Cobalt Strike is threat emulation software. Execute targeted attacks against modern enterprises with one of the most powerful network attack kits available to penetration testers. This is not compliance testing.
From an IR perspective the Cobalt Strike Beacon functionality is something that you’ll encounter most often during an incident. A beacon is used as a Command & Control (C2) channel, the beacon is highly customisable using so-called Malleable C2 profiles. These profiles are configuration files that can be used for a lot of things, for example to encrypt traffic using your own SSL certificates or to hide C2 traffic as DNS data.
Cobalt Strike attack
Due to the highly customisable nature of Cobalt Strike there is no default attack and there are lots of options for threat actors to choose from. At a high level there are two types of attacks with Cobalt Strike beacons:
- Staged attacks
- Stageless attacks
Staged attacks
In a staged attack a small malicious payloads is used to infect a system and then used to download a larger, more robust payload. Many of Cobalt Strike’s attacks and workflows deliver a payload as multiple stages. The first stage is called a stager, the stager is a very tiny program that connects to Cobalt Strike, downloads the beacon payload, and executes it. Learn more about staged attacks with Cobalt Strike here.
Stageless attack
In a stageless attack no staging is required and there is one payload that can be run (in)directly on a victim system e.g. executable or a DLL file. Learn more about stageless attacks with Cobalt Strike here.
Depending on the type of attack a Cobalt Strike attack consists of the following steps:
- In the first stage of the attack a victim system connects to a Cobalt Strike team server. An example could be a staged beacon packed in a Word document, which is activated upon enabling macros.
- The Cobalt Strike team server is listening for clients on a predefined domain and port.
- (Optionally) The Cobalt Strike team server will send an additional payload. The second stage payload can also be served on a different domain than the C2 domain.
- The threat actor can perform post-exploitation actions, such as lateral movement or privilege escalation.
The above is a simplified walkthrough of an attack, be sure to check out the official documentation which contains a detailed walkthrough of an attack here.
For incident responders there are a few important things to remember about Cobalt Strike and beacons:
- Beacons can come in all shapes and sizes, they can be part of a Powershell command a drive-by download or a straight up executable;
- Sometimes beacons/payloads are stageless sometimes they are staged, be sure to know what the difference is and what type of information will be present on a system depending on the type of attack.
- C2 traffic can be masqueraded very easily by the threat actor. There are Malleable C2 profiles available that masquerade traffic as an Amazon search for instance. Point here is don’t always believe what you see and where possible inspect traffic;
- If you want to stay up-to-date on the latest Cobalt Strike trickery be sure to follow pentesters and Red-teamers on Twitter and keep an eye out on the Cobalt Strike release notes.
Now let’s see how we can use what is readily available to make our life as incident responders a little bit easier.
Using OSINT/Threat Intelligence to respond to Cobalt Strike attacks
Luckily you’re not alone in the battle against Cobalt Strike, below an overview of some great resources that you can use to check whether an IP-address, URL or domain is already identified as Cobalt Strike.
- cobaltstrikebot, this Twitter users posts daily lists of Cobalt Strike servers, which you can use to perform lookups. We don’t know exactly how this users collects the information, but in the past we have been able to use the list to find Cobalt Strike servers for an actual incident.
- VirusTotal or any other online environment where you can search for Indicators Of Compromise (IOCs).
Tip: Use this VirusTotal to search for recent Cobalt Strike samples
- AlienVault Open Threat Exchange (OTX) has a few very good and up-to date collections of Cobalt Strike servers. The first one is the Malware Domain Feed V2, which can be found here. Another one from IronNet which is weekly updated.
- Shodan, you can use Shodan for a lot of things. When it comes to Cobalt Strike one of the interesting this you can do in Shodan is to search for the Cobalt Strike server default certificate. The default certificate has the following serial number ‘146473198’. Using this search you can identify Cobalt Strike servers with the default certificate. At the moment of writing 703 servers were up on Shodan with this certificate spanning most continents as shown below:
Another interesting thing you can do with Cobalt Strike is search for the default listening port which is 50050 (TCP) or search for the default NanoHTTPD webserver used by Cobalt Strike. There are a few good blogs about identifying Cobalt Strike servers in the wild see the References section at the bottom of this post.
Extracting the Beacon configuration
At this point you might have a domain, URL or an IP-address that is possibly hosting Cobalt Strike. As an incident responder you always want to know more, for instance you might be wondering if it’s possible to extract some additional information out of a Cobalt Strike server. The answer is most likely yes, as mentioned in the Cobalt Strike introduction section, Cobalt Strike relies on beacon configuration files to define what the beacon must do once it’s on a system for instance spawn a new process with the name ‘explorer.exe’.
The good news is that Cobalt Strike beacon configuration files can be extracted. In the next blog posts we will look at how to extract the configuration files from the host using executables or memory dumps.
Extraction using Triage
For now we will focus on automated extraction the first method is using Triage a malware sandbox. Triage is a unique sandbox, because it uses configuration extractors for known malware families including Cobalt Strike. For example you can search for “family:cobaltstrike” in Triage to get samples identified as CobaltStrike. It automatically extracts and shows you the configuration. For example check out the following sample with SHA hash
67173558f554be3acd49292c4614aa5ee81ecfa3
The Triage report for this sample can be found here.
Based on the sample Triage automatically shows you the Cobalt Strike C2.
Additional attributes related to the Cobalt Strike beacon are also automatically extracted from the sample as shown in the picture below:
Pay attention to the sc_process32 and sc_process64 these are the processes that are injected with the Cobalt Strike payload.
Tip: Use the sc_process names to hunt for active Cobalt Strike processes across your environment
Extraction using CobaltStrikeParser
Last but not least you can use CobaltStrikeParser a tool developed by SentinelOne hosted on GitHub. CobaltStrikeParser is a python script you can use for URLs, for stageless beacons, memory dumps or C2 urls. Let’s try with the C2 url from the previous sample:
parse_beacon_config.py http://5.8.18.118:45500/match
It will grab all the beacon configuration attributes, which you can then use to continue your investigation.
Incident Response scenario
Putting it all together let’s test our incident response approach with a scenario. You have been tasked with reviewing some firewall logs as part of an IR engagement. Quickly you’ve identified that there is a system communicating regularly to 121[.]41[.]101[.]90. So let’s see what we can find out about this IP address.
Step 1 — Search it with VirusTotal
You’ll see that one file flagged as Cobalt Strike shellcode is communicating with this IP address. This shows that this IP address at some point hosted a file identified as Cobalt Strike. If you click on the sample associated with this IP you will get some additional details such as the possible C2 server.
This is already a pretty strong indicator that something is wrong, let’s see what else we can find.
Step 2 — Search it on AlienVault OTX
This provides us with another hit for Cobalt Strike, it will also give you 2 URLs and the associated sample.
Step 3 — Extract beacons
At this point you have several options, either you extract the sample and run it in Triage or VirusTotal. Or you can try to extract the beacon configuration from the C2 server with CobaltStrikeParser. The latter is of course more fun so we will do that.
parse_beacon_config.py https://121.41.101.90
And here we have the details from the beacon using this we can either investigate the source system for presence of the process. We can also perform additional searches for the C2 url to identify other systems that are communicating to Cobalt Strike.
Summary
In this post we have described what Cobalt Strike is and how it’s used in attacks. As an incident responder or analyst, there are multiple websites such as AlienVault OTX and VirusTotal to identify Cobalt Strike servers. You can use these during an IR engagement to enrich your indicators. Additionally, you can extract beacon configuration files either through automated analysis with Triage or by using an external script like CobaltStrikeParser.
In the next post we will analyse host based Cobalt Strike components.
References & Resources:
- https://www.recordedfuture.com/cobalt-strike-servers/
- https://www.sekoia.io/en/hunting-and-detecting-cobalt-strike/
- https://s3.amazonaws.com/talos-intelligence-site/production/document_files/files/000/095/031/original/Talos_Cobalt_Strike.pdf?1600694964
- https://posts.specterops.io/a-deep-dive-into-cobalt-strike-malleable-c2-6660e33b0e0b