One of the questions I get asked almost every week is some variation of “… but how do I threat hunt?” By this, what they often mean is, there are tons of articles on threat hunting strategies, but there aren’t as many resources aimed at analysts on how to threat hunt. Now, this isn’t to say that the community hasn’t produced howtos and other documents. They have, and these are great.
But these tomes are often aimed at a specific technique or hunt. There are, unfortunately, fewer resources on more general ideas that analysts can use for inspiration. So, after sitting down with our hunt team and putting our heads together, we’ve come up with 30 hunts to try out. These hunts will expand your structured and unstructured repertoire, and can serve as inspiration for other hunts as well.
One of the first methods that analysts can learn, on how to threat hunt, are unstructured hunts. We have covered the difference before, but needless to say unstructured hunting is data intensive. Because of this, it is good to look at numerical elements of the data to give yourself a starting point. The first numerical element to look at is volume.
An example of this hunt could be in your firewall logs. Looking at all the high ports used, for example, and look for ones with more volume. Or look at the volume of high port-high port connections.
Another technique that can be useful is frequency analysis. How often does something happen? Is that suspicious domain observed around the same time every day? Do you see a noticeable pattern? If so, you may be on to something interesting, like a C2 node.
Grouping is handy, especially when you have access to detailed data. Grouping allows you to look for outliers in the details. For instance, if you have data from programs installed on systems, look for ones that don’t have a vendor tagged.
Or you could group by interesting commands that users have run in a terminal or command line. Look for non-administrators running “interesting” commands like whoami, net use, ipconfig, or nmap.
Stack counting is one of the most effective methods of performing unstructured threat hunting. We have covered the technique before here, but needless to say it is a power way to sift through data.
You could, for example, stack all program execution data (Windows Event ID 4688) from a department or organization. Then you can look for process names that aren’t known, or that are not considered “authorized” by the company.
Another option for stack counting would be stacking the most common hashes for existing programs. Look for hashes that might stand out, or compare them against lists of known-good hashes for those programs.
Stacking can also uncover names that are similar but different, especially for common process names. Look for processes that might use non-Roman characters to try and conceal themselves.
Analysts can also apply stack counting to things like AV logs. Most AV platforms have logs for both cleaning and quarantining files. Look for the locations where the cleaning and quarantining are happening and see if any stand out. A file cleaned in the “My Downloads” folder is a lot less concerning than one in “system32.”
Another handy technique can be stack counting common file names like Calc.exe. Is the file where it should be? If it isn’t, it might be time to dive in to the data to find out why.
Analysts can also stack things like network metadata to look for patterns. For instance, analysts could stack count user agent strings, and look for suspiciously short or long ones. Or even ones with small alterations like a period at the end.
While unstructured hunting can be very useful, it is also very time consuming. Structured hunting can often give hunters a leg up when looking for suspicious and malicious behaviours.
One of the easiest structured hunts analysts can perform is looking at parent-child relationships. For example, should Microsoft Word really be spawning PowerShell? Why is svchost spawning from a process other than services.exe? Analysts can also look for process execution from locations that look abnormal.
Another great method to use for structured hunting is to look at user behaviour. For example, an analyst can look at users added to privileged groups (look for IDs 4728, 4732, 4756). Are the people making these changes authorized to do them? Are the accounts being added normal?
A short and sweet method that can yield interesting results is looking for users logging in with alternate credentials (ID 4648). Is this behaviour consistent with an admin elevating their privileges? Or something more insidious?
A different hunt for user behaviour involves looking for users launching scripting interpreters. The most popular of these interpreters are cscript and wscript, and ordinary users aren’t likely to use them.
Like hunting for scripting interpreters, analysts can also look for executables like Rundll32. While these executables serve a legitimate function, a user in their day-to-day role won’t use them. So if you see a user invoking them, it might be time to dig deeper.
Finally, hunt teams starting out can look for activity around scheduled tasks. This could involve suspicious task creation, but it could also involve users disabling or reenabling them.
One of the best sources of adversary intelligence during or post breach is terminal activity. Terminals such as PowerShell, cmd.exe, BASH and others should be centrally stored. This data can provide hunters a wealth of hunting options.
The first hunt is the simplest. Hunters can look for administrators using unsafe procedures like passing passwords in the clear. Hunters can look for commands containing the argument “-p” or the more eponymous “pass” or “password” strings. This type of activity should be flagged for followup.
But terminal activity is not limited to looking for unsafe procedures. Another useful hunt can be to parse out arguments and switches passed to commands or executables. Certain arguments (like “sekurlsa::”) can often alert a hunter to the presence of a tool — like mimikatz — even if it has been renamed.
Some of the more useful terminal hunts relate to PowerShell. PowerShell is one of a threat actor’s best friends, and that is because of how versatile it is. Every hunter should be suspicious if they see a normal user passing commands using the encoded command parameter. Similarly, hunters can also look for other suspicious PowerShell activity like outbound connections.
Entropy, simply put, is a measure of randomness in any given attribute. Entropy can be a complicated to grasp, but once mastered it can be very useful for detecting usual activity in an environment. For instance hunters can look at the entropy of file or process names across a system to detect names that don’t seem right. Hunters may also look at the entropy of domain names, looking for domain generated algorithms (DGAs).
Some hunts don’t fit into a neat category, but if seen they do still set off alarm bells. A great example of this is reviewing AV logs and looking for suspicious detections. What do we mean by suspicious detections, you ask?
Look for quarantine or clean events for offensive security tools. These tools are ones that a user would have to download on their own — like generic mimikatz — and are less likely to have malware deposit them.
Another indicator of maliciousness can be connections direct to an IP with no associated DNS request. While this can be common behaviour for folks in the tech department, it is much less common in finance.
And finally, one of the simple but effective hunts is looking for standard HTTP connections going over non-standard ports. This can reveal a host of interesting activity from web-based proxies to malware command and control.
Finding inspiration for structured and unstructured hunting can sometimes be a challenge. This is often because a lot of the material on hunting may focus very heavily on specific hunting techniques, and less so on broader methods.
If you want to learn more about what to do with the hunt once you have finished it, check out our article on how to follow up after the hunt.