Matt Miller Incident Response Incident Response, methodology

How Does Triaxiom Investigate a Security Incident?

Let’s say that your organization has had a potential security incident and needs help. Triaxiom offers incident response services centered around investigating how it happened (so you can prevent it from happening again), what the attacker had access to, and whether the attacker is still present on the network. For more information on what our incident response services provide at a high-level, check out our recent post. In this blog, we will focus on some of the steps we take when we are asked to investigate a security incident.

Interview

When we investigate a security incident, we start with interviewing all involved parties. This is the first key to determining what happened during the incident and forming a baseline to begin investigation. This will include interviews with the user who first noticed abnormal behavior, system/network administrators, key organizational stakeholders, and any other individuals involved before the incident was reported. It is important for us to hear directly from the user what they noticed and try to understand what they were doing when the symptoms first occurred.

While interviewing the IT Staff, we will gain a familiarization with the network. We’ll determine how the network is laid out, what level of logging is being performed, what security controls are in place, if there is any segmentation and how it is enforced, etc. This information will help drive the scope of the response activities.

Finally, we will interview the key stakeholders within the organization. These are the executives and managers that set the goals for the response procedures and provide a baseline of questions they need answered. In this interview we will gain an understanding of the goals of our incident response. This interview will help us determine what the organization is most worried about, whether chain of custody enforcement is necessary, and what information should be included in the report.

Open Source Intelligence

Using all information available, we will perform open source reconnaissance to determine whether this incident matches other reported security incidents across the Internet. With the exception of nation-states, most attackers aren’t going to use zero-day exploits and don’t have the technical capability to not leave a trace. The vast majority of breaches are going to follow common patterns, incorporate elements of previous breaches, and utilize known exploits. Understanding the pattern is a key element in understanding what access the attacker achieved and ascertaining their motivation for the attack. Using information such as filenames, strings in the malware, ports the attack is using, and files it modifies, Triaxiom will attempt to find a match with a known malware variant, or known attack pattern, which will provide context for what to look for next.

Reverse Engineering

In cases where malware or suspicious attachments can be collected while we investigate a security incident, Triaxiom will perform reverse engineering to determine exactly what that malware is doing. Using a forensic virtual machine, we will execute that malware with a number of tools designed to monitor exactly what that suspicious program is doing. Does the Word Document contain a macro? If so what does that macro do? Does the program make any network connections? If so, to where? Are any processes started/stopped? Are files created or modified? All of this is valuable information as we investigate a security incident and can only be determined through reverse engineering.

Log Analysis

Perhaps the most obvious step when performing an incident response investigation is to review the logs. However, most security firms will start with reviewing the logs, or focus only on reviewing the logs. It is imperative to use the clues that were gathered in the previous steps to guide the review of the logs. Otherwise, it is little more than searching for a needle in a haystack. Once you know from reverse engineering that the malware uses port 1337 to communicate, the logs should be used to search for that port in and out of the network.

Not Necessarily in That Order

While we listed these as steps, it is important to note that they will not necessarily be done in any particular order. In fact, all of these steps will feed into each other and drive further analysis, creating a response “lifecycle” that requires iteration. For example, if reverse engineering shows that it creates a particular file, the logs should be reviewed looking for those files, and open source intelligence should be performed on that file name. Additionally, if something interesting shows up in the logs, such as the computer restarting several times, it may be necessary to go back to the end-user and ask if they did that or if malware may have caused it. All that to say, it is important to note that all of these steps will be running concurrently and may need to happen multiple times depending on where the investigation leads.