A full technical reference for the AI Malware Guardian detection pipeline — architecture decisions, training data, feature vectors, anomaly thresholds, and inference design.
Guardian runs two independent anomaly detection models against every suspicious process. The models operate at different levels of abstraction and different points in time, so they catch entirely different attack classes.
Layer 1a — Static PE Autoencoder fires the instant a new executable lands on disk. It encodes 17 structural features extracted from the PE header (entropy, sections, imports, packing indicators, compile timestamp anomalies, and architecture metadata) and compares the reconstruction error against a global baseline trained on 10,233 legitimate Windows programs. A file whose structure can't be well-reconstructed from patterns learned on benign software is flagged before it ever runs.
Layer 1b — Behavioral Autoencoder runs continuously in the background. It aggregates 12 Windows event trace (ETW) signals over rolling 5-minute windows and compares each window against a personal baseline specific to your machine. A process that triggers system behavior outside what your own machine normally produces, regardless of whether it has ever been seen before, is flagged live.
The two models are deliberately independent. A polymorphic file that rewrites its PE structure to pass Layer 1a will still leave a behavioral fingerprint that Layer 1b catches. A script-based attack with no PE on disk is caught by Layer 1b alone. Coverage is complementary, not redundant.
Every PE file that Guardian monitors is fed through a 17-dimensional symmetric autoencoder. The autoencoder encodes the file's structural fingerprint down to an 8-dimensional bottleneck and then reconstructs the original 17 features. The mean squared reconstruction error (MSE) is the anomaly score: low error means the file looks like normal benign software; high error means its structure deviates from anything in the training distribution.
The symmetric encoder–decoder design ensures the network has to genuinely learn a compressed representation rather than an identity mapping. All hidden layers use ReLU activation. The output layer uses a linear activation to allow unrestricted reconstruction. Loss: MSE.
All features are extracted directly from the PE binary before execution. No runtime behavior is involved at this layer.
| Feature | Description |
|---|---|
| file_size | Raw byte count of the PE file |
| overall_entropy | Shannon entropy of the full file |
| num_sections | Count of PE sections in the header |
| max_section_entropy | Entropy of the highest-entropy section |
| mean_section_entropy | Mean entropy across all sections |
| section_entropy_std | Std deviation of section entropies |
| num_imports | Total count of imported functions |
| num_import_dlls | Distinct DLLs imported |
| num_exports | Exported symbols (non-zero in DLLs/tools) |
| Feature | Description |
|---|---|
| compile_timestamp | PE header timestamp field (anomaly = 0 or future date) |
| is_dll | Binary: 1 if IMAGE_FILE_DLL characteristics flag is set |
| has_debug | Binary: 1 if a debug directory is present |
| is_signed | Binary: 1 if the file carries a valid Authenticode signature |
| is_packed_heuristic | Heuristic: 1 if entropy > 7.0 or section names are non-standard |
| file_ext_enc | Encoded file extension (.exe / .dll / .sys / other) |
| architecture_enc | Encoded target machine type (x64 / x86 / ARM64) |
| subsystem | PE subsystem value (GUI / console / driver / native) |
Why entropy matters: Legitimate compilers produce predictable entropy patterns — code sections hover around 5–6 bits/byte, data sections are lower. Packers, crypters, and reflective loaders compress or encrypt their payloads, which pushes section entropy above 7.5 bits/byte, often with near-uniform distribution across sections (section_entropy_std ≈ 0). A single high-entropy section in an otherwise normal PE is also flagged because it's consistent with a packed payload being carried inside a dropper.
Why compile timestamp matters: Malware authors commonly zero out or forge compile timestamps to evade heuristics. A timestamp of 0 or a date in the future is structurally anomalous relative to the training distribution and pushes reconstruction error upward.
Threshold calibration: The threshold of 0.163211 was set at the 95th percentile of reconstruction errors on 300 real Windows System32 PE files not seen during training. At this threshold, 5% of benign System32 files will generate false positives. In practice, user-space false positives are further suppressed by the process knowledge base (1,000+ known-good processes) before any alert is surfaced.
Layer 1b takes a completely different approach: instead of inspecting a file, it watches what your computer is doing in aggregate. Every 5 minutes, Guardian collapses all system event activity into 12 normalized rate features derived from Windows Event Tracing (ETW). These 12 numbers describe the behavioral "fingerprint" of the machine for that window. An autoencoder trained on thousands of benign behavioral windows from real machines tries to reconstruct each new window; a high reconstruction error means the window looks like nothing in the benign training distribution — it is behaviorally anomalous.
The critical distinction from Layer 1a is that Layer 1b is personal. Before monitoring activates, Guardian collects your own baseline — hundreds of 5-minute windows from normal use on your machine — and blends it into the model's context. An activity that would be unusual on a typical developer machine might be completely ordinary on yours (e.g., frequent WMI queries from a legitimate monitoring script). Your baseline teaches the system what your normal looks like specifically.
Each feature is an event count divided by window duration (events per second), giving rate normalization that is independent of whether the 5-minute window started at the beginning or end of a second-boundary. All 12 features are clipped at the 99th percentile of the training distribution before MinMax scaling to prevent rare bursts from distorting the anomaly score.
| Feature | ETW Source | What it Captures |
|---|---|---|
| wmi_query_rate | Microsoft-Windows-WMI-Activity / EventID 5857, 5858 | Rate of WMI queries and provider activations. Malware heavily abuses WMI for system reconnaissance, lateral movement, and execution. |
| task_register_rate | Microsoft-Windows-TaskScheduler / EventID 106, 107 | Rate of scheduled task registrations. Attackers register persistence tasks; high rates outside normal maintenance windows are suspicious. |
| task_run_rate | Microsoft-Windows-TaskScheduler / EventID 200, 201, 202 | Rate of scheduled task executions. Spike after a registration event strongly suggests a newly placed persistence mechanism firing. |
| bits_event_rate | Microsoft-Windows-Bits-Client / any EventID | Rate of Background Intelligent Transfer Service events. BITS is commonly abused for stealthy C2 downloads because it uses system-trusted network channels. |
| fw_rule_change_rate | Windows Firewall / EventID 2097 (add), 2052 (delete), 2002, 2004, 2006 | Rate of firewall rule modifications. Malware modifies firewall rules to open inbound ports, disable blockers, or allow C2 traffic. |
| rdp_session_rate | Microsoft-Windows-TerminalServices-LocalSessionManager / session events | Rate of RDP session events. Expected to be near zero on single-user workstations; non-zero values on machines without remote desktop enabled are always anomalous. |
| smb_access_rate | Microsoft-Windows-SMBClient / any EventID | Rate of SMB client events. Near-zero on isolated workstations; elevated rates suggest lateral movement scanning or unexpected file-share access. |
| error_event_rate | Windows Event Log / Level = Error or Critical, any channel | Rate of error and critical-level events system-wide. Malware commonly causes cascading errors through failed operations, process injection failures, or service crashes. |
| total_event_rate | All ETW channels / all EventIDs | Overall system event rate. Provides a normalization baseline and captures gross activity spikes that don't fit a specific category. |
| unique_channel_count | Distinct ETW provider channels with ≥ 1 event in the window | Number of distinct event channels fired in the window. Normal usage activates a predictable set of channels; unusual channel proliferation suggests a broad-spectrum system manipulation attempt. |
| group_policy_rate | Microsoft-Windows-GroupPolicy / any EventID | Rate of Group Policy events. Legitimate GP activity is periodic and predictable; manipulation attempts generate irregular bursts. |
| shell_core_rate | Microsoft-Windows-Shell-Core / any EventID | Rate of shell lifecycle events (UWP app state transitions, install notifications). Naturally sparse; spikes correlate with software installation activity and are used as a context signal. |
Why an autoencoder instead of a classifier? A classifier requires labeled attack samples to train. Attackers continuously generate novel malware specifically designed to evade classifiers trained on known samples. An autoencoder trained only on benign data has no concept of what attacks look like — it just learns what normal looks like. Anything that isn't normal produces a high reconstruction error, whether or not it has ever been seen before. This is the core property that makes anomaly detection effective against zero-days.
Why 5-minute windows? Most attack sequences that involve system manipulation — task scheduling, firewall changes, WMI queries for reconnaissance — leave traces over minutes, not milliseconds. A 5-minute window is long enough to capture a full attack phase but short enough to generate a timely alert before the next phase begins. Windows shorter than 2 minutes produce noisy rates; windows longer than 10 minutes delay detection.
Preprocessor design: Raw event counts are first clipped at the 99th percentile of training data (to keep rare bursts from warping the scale) and then scaled to [0, 1] per feature using MinMax normalization. Clipping values are stored in preprocessor_config.json alongside the scaler parameters so the on-device ONNX runtime can apply identical preprocessing without loading a scikit-learn object.
Both models are exported to ONNX (Open Neural Network Exchange) and run via the ONNX Runtime library directly inside the Tauri application process on the user's machine. No internet connection is required for inference; no data leaves the machine at any point during analysis.
Layer 1a inference flow: A PE file identified by the monitor thread is parsed in Rust to extract the 17 structural features. The feature vector is passed to the Python preprocessor stub embedded in the ONNX session for StandardScaler normalization, then fed forward through the autoencoder. The MSE between input and reconstructed output is compared against the stored threshold (0.163211). If the MSE exceeds the threshold, the file is handed to the alert pipeline.
Layer 1b inference flow: The ETW recorder accumulates event counts in a rolling in-memory buffer. At each 5-minute boundary, the buffer is flushed, counts are computed into the 12 rate features, preprocessing is applied (clip then MinMax), and the feature vector is passed through the behavioral autoencoder. The MSE is compared against the behavioral threshold (0.000507). A score above threshold generates a behavioral window alert.
Why ONNX? PyTorch and TensorFlow models are not embeddable in a Rust binary without pulling in a full Python runtime. ONNX Runtime ships as a single native library with Rust bindings (ort crate), adding roughly 30MB to the binary — acceptable for a desktop security application. Inference latency on both models is sub-millisecond on modern hardware.
Model versioning: Each model ONNX file ships alongside a model_meta.json that records the model name, layer, threshold value, preprocessing parameters, and training date. The runtime validates this file on startup to ensure the threshold in use matches the model in use. Over-the-air model updates are applied atomically: the new ONNX file is written to a staging path, validated, and then renamed into place — the monitor thread never reads a half-written model.
Not all anomalies are equally urgent. Guardian scores each anomaly against a three-tier classification that balances user attention cost against detection urgency. Alert generation is deferred until the process knowledge base (1,000+ known-good Windows processes) has been consulted — a high-MSE score on a process with a known-benign signature is suppressed or downgraded before it ever reaches the UI.
The behavioral model shipped with Guardian was trained on thousands of benign 5-minute ETW windows sourced from real machines. This global model defines what "typical Windows behavior" looks like across the range of machines in the training set. On installation, Guardian begins recording your machine's own behavioral windows in the same 12-dimensional feature space.
As your personal baseline accumulates — Guardian targets a minimum of several hundred windows across varied use sessions before the personal model activates — these windows are used to fine-tune the anomaly threshold for your specific machine. A developer who runs WMI-heavy build tooling will naturally generate wmi_query_rate values that the global model scores as unusual; once enough of those windows are in the personal baseline, the effective threshold for that feature is recalibrated upward, eliminating false positives from legitimate tools.
Baseline recording is transparent and passive. The ETW recorder runs as a scheduled Windows task at logon. It writes raw event counts per 5-minute window to a local CSV file. No process names, no file paths, no user content — only the 12 aggregate rate figures. The baseline file never leaves the machine.
Boot-window handling: The first 5-minute window after a cold boot predictably shows elevated rates for shell_core_rate, task_run_rate, and total_event_rate while Windows initializes its startup tasks. Guardian detects post-boot windows automatically (gap from previous window > 15 minutes) and excludes them from false-positive rate calculations during calibration to prevent the boot burst from inflating the threshold.
Sensitivity controls: Guardian exposes a sensitivity slider in the Settings UI. Under the hood, the slider scales the effective detection threshold multiplicatively: sensitivity = minimum applies a multiplier of 1.5× (fewer alerts), sensitivity = maximum applies 0.7× (more alerts). The calibrated threshold is never permanently modified by the slider — it is applied at score time, so the slider can be adjusted without retraining.