Carbon Black

I attended a Carbon Black (Cb) demo recently, at the invitation of the great folks of Kyrus.  The demo was intended to show some of the improvements to Cb, in particular the GUI available to quickly and easily mine through the available logs.

For those of you who haven’t heard of Cb…where’ve ya been???  Cb is a sensor that monitors the execution process on Windows systems, and reports on processes and file writes.  A coming update to Cb will also report on writes to the Registry, as well as network connections (source/dest IPs and ports, with a time stamp).

In the demo, Mike Viscuso demonstrated how the GUI can be used to quickly track down a FakeRean installation, and even track it back to an a Java “issue” (more analysis would be needed to determine if it were an exploit) delivered via Firefox.  Mike when through this slowly, and had he gone through this full speed, it would have only taken a couple of seconds.  In the demo, Mike identified three stages of the infection, and identified the executable files associated with each.  The first stage executable was identified by 14 of 42 AV engines on VirusTotal (for each stage, Mike submitted the hash of the file, not the file itself).  The second stage executable was not identified by any of the AV engines, and in fact was reported to not have been previously submitted.  Finally, the third stage executable was identified by 5 of 42 AV engines.

Now, compare that to the “normal” IR approach, and how long it would take to dump memory from that system…and this is assuming that you’ve got your IR toolkit prepped and ready to go, and you have personnel trained in the proper collection and analysis techniques.  How about obtaining a copy of the executable?  Cb does this for you; the traditional approach to doing this could take several hours, under the best conditions.

Finally, Mike could have issued a query to determine if the particular files in question had been “seen” on any other systems in the enterprise, an answer to which would be available within seconds.

Deployment, or “How this beats the current IR model”

The current model used for IR is that someone gets hacked or hit with malware of some kind and calls for help, or someone gets notified by an external third party that their data has been compromised (see annual reports from Verizon, TrustWave, or Mandiant) and calls for help.  Sometime after that, personnel and/or equipment are sent on-site, and all the while, data may continue to be exfiltrated from the infrastructure.  At some point after the call for help, network and host data, and possibly the contents of memory from hosts may be collected and analyzed…all of which takes considerable time.

Now, what if you deploy Cb before an incident?  If you were to do this, starting with a testbed of systems, and possibly some non-production systems, you could monitor that subset of your infrastructure, and once you become familiar and comfortable with the tool (check with Kyrus for licensing to get the log collection server within your infrastructure), progressively roll the sensor out to more systems.  Once you get Cb rolled out and the server installed, it’s simply a matter of reviewing the data.   Should you suspect that something has occurred, you now have considerable, albeit easily managed and viewed data available.  You can even set up a scheduled task on the server that queries for new executables having been launched, and have this task run every day (or even six hours).  You may initially get a lot of data, but over time, you’ll notice that the set that you receive back should be reduced.  You can even have the task email the list of new executables to you.

Now, even if you were to query the logs every 24 hrs (via a scheduled task or manually), the fact is that you’d know about the incident within 24 hrs (at the most), rather than hearing about it 3 months later from someone else.  Since many of these notifications come well after the actual data theft occurred, when deployed proactively, Cb is capable of providing a level of context that simply isn’t evident or available via more traditional means of IR, such as memory or even disk analysis.  Further, once something is “seen”, you can query the infrastructure for other affected systems, quickly scoping your incident.  Again, through traditional means of IR, scoping the incident can often take considerable time and be very expensive (in time, money, resources, etc.) to the already-compromised environment.

And Cb answers more than just questions related to security and IR.   One of the use cases that the Kyrus guys like to use involves addressing budgeting issues, and going out across the enterprise to determine how many employees were running all components of an office suite of tools.  With the returned information, the organization was able to drastically reduce licensing costs.  Cb can also be used to enforce acceptable use policies, among other things.

If you haven't done so, I'd recommend taking a look at Cb...it doesn't have huge overhead or a "big" footprint, and what it can save you in terms of much more than just IR and security is immense.