How the Canadian Centre for Cyber Security used frontier AI to accelerate detection engineering

Overview: How the AI-powered detection pipeline works

The Cyber Centre used frontier AI models to create an automated, end-to-end detection engineering pipeline capable of transforming public threat intelligence into validated, production-ready detection rules with minimal human intervention. The pilot project employed multiple agents with distinct roles.

Opus 4.8 was assigned the blue-team role of generating detection logic according to operational specifications.

Mythos was assigned the red-team role of adversarially reviewing the detection logic to identify potential bypasses and challenge its effectiveness.

Together, they form an iterative purple-team loop that produces validated detections for analyst review.

Below is the stepped process for the automated detection engineering workflow as shown in Figure 1:

1. Blue team agent (Opus 4.8): Threat article ingested
2. Blue team agent (Opus 4.8): Proposed detection
3. Red team agent (Mythos): AI generate attack plan
4. Red team agent (Mythos): Lab auto-provisioned
5. Red team agent (Mythos): Attack plan executed
6. Blue team agent (Opus 4.8): Analytic validated
7. Blue team agent (Opus 4.8): Detection rule to production

Figure 1 : Full end-to-end analytic pipeline

Full end-to-end analytic pipeline - Long description

Figure 1 shows the automated detection engineering workflow from threat intelligence ingestion through human review and production deployment. The Blue Team agent, Opus 4.8, is identified in steps 1, 2, 6 and 7, and is responsible for generating and validating detection logic. Steps 3, 4 and 5, identify the Red Team agent, Mythos, as responsible for creating attack scenarios, provisioning a test environment, and executing attack variants. Figure 1 demonstrates how the agents form an iterative purple-team loop that produces validated detections for analyst review.

Typically, these analytic development stages can take anywhere from several hours to one week, depending on complexity and urgency. The pipeline completed the same work in under an hour, and at a scale that would be difficult for human analysts alone.

Test case: Testing the pipeline against a real-world threat scenario

The following test case expands on each stage of the workflow, demonstrating its effectiveness in practice.

Threat article ingested

The analytic pipeline can begin with a range of inputs. This includes threat articles, blogs, incident reports, analyst descriptions, or any other threat source. In this test case, it began by ingesting public threat research from the GitHub: Exploitarium repository, a collection of vulnerability research and exploit proofs of concept (PoCs). (The Cyber Centre is not responsible for the content of the Exploitarium repository and does not endorse it.)

Proposed detection

The model proposed one or more candidate detections, each with a human-readable description of the logic and an associated hunt query. Several of these hunt queries are later combined, along with additional filters, to create a detection.

SELECT Parent.Tag, Child.Tag, action, eventtime, hbs_agent_id
FROM events
WHERE timestamp BETWEEN '{start}' AND '{end}'
    AND hostname IN ('rtlab-ubu01', 'rtlab-web01')
    AND action IN ('PROCESS_EXEC', 'PROCESS_START')
    AND Parent.Tag RLIKE '(?i)(redis-server|php|java|ffmpeg|gogs|ladybird|objdump)'
    AND Child.Tag RLIKE '(?i)(bash|dash|sh|cmd|touch|calc)'

AI generates an attack plan

An attack plan is generated, identifying the required infrastructure, software, and PoCs to be detonated. In this case, the PoCs were included in the repository; however, if no public PoCs were available, Mythos would attempt to create its own.

cd lab/ansible2-vm
ansible-playbook playbooks/scenario-exploitarium-rce-linux.yml \
    -e lab_unsafe_ack=true

cd /opt/lab/exploitarium/c-ares-tcp-uaf-calc-poc
# Build c-ares from vulnerable commit
./scripts/build_from_checkout.sh
# Run PoC (loopback DNS server + vulnerable client)
./scripts/run_until_hit.sh

Lab auto-provisioned

The lab environment is automatically provisioned based on the attack plan and instrumented with the same security stack used in production networks to capture comparable telemetry. Several environment variants may be created to ensure complete test coverage.

Attack plan executed

The attack plan is executed using multiple variants of the technique to exercise the detection logic under different conditions.

Analytics validation

The proposed detection logic is validated against both lab-generated simulations and real operational data, including client telemetry. This iterative process repeats earlier steps, as needed, until the simulated activity is reliably detected and false positives are minimized.

Detection rule to production

The resulting detections are then converted into the required analytic engineering formats. This includes Sigma implementations for straightforward detections and Python implementations for more complex analytics, along with any required filters, tuning logic, and supporting documentation. These artifacts are submitted for analyst review as a detailed package containing the supporting evidence, validation results, and implementation details behind the final analytics.

# UNCLASSIFIED / NON CLASSIFIÉ // TLP:CLEAR
title: SSH Client Process Spawns Shell Interpreter
name: SSH_Client_Process_Spawns_Shell_Interpreter
id: a3d7e1f2-9c4b-4a8e-b5d6-7f0e2c1a3b94
status: testing
description: |
  Detects an SSH client process (ssh, scp, sftp, libssh2-linked, PuTTY, plink, Dropbear)
  spawning a shell interpreter with the -c flag. A legitimate SSH client should never
  exec sh -c as a child process — this is the primary indicator of client-side RCE
  exploitation (e.g., CVE-2026-55200 libssh2 heap overflow).
references:
  - https://attack.mitre.org/techniques/T1203/
  - https://nvd.nist.gov/vuln/detail/CVE-2026-55200
author:  CCCS
date: 2026/07/13
modified: 2026/07/13
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1203
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|re: '(?i).*([]\\]ssh|[]\\]scp|[]\\]sftp|[]\\]putty|[]\\]plink|libssh|ssh2|dbclient).*'
  selection_child:
    Image|re: '(?i).*(bash|dash|/sh$|zsh|ksh|ash).*'
    CommandLine|re: '(?i)((ba)?sh|dash|zsh|ash|ksh|cmd)\s+(-c|/c)\s+'
  filter_server_side:
    ParentImage|re: '(?i).*(sshd|ssh-agent|ssh-keygen|ssh-add|ssh-keyscan|sshfs).*'
  filter_benign_commands:
    CommandLine|re: '(?i)((ba)?sh|dash)\s+-c\s+(umask|locale|ssh-agent|test\s+-|\[\s+-)'
  condition: selection_parent and selection_child and not filter_server_side and not filter_benign_commands
falsepositives:
  - SSH session setup evaluating .bashrc (filtered by benign command patterns)
  - Legitimate SSH-based automation (Ansible, rsync) — typically uses sshd as parent, not ssh client
level: high

Pipeline orchestration

The workflow is orchestrated by a collection of specialized agent skills, each responsible for a specific stage of the detection engineering process. These skills can be tuned by analysts to improve consistency, enforce quality standards, and ensure repeatable outcomes across different use cases.

Results and operational benefits

After multiple rounds of automated testing against generated telemetry and technique variants, the agents iteratively refined the analytics. Once completed, the pipeline prepared the production-ready detections and submitted them for analyst review. Analysts could then validate, approve, or modify the detections as needed before they were merged into the repository. In total, 8 new production detection rules were created from the above test case, with more than 5 variants of each technique tested to identify durable behaviour indicators.

Overall, frontier AI is a force multiplier that can help identify detection gaps faster and operationalize defensive analytics at a pace that better matches the evolving threat landscape. By automating much of the detection engineering workflow, analysts can spend less time performing repetitive tasks and more time:

• analyzing real malicious activity
• observing how techniques behave under different conditions
• providing valuable feedback to upstream engineering teams on identified visibility gaps

Next steps for the Cyber Centre’s use of frontier AI

While the overall capability continues to mature, the progress to date has been very encouraging. Several components are already delivering operational value, and the workflow will continue to evolve through collective use and feedback.

Additional ongoing efforts are applying the same techniques to continuously refine and strengthen existing detections by transforming validated false positives into structured, evidence-based tuning recommendations.