Natural language threat hunting: querying your EDR with AI

Threat hunting has always had a gatekeeping problem. To find an attacker who has quietly established persistence, an analyst needs to write a query - something like “show me all processes spawned by svchost.exe that loaded a network connection within 30 seconds of a scheduled task creation, in the last 7 days, on endpoints not in the baseline.” That is a useful query. It is also one that most analysts cannot write without help, because it requires fluency in whatever query language your EDR happens to use.

Natural language threat hunting changes the access equation. Instead of writing a query, the analyst describes the behaviour they are looking for in plain English. The AI translates that into a structured search against the telemetry. The analyst gets results; the EDR vendor doesn’t have to train every customer on a proprietary DSL.

This post explains how the translation layer works, what it’s actually good at, and where it still falls short.

What the AI is actually doing

The underlying model (GPT-4o, Claude, Gemini - it depends on what you’ve configured) receives the analyst’s plain-text description together with a schema description of the available telemetry fields. It produces a structured query - a filter expression, a time window, field selections - that gets executed against the indexed event data.

A rough example of what that looks like in practice:

Analyst types:

Find all instances where a PowerShell process made an outbound connection to an IP that hasn’t been seen from this endpoint before, in the last 48 hours.

AI produces (internally):

{
  "filter": {
    "process_name": "powershell.exe",
    "event_type": "network_connection",
    "direction": "outbound",
    "is_new_destination": true,
    "time_range": "-48h"
  },
  "fields": ["endpoint_id", "pid", "parent_pid", "destination_ip", "destination_port", "timestamp"]
}

The “is_new_destination” part is where this gets interesting. That is not a field in most EDR schemas - it is a derived signal that requires comparing the connection event against the endpoint’s historical network baseline. A good implementation pre-computes these baselines so the query can still return in a reasonable time. A bad one runs the comparison inline and times out.

Why this matters for smaller SOC teams

The honest reason natural language hunting matters for lean teams is not that it replaces skilled analysts - it doesn’t. It is that it extends the effective range of a Tier 1 analyst who knows what they’re looking for but doesn’t know how to ask for it in the platform’s native query language.

Consider the MITRE ATT&CK technique T1059 (Command and Scripting Interpreter). The detection logic is well-documented. The query to surface it in your telemetry - across Windows, macOS, and Linux endpoints, accounting for legitimate admin activity - is not something a junior analyst writes on their first week. With natural language hunting, that same analyst can type “show me unusual interpreter invocations across all endpoints in the last 24 hours, excluding the IT admin accounts” and get a starting point. They still need to review and interpret the results. But they’re not blocked waiting for a senior analyst to help them phrase the question.

This is why LightEDR’s AI analysis includes natural language threat hunting alongside the automated triage capabilities - it serves a different workflow. Alert triage is reactive: an alert fires, AI explains it and suggests next steps. Threat hunting is proactive: the analyst has a hypothesis, and needs a way to test it across the telemetry without writing SQL.

Where it still falls short

Be honest with analysts about the limits:

Ambiguous intent. “Find suspicious PowerShell” is too vague for the AI to produce a useful query. The analyst needs to know enough to describe a behaviour - “PowerShell launching child processes that write files to the Windows temp directory” is queryable; “suspicious PowerShell” is not. The AI can ask a clarifying question, but that breaks the flow.

Cross-entity correlation. Simple natural language queries translate well. Queries that require correlating events across multiple endpoints, or tracking an attacker’s lateral movement path, are harder to express and execute. The AI may generate a query that is logically correct but computationally expensive enough to time out on large deployments.

Novelty. If you are hunting for a technique the model has not been trained on - a zero-day or a very recent threat actor TTP - the AI’s query suggestions are less reliable. It does not know about techniques that post-date its training data. For novel hunting, the analyst still needs to drive.

False confidence. A natural language query that returns zero results is easily misread as “nothing to find here” rather than “the query may have been imprecise.” Training analysts to sanity-check the generated query before trusting a null result is part of making this feature useful.

Getting started with natural language hunting

If you’re evaluating EDR platforms for threat hunting capability, ask the vendor these specific questions:

1. What telemetry fields are exposed to the natural language layer? (Some vendors limit it to a subset of events.)
2. What LLM provider does it use, and can I bring my own? Air-gapped environments need an on-premise option like Ollama.
3. Does the system show the generated query before executing it, so analysts can review and learn?
4. What’s the retention window for huntable telemetry?

LightEDR supports 90-day telemetry retention and integrates natural language hunting with five LLM providers - Anthropic, OpenAI, Azure OpenAI, Gemini, and Ollama - so teams with data residency requirements or air-gap constraints can still use the feature with a local model. The generated query is always visible before execution.

If your SOC team is exploring threat hunting but finding the query-language barrier a blocker, reach out to discuss your setup.