Threat hunting is a popular concept in the modern Information Security space. Vendors will tout their systems as a threat hunting solution. Or even more inaccurately, they will claim their box or their service can eliminate the need to do threat hunting. Both of these claims are false. The first because it incorrectly defines threat hunting. The second because it claims to help you abdicate responsibility - the ultimate sin in Information Security.
Clearing the fog around the beliefs surrounding threat hunting starts with defining what isn't threat hunting. Checking on an alert in a system isn't threat hunting. This is triaging - determining the accuracy and risk of a given alert. If some source, a box, an indicator, or a listserv, tells you to go look to see if a given action is malicious, it's not hunting.
Hunting isn't about indicators. It's about behavior. You are looking for behavior out of the norm. For an adversary to get a foothold in your network, and then begin to act in their interests, their behavior will be both defined, and different from the norm.
To properly hunt, there are some prerequisites. First, hunting is a process that will take time. It can't be rushed. You can scope your hunts to look at a specific behavior on one system over a short time to control the time investment. Starting small will allow you to understand how much time you budget.
Second, create documentation. Hunts need to be documented to help baseline. Environments change, and the hunts can help keep baselines up to date. Hunt documentation needs to show exactly what the hunt was about, how it was scoped, what the hunter sought, and the results of that hunt. This allows the hunter to refine their process, create a history of refinements to the hunt, and provide a template for teaching junior security team members how to hunt. My personal preference is Microsoft OneNote, but you can use a wiki, you can use notepad. As long as you can organize your documentation, you are going in the right direction.
Third, have visibility. You will need to be able to see data. That data has to come from somewhere, and the easier the access, the easier it will be able to search. You can hunt with the windows event viewer. You can hunt with netflow. You can hunt with just about any logging data. You need to be able to see it and carve it.
Carving is the ability to manipulate data to remove irrelevant sections or sections that require further analysis. This manipulation can be based on simple thoughts (running FINDSTR looking for logon type 10 or using GREP to look for netflow connections into the server core from unexpected IPs). Talk to any experienced threat intelligence analyst, and they will sing the praises of Microsoft Excel.
Once you have set aside time, can create documentation, have visibility, and can manipulate data, you are ready to hunt. The process of a hunt is very simple. Behavior A is normal. An adversary on the network will have a behavior that will deviate from Behavior A. How do I find behaviors that deviate from behavior A? You then look at the data and filter out normal behavior. The behavior that's left needs your analysis. Every bit of anomalous behavior needs to be either justified or addressed.
This is where you find unique (or erroneous) configurations in your environment. This information can correct issues, or help people understand what their systems do. On more than one occasion I've asked system owners at multiple jobs why does their system do this, and repeatedly I have been told they have no idea.
Once you have cleared known good behavior, and you have justified what can be justified in your environment, you are left in two potential states. One - there is nothing left to carve out from your hunt. This means that an adversary didn't exhibit this behavior (or found a way to disguise it, but that's farther down the threat hunting rabbit hole). Two - there are unexplained behaviors found in your hunt.
If it's option two, congratulations! The process of hunting is now concluded. The process of incident response begins.