Locked Shields, organized by the NATO Cooperative Cyber Defence Centre of Excellence (CCDCOE), is the world’s largest and most complex live-fire cyber defense exercise. National blue teams, typically made up of military cyber commands, government CERTs, and national security agencies, work alongside specialists from industry and academia to defend a large, realistic, pre-compromised infrastructure against a professional red team.

The conditions are deliberately harsh: unfamiliar systems, constrained virtual machines, many security tools running in parallel, and very little time. That makes Locked Shields a stress test not only for the defenders, but also for every tool they bring.

Several participating teams used THOR APT Scanner during Locked Shields 2026. After the exercise, we asked how they used it, where it helped, and what got in their way. Their feedback covered deployment, detection, performance, automation, machine-assisted analysis, and usability.

How teams used THOR

Building a baseline before the exercise

One team backed up every machine during the familiarization phase and ran offline THOR scans across the resulting file copies and disk images. Once they received access to the pre-compromised systems, they scanned them again and compared the results.

The differences between the reference baseline and the exercise state gave them a fast view of what had changed on most systems before the live phase had even started.

Automating scans across the fleet

Another team deployed THOR to all compatible systems through Ansible playbooks. Results were forwarded to a central system for alerting and response, where the team built custom status reports and could quickly pivot from THOR findings.

They described THOR as instrumental in their ability to detect and respond to numerous threats during the exercise.

Scanning network and forensic evidence

The same team carved files transferred over the network and scanned them automatically using a THOR Forensic Lab license. They also ran THOR as a worker inside OpenRelik for triage and analysis of forensic cases.

Both integrations worked reliably in their setup and helped shorten case turnaround times.

Triaging unknown systems and validating DFIR work

One team used THOR to obtain an initial assessment of systems whose compromise status was unknown. This helped them decide where to focus their investigation first.

Another DFIR team used THOR throughout both the investigation tasks and the live-fire phase. They cleared most major DFIR tasks on the first day and reported that every piece of malware and suspicious artifact they identified during the exercise was detectable by THOR. For them, THOR served as a validation layer for the rest of their triage workflow.

One returning team summarized its experience more directly: “As always, we’d be lost without it.” They again reported that THOR surfaced findings their other tools had missed.

What worked

Across the feedback, four themes appeared repeatedly:

• Detection confidence. Teams used THOR’s findings as a confidence check for their own investigations. Among the teams that responded, none reported a piece of malware they had identified that THOR had missed.
• Baseline comparison. Scanning backups offline and comparing them with the compromised exercise systems proved especially effective in this format.
• Triage speed. Results arrived quickly enough to help teams prioritize systems and evidence under time pressure, although performance varied on the weakest virtual machines.
• Automation. Portable binaries, configuration-driven scans, and machine-readable output made it possible to integrate THOR into Ansible deployments, central alerting systems, network-carving workflows, and forensic pipelines.

What teams asked us to improve

The criticism clustered around three areas: performance on constrained systems, easier integration with LLM-assisted analysis, and a lower barrier for analysts using the platform for the first time.

Performance on constrained systems

The performance feedback was mixed. One team deployed THOR across systems with widely different hardware specifications and reported no noticeable impact on normal system performance. Teams working on the weakest exercise virtual machines, while also running several other security tools, saw higher load and sometimes waited longer than they wanted for actionable results.

THOR performs deep inspection across many different artifact types, so a complete scan is not free. On a low-resource system that is already busy, that cost becomes visible.

Much of the impact can already be controlled through scan configuration. Quick scan mode, selective module activation, CPU limits, file-size limits, and other scan options can substantially change runtime and resource use. Teams that prepared and tested a tuned profile before the exercise had a different experience from teams that ran a broad default scan under time pressure.

The lesson for us is not merely that tuning options exist. They need to be easier to find, understand, and apply before a scan starts. Better presets and clearer guidance for low-resource and time-critical environments are therefore just as important as further technical optimization.

THOR v11 is a substantial architectural rebuild rather than another incremental refactor, with roughly 75 percent of the codebase newly developed. The new architecture gives us more room to improve performance and resource handling, but it does not remove the basic trade-off between scan depth, runtime, and system load.

Better context for LLM-assisted analysis

The strongest recurring request was an easier way to use THOR results in LLM-assisted analysis. During the exercise, teams had to parse JSON output and reports themselves before passing selected data to a model for prioritization.

They asked for a comprehensive API, including alert management, structured output with enough surrounding context, and a direct integration point for LLM-based workflows. One participant also made an important point: an interface designed for machine use can lower the barrier for humans. In an exercise with dozens of unfamiliar tools, the ability to query a well-documented interface in natural language can become part of the onboarding process.

This request spans more than the scanner alone. THOR v11 addresses the structure and availability of scan data. Alert management and analyst workflows belong to the surrounding platform and its APIs.

The THOR v11 Tech Preview introduces several building blocks for this:

• Structured objects and JSON v3. Modules expose inspectable objects such as processes, registry entries, services, event log records, and browser artifacts rather than only flat text findings. The nested JSON output preserves the relationship between a finding, its reasons, signatures, and matches.
• Audit Trail. A separate output records every object processed and assessed by the enabled THOR modules, including objects that received no score and would not appear in a standard findings report. It records what THOR processed, not every action that occurred on the host.
• Plugin interfaces. Scan plugins can add new data sources, while output plugins can pass findings and artifacts into external workflows. Customers and partners can therefore support their own formats and pipelines without waiting for a native integration.

Our research team is also developing THOR Lens as an open-source reference implementation under Nextron Labs. Lens indexes the Audit Trail locally and turns it into a searchable timeline. Analysts can start with a high-scoring finding and pivot through parent and child processes, paths, hashes, users, services, and registry locations into the surrounding evidence.

Lens also exposes focused query functions through an MCP server. An LLM-based worker can request relevant slices of indexed data instead of receiving a multi-gigabyte log in a prompt. Its output is stored as reviewable annotations, with machine-generated work kept visibly separate from human analysis.

Together, these components are intended to reduce the custom parsing and glue code that exercise teams had to build themselves.

The boundaries matter. THOR remains the detection engine and continues to apply YARA, Sigma, IOCs, and built-in heuristics. LLM-assisted workflows operate around the resulting evidence to add context, correlation, and prioritization. The scope is analysis, triage, and case synthesis, not autonomous remediation. Raw evidence remains authoritative, and the final assessment remains with the analyst.

THOR v11 is currently a Tech Preview for testing and feedback. Object structures and command-line behavior may still change. The current stable release remains our recommendation for production and other critical environments until the final release. THOR Lens is a research project and reference implementation, not a commercially supported product. The capabilities described here reflect current development and product direction, not committed release dates.

Lowering the barrier for first-time analysts

Analysts using the Analysis Cockpit for the first time found the number of available options overwhelming. The distinction between events and cases was also not immediately clear without an introduction.

That is valid criticism. Locked Shields compresses product familiarization into a few hours, exposing usability problems that may be less visible during a normal deployment.

Current development work includes faster baselining to suppress known-good activity, case-free event handling for confirming or dismissing events without unnecessary administration, score-based filtering, and modernized interfaces across the platform. The underlying lesson is simple: a capability does not help during an incident if an analyst cannot find or understand it under pressure.

Why this matters beyond the exercise

Locked Shields combines unfamiliar infrastructure, constrained resources, a live adversary, and analysts working under real-time pressure. Those conditions are artificial, but they resemble many of the practical problems teams face during a real incident response engagement.

What stood out was the range of ways teams used the same scanner: offline comparison of disk images, automated deployment across a fleet, scanning of network-carved files, processing inside a forensic pipeline, initial triage of unknown systems, and validation of hands-on DFIR work.

That range is important. THOR should fit into the workflow a team already has rather than force the team to build a new workflow around the scanner.

We thank the participating teams that used THOR under these conditions and told us plainly what worked and what did not. Several have already asked to work with us on deeper automation before next year’s exercise, and we plan to continue those discussions.

Want to see how THOR performs in your environment? Get in touch.