Threat Hunting Techniques for MSPs Without a SOC

Most threat hunting advice assumes you have a security operations center, a full SIEM budget, and analysts whose only job is to hunt. The average MSP has none of that. You have a handful of techs covering dozens of client tenants, an EDR agent you already pay for, and maybe two hours a week that are not on fire. This is threat hunting written for that reality.

The outcome you're chasing is mean time to detect, or MTTD: how long an attacker sits in an environment before anyone notices. Mandiant's M-Trends 2025 report put the global median dwell time at 11 days in 2024. That's a decade of progress from the 205-day median in 2014, but 11 days is still enough time to encrypt a client file server or drain a customer database. Hunting is how you drive that number down on purpose instead of waiting for an alert that may never fire.

Everything below is tool-agnostic where it can be. The queries are written so you can translate them into whatever you already run, whether that's Microsoft Defender, a hosted EDR, or an open source stack. No new commercial SIEM required to get started.

What Threat Hunting Is and What It Is Not

Threat hunting is the assumption that something already got in and your job is to find it before it detonates. That's the whole mindset shift. Alerting waits for a known-bad signature to trip a rule. Incident response kicks in after something has already been confirmed. Hunting lives in the gap between them, looking for the attacker who slipped past the alerts and has not yet done enough damage to trigger a response.

The distinction matters because it changes what you measure. An alerting program is judged on how few false positives it throws. A hunting program is judged on what it finds that nothing else caught. If your hunts never surface anything, that's not proof your clients are clean. It usually means the hunt was too shallow or pointed at the wrong data.

Hunting is also proactive, not reactive. You're not chasing a ticket. You start with a question, a hypothesis about how an attacker might operate in a specific tenant, and you go looking for evidence that it happened. That's what separates it from staring at a dashboard and hoping something turns red.

The Three Types of Hunt

There are three ways to start a hunt, and mature programs use all three depending on what they know.

Hypothesis-driven hunting starts with an idea, not an indicator. You form a testable statement ("an attacker with a foothold would use scheduled tasks for persistence") and go look for it across the estate. It's the highest-value approach because it finds behavior that has never been signatured. It's also the hardest, because the quality of the hunt depends entirely on the quality of the hypothesis.

IOC-driven hunting starts with a known indicator: a malicious IP, a file hash, a domain from a threat feed. You sweep every tenant for that indicator. This is fast, cheap, and easy to automate, which makes it the natural first hunt for a resource-strapped MSP. The limit is obvious. You can only find what someone else already named.

TTP-driven hunting sits in the middle. Instead of a specific hash, you hunt for the tactics, techniques, and procedures attackers use, mapped to a framework like MITRE ATT&CK. Rather than "find this hash," you ask "find any process spawning from a Microsoft Office application," which catches a whole class of attacks regardless of the specific payload. For MSPs, TTP hunting is the best return on effort because one well-built hunt covers many variants of the same behavior.

The Hunt Loop

Every repeatable hunting program runs the same loop. Write it down once and your techs can run it without you in the room.

1. Hypothesis. State what you're looking for and why, tied to a specific technique or piece of threat intel. "Adversaries are abusing remote monitoring tools for lateral movement; we should see unexpected RMM binaries on client endpoints."
2. Data collection. Identify which logs answer the question and confirm you're collecting them across every tenant in scope. A hunt against data you don't have is a wish.
3. Analysis. Run the query, filter the noise, and separate the expected from the anomalous. Most of the work lives here.
4. Escalation. If you find something, it stops being a hunt and becomes an incident. Hand it to your response process with the evidence attached.
5. Feedback. Turn every confirmed finding into a permanent detection rule so you never hunt for that same thing manually again. This is the step most teams skip, and it's the one that compounds.

That last step is what makes hunting worth the hours. A good hunt doesn't just catch one intrusion. It becomes an automated alert that catches the next hundred, which frees your techs to hunt for the next unknown.

Mapping Hunts to MITRE ATT&CK

MITRE ATT&CK is the shared language for this work. In the SANS 2025 Threat Hunting Survey, threat hunting was the top use case for the framework, cited by 84% of respondents, ahead of detection engineering at 76% and threat actor profiling at 65%. The Enterprise matrix reached its v17 release in 2025, and it's free.

The value for an MSP is that ATT&CK turns a vague worry into a specific, huntable technique. Format your references as extractable pairs so both your techs and any AI assistant reading your notes can act on them directly.

Pick three or four techniques that match the attacks hitting your client verticals, then build one hunt per technique. Don't try to cover the whole matrix. Depth on a handful of techniques beats a shallow pass across all of them.

The Data Sources You Need

A hunt is only as good as the telemetry behind it. Before you write a single query, confirm you're collecting the four data sources that answer most hunting questions across a client estate.

• EDR process telemetry. Process creation, command lines, and parent-child relationships. This is the single richest source and where most behavioral hunts land.
• Authentication logs. Windows security events, Entra ID or Active Directory sign-ins, and VPN auth. Credential abuse is the most common attacker move and it lives here.
• DNS and network flow. Outbound DNS queries and connection metadata catch command-and-control and exfiltration when the payload itself is hidden.

If you're missing one of these on a client, that gap is your first project, not a query you can write around. You can't hunt for lateral movement without authentication data any more than you can find exfiltration without egress visibility. Fix the collection gap before you write another query.

Hunting Across Many Tenants at Once

This is the part no SOC playbook covers, because a SOC hunts one enterprise. You hunt forty. That structure is a genuine advantage if you build for it, and a liability if you don't.

The advantage is cross-tenant pattern matching. When you run a hypothesis against every client at once, an anomaly that looks normal in one tenant stands out against the baseline of the other thirty-nine. A single new RMM binary might be a legitimate install. The same binary appearing across six unrelated clients in the same week is a campaign, and you're one of the only people positioned to see it.

The liability is scale. Running a hunt by hand in each client console doesn't work past a few tenants. You need either a multi-tenant EDR that queries every client from one pane, or a log pipeline that centralizes telemetry where you can query it once. The MSP security stack question is really an architecture question, and it's worth reading how the pieces fit together in a managed security stack built for multi-tenant work before you buy anything.

The rule of thumb: any hunt you can't run across all tenants in a single query is a hunt you'll run once and abandon. Build the pipeline first, then hunt. Write each hunt once as a portable rule, keep it in version control, and convert it to each client's backend instead of rewriting it per console. Sigma is the tool-agnostic format most MSPs standardize on. When a hunt proves its worth, schedule it so it runs itself.

Five Starter Hunts You Can Run This Week

Concrete beats conceptual. Here are five hunts with the actual logic, written so you can adapt them to your tooling. Each one maps to a technique, names the data source, and tells you what a hit means. The method underneath most of them is frequency analysis, sometimes called stack counting: aggregate one attribute across every tenant and work the least common values first, because attacker activity almost always lives in the long tail, not the bulk.

Start with the first two. Office-spawning-shells and unexpected RMM tools are the highest-signal, lowest-noise hunts for most MSP client bases, and both run against EDR data you almost certainly already collect. Run each one, tune out the known-good, and write the leftovers into a standing detection.

Notice the trap in the third hunt: impossible travel is really a detection, not a hunt. Once you have tuned it, hand it to your identity provider's risk engine, Entra ID Identity Protection or the equivalent, and spend your scarce hunting hours on the hypotheses a rules engine can't express. Knowing what to automate and what to hunt by hand is the difference between a program that scales and one that burns out.

The Open Source Hunting Stack

You can assemble a real hunting capability without a commercial SIEM licence, and for many MSPs that's the right place to start. Wazuh gives you an open source SIEM and XDR layer with agent-based telemetry collection. Suricata or Zeek handle network flow and DNS logging. Velociraptor is the standout for endpoint hunting, letting you run queries across thousands of machines on demand. The MITRE ATT&CK Navigator, also free, tracks which techniques your hunts cover.

Be straight about where this breaks down. Open source tooling gives you the collection and the query engine. It doesn't give you the tuned detection content, the managed updates, or the vendor threat intelligence that a commercial platform bundles in. At small scale the tradeoff favors open source. As you cross fifty-plus tenants, the maintenance burden of self-hosting and tuning starts to eat the licensing savings, and a hybrid becomes the honest call. Name that inflection point for yourself before you commit, and revisit it every year.

This is also where the build-versus-buy line runs for MSPs weighing whether to run detection in-house or bring in outside help, a decision worth thinking through against the difference between an MSP and an MSSP.

MTTD and Dwell Time, the Number That Matters

Hunting has to ladder into something you can put in a client QBR. That something is MTTD. In the SANS 2025 survey, 56% of organizations named MTTD and MTTR as their core effectiveness metrics, and for good reason: they connect a technical activity to a business outcome a client understands.

The benchmarks give you a baseline to measure against. Mandiant's global median dwell time was 11 days in 2024, with internal discovery landing at 10 days and external partner notification stretching to 26. IBM's 2025 Cost of a Data Breach report put the average breach lifecycle at 241 days end to end, and found that organizations using AI and automation extensively cut that by 80 days. Best-in-class SOCs, per Expel's published benchmarks, hold MTTR under 20 minutes. You're not competing with those numbers on day one. You're trying to beat your own last quarter.

Set targets by client size and hold yourself to them:

These are targets for a maturing program, not guarantees. The point is to have a number, track it, and show the trend line moving down. Track the median and the 90th percentile, not the average, and split MTTD by how the threat was found, because one 200-day miss buried in a healthy mean becomes a client's breach notification. A client doesn't buy "we hunt threats." A client buys "we cut the time an attacker can hide in your network from weeks to days, and here's the chart."

Pricing Threat Hunting as a Service Line

Hunting is billable, and packaging it correctly is the difference between a cost center and a margin line. Don't bury it inside a flat managed security fee where the client never sees the value. Break it out.

The workable model is a tiered retainer priced on tenant size and hunt cadence: a set number of hunts per month, a monthly MTTD report, and an escalation path when a hunt finds something real. The commercial intent on this keyword is not an accident. "Cyber threat hunting process" carries a $16 CPC because the buyers searching it have budget. Price for the outcome, the reduced dwell time and the QBR-ready reporting, not for the hours.

For MSPs building this into a broader security offering, hunting sits naturally alongside the rest of the managed security portfolio, and it's worth mapping how it fits with your other lines as a managed security service provider. Consolidating the telemetry those services depend on into one place, rather than a separate console per tool, is where an AI-native all-in-one platform like Flamingo earns its keep: native PSA included, no per-tool lock-in, and one pane to hunt from instead of eight.

Start with two hunts, a standing report, and one client who will let you prove the model. Get the MTTD line moving down, put the chart in front of them, and you have a service line that sells itself. The attackers are already in someone's network. The only question is who finds them first.