InfoSec-Specific Executive Development for
CISOs and Aspiring Security Leaders.
Live Faculty-led instruction and interactive
labs to build you and your team's InfoSec skills
At its core, a threat hunting team’s mission is to look for indicators of compromise (IoCs) that have gone undetected by other security controls. As such, a hunt begins with the premise that the organization has been compromised but doesn’t
(yet) know it. At a minimum, that requires some level of understanding of the existing security controls. It’s also helpful to have an up-to-date understanding of threats.
Most of today’s malicious software and activities fall into one of only a few categories.
A hunt team should have the ability to detect any of these threats, even if the malware uses entirely new techniques and can otherwise bypass every deployed security defense.
Most of today’s security tools, at least those intended to detect and/or prevent threats, operate by continuously monitoring a system (e.g., process memory, disk storage, network activity, etc.) and looking for IoCs, which are in the form of:
Vendors often speak of other proprietary techniques their products use, but they generally fall under those two broad categories.
One of the problems with this approach is that detecting malicious activities and tools on a running system can be problematic. With the advent of rootkit techniques in the mid-‘90s, adversaries gained the ability to compromise and modify systems
to make malicious software exceedingly difficult to detect.
Thus, reliably detecting modern malicious tools is best done by starting from a known and trustworthy starting point. This is generally best accomplished by initializing the system being analyzed from otherwise trustworthy boot media, and then examining
the storage devices on the system being analyzed.
Of course, no technique is perfect. Even booting from trustworthy removable media can yield false results if the system has been compromised at the firmware or hardware level.
Nonetheless, the most consistently reliable method of detecting malicious activity on a system is to boot it from trustworthy media and examine its persistent storage for indications of unauthorized changes.
Process memory can also be examined for malicious tools that do not make changes to storage media, but since most of these do not survive reboots, they present another challenge for a hunt team.
READ: Setting Up a Successful Vulnerability Management Program
At the most basic level, threat hunting teams should:
Because of this, it is not sufficient to only examine system activities as reported by the system itself. One place to look for (relatively) independent indications of system activity is to do traffic analysis of a system’s network data over time.
Data such as NetFlow can be analyzed to look for anomalous or otherwise unauthorized network behavior.
From a practical standpoint, then, a hunt team should be built on numerous activities for detecting IoCs. These should include the following:
The above list is a solid starting point for hunt activities.
Each hunting activity carries with it myriad technical challenges. Some, but not all, of those challenges can be addressed through automation. For example, it may be helpful to automatically:
This is really just scraping the surface of the problem space. Because hunt team activities are relatively nascent, tools are scant and still fairly immature.
Most hunt teams cobble together a tool chest of security tools and custom-made scripts and processes for analyzing systems. While certain tools can be helpful in looking for unauthorized changes in systems, they can sometimes seek to solve a different
problem set than what most hunt teams face today. Tools like Splunk can be enormously helpful for analyzing NetFlow, syslog and other system activity log sources, looking for signs of unauthorized activity.
However, when it comes to low-level analysis of critical IT assets, there remains plenty of heavy lifting in terms of developing operating procedures for booting a system from trustworthy media and examining all the installed software for indications
of unauthorized changes.
Most hunt teams operate on a limited scope and examine just a subset of an organization’s most vital IT assets. They rarely, if ever, are called to examine general-purpose desktop systems because the complexity there is enormous. Either that, or
they examine a mere subset of system attributes, such as an inventory of installed application software vs. an authorized whitelist of authorized application software.
One notable exception to this is special-purpose internet of things (IoT) devices such as security cameras, point-of-sale (PoS) terminals and such. Many of these ae built from open source components and many provide some form of administrative interface
for examining the firmware version or even entire file systems for indications of unauthorized activity.
While the same caveat regarding supply chain attacks exists on IoT devices, even relatively simple actions like verifying the checksums on firmware images can be helpful to a hunt team.
READ: How to Build a Proactive Threat Hunting Strategy
In summary, setting up a hunt team has no shortage of technical challenges. Most teams find it helpful to:
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.
January 26, 2023
By IANS Faculty
Gain an understanding of primary passwordless use cases along with helpful passwordless workarounds to address common issues.
January 24, 2023
Gain a more in-depth understanding of common passwordless platform issues, alternative solutions as well as tips to make passwordless work in real-world business environments.
January 19, 2023
By Ian Amit, IANS Faculty
IANS Faculty member, Ian Amit, discusses how shifting the Security/DevOps paradigm can help improve cloud infrastructure security.