KQL threat hunting with Microsoft Sentinel: a practical guide for UK SMEs

For many UK SMEs, Microsoft Sentinel is most useful when it helps the team move from reacting to alerts to actively looking for suspicious behaviour. That is where threat hunting comes in. In simple terms, threat hunting is the practice of searching your logs for signs of activity that may not have triggered an alert yet, but still looks unusual or risky.

KQL, or Kusto Query Language, is the query language used in Microsoft Sentinel. It lets you ask questions of your data in a structured way. You do not need to be a data scientist to use it well. For most small teams, the goal is not to write clever queries for their own sake. The goal is to find useful patterns, confirm whether something deserves attention, and improve detection over time.

This article is written for UK SMEs that want a practical starting point. It assumes you have limited time, a small security team, and a need to make sensible trade-offs. The aim is to help you get value from Sentinel without turning it into an overcomplicated project.

What threat hunting means in Microsoft Sentinel

Threat hunting is a proactive activity. Instead of waiting for an alert, you look for signs of compromise, misuse, or policy drift across your logs. In Microsoft Sentinel, that usually means searching identity, endpoint, cloud, and network data for patterns that deserve a closer look.

It is helpful to think of Sentinel as the place where your security data comes together. KQL is the tool you use to interrogate that data. A hunt might start with a question such as: are there sign-ins from unusual locations, admin activity outside normal hours, or endpoints running processes that do not fit the usual pattern?

How KQL supports investigation and detection

KQL is designed for filtering, grouping, joining, and summarising log data. That makes it well suited to security work because most investigations begin with a simple question and then narrow down from there. For example, you may start with a broad search for failed logins, then filter to a specific user, then look at the devices, IP addresses, or time of day involved.

For SMEs, the value of KQL is that it allows repeatable analysis. Once a useful query is built, it can be reused, adapted, or turned into a scheduled detection. That is a practical way to make the most of a small team.

Where threat hunting fits alongside alerts and incidents

Threat hunting does not replace alerts or incident response. It sits alongside them. Alerts tell you when a rule has been triggered. Incidents help you manage and investigate those alerts. Hunting is broader and more exploratory. It is how you look for things that are not yet obvious enough to generate an alert.

For a small team, a sensible model is to use alerts for known bad patterns, incidents for triage and response, and hunts for improving visibility and finding gaps. That keeps the work balanced and avoids trying to make every question into a high-severity alert.

Getting the right data into Sentinel

Good hunting depends on good data. If the logs are incomplete, delayed, or inconsistent, even a well-written query will only tell part of the story. Before spending too much time on hunts, it is worth checking whether Sentinel is receiving the data you actually need.

Useful log sources for SMEs

Most UK SMEs get the best return from a focused set of sources rather than trying to ingest everything. The most useful sources usually include identity logs, endpoint telemetry, and key cloud service logs. Identity logs help you understand who signed in, from where, and whether the sign-in looked normal. Endpoint logs show process activity, device behaviour, and security events on laptops and servers. Cloud service logs help with administrative actions and access to business-critical systems.

If your business uses Microsoft 365 heavily, identity and cloud activity are often the first places to look. If you have a managed endpoint platform, make sure the telemetry is actually flowing into Sentinel and that the fields you need are present. A hunt is only as good as the data behind it.

Common visibility gaps to watch for

Small teams often run into the same gaps. One common issue is partial logging, where only some devices or accounts are covered. Another is poor retention, which means you cannot look back far enough to spot patterns. A third is inconsistent naming or tagging, which makes it harder to group related activity.

It is also common to have strong visibility in one area and weak visibility in another. For example, you may have decent endpoint logs but limited identity detail, or the other way round. That matters because attackers often move between identity and endpoint activity. If one side is missing, your hunt may miss the full picture.

Writing useful KQL queries without overcomplicating it

Many people assume KQL has to be complex to be useful. In practice, the best hunting queries are often simple. Start with a clear question, use a narrow time window, and only add complexity when it improves the result.

Basic query structure and filtering

A basic KQL query usually starts by selecting a table, then filtering to the records you care about. For example, you might look at sign-in logs, filter to failed attempts, and then narrow by user, device, or country. The key is to reduce noise early.

Think of the query as a funnel. First, define the data source. Then filter out what is clearly irrelevant. Then group the remaining records into something meaningful, such as counts by user, device, or source IP address. This approach is easier to maintain than trying to build one large query that does everything at once.

It also helps to use comments and keep queries readable. If a query is going to be reused by someone else, or by you in three months, clarity matters more than cleverness.

Using time ranges, joins, and summarisation

Time ranges are important in hunting because suspicious behaviour often only becomes visible when you compare activity over a period of time. A short window can help you spot immediate issues, while a longer window can reveal patterns such as repeated failed sign-ins, unusual admin activity, or a device that behaves differently from its peers.

Joins allow you to combine related data from different tables. In security work, that can be useful when you want to connect identity events with endpoint activity or correlate a user account with a device. Use joins carefully, because they can make queries harder to read and more expensive to run. For a small team, the rule is simple: only join data when it helps answer the question.

Summarisation is one of the most useful KQL features for hunting. It lets you group records and count how often something happened. That is often enough to highlight outliers. For example, if one user has far more failed sign-ins than everyone else, or one device is generating a different pattern of events, that is worth a closer look.

Practical hunting ideas for common suspicious activity

Good hunts are usually based on realistic behaviours, not theoretical edge cases. For SMEs, the most useful starting points are identity anomalies and unusual endpoint activity. These are common places for misuse, mistakes, or early signs of compromise.

Identity anomalies and unusual sign-ins

Identity is often the first thing to check because it is the front door to most business systems. Useful hunts include repeated failed sign-ins, sign-ins from unusual locations, logins at unusual times, and access to privileged accounts that does not fit the normal pattern.

It is also worth looking for changes in behaviour. A user who normally signs in from one region and one device may suddenly appear from somewhere else, or begin accessing systems they do not usually use. That does not automatically mean malicious activity, but it is a sensible place to investigate.

For SMEs, context matters. A remote worker, a travelling director, or a third-party support engineer may all create unusual patterns that are legitimate. The point of the hunt is to separate expected exceptions from activity that needs explanation.

Endpoint and process activity worth checking

Endpoint hunts are useful when you want to understand what is happening on laptops and servers. Look for unusual process launches, scripts running where they are not normally expected, or administrative tools being used in ways that do not match your standard operating model.

It can also help to look for process chains that do not fit the environment. For example, a document application spawning a command-line process, or a user session launching tools that are normally reserved for IT staff, may deserve attention. The aim is not to treat every unusual event as malicious, but to identify activity that is worth validating.

If you already have endpoint detection in place, use hunts to complement it. Alerts may tell you that something crossed a threshold. Hunting helps you ask whether there is a wider pattern behind it.

Turning hunts into repeatable detections

One of the biggest benefits of threat hunting is that it can improve your detection coverage. If a hunt keeps finding the same kind of suspicious activity, that is a sign it may be worth turning into a scheduled analytic rule.

When a hunt should become an analytic rule

A hunt should become a detection when the pattern is repeatable, meaningful, and worth alerting on. In practice, that means you have seen the behaviour more than once, you understand why it matters, and you can describe what would make the alert actionable.

Not every hunt should become a rule. Some are exploratory and only need to run occasionally. Others are too noisy to alert on directly, but still useful for periodic review. A good test is whether the result would help the team make a decision without too much manual interpretation.

If a hunt becomes a detection, keep the logic as simple as possible. The more complex the rule, the harder it is to maintain and the more likely it is to drift away from the environment it was built for.

Keeping detections relevant and manageable

Detections need maintenance. Business systems change, users move roles, devices are replaced, and normal behaviour evolves. A rule that was useful six months ago may now generate noise or miss important activity.

For SMEs, it is better to maintain a smaller number of useful detections than a large number of weak ones. Review what each rule is trying to catch, what it is missing, and whether it still reflects the way your business operates. That keeps the workload realistic and the signal useful.

Reducing false positives and improving signal quality

False positives are not just an annoyance. They consume time, reduce confidence, and can cause important alerts to be ignored. The aim is not to eliminate them entirely, which is unrealistic, but to keep them at a level your team can manage.

Tuning queries for your environment

Tuning starts with understanding what normal looks like in your organisation. A query that works well in one business may be too noisy in another. For example, a company with many remote workers will see different sign-in patterns from one with a single office. A business with a small IT team will also have different admin activity from one with several support functions.

Use your own data to refine thresholds and filters. If a query is flagging activity that is clearly expected, adjust it. If it is missing obvious cases, broaden it. The best tuning is based on real observations, not guesswork.

It is also worth documenting why a query was tuned a certain way. That helps if someone else needs to review it later, and it reduces the chance of undoing a useful change by accident.

Balancing coverage with analyst time

Small teams rarely have time to investigate every possible lead. That means you need to prioritise. Focus on the hunts and detections that protect the most important accounts, systems, and data. A few high-value queries are usually better than a long list of low-value ones.

Think about the cost of each alert in analyst time. If a rule generates frequent low-quality alerts, it may be better to change the logic, reduce the scope, or move it back into a periodic hunt. The right balance is the one that gives you useful coverage without overwhelming the people who have to act on it.

A simple operating model for small teams

You do not need a large SOC to make threat hunting work. You do need a clear process. Even a small team can run hunts effectively if responsibilities are defined and follow-up is consistent.

Who owns hunts, review, and follow-up

Someone should own the hunt schedule, even if that person is also responsible for other security tasks. That owner should decide which questions to ask, which data sources to use, and how findings are recorded. If a hunt identifies something suspicious, there should be a clear path for review and escalation.

For many SMEs, the practical model is shared ownership. IT may manage the platform and data quality, while a security lead or external consultant helps define the hunts and interpret results. The important thing is that nothing falls between roles.

How to track findings and improve over time

Keep a simple record of what each hunt looked for, what it found, and what action was taken. Over time, this becomes a useful source of operational knowledge. It shows which queries are valuable, which ones are noisy, and where your visibility still needs work.

Use the findings to improve your environment. If a hunt repeatedly highlights a gap in logging, fix the logging. If it repeatedly finds legitimate but unusual behaviour, update your baselines or access model. That is how hunting becomes part of continuous improvement rather than a one-off exercise.

For UK SMEs, the main benefit of KQL threat hunting with Microsoft Sentinel is not sophistication. It is consistency. A small number of well-chosen hunts, based on the data you actually have, can give you much better visibility than a large set of rules that nobody has time to maintain.

If you want to build a practical hunting approach, start with one or two high-value questions, keep the queries readable, and review the results regularly. From there, you can decide which hunts should stay exploratory and which ones should become detections.

If you would like help shaping a Sentinel approach that fits your team and your risk profile, speak to a consultant.

Frequently asked questions

What is KQL in Microsoft Sentinel, and why does it matter for threat hunting?

KQL is the query language used in Microsoft Sentinel. It matters because it lets you search and analyse security logs in a structured way. For threat hunting, that means you can look for suspicious patterns, compare behaviour over time, and turn useful findings into repeatable detections.

How can a small UK business start threat hunting without a large SOC team?

Start small. Focus on a few important data sources, such as identity and endpoint logs, and ask simple questions about unusual sign-ins, admin activity, or unexpected process behaviour. Keep the queries readable, review the results regularly, and only turn a hunt into an alert if the pattern is repeatable and worth acting on.