Skip to main content

Detection pipeline (on the endpoint)

Dependencies​

  • Sysmon must be installed and logging. The agent’s monitoring path is built around Sysmon operational events, not generic WMI polling for all rule types.
  • Administrator elevation is required for full access to logs in typical deployments.

From Sysmon record to rule match​

  1. Sysmon writes to the operational channel (event IDs for process, network, file, registry, DNS, etc.).
  2. SysmonEventReader parses XML / structured fields into SysmonEventData (process name, command line, IPs, ports, paths, etc.).
  3. SysmonEventProcessor maps that into a flat eventData dictionary used by the engine (process_name, command_line, sysmon_event_type, network_connection as destination port string for network events, etc.).
  4. DetectionEngine loads all detection-rules/*.json rule sets. For each Sysmon message, it evaluates every enabled rule (category in the JSON file does not limit evaluation—rules are global to the event).
  5. Logic AND means all conditions must pass; OR means any condition passes. Operators include equals, contains, matches (regex), in, not_in, comparisons where implemented.
  6. On match, CreateDetectionEvent fills DetectionEvent (rule id/name/severity, optimized EventData, optional forensic enrichment from SystemInfoCollector / processor).
  7. SaveEventAsync writes JSON to disk; upload path picks it up separately.

Deduplication​

The engine keeps deduplication caches (time-windowed) to avoid duplicate alerts for the same noisy Sysmon line / process burst. Exact keys are implemented in DetectionEngine (see code comments).

Rule testing​

Operators can run Invoke-EdrDetectionPenTest.ps1 in the repo to trigger benign commands that align with many rules (pen-test style validation).