I am frequently asked to give the “elevator pitch” for the Carbon Black security solution. When speaking to someone who is technical and familiar with Windows, my response is heavily dependent on comparisons with SysInternals tools.
The SysInternals tools are a neat set of Windows utilities from Microsoft. Although the tools are now distributed by Microsoft, most came from Winternals, a 2006 acquisition that brought Mark Russinovich to Microsoft. They are used by system administrators, forensic engineers, developers and many others that need a “under the hood” peek into Windows.
So, back to the elevator pitch. In a sentence, Carbon Black is a “Distributed Process Monitor.” Let’s break that down:
“ProcMon” is the flagship SysInternals utility that combines the legacy RegMon and FileMon utilities and then adds more. It captures activity on a Windows system, including process creation and termination, file IO activity, registry activity, module (such as DLL) load, and network activity. It then ties all activity to individual processes.
Like ProcMon, Carbon Black captures detailed activity on a computer and ties the activity to specific processes.
As for the “Distributed” part, Carbon Black is meant to be deployed on a network. The Carbon Black “sensor”—lightweight Windows data capture utility—captures events similar to ProcMon. Rather than logging or displaying locally, Carbon Black pushes the events to the Carbon Black Enterprise Server, where it is indexed, stored and made accessible via a Web UI.
Carbon Black one-ups ProcMon by aggregating the captured data from thousands of Windows hosts into a single queryable data store.
Because the Carbon Black sensor is always on and always collecting, there are broad ramifications to how the data can be used. For example, if an analysis of firewall logs turns up something suspicious from three days ago, a Carbon Black query can determine the responsible host, process and all other activity from that process. The network connection can now be placed in context, and the processes activity around the network connection can be used to provide more detail.
Cb In Action
Enough talking…let’s see some screenshots. The following screenshots are of the Carbon Black Web UI and trace the execution of Process Monitor. One of the neat things about Process Monitor is its single executable for both x64 and x86 systems. With Carbon Black, we can watch how Process Monitor performs this magic.
The first step is to target our search. In this case, we have a file name, so it’s easy. We search for all processes named procmon.exe:
Autocomplete does most of the work for us, although I could have just typed “procmon.exe.” The search results show a list of processes named procmon.exe:
In this case, you can see four processes—two from my dev box (SDL-DEV) when I was preparing the draft of this post, and two as I finalize it. Clicking the top, most recent, result takes us to the Carbon Black Process Analysis page. This shows a “tree view” of the process hierarchy, process metadata and detailed process activity. The process activity is similar to the Process Monitor results. The screenshot below are close-ups of the key elements from the process analysis page:
This was on my x64 system. The top-left element is the process tree, and shows the procmon.exe process with a child process named procmon64.exe. That explains how a single procmon executable runs on both x64 and x86 architectures—it’s actually two executables. But how did procmon64.exe get there? The answer is in the process activity list, the right-central pane. Highlighted in red, it shows that procmon.exe recognized it was on an x64 system, created a new file called procmon64.exe in the temp directory, then executed it. (It also shows the MD5 hash of the file: b0a3ecc9eaa2521ddea2fc067785b84e.) Everything else happened in the procmon64.exe process.
By clicking on that node in the tree, CB brings up the collected data for procmon64.exe.
It lists four file operations: procmon64.exe creates c:\windows\system32\drivers\procmon23.sys, writes to it, completes the write with a final MD5 of 21bdf404d829667477160f3942f7159a, and deletes the file:
When Windows loads a device driver, it immediately makes a copy of all the data it requires in kernel memory. It therefore does not block the file from being deleted. ProcMon takes advantage of this fact by deleting the driver file from disk as soon as the driver is loaded, rather than risk leaving it around should the system shutdown unexpectedly.
Let’s follow this trail one step deeper by clicking the MD5 and bringing up the Carbon Black “binary view” page:
The binary detail page has version information, digital signature data, frequency information and a link to download a copy of the file itself. Most interesting for this discussion are the two links highlighted: the first to find processes that wrote a file with this MD5, the second to find processes that loaded binaries with this md5.
The “Find related »” link, retrieves a list of processes that loaded a binary with this md5:
The match on ntoskrnl.exe is expected, as drivers are loaded into the context of the “system” process:
To sum it up—we used Carbon Black to monitor Process Monitor. In doing so, we learned that Process Monitor—running as procmon.exe—extracts a 64 bit executable called procmon64.exe to the temporary directory and executes it. That executable, in turn, extracts a driver named procmon23.sys to the system32\drivers directory, loads it into the kernel, and then deletes the file.
In the case of Process Monitor, we are watching a very useful utility do its work. Tellingly, malicious software often follows the same general pattern—run, drop another payload to disk, execute that, drop a driver file to disk, load it, delete it, etc. With Carbon Black, we can not only observe that pattern shortly after it occurs, but perform the analysis days, weeks or even months later, if necessary, and easily take the resultant indicators of compromise and search for them across the entire network.