In this mini-post, we’re going to look at how to easily bypass network detections for Cobalt Strike beacons. Many AV products like Symantec Endpoint Protection (SEP) have network detection capabilities that monitor traffic passing through a device’s network interface. Additionally IDS and IPS also have basic detections for C2 traffic. These detections are basically looking for specific patterns in network packets.
For popular tools like Cobalt Strike the basic “out-of-the-box” settings for Beacons are fingerprinted by vendors, and therefore going to be detected.
In Cobalt Strike, Malleable profiles are used to define settings for the C2. You have a choice of different protocols for your C2 with HTTP, HTTPS and DNS being three popular ones. HTTP Beacons are easily detectable, due to the payload being unencrypted. For HTTPS connections, detections occur on the certificate used for encryption.
Like with any exploitation tool, if you use the default values it’s likely you’ll be detected. There are Malleable profiles available on GitHub which can be used and these will change your C2 settings from the default. However, these have also been fingerprinted, and will also generate a detection. The profiles available on GitHub are more aimed at testing your detection capability of different APTs and CrimeWare C2s seen in the wild in the past.
The Solution
Luckily Cobalt Strike Malleable C2 profiles are highly customisable. In fact, customisation is one of the reasons why Cobalt Strike is so popular and also so effective. You could write your own profile and there are some guides online that show you how to do this.
However, there is an easier way, C2 Concealer. The tool, created by FortyNorth Security, was released last year and features a Python Script which will generate a C2 Profile based on a few variables defined by the user.
Demo
Installation is easy, just clone the GitHub repo, and run the install script.
Once the install is complete, run the script and define a hostname you wish to use.
C2concealer --hostname newtpaul.com --variant 1
Next, C2Concealer will scan your host to locate where c2lint is located. C2lint is a tool included with CobaltStrike which is used to test/troubleshoot profiles before they’re used.
Once the scanning is finished, you’ll be asked to choose an SSL option. Using a legit LetsEncrypt cert is obviously going to be the most effective at avoiding detection. However, that requires you to point the A record at your team sever. For the purposes of this, we’ll just use a self-signed cert.
You’ll be asked to fill out some basic information for the cert. It doesn’t matter too much what you put here.
Once it’s complete you should receive confirmation that the profile has passed the c2lint check. The name of the newly created profile will also be displayed.
Next, launch your team server, but this time defining the profile to load.
Generate a new listener and a new payload of your choice.
Before VS After
Before using our newly created profile, SEP blocked outbound connections to our Cobalt Strike team server. This was when using just the default C2 profile.
However, after using our newly created profile, nothing was blocked and we were able to successfully establish a C2.
Conclusion
And that brings this quick post to an end. I hope you found it useful! You can read a previous post I wrote on Cobalt Strike here.
In this post, we’re going to take a look at Volatility 3, the newest version of the industries most popular memory forensics tool (within the open-source community at least).
We have a memory dump from an infected host that we’re going to look at and compare how the newest version of the tool performs as opposed to volatility 2. Let’s get started!
Install Volatility
Firstly we need to install a couple of dependencies, Python3 and Pefile. I’ve installed Python 3.8.6 from here.
When installing Python, make sure you tick the box “Add Python 3.8 to PATH” if you do not want to add the PATH manually.
Follow the default instructions to complete the installation.
Next, we need to install PEFile. I installed PEFile using pip.
pip install pefile
I installed version 2019.4.18 which you can find here.
These are the only two “required” dependencies that volatility requires, so we can now move on to install volatility.
I used git to download volatility, you can download git from here if you do not already have it installed. Once installed, launch Git Bash and run the command
The package should be cloned into a folder called volatility 3, which by default will be located in your user folder. So in my case, it’s C:\Users\paul\volatility3
We can now check if volatility has been installed properly by navigating to our volatility3 folder in CMD and running the command.
python vol.py -h
If all has gone right, we should see an output like the following:
This means that we’re now ready to use volatility to analyse our memory dump.
Using Volatility
Anyone who like myself is used to using Volatility 2 will notice that there are immediately some obvious changes with Volatility 3. Firstly, profiles are gone so you no longer have to scan a memory dump to find out which OS profile it’s compatible with. YAY 🙂
The way in which plugins are called in the command line is also slightly different. For example, if we want to run the plugin pslist to display the running processes in a memory image, we would do so by specifying the plugin name windows.pslist.PsList
Let’s give that a try now!
Top Tip: It’s good practice to record the output of volatility into txt files. That way we can easily go back and read through the results instead of having to try and read everything via the command line. I’ve created a new folder called evidence, and the results from each plugin run will be written to txt files in there.
To run the pslist plugin we’re going to run the following command:
Let’s break this command down to understand what it’s doing. Firstly, we’re telling Python to run our volatility script called vol.py. Then we’re using the -f flag to specify the location of our memory dump file. Next, we’re specifying the name of the plugin we want to run, and finally, we’re using the > flag to say that we want the results to be written out to a txt file called pslist which will be written to our evidence folder.
This is the basic command line format that we’re going to need to use for most plugins. Let’s go ahead and run some of the core plugins to gather some basic information. We’re going to run:
pslist – gives us a list of running processes.
pstree – gives us the same information as pslist, however, displays the output in a process tree so we can see child and parent process relationships.
netscan – gives us open network connections.
Processes
If we look at the output from running pslist below, there are a couple of processes that catch my eye, firstly Microsoft Word. As we know, Microsoft Office applications like Word and Excel are commonly used to distribute malware usually by using a malicious macro or embedded file. The Emotet campaign is particularly well known for using these methods.
The other application that catches my eye is fphc.exe. This is not an application that I am familiar with and does not look to be a Windows application. Basically, it looks weird.
Running pstree does not give us anything else of interest. WinWord.exe has a parent of explorer.exe which is to be expected. While our other application of interest, fphc.exe has a Parent Process ID (PPID) of 5668. However, there is no application that has this PID in the recorded pslist output. This likely means that our fphc.exe is an orphan process.
We can perform basic OSINT on the IPs returned below using tools like VirusTotal. Many of the IP addresses appear to belong to Microsoft, specifically Azure.
When searching on the Microsft IP addresses, none of them returns any “detection” hits. However, if we look in the “relations” tabs and look at communicating files, we can see many hits on malicious word documents that have called out to some of the IPs we’ve seen. If we draw a threat graph, like the one below, we can see an example of a malicious document that has been associated with the Microsoft IP 52.114.132.91.
It can often be difficult to determine if connections to cloud services like Azure and AWS are malicious or not, due to the fact that IP addresses are shared and reused by different users. It’s a good place for malware authors to hide their attack infrastructure and attempt to blend in with legitimate traffic.
Aside from the Microsoft IP addresses, there were also two other addresses from netscan which are of significant interest.
62.108.35.36 185.99.2.123
Both of these addresses returned detection hits on VirusTotal. Additional OSINT links both of these IP to TrickBot infrastructure. TrickBot is a well-known banking trojan that has been around for several years now. It is commonly distributed via Emotet.
Digging Deeper
We’ve seen a few things now which make us suspect that TrickBot malware has been delivered onto the host via an Emotet. Now we need to try and confirm that this is what has occurred.
Firstly let’s look to see if PowerShell was used by a Macro to download malware as can commonly be the case. We can use the command cmdline to list process command line arguments.
Unfortunately, there were no interesting PowerShell commands in the results. In Volatility 2, we had the option to use the plugins “cmdscan” and “console” as well as the third-party plugins which try to locate interesting Powershell activity in memory. We’re a little more limited with Volatility 3 as we only have the “cmdline” command.
However, cmdline still did return some useful pieces of informatiuon.
We have the name of the Word Document that was opened by the user:
In volatility 2, we were able to use the “dumpfiles” plugin to dump files from memory. However, that seems to no longer be an option in Volatility 3. We can, however, dump a running process by using the pslist command with a dump flag. Using the command below we can dump fphc.exe to analyse.
We still need to obtain the Word Document, but this is going to be difficult without being able to dump individual files. What we could do is dump the WinWord.exe process and try to carve the file out. This is a lot of effort though for what is likely to be commodity malware. So instead we’re going to cheat and just pull the file directory from the host now that we know the path that it’s located in. You could also do OSINT on the filename and try to find a copy on VT or AnyRun to download.
Emotet Analysis
As expected, the document contained a malicious VBS macro, which launches PowerShell with a base64 encoded command. I used CyberChef to decode the text from Base64 and also decoded the text from UTF-16LE (1200). Below we have the obfuscated PowerShell command:
I performed some basic deobfuscation of the code, which I’m not going to go into in this post. I have written how to deobfuscate Emotet Powershell in a previous post here.
Below is a rough deobfuscation of the PowerShell. We can see the script tries to download the file I3d47K.exe into the user’s directory from one of the URLs contained in the site list. A check of the file size of the downloaded file is performed to ensure that the file was properly downloaded, and if it passes that check, the file is then executed.
It’s interesting that we have not seen any sign of the executable I3d47k.exe within any of our Volatility outputs. It’s likely that this executable either drops fphc.exe or is renamed to this.
Executable Analysis
OSINT on our dumped application fphc.exe identifies it as Emotet, as expected. Dynamic analysis on the executable however has shown that it fails to execute properly. We see werfault.exe executed as a result of the application crash. It is possible for malware like TrickBot and Emotet to inject into WerFault. However, when this happens the command line for the process is usually empty, but in our case, we have flags being parsed. Additionally, we’re presented with a crash error, and there is no other typical Emotet activity.
There are a few reasons as to why the malware is not executing properly and the most likely is due to an error when dumping it from memory.
Review of Volatility 3
We’ve been able to build a rough picture of what has occurred on the host, but our analysis is not as complete as I would like. In forensics, you aim to build as clear a picture as possible, and in this case, there are definitely some gaps in our timeline of what’s happened. There was some information missing from our evidence collected with Volatility, but this can often occur in memory forensics as the data we’re dealing with is…..volatile.
The lack of plugins for Vol 3 is something that makes me still favour Vol 2. This will change over time though. As the tool is adopted more widespread, additional plugins will be developed. The Volatility Foundation’s annual plugin competition will from this year be focused on Volatility 3, and with official support for Volatility 2 ending in 2021, it’s only a matter of time before more users move to the newer version and the tool improves.
The two main things that Volatility 3 has going for it is its speed (it’s a huge improvement on Vol 2) and that it is now easier for developers to use the codebase to develop new plugins. The move away from OS profiles is also a welcome addition, as is it’s support for a larger variety of OS versions.
Volatility 3 Plugins
Here’s a list of the different Volatility 3 Plugins for Windows. Don’t forget there are also Mac and Linux plugins too.
