Threat hunting with AI can go sideways fast if you do it wrong.
Ask a broad question, get a broad pile of results, and it is very easy to mistake motion for progress. The model sounds confident. The output looks busy. The search results contain scary strings. None of that means you have a finding.
The Cribl MCP is useful for threat hunting for a more specific reason: it shortens the loop between a question and the evidence that can answer it.
It does not replace the hunt. It does not decide impact for you, but it can remove a lot of the small friction that usually slows an investigation down: query syntax, field names, time-window math, grouping, sorting, and the first pass of correlation. That means you can spend more of your time and attention on the part that matters:
What did the system do and what actually happened?
That question should be the center of the hunt.
Why speed is not enough
The first interesting results were not surprising. Internet-facing systems attract a steady stream of ugly web requests: SQL injection probes, XSS payloads, directory traversal attempts, old CVE checks, scanner noise, and payloads copied from tools that have been making the rounds for years.
That traffic can be useful, but it is rarely interesting by itself. Mature environments expect to see it. They expect edge controls to catch most of it. They expect a lot of it to be automated, opportunistic, and disposable.
The better question is what you can prove after the noise appears:
Did the request reach the application or stop at the edge?
Did the response behavior change in a way the payload would require?
Did the same signal show up in another dataset?
Did anything happen after the request that suggests execution, access, or persistence?
Did the telemetry answer the question, or did it expose a blind spot?
That is where the MCP helped. It made it easier to keep asking the next small question while the context was still fresh.
What is the Cribl MCP?
MCP stands for Model Context Protocol. In this case, the Cribl MCP lets an AI assistant interact with Cribl Search. You describe the behavior you want to investigate, and the assistant can translate that into searches, run them, summarize the results, and suggest the next question to ask.
That last part matters.
The recommendations are useful, but they get a lot better when they are tied back to evidence. I want the assistant to tell me what it thinks, why it thinks that, and what data would make the answer stronger so I can make an informed decision.
Threat hunting has a lot of little speed bumps. Translate the question into syntax. Get the time window right. Remember the field name. Fix the sort. Wait for the result. Realize you ran the search slightly wrong. Do it again.
None of that is especially hard, but it slows you down. The MCP removed a lot of that friction, which made it easier to follow the trail while the context was still fresh.
Setting it up is pretty simple too. If you want to try it yourself, start with the Cribl MCP setup docs.
Start with boring
The fastest way to overreact during a hunt is to skip normal. Without a baseline, every odd user agent, path, source network, status code, and response size can feel meaningful. With a baseline, a lot of scary-looking traffic becomes background radiation, and the truly strange events stand out more clearly.
This was a useful starting prompt:
Using the Cribl MCP, help me build a baseline of normal activity for the last 30 days across access, system, and network logs. Summarize top paths, status codes, user agents, source IPs, request patterns, audit activity, system signals, and obvious outliers.
The output was not a finding. It was a map. It gave me a working sense of what "normal" looked like before I started pulling on unusual behavior.
One useful variation was asking the assistant to save the baseline as a Markdown note:
Create a concise Markdown baseline from these results. Include the normal patterns, expected noisy sources, common status-code behavior, and questions that should be revisited if later searches find anomalies.
That made the baseline portable. I could bring it into a new context window, share it with another analyst, or use it as the anchor for a later hunt.
Prompts that produced useful evidence
There is no magic threat-hunting prompt. If there were, every SOC would probably be using it.
The prompts that worked best had four parts:
A scope
A time window
The behavior I cared about
The decision I was trying to make
These were the patterns that held up.
Find leads, not findings
Find external requests that look security-relevant or unusual over the last 30 days. Group the results by behavior, response, source, and tooling pattern. Treat these as leads, not findings.
That last sentence matters. I did not need the assistant to discover that SQL injection and XSS exist. I needed it to help separate common scanner noise from activity worth validating.
Good lead output grouped activity by behavior: similar payloads, repeated paths, response patterns, source tooling, and whether the same request shape appeared more than once. That made it easier to pick the next question instead of reacting to whichever payload looked loudest.
Pressure-test successful-looking responses
For suspicious requests that returned 200 or 500, show the paths, response times, domains, status codes, response sizes, and user agents. Help me decide whether each payload appears to have executed, reached a real handler, or only received a generic response.
This is the prompt that keeps the hunt honest.
A suspicious payload with a 200 or 500 deserves attention, but it is not proof of compromise. Some applications return 200 for soft errors. Some scanners hit paths that always return the same page. Some error responses look dramatic but never reach the vulnerable code path.
The useful move is to compare the response to what the payload was trying to do.
If a time-based SQL injection payload asks the database to sleep for 20 seconds and the response comes back in 31 milliseconds, that payload did not execute. If an XSS payload appears in a response body, that is a stronger reason to keep digging. If a traversal attempt returns the same byte count as a normal 404, that probably tells a different story than a response that suddenly contains file-like content.
Hunt the response, not just the request.
Correlate across other surfaces
Take the strongest indicators from this hunt and correlate them across other datasets when available: CDN logs, WAF logs, public API logs, authentication logs, application logs, runtime detections, network flow logs, and audit logs. Only return correlations that add useful context.
One dataset rarely tells the whole story.
Edge logs can show what hit the front door. WAF logs can show whether a rule blocked or challenged the request. Application logs can show whether the request reached meaningful code. Authentication logs can show whether the same source attempted account access. Runtime detections and network flow logs can show whether anything unusual happened after the request landed.
That correlation is where noisy traffic starts to become useful. A single request from a disposable IP might not matter. The same payload family appearing across multiple surfaces, tied to a tenant, request ID, path sequence, or tooling fingerprint, is a better reason to keep investigating.
Force a pause before the next search
Before running the next search, summarize what we know, what we do not know, and the next best question to ask. If the available telemetry cannot answer the question, say that directly.
This became one of my favorite prompts.
AI makes it easy to run the next search, which is both useful and dangerous. Fast searches can turn a focused hunt into wandering. Forcing a short summary before the next query keeps the investigation anchored.
The assistant had to explain why the next search mattered. If it could not do that, I probably did not need to run the next search yet.
Use the Cribl MCP to prove impact
The best way to use the Cribl MCP in a hunt is not to ask it to find something scary. It will find scary-looking things. The internet is generous like that.
The better move is to use it to turn noisy leads into evidence. Treat suspicious activity as a starting point, not a conclusion. Some of it will be common automated probing. Some of it will be obviously nonsense. Some of it will come back with responses that deserve a second look. None of that makes it a finding yet.
The useful question is:
What would I expect to see if this actually worked?
That question changes how you prompt. Ask the MCP for a recommendation, but make it show its work. Have it pull back the facts that would make the concern true or false:
What did the system return, and how long did it take?
Did the request hit something real, or was it just a nonsense path?
Did related service events, error spikes, or unusual response patterns appear?
Did the same source, user agent, request ID, tenant ID, path, or payload pattern show up anywhere else?
What changed from the baseline?
Then pressure-test the recommendation:
Does the available telemetry actually answer the question?
Did the response behavior change in a way the payload would require?
Did the payload show up anywhere it should not, like a response body, error, or downstream event?
Did anything line up with expected testing or known benign activity?
If the answer is "not enough data," what would settle it?
This is where the MCP helps the most. It makes it easier to ask the next small question without losing the thread, while still forcing you to decide whether the evidence is strong enough.
Sometimes the answer will be yes. The data shows noisy attempts with no evidence of impact.
Sometimes the answer will be more subtle. A source or pattern is worth tracking because it repeats across more than one place. That is more useful than chasing every disposable IP or email address in a scan.
And sometimes the answer will be, "this data cannot prove that by itself." That is still a good outcome. It tells you where the boundary is. It gives you a follow-up. It keeps you honest.
That is the point. The MCP does not need to make the hunt dramatic. Used well, it makes the hunt easier to keep grounded.
What to take away
The MCP helped most when I used it to maintain investigation discipline. These are the habits I would carry into the next hunt.
Start with normal. A baseline turns weird events into comparable events. Without it, everything looks special.
Treat suspicious requests as leads. A payload is not a finding. A scanner string is not impact. Let the evidence earn the escalation.
Hunt the response. Status code, latency, response size, content type, error behavior, and downstream events often matter more than the payload itself.
Prefer durable indicators. IPs rotate. Email addresses and hostnames can be disposable. Payload families, tooling fingerprints, request sequences, route patterns, tenant IDs, and request IDs usually survive longer.
Make each result choose the next question. The MCP makes searching faster, but speed only helps if every query tightens the investigation.
Write down the unknowns. "We cannot prove this with the available telemetry" is better than pretending the data says more than it does.
Final thoughts
Where the MCP clicked for me was the rhythm. Ask a question, read the evidence, ask a better The Cribl MCP clicked for me when I stopped treating it like an answer machine and started treating it like a way to keep the hunting loop tight:
Ask a question. Pull the evidence. Pressure-test the result. Ask a better question.
That is the line I want to keep. Let the tool speed up the loop, make recommendations, and show its receipts.
Get curious. Check the response. Keep hunting.
