Digital Forensics and Incident Response (DFIR) is the art of studying a potentially compromised system to understand the blast radius of an attack. In this article I will look at some of the DFIR steps a security analyst might take following an incident. I will also simulate a couple of attacks and then go through how an analyst might respond after a monitoring system raises an alarm about a potential attack. (See the box entitled "Resources and Tools" for more on the post-incident investigation environment.) A large part of this discussion was inspired by an excellent article by Craig Rowland [1].

For purposes of illustration, I will work with a live, running system, but keep in mind that a real forensic investigation would be more likely to make an exact copy of the compromised system and scrutinize it offline. If you work offline, the offline copy should be a block-for-block carbon copy of the compromised system that contains all the metadata and potentially even live processes (depending on how the copy was created). Many professional investigations will make multiple copies of the original in order to study the problem from multiple viewpoints and still retain the integrity of the original.

Digging Deeper – Attack #1

I will use the opening example in Rowland's excellent article for the first attack. The example involves what's called a bind shell. The more popular version of backdoor access into a remote system is called a reverse shell. A reverse shell causes the compromised system to phone home back to an attacker's computer. Reverse shells are easier to instantiate because, generally, outbound firewalling is much more attacker-friendly than inbound firewall rules. In other words, a process on the system that wants to communicate with the Internet can generally do so by default. Whereas inbound traffic is almost always limited to a select number of network-based services.

[...]