Okay, I get it, there are hundreds of blogs about Threat Hunting already, but many are focused at large SOC teams with lots of resources. Even if you are a one-person team, this blog will address the problems you may face, a very simple process to structure your hunts, and a small library of hunts to get you started!
Threat Hunting has gained a huge amount of interesting in the last few years and is starting to become an expected function of many SOCs and blue teams.
Threat Hunting: Proactively searching for threats missed by defenses in the enterprise. — @GuyBruneau
Common Pitfalls
As with many trends in infosec, management will always be pushing the latest and greatest security technologies or fads before they have mastered the basics. Unfortunately, Threat Hunting is no different.
Trying to fly before you can run
This is the most important point for small teams. If you are being asked why you or your team aren’t threat hunting, don’t feel pressured to drop everything and start. Threat Hunting is a mature function which requires lots of resources and visibility into the business. There are many fundamental controls and functions that blue teams should tackle before addressing hunting. Threat Hunting probably falls into the Intelligence/Active Defense tiers of The Sliding Scale of Security by Robert M. Lee which demonstrates the value vs cost of security functions.
Process
You may be asked in a common knee jerk reaction, “I heard about X threat, are we okay?” and “Did you see any abnormalities in the network” etc… Threat Hunting isn’t just a reactive process. It requires planning and time to proactively and methodically search in the enterprise. Those questions could be a catalyst to organise a hunt, but don’t let open-ended questions from management rush a hunt!
Data, data, data
Hunting without data or a way to generate the datasets you need is a major problem. Having access to logs or support from the business to get what you need is a must.
Okay, your SIEM and/or EDR may already have a lot of what you need. That’s great! But don’t fall into a mentality of relying on pre-collected data. You will need to get your hands dirty!
For those that don’t have centralised logging or EDR, make sure you get very friendly with your IT admins! As an example, you can push out GPOs with scripts to run Sysinternals Autoruns or collect Security event logs to a network share.
Full Automation
Putting it simply, if we could fully automate threat hunting, then it would be just another detection method like a SIEM rule. This undermines the main reason to hunt; to find threats that weren’t detected by existing controls. This doesn’t mean you shouldn’t automate data collection or data processing, it just means there will always require a human doing the analysis.
Getting Started
Let’s get started! There are other threat hunting process frameworks, but I’ve tried to keep it as simple as possible to maximize accessibility by extending the simple 3 step process by Joe Ten Eyck (Building a Threat Hunting Framework for the Enterprise).
1. Prepare
What are we looking for? Where do we find it?
- Create a hypothesis (see below),
- Start researching and understanding the TTPs associated with the hunt,
- And start to scope out the data required (Can you get the data you need?)
Hypothesis
A hunt should be drive by a tangible question or catalyst:
- Intelligence-driven
- Situational awareness
- Domain expertise
Read Generating Hypotheses for Successful Threat Hunting by Robert M. Lee and David Bianco, which goes into details and examples.
2. Find
How do we find it? Can we test it?
- Develop analytics (see below) to break up hunt into practical, quantifiable procedures using searches/queries
- Requires time for experimentation and data acquisition/analysis
- Assess visibility and current controls via Atomic Red Team tests (see below)
Analytics
Based on the term coined by MITRE, an analytic describes observed behaviour for a tactic, technique or procedure (TTP). This allows you to break down the hypothesis into testable and measurable results.
Testing (with Atomic Red Team)
During your hunts, you may want to generate events or traffic based on the TTPs you are investigating:
- Assess the data sets you are hunting with are providing the visibility you require
- Assessing existing controls and detections to provide feedback loop during hunting.
Each hunt will automatically map to the relevant Atomic Red Team test for the given techniques/subtechniques.
3. Communicate
Review the hypothesis, document findings and present to the team. The output of each hunt can vary immensely. It may include one or more of the examples below:
- Incident Response — identified legitimate incident
- New detection rule in SIEM based on analytics created in hunts
- Update to Group policy to harden identified gap
- Identified gaps in visibility that affected the hunt
- Lessons learnt and reflection for the next hunt
TheTheatHuntLibrary
So now you know what you need to do, where do you go from here?
https://github.com/svch0stz/TheThreatHuntLibrary
Documentation
An important part of Threat Hunting sustainably is to create clear and concise documentation, in case someone needs to repeat your work, or take over from where you left off.
Here is an example of a hunt that is specific to adversaries taking advantage of standard protocols to hide C2 traffic. Each analytic has a clear objective and the data source required.
These hunts are based in YAML which then has a markdown page dynamically generated using python.
Analytics should have clear instructions to generate the data and how to interpret the data and what limitations the analytic has.
Depending on the MITRE Techniques, the hunt documentation will suggest associated Atomic Red Team tests.
Conclusion
I hope this gives people out there a bit of a kick start if they haven’t gotten around to starting to threat hunt as there are many merits to having this function as part of your blue team exercises.
Feel free to create new hunts and raise a pull request.
Thanks,
Zach
