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.
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!
- Comments (0)