Every now and again, I talk about incident preparation. For the most part, as a responder, this is something of a fantasy, because most folks that call people like me are simply not prepared for a computer security incident. However, every once in a while, responders do get a chance to work with a customer who was either prepared for an incident, or in the process of getting there, and it's a whole different world!
So when I talk about incident preparation, many times those things that I talk about, like network segmentation, VLANs, enabling more appropriate logging, etc., are all things that require a good bit of work because, to be honest, well, they do. They require changes to how the organization has been doing business for some time. However, many of the changes are just the first step; for example, increased logging requires additional storage space, as well as someone to collect and possibly even review the logs.
Well, the folks at Kyrus Technology have a solution called Carbon Black. Cool name, I know...but what is it? Here's a description from the FAQ:
Carbon Black is a software sensor we created that monitors key points on the operating system and gathers data that is useful to intrusion responders and system administrators for security and compliance functions.
Carbon Black is less than 100 KB and runs on 32- and 64-bit Windows systems, from XP through Windows 7. Given sufficient demand, Linux and OS X versions may be warranted in the future.
I've had an opportunity to install a standalone version of the sensor on a Windows XP SP3 VM, and so far, it's proven to be very valuable. The sensor monitors execution on systems, watching what's being run, and and logs this in a couple of different formats. The full version logs to a remote system, either within the organization's infrastructure or to a designated SOC. When a new executable is detected, CB will make a copy of it, which in itself is pretty cool. Right now, the sensor has execution monitoring, but an update due out on 4 April will include file system modifications, socket creation, and a new UI.
Another update planned for this summer will include monitoring for Registry modifications, as well as a schema and API.
So, what can you do with Carbon Black? Well, quite a bit...and not just IR. One of the case studies that the Kyrus guys have involves cost reduction by looking out across an enterprise to determine the overall use of an office suite of applications; by determining that not all of the applications included in the suite were being used by all employees, the CIO was able to reduce the license costs and save the organization a good bit of money.
But what does all this mean to IR? Well, CB is pretty lightweight...I'm running a standalone sensor in an XP SP 3 VM with 1GB RAM, and there are no noticeable hitches or slow downs. As an analyst, there are a number of places that I look on systems for information. For example, I will look to the Application Event Log for indications of running AV, and possibly any detections. However, Event Logs (particularly on XP and Windows 2003) tend to "roll over", so I will also look for the text-based AV logs on the system, which tend to contain more historical information. Sometimes, there is no AV installed on the system. Other times, I will find that the infrastructure has Process Tracking enabled, so I see the corresponding events in the Event Logs...most times, this isn't the case. Another option for getting some information about programs run on a system includes Prefetch files, but application prefetching is not enabled by default on Windows 2003 and 2008.
CB would be useful in a variety of environments. The first that comes to mind is a large data center; such systems usually have a small set of processes that actually run all the time on the servers, so finding new things being run on systems would, after a familiarization period, actually be pretty simple. Remember the Least Frequency of Occurrence? But this would also apply to SMB infrastructures; if you follow Brian Krebs blog at all, you likely have seen that a pretty significant number of SMBs have contacted him over the years to say that they got hit with Zeus and funds were stolen from their bank, transferred to money mules. While Carbon Black isn't a preventative measure (it doesn't block stuff), having something like this in place, reporting to a SOC would significantly improve detection, as well as response by law enforcement.
But again, Carbon Black isn't just about IR...IR is one of the uses of a sensor like this. If any of this sounds interesting to you at all, get in touch with the Kyrus guys and ask them about their case studies.
Carbon Black is less than 100 KB and runs on 32- and 64-bit Windows systems, from XP through Windows 7. Given sufficient demand, Linux and OS X versions may be warranted in the future.
I've had an opportunity to install a standalone version of the sensor on a Windows XP SP3 VM, and so far, it's proven to be very valuable. The sensor monitors execution on systems, watching what's being run, and and logs this in a couple of different formats. The full version logs to a remote system, either within the organization's infrastructure or to a designated SOC. When a new executable is detected, CB will make a copy of it, which in itself is pretty cool. Right now, the sensor has execution monitoring, but an update due out on 4 April will include file system modifications, socket creation, and a new UI.
Another update planned for this summer will include monitoring for Registry modifications, as well as a schema and API.
So, what can you do with Carbon Black? Well, quite a bit...and not just IR. One of the case studies that the Kyrus guys have involves cost reduction by looking out across an enterprise to determine the overall use of an office suite of applications; by determining that not all of the applications included in the suite were being used by all employees, the CIO was able to reduce the license costs and save the organization a good bit of money.
But what does all this mean to IR? Well, CB is pretty lightweight...I'm running a standalone sensor in an XP SP 3 VM with 1GB RAM, and there are no noticeable hitches or slow downs. As an analyst, there are a number of places that I look on systems for information. For example, I will look to the Application Event Log for indications of running AV, and possibly any detections. However, Event Logs (particularly on XP and Windows 2003) tend to "roll over", so I will also look for the text-based AV logs on the system, which tend to contain more historical information. Sometimes, there is no AV installed on the system. Other times, I will find that the infrastructure has Process Tracking enabled, so I see the corresponding events in the Event Logs...most times, this isn't the case. Another option for getting some information about programs run on a system includes Prefetch files, but application prefetching is not enabled by default on Windows 2003 and 2008.
CB would be useful in a variety of environments. The first that comes to mind is a large data center; such systems usually have a small set of processes that actually run all the time on the servers, so finding new things being run on systems would, after a familiarization period, actually be pretty simple. Remember the Least Frequency of Occurrence? But this would also apply to SMB infrastructures; if you follow Brian Krebs blog at all, you likely have seen that a pretty significant number of SMBs have contacted him over the years to say that they got hit with Zeus and funds were stolen from their bank, transferred to money mules. While Carbon Black isn't a preventative measure (it doesn't block stuff), having something like this in place, reporting to a SOC would significantly improve detection, as well as response by law enforcement.
But again, Carbon Black isn't just about IR...IR is one of the uses of a sensor like this. If any of this sounds interesting to you at all, get in touch with the Kyrus guys and ask them about their case studies.
Tools
The Malware Analyst's Cookbook tools are now online. This is an extremely well-written and valuable book for analysts to have available, and the "recipes" that demonstrate the use of the tools really do a lot to show folks what can be done. I have found that a lot of analysts really look to this sort of thing; "show me how it's used" really does a great deal more to get them to actually use it than just posting the tool to the web. The Cookbook is an excellent and invaluable resource, not just to malware analysts, but also to a wide range of infosec professionals, offering a great deal of insight into the nature of malware.
I have a blog post here that describes how to get pescanner.py running on Windows.
Registry Stuff
The folks over at the DFS blog have an interesting post about Registry backups on Vista, Win2008, and Win7. Apparently, the backed-up copies of the Registry hives on Win7 are the result of the RegIdleBackup Scheduled Task.
This is definitely something to keep in mind when analyzing these systems. For example, I have used regslack on a number of engagements, and found some pretty valuable information. Running a 'diff' on the current, active hives and the backed up versions might provide some useful insight, as well. So this is yet another analysis technique to add to your bag of tricks.
No comments:
Post a Comment