Performing threat hunting and incident response on live hosts, collectively referred to here as live analysis, can be a complicated task. When performed properly, they can detect and preserve volatile artifacts, such as network connections, running processes, hooks and open files, which may be the only evidence of today’s advanced attacks. Live analysis may also be the only option when taking a host offline for traditional disk forensics is not an option, such as with business-critical application servers or domain controllers. However, if performed improperly, they can alert attackers to your presence, destroy critical information or render any evidence gathered inadmissible in legal proceedings.
Live forensics and live threat hunting
Live forensics and live threat hunting begin as two different processes. When performing live forensics, we typically start with a pivot point; something has already been detected as anomalous which has prompted us to examine the host. During live threat hunting, we are seeking that anomaly, that indicator of potential malicious activity, to use as a pivot point for further investigation. Once that initial indicator has been discovered, the traditional incident response process, often involving further live forensics begins.
Performing live analysis poses several unique challenges when compared to traditional offline disk forensics. Although any forensic process must be documented and repeatable, these attributes are especially important when performing live analysis. Unlike offline disk forensics, where the original evidence should theoretically remain static and unchanged, live evidence is constantly changing. In fact, we are changing the live evidence by performing live forensics. Although the live analysis process is repeatable, it cannot be repeated while achieving exactly the same results; processes start and end, network connections are terminated, and memory is re-allocated. This means that our live analysis processes must be able to stand up to increased scrutiny.
Because live analysis involves executing commands on a running host, it is crucial that the process is also performed in a secure manner. Only trusted tools should be executed. Each tool and the commands used to execute them should be tested prior to being executed during a live analysis to ensure that the results are known and only the intended actions occur. It is also important to ensure that the tools and commands you tested are the same ones being executed during each live analysis situation.
On Friday, September 7th, I will be speaking at the SANS Threat Hunting and IR Summit in New Orleans regarding some of the challenges and best practices when performing threat hunting and incident response on live hosts. I will also be demoing DFLabs free tool, the No-Script Automation Tool (NAT), which can be used to assist in the live data acquisition process. If you have not had a chance to see NAT, please check out our blog post here, and our demo video here.
Also, find out which top cyber security events DFLabs will attend this fall.
I hope to see you all at the SANS Threat Hunting and IR Summit soon. Safe travels and avoid the storm!
Threat hunting is defined as an iterative and focused approach to searching, understanding and identifying internal adversaries that are found in the defender’s network. It’s been shown that incident response automation tools can provide Security Operations Center (SOC) team members with additional time that can be leveraged in a more focused, threat hunting role within the SOC environment.
The SOC staff members should have some understanding of how they can use this additional time provided by incident response automation to enable them to hunt for threats, rather than spending valuable time and resources gathering threat information which could otherwise be done in an automated fashion. It’s long been established as we make the migration from threat prevention to threat discovery that malicious actors and processes are frequently well-hidden within the organizations infrastructure and in order to effectively locate and investigate them we must start by asking the 5 W’s, who, what where, when, why and perhaps most importantly, how.
SOC team members must first understand what threat hunting is to be truly effective. The staff members should channel their question on the three tenets that make up the threat triangle; capability, intent, and the opportunity. By focusing on these three tenets, threat hunters can leverage orchestration to accomplish not only the system monitoring but the automated data gathering to support this expanded role without adding additional infrastructure. Additionally, team members must understand that the threats can be human and not just, for example, malware that is directed at them. This, coupled with an understanding of the affected systems function, will help provide the insight into possible contributing factors to the incident.
As the level of automation scales upward, we’ve seen a corresponding scaling of the transition from simple incident data gatherers to data hunters. Additional time and resources will become available to teams that leverage incident automation, permitting them to forego the traditional gatherer role and begin to embrace a more proactive hunter role. The good news is both of these roles can be supported within the SOC and also within the same Security Orchestration, Automation and Response (SOAR) platform. IncMan SOAR from DFLabs provides the necessary combination of force multiplication and machine learning to ensure that not only are incidents capable of being prioritized automatically, but the necessary actions for successful resolution are available at incident inception.
If you would like to see how a SOAR platform can give your incident response team the necessary tools to make the migration from simple data gatherers to threat hunters, reach out to us for a free, no obligation demo.