Carbon Black

I was recently afforded an opportunity to download and install the Carbon Black (Cb) standalone server; for testing purposes, I installed it on a Windows 7 host system, and got it up and running right away. 

If you're not aware, Cb is a small sensor that you can load on a Windows system, and it monitors executables being launched.   When a new process is started, information about that process is monitored by the sensor, and sent to the server for correlation and presentation.  The server can be maintained by the Kyrus guys, or it can be maintained within your infrastructure.  If you choose to maintain the server yourself, that's fine...it just means that you're going to need to have someone work with the tool, get familiar with it, and monitor it.

Getting Cb set up is easy.  The process of generating a license and getting the necessary sensor from the guys at Kyrus was simple, straightforward, and very quick.  From there, I rolled out the first sensor to a Windows XP VM that I set up as a guest on the Windows 7 host system via VMPlayer.  Shortly after installing the sensor on the target system, I began seeing events populating the dashboard, just like what I saw in the demo I attended in July.  I even began doing things on the system that one might expect to see being done during the recon phase of an incident, such as running some native tools to start mapping the network just a bit.  My "infrastructure" is a bit limited, but I got to see the Cb functionality first hand.

It's clear that a great deal of thought and effort has gone into the creating Cb, as well as structuring the interface, which is accessible via a browser.  I found that the interface and functionality is far more intuitive that other, similar tools I've seen, and in very short order, I was able to narrow down the information I wanted, based on my experience as an incident responder.

That's another thing I like about Cb...I can use the experience I've developed as an incident responder to get timely answers, and I don't have to learn someone else's framework or methodology.  For example, I look at the dashboard and see a "suspicious" process...in this case, I'd run "ipconfig /all" on the XP VM system...and all I have to do is click on an icon to see the parent process (in this case, cmd.exe).  I could also see loaded modules and files that had been modified.  I could even get a copy of the new executable that was 'seen' by the sensor.  Future enhancements to the sensor include monitoring of network connections and Registry keys.

All of this is very reminiscent of the demo...consider a "normal" incident involving a browser drive-by or some phishing attack against an employee.  Having Cb installed before an incident is the key, as it would allow a responder to very quickly navigate through the interface and once a suspicious process is located (based on a time hack, process name, or in the near future, network connection...), the responder can quickly identify the parent process or any child processes.  So why is this so special?  Well, most times for me, as a responder, I don't get called until after an incident occurs...which means processes have long since run and exited, and there may even have been efforts to clean up (ie, files deleted, etc.).  However, with Cb, there would still be a history of process execution, copies of the EXEs, etc.  In the case of July's demo, there were three stages to the attack, the first two of which launched and exited once their work was complete.  Further, of the three EXEs, AV detection of each was spotty, at best.

Having something like Cb deployed in your environment before an incident occurs is really the best way to approach not just using tools like this, but incident response in general.  In addition, Cb has a range of other uses...just ask the Kyrus guys for their case studies and stories, particularly the one about the CIO who used Cb to save thousands of dollars on Office licenses, based on actual, hard data (Deming, anyone?).

Cb is also a valuable tool to deploy during an incident...it's like sending out a bunch of lightweight little LP/OPs (listening or observation posts) to cast a wide net for data collection and correlation.  Under normal conditions, responders need to start taking systems down or performing live acquisitions, and then start analyzing those acquisitions, along with log files, network captures, etc., in order to begin scoping the incident and identify other systems that need to be acquired and analyzed.  Deploying Cb could (depending upon the type of incident) provide more information in a quicker manner, and require fewer resources (ie, fewer analysts/responders to send on-site, pay for travel, lodging, etc.), and reduce the overall impact on your infrastructure.  Deploying Cb in conjunction with F-Response would REALLY up your game to a whole new level.

Carbon Black is a tool that should be in your arsenal, as it changes the dynamics of incident response, in favor of the targets and responders, and takes away a lot of the advantages currently enjoyed by intruders.  If you have an infrastructure of any size, you should be calling the Kyrus guys.  It's not just large infrastructures that are being targeted...don't believe me?  Spend a rainy Sunday reading through Brian Krebs' blog, and then, if you can stop crying, look me straight in the eye and tell me sincerely that you're below the bad guy's radar.

In my experience as a responder, when a call came in, we'd start collecting information, not only about the incident, but we'd also have to get information from the customer that we'd use to populate the contract, so we'd have a couple of things going on in parallel.  Even so, it would still take us some time to get on-site (6 hrs, sometimes out to 3 or more days...), and then we'd have to start collecting data.  Even though we'd asked for network device and firewall logs to be collected, in some cases, it was only as a result of the incident itself that the customer found out that, "hey, wait a minute, what do you mean we aren't logging on the firewall (or web server)?"  I've had only one instance where I showed up and some data had actually been collected...in every other instance, when an incident occurred, the customer was completely unprepared and we didn't start collecting data until someone got on-site. 

Think about that, as well as any other incidents you may have encountered, for just a moment.  Now, imagine what it would be like if the customer who called you already had a contract and a relationship in place, and you'd helped them install Cb.  With the contract already set up, that's one thing you don't have to deal with...and with Cb rolled out, data is already being collected.  So, while they're on the phone, you can begin to assist them, or you could VPN into their infrastructure and access the Cb server yourself.  If a team needs to be deployed to assist, then you're already collecting information (if you have F-Response rolled out or the local IT staff has the training, memory and images may also be collected) even before the responders are able to get airline tickets!

Cb is like Burger King for IR...have it your way!