In my previous post, I demonstrated a few simple ways a user can take advantage of the built-in utilities in Windows to perform a high-level-malware investigation. In this post, we will examine a specific sample of this malware using Carbon Black.
For this analysis I executed the sample above on a Windows 7 host. The Windows system was fully up-to-date on patches (as of 05/30/2014) and I intentionally ran only Carbon Black on this host.
Where do we start?
In this scenario we have the advantage of knowing when the malware was detonated and on what system. In a real-world scenario we might not have that information and would need to find malware. To make this more realistic, I will not leverage my prior knowledge of this malware to investigate it with Carbon Black.
So, where do we start and how do we find this malware on this system?
The first thing I did after installing the Carbon Black server was enable watchlists under the alliance feeds administrative option. I won’t delve into the setup of this application too deeply because this is an investigation, not a product demo. With watchlists enabled and the sensor installed on the win7 client, I detonate the Bitcoin malware.
Next, I switch to the Carbon Black console tab “watchlists” and look for any hits.
Right away I can see five matches for files in my environment that have a VirusTotal rating of four or more. These files are:
Seen as: coinutil.dll 19 minutes ago
Signature: Unsigned Company: Ufasoft
Size: 29 KB
VirusTotal Hits: 12
Seen as: miner.dll 19 minutes ago
Signature: Unsigned Company: Ufasoft
Size: 335.5 KB
VirusTotal Hits: 18
Seen as: usft_ext.dll 19 minutes ago
Signature: Unsigned Company: Ufasoft
Size: 850 KB
VirusTotal Hits: 15
Seen as: shell.exe 19 minutes ago
Signature: Unsigned Company: Systemt
Size: 54.5 KB
VirusTotal Hits: 33
94fe198e4614bec6233585d518adde34a01dc0a35c7115c79532564b9e0e4080.bin 19 minutes ago
Size: 900.07 KB
VirusTotal Hits: 26
Drilling into process execution chains
Immediately, my eyes are drawn to the last two files in this view because they have more than 25 hits from VT. Let’s click on this bottom one and see what we learn about it.
From the Carbon Black process analysis of the file “94fe198e4614bec6233585d518adde34a01dc0a35c7115c79532564b9e0e4080.bin” we are able to see the spawn of :
If we then drill into each of these child processes we can see that “csscript.exe” spawned three processes.
Cscript.exe shows us that it spawned:
This visualization of the execution chain gives us a very quick and easy view of this binary we are investigating spawning another of the processes that came up in the VT watchlist search, “shell.exe”. This leads me to believe from the evidence shown so far that “94fe198e4614bec6233585d518adde34a01dc0a35c7115c79532564b9e0e4080.bin” and “shell.exe” are at least related, if not also malicious, and that the bin file is the parent process that created “shell.exe.”
Drilling into process analysis
Since this bin file seems to have started the trouble, let’s look a bit closer at it. Since the page that drills down into this process has a bunch of information on it, I have broken it up below for easy digestion in this blog post.
Below, we can see a bunch of useful expected file information about the process we are analyzing. We have its hash; we have the first seen event, status, and a few other odds and ends about it. I mostly used this section to compare against timestamps of the other associated files to confirm this file came first and is most likely the catalyst binary.
Next, we can see something very important for any incident—scope. We can see that only one computer in our environment has this file on it and that VT has 26 hits for it.
Next we see that the file is a 32-bit binary with shared resources, the size of the file, and that observed path of the file. This path in this case shows the username of the user that executed the binary.
Last, but not least, we can see that this file is only observed on one host. This tells us that this incident is not part of a large-scale attack and is most likely either a targeted attack or just a one-off infection.
Now that we’ve seen what the file is, what did it do? This bin file’s behavior can be narrowed down to eight file creations, five registry modifications, and a handful of child processes spawned that will require further investigation.
According to the analysis page the above snippet is just the tip of the iceberg. There were 1805 file modifications, 63 module loads, four registry modifications, and two child processes spawned just from this file alone. These counts do not include everything done by the child processes spawned.
To find out what the child processes did, you simply have to choose that option under type and drill into the results.
If you continue to drill down into each child process, you will eventually get to the first diagram I displayed with the cscript.exe file running.
This is the process analysis of the script and you can see it showing the spawning of six child processes, two of which are on the VT watch list. Two file modifications are the file creation events for the fake skype.ink file.
The more we drill into each of these unique events, the more we can learn about the malware. This is a great feature of Carbon Black and extremely useful when trying to track down the flow of each execution and child processes.
Did it phone home? Was data exfiltrated?
Now that we have the binary that started all the fuss, let’s do some research on it. I click on the VirusTotal link from inside the Carbon Black console and see the output below.
Above you can see that 26 virus scanners confirm that this binary is malware and that most of them name it as something containing the word “Bitcoin,” “miner,” or “coin” in variations. This now leads us to what is a Bitcoin miner and a quick Google search will return most of what we posted in my first blog in this series.
Almost every description of a Bitcoin mining malware contains some discussion on how the malware talks to home. So did it talk to home? Did it just send information about the coins it mined or did it send back all of your browser’s saved passwords?
How do we know?
Easy. We use Carbon Black to look for network connections from the host in question, “Win7,” and any of the associated processes we found in the previous steps.
This narrow search returned zero results so I broadened the search to any network connections from the host “Win7.”
This wider search returned only one connection attempt. It is from ntoskrnl.exe and as you can see below, was from 172.16.233.1, which is the gateway address for my virtual network. This tells us that the malware did not phone home and no data was exfiltrated.
Now that we have completed the analysis into one binary, we can repeat this process for the other associated files found. Repeating this process for new files will help fill in any analysis gaps and solidify our incident scope as it both expands and contracts with each repetition.
Using Carbon Black really sped up that process, and that was just for one host. If I had 100 or more hosts, it is not only impractical to do the searching manually but next to impossible with time constraints. I would have to script the majority of that searching and basically create a poor imitation of Carbon Black. This would not give us the same level of visibility of Carbon Black nor would we have the drill-down effect of Carbon Black to lead us to associated processes easily.
The last thing I want to point out is that while we provide this enterprise intelligence to our users to make responding to incidents much faster, there’s a whole new realm of detection that is possible. By creating watchlists, we can detect and be alerted when these or similar behaviors occur. These watchlists can be customized for each environment.
For a few examples of watch lists, check out Ben Johnson’s blog “Screenshot Demo: Hunt ‘Evil’ Faster than Ever with Carbon Black.”
The final installment of the series will be a high-level walkthrough of stopping this malware leveraging the Bit9 Security Platform. Check back in to the Bit9 blog soon so you don’t miss it!