Prerequisites To DFIR

2012-12-15 21:24:08 by chort

I gave a short presentation at Baythreat this year titled My First Incident Response Team: DFIR for Beginners. Due to the time format, I wasn't able to give a lot of context around some of the concepts. A few people asked if I had suggestions of simpler things to start with prior to diving into digital forensics. I hope to address those questions in a long-form version of my presentation at conferences in 2013, but in the mean time here are a few things I consider prerequisites or jumping-off places for new incident responders.

To me, the obvious place to start was network forensics. I read TCP/IP Illustrated, Vol 1 (now available in 2nd edition) very early in my career and had used tcpdump and Ethereal/Wireshark as go-to tools for network troubleshooting. Thus it was only natural to me to use those same tools for analyzing potential malware and malicious network behavior. I was only recently made aware that it's referred to as "network forensics," I always thought of it as "find out what the heck is going on with the network." The point being: It will be very tough to analyze malware, reverse tunnels, non-standard traffic on well-known ports, etc without having a solid grasp on TCP/IP. It's also possible to spot potential malicious behavior when security tools fail to alert, just by noticing anomalies or things that don't belong.

There's no fast or easy way to learn TCP/IP. These days you can leverage desktop virtualization to great advantage by setting up functional networks with multiple operating systems all on one computer, then analyze the traffic going between the virtual machines. I highly recommend reading volume 1 of TCP/IP Illustrated to get you started. After that it's just a matter of running many different network services and observing their behavior. When you have a solid understanding of how protocols run in normal conditions, move up to using Metasploit to launch exploits and open remote shells, while you're capturing traffic, so you can analyze what attacks and remote control/data exfiltration look like.

After basic networking, take on IDS. While I don't think NIDS is a highly effective defense, it is an important tool when deployed correctly (inside the firewall, matching internal IPs as both source and destination). In my experience the most useful rules are for general behavior, such as suspicious HTTP POST operations, JavaScript obfuscation, port/protocol mismatch, etc. Unfortunately a lot of the rules for specific exploits (especially SMB) generate torrents of false positives. Here's the major catch with NIDS: The countless hours you'll spend trying to determine if a particular alert is an actual attack. You can't trust what NIDS tells you, even expensive commercial NIDS. You need to spend hours and hours chasing down the CVE linked in the alert, finding related Proof of Concept code on the web, finding blog posts explaining either the exploit itself, or reverse-engineering malware that uses the exploit, etc... In order to get any value out of NIDS you need to be very skilled at analyzing the captured packets in a protocol analyzer and in getting your Google fu just right to find relevant information quickly.

Another necessary topic is OS internals. Clever attackers and the malware they write have all kinds of nooks and crannies on a system to hide in. Keep in mind it's not just the intended mechanisms that get used to establish persistence (ability to survive a reboot), but flaws in the OS or programs installed on it. That means a responder needs to be aware of all the ways someone could achieve persistence, hide data being collected, exfiltrate said data, and download new programs or commands. If that sounds like a lot of information to know, it is. It's even tougher if the OS you have to do incident response for is not one you use every day.

I've used BSD, OSX, and Linux operating systems as my workstations for years. I haven't used Windows daily since the Win2K era, so it's a long up-hill climb learning about Windows internals for me. You might have a similar struggle if you've been using Windows for your whole life and suddenly have to do IR for a bunch of Linux webservers. The important thing is to not get overwhelmed. Start with the basics (where are programs installed, how do services get started, how does the system schedule repetitive tasks, etc). This is another opportunity to use virtual machines to speed up the process--create a snapshot, install some programs, observe what has changed, revert and repeat. I wouldn't recommend it for early reading, but the Windows Internals series (part 1, part 2) by @markrussinovich, David Solomon, and @aionescu is a great resource for advanced topics.

Finally, I recommend becoming familiar with attack techniques. Thankfully the moral debate about whether defenders should learn attack tools is pretty much over (if you didn't have to live through it, be grateful). It's fairly widely accepted these days that blue team members will use Metasploit, sqlmap, Burp Suite, and similar software to assess the strength of their defenses, and model attacker behavior. The goal here is not simply to open some offensive tools and randomly click on things--the idea is to actually mimic attacker behavior. You should know what it looks like for an attacker when they're trying to break into a network, so you know what flaws they're likely to take advantage of and what artifacts they'll leave behind. For a good example of this, check out the APTish Attacks with Metasploit series (link is to part 1).

That about wraps it up. It's by no means an exhaustive list, but it's a good set of basics to start with. Hopefully I'll see some of you at conferences next year!

Add a comment:

  name

  email

  url

max length 1000 chars