Proactive Incident Response

A little while ago Harlan Carvey posted on Proactive Incident Response. I've been thinking about this for a while, but have a different perspective on Proactive IR than he does. (I agree with his take on it, I just look at Proactive IR differently.)

Computer Incident Response Teams (CIRTs) are often referred to as fire fighters. This analogy is very true - most of the time CIRTs are fighting fires; the fire being a hacked server, a malware outbreak or a targeted phishing campaign. We're often jumping from one problem to the next, determining who got in, how they did it, what damage they caused and how to prevent it in the future. However, is that all CIRTs should be doing?

The CERT Handbook for Computer Incident Response Teams states that CIRTs should offer three different services: reactive, proactive and security quality management services. Reactive services are the fire fighting done on a daily basis. Security quality management services include project and security consulting for other business units; you know, those meetings you get pulled into where they ask you what you think. What about proactive services?

If we look back at actual fire fighters, we see that they don't just spend their time putting out fires. One of their duties is to help fire prevention through education and fire inspections. In the security world, this is analogous to doing user education, vulnerability scanning and penetration tests. This is what proactive services are. But I believe these is another aspect of proactive services that CIRTs tend to miss.

One of my co-workers has coined a term: hunting trips. This basically boils down to proactively looking around the interwebs for attackers you've seen in the past. Since attackers tend to use the same, or similar tools and tactics, indicators of their compromises in other organizations appear if you know where to look. You can then use the new indicators you've just found to check for signs of compromise in your network.

Where can you look? Anywhere that information on security analysis can be found. This includes blogs, twitter, forums, online sandboxes, AV signature descriptions, etc. All of these places (and more) have information you can use to tie attackers to new attacks and malware they are using.

Of course, I wouldn't recommend hand-searching each of these places for information. Google is the obvious place to start, but be prepared to get back hundreds of results (at best) that are not of interest to you. I would recommend using the Google Malware Analysis Search, created by those behind the Hooked on Mnemonics Worked for Me blog, that narrows Google's search to 75 different security sites and feeds.

So, an example so this might actually make sense. In the last few days there has been an uptick in spammed emails that contain a link to a zip file named order.zip. Within this file is a SpyEye trojan. Analysis of the trojan shows that it drops itself as c:\recycle.bin\recycle.bin.exe (which to my knowledge is not a default location for SpyEye). This location is fairly unusual and can be a good indicator to use on a hunting trip.

Using the Google Malware Analysis custom search to look for "recycle.bin.exe", we come across a ThreatExpert report from March 2011 for the same filename being dropped for a SpyEye trojan. The TE report also shows that it attempts to contact zweor.com for its C&C server. We now have a new indicator to search our network for and to go hunting with.

This is a very simple scenario, but demonstrates the usefulness of performing information gathering to find additional indicators. I have a feeling most CIRTs are not doing this and would benefit greatly from setting aside time to make sure this is done.