Operationalizing EDR-based Detection Engineering: A Deep Dive with HarfangLab and M&NTIS Platform

For detection engineers, the objective is no longer just to deploy tools, but to achieve validated defensive readiness. Detection engineering has evolved into a hybrid discipline at the intersection of offensive security, defense, data, and software engineering.

This article details how to operationalize each stage of the detection engineering lifecycle by leveraging the high-resolution telemetry of HarfangLab EDR, used as a reference example, and the immersive testing capabilities of the M&NTIS Platform. The recurring pattern across every stage is a stimulus / observation / validation loop: M&NTIS generates the stimulus in a realistic lab environment, HarfangLab produces the observation, and the engineer closes the loop by validating detection coverage.

At a high level, the complimentarity of both solutions to achieve validated defensive readiness looks like this:

1. Threat Selection: Identifying Risk Behaviors

The first task is understanding what to detect, which involves analyzing recent intrusion sets, attack scenarios such as phishing or ransomware, and adversary TTPs mapped against frameworks like MITRE ATT&CK. Attackers continually adapt their methods, often relying on “dual-use” tools that are difficult to prioritize.

M&NTIS Platform addresses this by exposing real-world adversary emulation through full attack chains via its ready-to-use scenario catalog. Scenarios from the M&NTIS catalog, such as Venopie (theft of confidential company data) or Aetheris (data theft via spoofed updates), can be used to assess the efficiency of the defensive stack, and the deployed EDR solution in particular.

The figure below shows a phishing attack step executed inside M&NTIS, along with its produced attack metadata. This metadata serves as ground truth for the detection engineering tasks covered in the following sections. Every stimulus generated here will later be matched against the corresponding observation in HarfangLab EDR.

2. Data Collection: Leveraging High-Resolution Telemetry

A detection engineer depends strongly on the quality and granularity of available data. EDRs like HarfangLab act as a high-resolution sensor on endpoints, providing the visibility required for modern defense. They capture several actionable types of data, such as full process trees, complete command-line arguments, network activity, or even low-level system events such as DLL loads or process hollowing. As shown in the HarfangLab Telemetry Data Explorer, the EDR can display every process creation across the fleet.

At this stage, the engineer focuses on Visibility (did the EDR record the event?) rather than Detection (did the EDR raise an alert?). When a M&NTIS scenario executes a payload, the corresponding events must appear in HarfangLab’s telemetry.

This granularity allows precise tracking of suspicious activity and artifact manipulation (for example, a specific file download initiated by a browser), providing the raw metadata (URLs, file paths, hashes) needed to build high-fidelity hunting queries.

3. Rule Creation: White-Box Logic with Sigma and YARA

Writing effective rules requires transparency and the ability to model complex, multi-step behaviors. HarfangLab follows a white-box approach, using open and editable formats such as Sigma for behavioral detection and YARA for file and process signatures.

Unlike “black-box” EDRs, HarfangLab allows engineers to directly create or update rules. For example, a detection engineer can define or tune a Sigma rule targeting specific process creation patterns (here, an executed binary located in a user-writable directory often abused for staging payloads), ensuring the logic is perfectly adapted to the organization’s technical context.

4. Tuning and Noise Reduction: Managing Ambiguity

The most significant transversal difficulty in detection engineering is ambiguity. Distinguishing between a legitimate administrator script and a malicious “living-off-the-land” (LotL) technique is rarely binary.

M&NTIS addresses this challenge through Legitimate Activity Simulation, generating realistic business noise (e.g. PowerShell administrative tasks, scheduled software updates, archive extractions, scripted file transfers), concurrently with attack chains. The detection engineer then iterates the Sigma rules deployed in HarfangLab against this mixed signal: a rule can be considered acceptable only when M&NTIS attack steps still trigger alerts while the surrounding legitimate workload remains silent.

Legitimate software, management agents, installers, and update mechanisms frequently execute binaries from locations such as C:\ProgramData, while some enterprise applications may also launch executables from C:\Users\Public. Consequently, a rule based solely on execution from these directories often generates false positives. To improve detection fidelity, engineers should incorporate evidence-driven exclusions based on trusted code-signing information and observed legitimate activity within their environment:

title: Suspicious Process Execution from Public Directory (Tuned)
id: 8e1a0c2f-3b4d-4a7e-9c1b-2f5d6e8a9c3b
status: stable
logsource:
    product: windows
    category: process_creation
detection:
    selection:
        Image|startswith:
            - 'C:\ProgramData\'
            - 'C:\Users\Public\'
    filter_trusted_publishers:
        Signed: 'true'
        Signature:
            - 'Microsoft Corporation'
            - 'Google LLC'
            - 'Adobe Inc.'
    condition: selection and not filter_trusted_publishers
level: high
tags:
    - attack.execution
    - attack.defense_evasion

After deploying this tuned rule in HarfangLab and replaying the mixed M&NTIS workload, the engineer verifies that the associated attack stimulus still triggers the rule while the legitimate signed and trusted activity remains silent.

This stimulus / counter-stimulus loop yields a measurable false-positive rate per rule, replacing intuition with evidence and preventing the “alert fatigue” that often paralyzes SOC units.

5. Validation: Adversary Emulation and Defense Testing

Validation is the core of the Defense Testing workflow. It is not enough to run a unitary command; the security stack must be assessed under realistic threat conditions by comparing the expected outcome (derived from the stimulus) with the observed outcome (the EDR alert).

In M&NTIS, scenario execution produces a detailed attack report with actionable metadata and indicators of compromise (IOCs). This report serves as the ground truth against which HarfangLab detections are scored.

The engineer then verifies that each stimulus triggered the expected alert in HarfangLab EDR. Beyond the alert itself, the EDR exposes rich metadata (e.g. parent process, command line, signer, telemetry chain), required to assess the detection’s reliability. For instance, the execution of set_empty_pw.exe (a credential-manipulation payload mapped to T1098 - Account Manipulation) is correctly classified as a malicious Python module.

This pairing yields a concrete coverage matrix: for each of the N attack steps emitted by M&NTIS, how many were detected by HarfangLab, with what fidelity, and how quickly. Undetected steps become the prioritized backlog for the next iteration of rule development.

6. The Feedback Loop: From Investigation to Rule Refinement

Detection engineering is a continuous cycle: every M&NTIS run produces a delta between the expected detections (derived from the scenario’s ground truth) and the observed detections in HarfangLab. This delta is the raw material that drives the next iteration of rules and scenarios.

HarfangLab’s native correlation engine is the entry point of this loop. By grouping multiple events into a single enriched incident, it lets the engineer reconstruct the full attack path observed on the endpoint (e.g. parent processes, lateral movement, persistence artifacts) and compare it step-by-step against the attack chain emitted by M&NTIS. The gaps reveal exactly where detection logic is missing, redundant, or noisy.

Three concrete actions feed back into the rule base from this comparison:

• Missed steps become new Sigma rules or YARA signatures, mapped to the corresponding ATT&CK technique surfaced by the M&NTIS attack report.
• Noisy rules (high-fidelity against M&NTIS attack steps but false-positive-heavy under Legitimate Activity Simulation) are tuned, narrowed, or replaced.
• Layered detections are evaluated for intent. For instance, a ransomware step may be caught simultaneously by a YARA signature, a behavioral Sigma rule, and Ransomguard heuristics (suspicious file operations such as high-entropy writes); the engineer decides whether this redundancy is deliberate defense-in-depth or wasted coverage to consolidate.

The refined rule set is then re-validated by replaying the same M&NTIS scenario, and new scenario variants (obfuscated payloads, alternate execution chains, swapped LotL binaries) are added specifically to exercise the gaps surfaced in the previous iteration. This ensures the updated logic generalizes rather than overfitting to a single attack sample. And each closed loop measurably reduces the team’s mean-time-to-detect on the next emerging variant.

7. Pipeline Engineering: Toward Detection-as-Code

The final maturity level involves treating detection rules like software, versioning them in Git, and deploying them via CI/CD pipelines.

The M&NTIS API enables this automation end-to-end. Organizations can schedule automated attack campaigns and trigger them from a CI job whenever a Sigma or YARA rule is updated in the HarfangLab rule repository. The pipeline then queries the HarfangLab API to verify that the expected alerts were raised, and fails the build if coverage regresses.

A simplified GitHub Actions job illustrates the pattern:

- name: Trigger M&NTIS validation campaign
  run: |
    curl -X POST "$MANTIS_API/scenario/run" \
      -H "Authorization: Bearer $MANTIS_TOKEN" \
      -d '{"content_type": "scenario", "content_name": "venopie", "lab_config": (...)}'

- name: Verify HarfangLab detections
  run: |
    python scripts/check_coverage.py \
      --hlab-api "$HLAB_API" \
      --expected-iocs ./mantis-report.json \
      --min-coverage 0.95

In this model, every new signature or behavioral rule is automatically validated against fresh adversary emulation before reaching production, ensuring the defense stays ahead of the evolving threat landscape.

Conclusion

By integrating HarfangLab EDR and M&NTIS Adversary Emulation Platform, operational security teams move beyond theoretical or pure log-based detection coverage analysis. M&NTIS supplies the controlled stimulus (realistic adversary emulation and legitimate-activity noise in ephemeral lab) while HarfangLab provides the high-resolution observation surface and the white-box rule engine to act on it. Closed as a feedback loop and automated through CI/CD, this pairing transforms raw telemetry into validated, high-fidelity alerts, measurably reducing the time between a threat’s emergence and its reliable detection.