Threat hunting is the capability every security programme claims and few can prove. As Service Delivery Lead in the EU-funded iSOCaaS project, Obrela is contributing an AI-enabled hunting capability built to make hunting measurable, not just faster - including a Threat Hunting Copilot, now in production, that turns a hypothesis written in plain language into a governed, executable hunt.
Detection scales. Hunting does not.
A detection rule is written once, provisioned into a platform, and runs on every event thereafter without further human involvement. A hunt is a different animal. It is a question, asked by a person, against a particular body of data, at a particular moment. Someone has to translate that question into the query language of every platform it must run against, execute it, wait for it, collect what comes back, read it, and decide what it means.
Multiply that by the number of platforms in one estate, then again by the number of environments a managed provider serves, and the arithmetic stops working long before the ambition does. The industry's own data describes the consequence plainly: in the SANS 2025 Threat Hunting Survey, 61% of organisations named skilled staffing shortages as the primary barrier to a successful hunting programme, while the share formally measuring whether their hunting is effective fell from 64% to 51% in a single year. Hunting is being asked for more, and understood less.
That is the problem iSOCaaS asks its partners to solve at a level above any single organisation, and it is the problem the enabler described here was built for.
What we built
OBRELA's response was not to buy a better hunting tool. It was to remove the reason the work was expensive in the first place.
The Swordfish OpenXDR Databus is a technology abstraction layer that homogenises security data and security actions across the vendor platforms customers actually run. Built on top of it, the MDR Threat Hunting Orchestrator takes a single hunt package, authored and governed once in a vendor-neutral model, and executes it in parallel across supported SIEM and XDR platforms, across every environment in scope, in one pass. Our design documentation records the effect on hunt execution as a shift from hours to minutes.
The principle is deliberately narrow, and we state it rather than let a slogan do the work: author and govern once; execute natively everywhere.
What is common across platforms is the hunt's identity, scope, judgement and lifecycle, its name, the environments it applies to, the time windows, the severity and confidence, the MITRE ATT&CK mapping, the triage guidance, the version history. What stays native is the query itself. Each supported engine carries its own implementation of the behaviour, written in that engine's language, because a Kusto query and an XQL query are not translations of one another, and pretending otherwise produces worse hunting rather than better portability.
Critically, the orchestrator does not extract telemetry in order to search it. It sends each platform a query in that platform's own language, and the search executes inside the platform that already holds the data, against telemetry that never moves. Only the results come back, bounded by an explicit ceiling set on the hunt definition. Residency is preserved by construction rather than by policy, which is what makes the capability deployable in a national and cross-border setting rather than only a commercial one.
Where the AI sits, and where it does not
Every security vendor currently has an AI story. The useful question is narrower than the marketing: what specific job is the model doing, what happens when it is wrong, and would the system still be sound without it?
In our design, AI appears at two points, at opposite ends of the process. At the front, the Threat Hunting Copilot turns a hypothesis written in plain language into a structured hunt package. At the back, correlation and summarisation help an analyst read what a hunt returned across several platforms at once. Neither of them decides anything: in both cases a model proposes and a person disposes, and in both cases the system still works without the model, more slowly.
The Threat Hunting Copilot: from a sentence to a governed hunt
The Threat Hunting Copilot is in production. A hunter types the hypothesis the way they would say it out loud - "hunt for WMIC and PowerShell being used to create a volume shadow copy, across Defender and CrowdStrike, last fourteen days" - and receives a complete draft hunt package in return: the indicator lists, the inferred MITRE ATT&CK techniques, an engine-native query for each supported platform, the lookback window, a severity, and a plain-language description of what the hunt looks for and why it matters.
It runs as a staged pipeline rather than one large prompt, so that each stage can be inspected, evaluated and improved on its own. Indicators and the requested time window are extracted first. A sufficiency check then decides whether the hypothesis is fully expressible as indicators alone - a hunt for connections to a known command-and-control address needs no behavioural query, and generating one would add noise and cost for nothing - in which case the pipeline exits early and says so. Otherwise ATT&CK techniques are inferred, one engine-native query is produced per supported platform, written to summarise aggressively rather than return every row behind a hit, and the resulting package is validated for structure and consistency before a person ever sees it.
A hunter reviews and approves every package before it is scheduled. The Copilot is grounded on validated hunts written by our own threat hunting team across all three query languages, so it inherits their conventions rather than inventing its own, and the fields that would make a hunt expensive or dangerous to run sit deliberately outside what it is permitted to touch. Nothing it writes reaches a monitored environment unreviewed. What changes is the shape of the constraint: a hunter's judgement about what is worth looking for is no longer rationed by the hours it takes to express it.
Reading what comes back
At the other end of the process, two models do two different jobs. Entity resolution across disagreeing schemas - determining that a user field in one vendor's result set and a differently named field in another's refer to the same person, or that a host appears in two datasets under different identifiers - is language work rather than security reasoning, and it is high volume, so it is assigned to a locally hosted open-weight model. The cybersecurity reasoning, explaining in plain language why a set of correlated results is interesting and what it appears to indicate, is assigned to a frontier commercial model, invoked on curated hunt results rather than on raw telemetry.
The model's output is treated as a proposal that must remain checkable, not as a conclusion. Every proposed correlation carries the source records it was derived from. Deterministic identifiers are preserved verbatim; where an identity can be resolved deterministically, the deterministic answer is authoritative and the model is not asked. A correlation becomes a lead for an analyst, it does not become an incident, a containment action or a notification without a person.
Correlation is strictly per-customer. The multi-tenancy of the orchestrator is an execution efficiency; it is never a data merge. Where a frontier model is involved, it is reached through an Obrela-operated Azure OpenAI deployment under enterprise terms rather than a public consumer endpoint, pinned to a regional endpoint consistent with the environment being served, with submitted data not used for model training - a distinction that carries more weight in a European public-sector setting than in a purely commercial one. AI enrichment is also off by default and switchable at both service and hunt level: remove it entirely and the orchestrator still executes hunts across every supported platform and every environment in parallel, and the results simply arrive without a written summary. That is the correct dependency relationship between an operational capability and a probabilistic one.
What this contributes to iSOCaaS
iSOCaaS, Intelligent SOC as a Service for European Cyber Resilience, sets out to deliver managed SOC services tailored to sectorial, national and cross-border cyber resilience, integrating shared situational awareness, coordinated incident response and joint preparedness. Its second objective is explicit: to deliver AI-based, beyond-state-of-the-art enablers augmenting SOC capabilities for those three functions.
Orchestrated hunting, with natural-language hunt authoring in front of it, is one such enabler, and it addresses each of the three:
-
Situational awareness. When a hypothesis is developed, from intelligence, from an incident elsewhere, from a published campaign, it runs against every environment in scope in the same pass, rather than reaching each one when an analyst gets to it. With the Copilot in front of the orchestrator, the interval between a hypothesis being formed and being under execution everywhere is measured in minutes. At sectorial and national level, that is the difference between knowing whether a campaign has touched a sector and believing it has not.
-
Incident response. Each hunt returns the matching records, a deeplink that reopens the query in the operator's own console, the ATT&CK techniques the hunt was designed around, and triage guidance authored in advance by the person who designed the hunt, at the moment they understood the behaviour best, rather than improvised by whoever is on shift. Responders receive evidence they can verify, not an alert they must trust.
-
Preparedness. A hunt that finds nothing still produces an outcome. Negative assurance, documented proof that a specific threat behaviour was looked for and not found, is a deliverable, not an absence of one. It is also stated narrowly: no evidence matching this defined hypothesis was found in the platforms that were successfully queried, within the specified window, in the telemetry those platforms retained. It does not assert that an environment is uncompromised. Narrower is stronger, and it is the form that stands up in front of a supervisory authority.
That last point matters disproportionately in this project. iSOCaaS is designed around entities in the essential and important sectors under NIS2 and their supply chains, and it carries accompanying cybersecurity insurance schemes. Both audiences, the regulator and the underwriter, ask the same question of a security programme: not did you find anything, but what did you look for, where, when, and what answered. Because every hunt is submitted as a structured definition and executed through a common pipeline, coverage, completeness, reach, latency and validated-lead rate are emitted by the machinery rather than assembled after the fact.
Where the hunt reaches four of five platforms and the fifth is unreachable, an expired credential, an API outage, a rate limit, the outcome is still delivered, and its status names what did not answer. A system that hides partial failure produces reports that are more comfortable and less true.
What comes next
Three further developments follow from the architecture, at three different stages, and it is worth being explicit about which is which rather than blurring them into a single hopeful tense.
-
In development. The Copilot currently generates engine-native queries from a frontier model's knowledge of each platform's query language. Specialising that generation per platform, with active knowledge of each platform's schema, is the next increment: better field-name accuracy, and each engine's query tuned independently rather than produced in one pass.
-
Under review. Scoping hunts by sector, technology or asset class, so that a campaign targeting a specific control system runs where that system exists. The asset and identity inventory this depends on already exists in the platform.
-
Delivered, and expanding. Hunt definitions are already generated directly from STIX reports in our Threat Intelligence Orchestrator, and the same central intelligence pipeline now feeds indicators into the SIEM estate. The remaining work is coverage: more feeds, more report formats, and a shorter path still from publication to executed hunt.
Each is a capability written once against the Databus, and each therefore arrives across every supported platform and every environment at the same time. That is what an abstraction layer is for, and it is why a capability funded and validated inside iSOCaaS does not stay inside iSOCaaS.
Threat hunting should not be sold as analyst activity. It should be delivered as measurable security assurance. That is the argument, and iSOCaaS is where we intend to prove it at European scale.
Obrela is Service Delivery Lead in iSOCaaS, alongside project coordinator Sphynx, AI development lead CyberSafe, the Hellenic Republic Ministry of National Defence as national CSIRT operator, the Greek Ministry of Digital Governance as national competent authority, Karavias Underwriting Agency, Insuretics and Netsquare. Learn more at isocaas.eu.
Co-funded by the European Union
This project has received funding from the European Union under grant agreement No. 101190388. Views and opinions expressed are those of the author(s) only and do not necessarily reflect those of the European Union or the European Commission. Neither the European Union nor the granting authority can be held responsible for them.