A prediction of the past, Retro Hunt for everything utilizing Threat Intelligence and the Kill Chain

A prediction of the past, Retro Hunt for everything utilizing Threat Intelligence and the Kill Chain

ZeroDays and the next big thing seems to be a driver for the modern age security posture, but we should never forget that when the next big thing is public knowledge, you might have experienced a test attack already. Retro Hunting is the small and underappreciated art of locking back in has happened already.

I have been a fan of retro hunting for a while now, basically since I tried to file a patent for an automated retro hunt in my former company, now with the tools I have in my new company it is time to tackle this topic once more.

When you look at wikipedia and search for retro hunt you will come across this definition

Cyber threat hunting is an active cyber defence activity. It is “the process of proactively and iteratively searching through networks to detect and isolate advanced threats that evade existing security solutions.”[1] This is in contrast to traditional threat management measures, such as firewalls, intrusion detection systems (IDS), malware sandbox (computer security) and SIEM systems, which typically involve an investigation of evidence-based data after there has been a warning of a potential threat.(Source: Wikipedia)

To put it in some different words, retro hunting actually means that you take all indicators, that can be what I would call traditional indicators like IP addresses, domain names and hashes but as well the newer techniques, tactics and procedures you know from MITRE ATT&CK. And you start searching your environment for any observation on these indicators. There are some things you want to keep in mind

Start from Threat Intelligence

I already wrote a separate post about Threat Intelligence. You should make sure that the indicators or reports you receive have been analysed taking in your unique environment. Threat Intelligence should tag indicators which are to be hunted, in that case you can save time letting the hunter decide what to hunt for and focus on the how to hunt.
You always want to make sure that the indicators are enriched in a way which makes them applicable for your environment, some examples

• hashes are always great, but they will require that you have log of data which include those hashes. It will not make sense to search all data for hashes but no hashes are stored.
• IP addresses, maybe the easiest to find, as proxy, firewalls, dns logs and even web server logs will be a great source of events. But, make sure that you analysed the ip’s first. We have seen threat reports which included ip’s of content delivery networks, you may find many of those ip’s, but without any other indication these findings are meaningless.
• In the vulnerability space, you have reports including CVE’s (Common Vulnerability and Exposure… I actually thought it stands for Enumeration, anyway), but the report might talk about a very high level system version, like Windows 11, so you want to make sure that you enrich these indicators with the full version number which is affected, otherwise, again, the findings will be meaningless

Let’s get hunting (what, where, how)

The extreme challenge of hunting is what and where to look for and how to do it. Threat intelligence should have taken care of the what, so we stay with the where and how.

Maybe you are lucky (or paranoid or lucky paranoid) and all event data live in a big data warehouse, your SIEM, your data lake, your data lake-house or something like that. This is good, cause you can come up with some queries which include indicators and their relation to each other.

Always keep the kill chain in mind (or MITRE ATT&CK, I stopped fighting people on that a while ago), you would expect finding events meeting “delivery” phase before an event of the “installation” phase. Simple, right? With this you can narrow down the queries and tailor them to the full report instead of single events you need to glue together afterwards.

There are plenty of tools, like always, and I will be honest with you, the data you out into the tools will matter more than the tool itself. Most tools are based on an query language of some sort. Palo Alto Networks XDR and Cortex Data Lake as an example use XQL so you are able to look at a time frame and combine statements with AND and OR to combine indicators into one search.

As a site note, please (please, please, please), OR is nice, I get that, but if you combine all indicators with OR the result mean nothing. There should be at least one AND statement somewhere.

If you don’t know how you want to store your data, I also recommend reading the blog post of a friend of mine, Richard de Vries talks you through how you should store your (security-) data

Finally lets assume you want to run this automatically

The approach of automatic vs. manual will definitely give us some disadvantage and break the idea of “you need at least one AND”, cause we can’t have the machine decide which indicators should be combined and when.

These are the steps you want to perform

• Tag indicators for automatic retro hunting, you can also simply rely on the verdict and time, so lets say “verdict: malicious AND time:{today}” as a XSOAR TIM style query
• Also, as queries and tools might differ you want to extend the query with the indicator type like “type:FileHash AND …”
• With this you should end up with different lists of indicators you can feed into the different storages (Cortex XDR, SIEM, Data Lake, etc)
• Look for any findings and report them

That is actual all you need to do to have a minimum starting point of your Retro Hunting journey

That’s it for today, please 👏 if you like the post, and like always, be excellent to each other