Some things sound more interesting than they actually are. Some things are more interesting than their names make them sound. In a rare few cases, things align so that the coolness factor of the name and the thing match up. This is the case with “threat hunting,” the process of looking for actual or potential intrusions or compromises in a system or network. It sounds interesting, and it is, so let’s dive into a few basics that will help you get started with it.
Being a Good Detective
Police detectives have, on average, an extremely difficult job. So it is with threat hunting. Sometimes it’s obvious who committed a crime, and why, and how. Other times, it isn’t. In some cases, it’s not even clear if there was a crime. You should understand that the same is true with threat hunting. Sometimes you may want to gather evidence after a known intrusion or breach. Other times, you may investigate to see if there is evidence indicating a compromise. Sadly, sometimes you may end up chasing shadows. The famous phrase “absence of evidence is not evidence of absence” definitely applies; you should always keep it in mind.
The Very Basics of Threat Hunting
At its core, threat hunting essentially involves a lot of looking at logs. This is tedious for humans, but thankfully, we have automated tools that reduce the drudgery. The two key things you need to be thinking about when hunting are:
- What data am I using?
- What am I looking for?
The answer to the first question will determine what is possible to find, e.g. if you’re looking at Entra ID logs, that may not be the best place to determine if someone modified a OneDrive file. The answer to the second question is a little more variable. You may be investigating a known threat or issue (in which case, you know exactly what you’re looking for), or you may be doing a less-focused search to look for anything that seems odd or out of place. This is harder to do and requires more experience, so you know what “odd or out of place” looks like.
In Microsoft 365, you have many potential sources of data about what users, threat actors, and the system are doing. The Microsoft 365 unified audit log, Entra ID sign-in logs, and Graph activity logs are three common data sources. Microsoft and its competitors in the security market would all like you to buy an SIEM (security information and event management) system, such as Microsoft Sentinel or Varonis. While these systems certainly make threat hunting easier, you can get started without one.
Basic Threat Hunting in Exchange Online
Mezba Uddin wrote a solid Practical 365 article, “Using Audit Logs and the Graph API to Investigate Security Incidents in Exchange Online”, that covers a common threat hunting scenario: you know, or suspect, that your Exchange Online system has been compromised somehow, and you want to gather evidence. The article includes a companion script that covers hunting, using Graph API and unified audit log data, for five common scenarios: malicious inbox rules, anomalous amounts of outbound email, mailbox permission changes, suspicious access to mailboxes, and suspicious mailbox exports. Because he’s written a script to do the work for you, this is a really gentle introduction to the mechanics of how you actually look for evidence after a known compromise. The script also includes code to block affected accounts, which is very much a piece of knowledge you need for a variety of scenarios.
The rate of business email compromise (BEC) attacks is steadily rising—Arctic Wolf estimates that 70% of businesses were targeted in 2024— so the odds are good that this one script will be useful to you by itself. It’s a good source for you to see how such tools are built, too.
More Advanced DIY Threat Hunting
Microsoft’s security center has multiple articles that show example queries that can be used to identify specific indicators of compromise (IOCs). For example, this article on the Russian “Void Blizzard” threat actor includes sample queries for “determine successfully delivered phishing emails” and “phishing link click observed in network traffic,” among others. Looking at these often-complex KQL (Kusto Query Language) queries can be enough to scare you away from even attempting your own hunting, which is a shame. The good news is that it’s easier to get started than you may think.
First, go read Mezba Uddin’s article “Securing Microsoft 365 With Graph Activity Logs.” It outlines how to enable Graph activity logs (which are off by default) and put them into an Azure Log Analytics workspace. This isn’t free, but it’s also not terribly expensive, and having the logs centralized makes it much easier for you to query them over time.
Second, start in on Microsoft’s “Must Learn KQL” course. This free course, created by Microsoft’s Rod Trent, will help you understand how KQL works and how to use it for practical queries. If you’re already familiar with other query languages, you’ll have an advantage. You’ll learn how to use KQL to filter and query data, including from Azure Log Analytics, and what you learn applies directly to Sentinel.
Third, start building some example queries of your own. These can be as simple or complex as you like, and of course, you can adapt existing queries. The skill of creating and refining queries takes time to build, and it’s important to remember that quote about evidence and absence: just because your query doesn’t produce results showing an issue does not mean that the issue isn’t present. As you get more skilled with knowing both what to look for and how to interpret the results, you’ll become increasingly able to identify and respond to both threats but also incidents.
