Only $2.99/month

CySA+ Chapter 7: The Incident Response Process

Key Concepts:

Terms in this set (34)

Through segmenting the network as part of its architectural design, we already saw that his can still allow an attacker to easily move between hosts on the same subnet. As part of the preparations for IR, it's helpful to establish an "Isolation VLAN," much like hospitals prepare isolation rooms before any patient actually needs them. The IR team would then have the ability to quickly move any compromised or suspicious host to this VLAN until they can be further analyzed. The isolation VLAN would have no connectivity to the rest of the network, which would prevent the spread of any malware.

This isolation would also prevent compromised hosts from communicating with external hosts such as Command-and-Control (C2) nodes. About the only downside to using an isolation VLAN is that some advanced malware can detect this situation and then take steps to eradicate itself from the infected hosts. Although this may sound wonderful from an IR perspective, it does hinder our ability to understand what happened and how the compromise was executed so that we can keep it from happening in the future.

While a host is in isolation, the response team is able to safely observe its behaviors to gain information about the nature of the incident. By monitoring its network traffic, we can discover external hosts (for example, C2 nodes and tool repositories) that may be part of the compromise. This allows us to contact other organizations and get help in shutting down whatever infrastructure that attackers are using.

We can also monitor the compromised host's running processes and file systems to see where the malware resides, and what it's trying to do on the live system. This all allows us to better understand the incident and how to best eradicate it. It also allows us to create "Indicators of Compromise (IOCs)" that we can then share with others such as CERT or an "Information Sharing and Analysis Center (ISAC)."
1) The first approach does not really know about what the binary is, but rather what the binary does. This is called "Dynamic Analysis," and it requires a sandbox in which to execute the malware. The sandbox is a virtual OS that has a file system, network interface, memory, and anything else malware asks for. Each request is carefully documented to establish a timeline of behavior that allows us to understand what it does. The main advantage of dynamic malware analysis is that it tends to be significantly faster and requires less expertise than the alternative (described next). It can be particularly help for code that has been heavily obfuscated by its authors. The biggest disadvantage is that it does not reveal all that malware does, but rather simply what it did during its execution in the sandbox. Some malware will actually check to see if it is being run in a sandbox before doing anything interesting. Additionally, some malware does not immediately do anything nefarious, waiting instead for a certain condition to be met (for example, a time bomb that only activates at a particular date and time.

2) The alternative is "Static Code Analysis." In this approach, a highly skilled analyst will either disassemble or decompile the binary code to translate its 1s and 0s into either assembly language or whichever higher-level language it was created in. This allows a reverse engineer to see all possible functions of the malware, not just the ones it exhibited during a limited run in a sandbox. It is then possible, for example, to see all the domains the malware would reach out to given the right conditions, as well as the various ways in which it would permanently insert itself into its host. This last insight allows the IR team to look for evidence that any of the other persistence mechanisms exist in other hosts that were not considered infected up to that point.