This is the third and final part of our blog series on Cobalt Strike attacks and Incident Response. We suggest you first read Part I and Part II, to understand how Cobalt Strike works and how to analyse a Cobalt Strike executable during an incident response case.
Analysis of in-memory Cobalt Strike payloads
As described in the earlier parts a big part of why Cobalt Strike is so successful is the fact that Cobalt Strike allows for attacks that leave little to no traces on disk. A lot of endpoint security products miss attacks that are performed in memory-only and that built-in capability is one often used by threat actors. One of the most popular attack vectors is using Powershell to inject Cobalt Strike directly into memory. The DFIR Report has a nice write-up on exactly this topic, read it here. In this section we will discuss the response options you have when faced with an in-memory Cobalt Strike payload.
Memory analysis
There are a few options for memory analysis depending on the data available during an incident response. Broadly speaking there are two options for memory analysis:
- Memory analysis on a full memory image
- Analysis of a process dump
If you’re working on an engagement where your client is using a virtualised environment grabbing a memory image can be as easy as navigating to the file storage for the virtual environment and copying the memory file. However, sometimes it might be more difficult and you need to manually create an image. Acquisition of volatile memory is out of scope for this series, there are lots of great resources that cover that topic. We will assume you have successfully acquired a memory or process dump. So what’s next? We created a little mindmap to help you investigate the memory of a machine that is suspected to be infected with Cobalt Strike please see below:
The first method is investigating the full memory image. Our preferred method is loading in the memory with Volatility an (awesome) open-source framework for memory analysis. Volatility works with plugins to carry out analysis tasks, if you never used it start with the official documentation. For now we will focus on several plugins that have proven to be useful for identifying in-memory Cobalt Strike attacks.
Process analysis
Starting with psscan, this plugin scans the this plugin scans the memory for the presence of process headers. This plugin can also find terminated and/or hidden processes. With this plugin you can search for processes that contain Cobalt Strike based on an unexpected parent/child relationship. The second plugin we wanted to highlight is pstree, this one helps you understand the relationship between various processes. The last one related to processes is cmdscan this plugin shows you the command line that was used to launch a process. As a little exercise, below a screenshot with the output of the pstree plugin, what stands out to you? Comment below with your answer.
Network activity analysis
Another method to identify Cobalt Strike attacks from a memory image perspective is analysis of established outgoing connections. Cobalt Strike is often injected in default Windows processes to avoid detection such as svchost.exe, however how often do you see these processes making external connections? The answer is you should not see that very often. With the netscan plugin you can easily spot what processes are performing external connections and over which ports.
See the example below, there is an active Cobalt Strike beacon connection, can you find it?
Other plugins
The malfind plugin is useful for detecting malware in a memory image. The malfind command helps find hidden or injected code/DLLs in user mode memory, based on characteristics such as VAD tag and page permissions. This plugin shows you the processes that might have been injected, further analysis is required.
The cmdscan plugin is interesting, because it contains the command line that was used to start a process. Below you’ll find the output of running the cmdscan plugin. Pay close attention to the Powershell process, does something stand out?
Last but not least the Japanese Computer Emergency Response Team (JPCERT) developed a set of Volatility plugins (cobaltstrikescan & cobaltstrikeconfig) specifically for detecting Cobalt Strike, read the blog here.
Tip: The cobaltstrikescan & cobaltsrikeconfig will only work with the 2.x version of Volatility.
For our second scenario, we don’t have access to a full memory image, however we can still investigate the process dump. There are a lot of options to pick from if you want to create a process dump:
- Procdump from Sysinternals
- Process Explorer from Systinternals
- Process Hacker by Wen Jia Liu and Steven G
- Windows Task Manager, right click on a process and select ‘Create dump file’
For manual analysis of a process dump you can use a debugger. For Windows the one we recommend is x64dbg or Windbg, there is an excellent presentation on Windbg by SANS up on their YouTube. As an incident responder you are mainly interested in getting Indicators Of Compromise (IOC) related to the Cobalt Strike beacon. Therefore, we don’t have to manually analyse the dumps ourselves, rather we scan the process dump for the Cobalt Strike beacon configurations.
To showcase this ability we run Cobalt Strike on a test system, dump the process memory of the Cobalt Strike process and analyse that dump with the SentinelOne Cobalt Strike parser.
In the first step we will infect a virtual machine with Cobalt Strike for this task we leverage one of the public samples of Cobalt Strike(cs.exe) with SHA1 hash:
18bab8808b10f188f20999b8184755270696ab0f
Next we will dump the process memory with Process Hacker and save it on the desktop for further analysis. Please see the video below that shows the infection with Cobalt Strike and the creation of the process dump with Process Hacker.
Next we open the process dump with the Cobalt Strike Parser and point it to the process dump as shown in the video below.
Bonus question: The sample used a ‘known’ malleable C2 configuration, can you find the GitHub where it was collected from? Post it in the comments below.
In this section of the post, we have shown two different methods for analysing live systems infected with Cobalt Strike, method one using a full memory image or method two using a process dump. Memory analysis is one of the most powerful capabilities in your incident response arsenal use it when you can!
Wrap up
It could be a coincidence, but in the past few weeks during the writing and release of this series a lot of additional resources on Cobalt Strike detection have come to light, which is awesome. Before we dive into some of our favourite resources, we have also created a mindmap that you can use for Cobalt Strike investigations. The goal of this mindmap is to help you decide during an investigation what you can do. So let’s say you have a network indicator, you can go to that section in the mindmap and determine your next step. Any feedback on the mindmap is welcome, the source file is also available on our GitHub page.
Thank you for following this blog series and as always we love to hear your feedback, don’t hesitate to comment or reach out.
Resources
The following resources have been very helpful during the creation of this blog series:
- https://thedfirreport.com/2021/08/29/cobalt-strike-a-defenders-guide/
- https://github.com/Te-k/cobaltstrike
- https://github.com/RomanEmelyanov/CobaltStrikeForensic
- https://go.recordedfuture.com/hubfs/reports/mtp-2021-0914.pdf
- https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html
- https://github.com/MichaelKoczwara/Awesome-CobaltStrike-Defence
If we have missed links, citations that you think should be in here, please let us know and we will correct accordingly.