DOCSEARCHbyAlgolia
Submit Docs

rustinel

repository·main·Indexed 19 days ago

https://github.com/karib0u/rustinel

An open-source endpoint detection engine written in Rust for Windows, Linux, and macOS. It provides native telemetry collection via ETW, eBPF, and Endpoint Security, evaluating events against Sigma, YARA, and IOC rules to emit SIEM-ready ECS NDJSON alerts. Features include an active response engine for process termination on Windows and Linux, and integrations for the Elastic Stack and Splunk.

Tokens
32.4K
Snippets
98
Records
170
Agent score
65%

What's inside rustinel

  1. Overview of Rustinel capabilities

    main

    Rustinel is an open-source endpoint detection project for Windows, Linux, and macOS. It functions as a transparent detection engine that collects native host telemetry, normalizes it into a shared model, and evaluates detections using Sigma, YARA, and IOCs. Alerts are output in ECS NDJSON format.

    Supported Platforms & Telemetry Methods

    • Windows: Uses ETW (Event Tracing for Windows).
    • Linux: Uses eBPF.
    • macOS: Uses Endpoint Security and /dev/bpf (Note: macOS support is currently experimental).

    Core Features

    • Detection Engines: Sigma rule evaluation, YARA scanning on process creation, and IOC matching (file hashes, IPs, domains, and path regexes).
    • Output: Alerts are written as ECS NDJSON.
    • Rule Management: Supports hot reload for rules and indicator files.
    • Active Response: Optional active response is available on Windows and Linux (includes dry-run and allowlists). macOS is currently detection-only.

  2. Review long-term product and platform goals

    main

    The following features are in the active backlog without a committed release target:

    • Diagnostics: Per-rule compatibility diagnostics.
    • Linux Expansion: Expanded file telemetry (chmod, chown, truncate, link) and adding container/cgroup context to process events.
    • Rule Management: Atomic rules-pack updates and rollbacks.
    • Advanced Detection: Stateful Sigma correlation, temporal evaluation, and periodic YARA memory sweeps.
    • Platform Work: Replacing macOS BPF capture (pending Apple entitlement resolution).

  3. Core capabilities of Rustinel

    main

    Rustinel is an open-source endpoint detection engine designed to provide a unified, cross-platform detection pipeline. It is built in Rust for performance and memory safety. Key capabilities include:

    • Native Telemetry: Uses OS-native sources (ETW on Windows, eBPF on Linux, and Apple Endpoint Security//dev/bpf on macOS).
    • Cross-platform Detection: Normalizes events into a shared model to allow reuse of detection logic across different operating systems.
    • Community Rule Support: Directly supports industry-standard formats like Sigma and YARA, allowing users to reuse existing detection content.
    • IOC Matching: Supports matching Indicators of Compromise (IOCs) including hashes, IPs, domains, and path regexes.
    • Standardized Output: Generates alerts in ECS NDJSON format for easy ingestion into SIEM and logging pipelines.

  4. Understand the Rustinel development roadmap

    main
    The Rustinel roadmap outlines planned improvements across several release themes. Key focus areas include stability, detection correctness, telemetry expansion, and the transition to the RSigma evaluation backend. Users can track specific feature progress and discussions via the project's GitHub Issues.

  5. Platform support and telemetry coverage

    main

    Rustinel is a cross-platform endpoint detection engine. Telemetry coverage varies by platform:

    • Windows (10/11, Server 2016+): Broadest coverage including process, image load, network, file, registry, DNS, PowerShell, WMI, service, and task telemetry.
    • Linux (Kernel 5.8+, BTF required): Covers process, network, file, and DNS. Requires root or specific capabilities (CAP_BPF, CAP_PERFMON, CAP_NET_ADMIN, or CAP_SYS_ADMIN).
    • macOS (11+, experimental): Covers process, network, file, and DNS using Endpoint Security and /dev/bpf. Requires root, Full Disk Access, and a signed app bundle with com.apple.developer.endpoint-security.client authorization.

  6. Overview of Rustinel Detection Paths

    main

    Rustinel utilizes three distinct detector paths to identify threats, each with different inputs and execution behaviors:

    1. Sigma: Behavioral rules applied to every normalized event. Execution is inline via SigmaDetectionHandler, producing at most one alert per event.
    2. YARA: Executable scans applied to process-start executable paths. Execution occurs in a background worker via YaraEventHandler, producing one alert per matching rule.
    3. IOC (Indicators of Compromise):
      • Domains / IPs / Paths: Applied to every normalized event inline via SigmaDetectionHandler. Can produce zero or more alerts per event.
      • Hashes: Applied to process-start executable paths via a background worker. Can produce zero or more alerts per file.

    All detection hits are emitted as ECS NDJSON alerts.

  7. Critical Silent Risks in Rustinel Detections

    main

    Certain limitations in Rustinel can cause rules to fail to fire or match incorrectly without producing an error. These are categorized as silent risks. Before relying on a specific detection, verify if it falls into these categories:

    LimitationAreaImpact
    Registry value data is never captured; Details holds the value name insteadWindowsRule matches name instead of content
    Process events carry no hashes (Hashes / Imphash)WindowsSigma rules keyed on hashes will never fire
    Command line is lost for short-lived processesWindows/LinuxDetection based on CommandLine may miss fast-exiting processes
    No correlation, aggregation, or temporal rulesEngineCannot detect brute-force, beaconing, or 'N events in M minutes'
    Rules are silently inert when no collector backs their logsourceEngineRules for unsupported platforms/categories load but never fire
    Telemetry is dropped under burst load (no backpressure)PipelineSilent detection gaps during high activity

  8. Configure Active Response modes

    main

    Rustinel's response engine can automatically terminate processes when an alert meets a minimum severity threshold. It is disabled by default. You can choose from three modes:

    1. Disabled: No response work is queued.
    2. Dry-run: Rustinel logs what it would do without actually taking action. This is the recommended mode for initial testing.
    3. Prevention: Rustinel actively terminates eligible processes.

    Active response is currently supported on Windows (using process termination APIs) and Linux (sending SIGKILL). It is not supported on macOS (detection-only).

    [response]
enabled = true
prevention_enabled = false # Set to true for 'Prevention' mode, false for 'Dry-run'

  9. Understand the RSigma transition (v1.5.0)

    main

    Starting with v1.5.0, RSigma is intended to become the default evaluation backend.

    • Fallback Mechanism: The built-in backend will be retained as a documented fallback and is expected to remain available throughout the v1.x series.
    • Key Goals: Testing RSigma runtime capabilities through the adapter, restoring match-debug parity with the built-in backend, and reconciling Sigma capability documentation across the parser, library, and runtime.

  10. Understand Rustinel's non-goals and limitations

    main

    Rustinel is a detection engine, not a full-featured commercial EDR. It is specifically designed for blue teams, researchers, and detection engineers. It does not currently provide:

    • Kernel-level self-protection
    • Full anti-tamper protection
    • Pre-execution blocking
    • Managed response workflows
    • A full enterprise console
    • Cloud-managed policy orchestration

  11. Use detection packs with Rustinel

    main

    The Rustinel engine (rustinel) collects telemetry and evaluates rules, but it does not include comprehensive detection coverage by default. To get real-world coverage, you must load curated content from the rustinel-rules repository.

    Detection packs (Sigma, YARA, and IOC) are organized into folders. You point your config.toml directly at these folder paths to load the rules into the engine.

  12. Understand default trusted paths and allowlisting

    main

    Rustinel maintains a list of default trusted paths which feed into allowlist.paths. These allowlisted paths are used by active response, YARA allowlists, and IOC hash allowlists unless a module-specific override is provided.

    Default Trusted Paths by Platform

    Windows

    • C:\Windows\
    • C:\Program Files\
    • C:\Program Files (x86)\

    Linux

    • /usr/bin/, /usr/sbin/, /usr/lib/, /usr/lib64/, /usr/libexec/, /bin/, /sbin/, /lib/, /lib64/

    macOS

    • /usr/bin/, /usr/sbin/, /usr/libexec/, /bin/, /sbin/, /System/

    Note on macOS: /Applications is not allowlisted by default. This is intentional to ensure that user-installed software (a common malware location) is still scanned and subject to response actions.