Hunting Cobalt Strike in Memory
I’ve been meaning to get back to writing for a while now and have finally been able to carve out some time for it, so hunting season is back!
The time has come to play with Cobalt Strike in my lab due to the number of security incidents in which it is used and how complex it is sometimes to investigate.
For those of you who don’t know about it, Cobalt Strike is an attack framework that allows anyone with $3500 to have an arsenal of really powerful offensive tools at their disposal.
It may seem like a lot of money, but for cybercriminals who have found in cybercrime a profitable business, it is not so much.
If we take a look at MITRE’s Cobalt Strike knowledge base, we will see how many advanced groups use this framework.
When faced with a challenge like this, there are many ways to deal with it and in this case, I have decided to focus this little research on detecting the Cobalt Strike agent by analyzing the memory of the compromised computer. I thought that this approach could be useful due to the large number of attacks that currently exist that avoid touching the disk during the infection process, but memory is impossible to avoid 😉
On the attack!!
For this example I have created an executable with Cobalt Strike in the Windows Executable mode, if you notice, without the option (S), this option would make the agent to be included in the executable. Both options have their advantages and disadvantages but in this case we will use the first one, the one that does not contain the agent and the one that will perform the download in memory of the agent.
As this article is not about attack but about detection, we skip the rest of the steps for the generation of the executable 😄.
Once we have executed the binary on our victim machine, we will see a process like this. With PID 420.
In order to have a sample as complete as possible, I am going to use two very useful attack techniques when it comes to evading both anti virus programs and to make manual analysis difficult for hunters like us.
These techniques are the “Parent Process ID Spoofing” and the “Process Hollowing”, in this article I tell you more about these techniques and possible ways of detection.
To do this, I will configure the Cobal Strike session so that the following processes running from the active session, are launched as children of the process “explorer.exe” and run within a process emptied from “iexplorer.exe”.
Once everything is configured, we launch a second malicious process, but this second one is a little more difficult to find than our “bicho_malo.exe”.
As you can see in the image, this process has the appearance of a legitimate Internet Explorer process and appears as a child process of Explorer, so everything leads you to believe that it is a process launched by the user and with PID 2852.
Memory extraction💻
For memory extraction I used “Magnet Ram Capturer”.
It is a free tool developed by the company Magnet and it works really well.
Although few sites talk about it, it is possible to run this tool from command line, very useful to perform memory captures in an automated way.
Memory analysis 🔎
The moment of truth has arrived. Although we know what we have to find, we are going to try to learn as much as possible in the process.
To perform the analysis we will use Volatility, both in its version 2 and in its most modern version, version 3.
For the analysis we will use several Volatility plugins that will be very useful.
Malfind — Volatility3 🐛
python .\vol.py -f C:\Users\user1\dump_cobalt.raw windows.malfind.Malfind | Select-String ".exe"This plugin is one of the most famous of Volatility and it is not for less. This plugin performs an automated analysis of the memory structure of the processes in search of anomalies that make them suspicious, such as, for example, when a process has a memory page marked as executable and modifiable.
As can be seen in the image, the plugin gives several false positives (which are practically always the same) but the important thing is that it is able to detect the two malicious processes that we had generated with PID 420 and 2852.
Netscan — Volatility3 📶
python .\vol.py -f C:\Users\user1\dump_cobalt.raw windows.netscan.NetScan | Select-String -pattern "Offset|ESTABLISHED"On this occasion, this plugin will help us to try to detect processes that have open connections. Although this behavior can be common in many processes, it can be a good approach since the connection with the command and control console is something that sooner or later almost all malicious processes need to do.
In the image we can see three “live” connections, two Microsoft IPs and a private IP which is the IP assigned to the attacking machine.
To check which process has established that connection, we will resort to another very useful plugin used by Yara.
YaraScan — Volatility
C:\Python27\python.exe .\vol.py yarascan -Y "192.168.129.131" -f C:\Users\user1\dump_cobalt.raw --profile=Win10x64_19041 | select-string "Owner" -Context 0,2For this example I will use Volatility2 since version 3 does not work as well as version 2, yet. This plugin allows us to use the power of Yara to identify strings in processes, in this case I will use it to search for processes containing the suspicious IP address returned by the NetScan pugin.
Analyzing the results, this plugin shows malicious processes, in which we can see parameters used by Cobalt Strike to connect to the command and control console, but there is also a false positive, “msedge.exe”.
his is because Microsoft browsers save all HTTP communications made by the computer, something a bit intrusive but very useful in forensic analysis 😃.
YaraScan II — Volatility
C:\Python27\python.exe .\vol.py yarascan -y D:\rules.yar -f C:\Users\user1\dump_cobalt.raw --profile=Win10x64_19041Due to the power of Yara, this plugin allows us to perform multiple approaches to malicious process detection using Yara rules.
For this second example, I am going to use the Yara rules created by Etienne Maynier which can be found on his Github 👏.
This researcher has created three Yara rules that allow to detect the Cobalt Strike agent in memory with very few false positives.
As can be seen in the image, these rules have detected the malicious process with which the “PPID Spoofing” and “Process Hollowing” techniques had been used, but not the initial process that generated the malicious binary with PID 420.
As the mission of this article is to detect Cobalt Strike in these two versions, we are going to try to modify the “CS_beacon” rule to detect both processes. To do this, I will use the Volaitlity3 plugin “PsList” to create a dump of the process memory.
python .\vol.py -f C:\Users\user1\dump_cobalt.raw windows.pslist.PsList --pid 420 --dumpThis plugin allows us to see some basic information of a process, but with the option “- -dump” allows us to generate a dump of the process memory for inspection 🔎.
Although to create a Yara rule from a binary you can use the linux “strings” tool, this time I am going to use an essential tool in any analyst’s computer, PeStudio from Winitor.
If we look at the first result, there is a text string that is “\\.\pipe\MSSE-8093-server”, this is one of the signs of identity in the Cobalt Strike binaries since it fulfills one of the patterns used by the program by default.
Here is a link to an article written in the Cobalt Strike blog talking about the patterns in the names of the default “Named Pipes”. This information is very valuable to be able to generate a new Yara rule very useful when the attacker has not modified the configuration.
//"\\.\pipe\MSSE-"
$p1 = {5c 5c 2e 5c 70 69 70 65 5c 4d 53 53 45 2d}
//"\\.\pipe\status_"
$p2 = {5c 5c 2e 5c 70 69 70 65 5c 73 74 61 74 75 73 5f}
//"\pipe\msagent_"
$p3 = {5c 70 69 70 65 5c 6d 73 61 67 65 6e 74 5f}
//"\\.\pipe\postex_"
$p4 = {5c 5c 2e 5c 70 69 70 65 5c 70 6f 73 74 65 78 5f}When these lines are added to the Yara rule created by Etienne Maynier, we get our desired result, detecting both malicious processes, with the false positive of “MsMpEng.exe” which is the Windows Defender process and which has rules very similar to these for the detection of Cobalt Strike.
Once we have tested the Yara rule in our team, I recommend testing it against public databases to check if they are well debugged.
Hybrid Analysis offers the possibility to launch Yara rules against its database and thus be able to see for free artifacts that have matched our rule.
As you can see in the image, the rule has detected 41 files available with the free account and 1959 with the premium account.
Although the first results have not been detected by this sandbox during its static analysis, we can take the hash of the first result and look it up in Virus Total to make sure.
Indeed, when antivirus scan the behavior of this file it is detected as an agent of Cobalt Strike.
In future posts I will talk about the traces left by Cobalt Strike during its initial execution and during its actions such as lateral movements, elevation of privileges…
I hope you liked it and see you in the next one.
Happy hunting! 😃