Most anomaly detection watches one stream of evidence at a time. Behavioral tools watch what systems do; configuration tools watch how systems are set up. Each on its own produces noise — a behavioral spike that might be benign, a configuration change that might be routine. The interesting signal often lives in the correlation: a suspicious behavior and a suspicious configuration on linked machines, observed together.

The grant US12328323B2, "System and method of anomalous configuration-related activity" (assigned to Acronis), is built around exactly that correlation. It uses a cascade of machine-learning models that combines behavioral analysis of network assets with configuration analysis of the endpoints attached to them, on the premise that the combination is more discriminating than either signal alone.

"An anomaly detection system uses an AI engine to analyze configurations of endpoints using backup archives and system events on shared network assets to detect and verify anomalies."— U.S. Patent No. 12,328,323 source

The architecture is explicitly a cascade — multiple models feeding one another rather than a single classifier. The independent claim describes training a "behavior analysis machine-learning model" whose inputs are "system events of shared network assets" and whose output is "a probabilistic characteristic of suspicious activity on at least one shared network asset." Separately it trains a "configuration-behavior analysis machine-learning model" whose inputs are both the system events and the "system configuration parameters of linked endpoints and shared network assets," and whose output is "a probabilistic characteristic of configuration-related anomalous activity." One model reasons about behavior; the second reasons about behavior and configuration jointly. The training pipeline first preprocesses the raw events and configuration parameters "into a dataset format for processing by a machine-learning model."

The detection phase shows why the cascade is ordered the way it is. According to the claims, the system switches to detection mode and first analyzes collected system events with the trained behavior model. If "the probabilistic characteristic of suspicious activity on the shared network asset exceeds a first predefined threshold," it registers anomalous activity on that asset. Only then does it pivot to configuration: it "determin[es] a list of endpoints linked to shared network assets on which the anomalous activity is registered," obtains those endpoints' "system configuration parameters... from backup archives," and runs the combined configuration-behavior model. A final threshold check confirms the finding. The behavioral signal acts as a trigger that tells the system where to look at configuration, rather than analyzing every endpoint's configuration all the time.

The use of backup archives as a configuration source is a notable, specific detail. Rather than querying live endpoints — which a sophisticated attacker on those endpoints might tamper with — the system pulls configuration state from backup archives, a source the endpoint itself doesn't control in the moment. The claims also define how endpoints and assets are linked: the "list of endpoints linked to shared network assets is determined using system configuration parameters of endpoints corresponding to access permissions to shared network assets," or alternatively "using system events of shared network assets corresponding to network connections." Access permissions and observed connections both serve to map which endpoints touch which shared resources, so the system knows which machines' configurations are relevant to an anomaly on a given asset.

The claims are generous about what feeds the models. A "shared network asset" can be shared network storage, a website, an FTP server, a remote computer, a mail server, or a proxy server. "System events" can include operating-system events, API calls, driver logs, network events, hooked operations, system metrics, or BIOS parameters. "System configuration parameters" range across hardware configuration, application configuration, system settings, installed updates, registry keys, system users, running processes, system files, user files, connected networks, and active network connections. That breadth matters because configuration-related attacks hide in exactly these crevices — a changed registry key, a new local user, an altered scheduled task — that look unremarkable in isolation and only become suspicious next to anomalous behavior on a resource that endpoint can reach.

A second independent claim reverses the cascade's entry point to cover the symmetric case. There the system trains a "configuration analysis machine-learning model" on configuration parameters alone, detects an anomalous configuration change first, then "determin[es] a list of shared network assets linked to endpoints on which the anomalous configurational change is registered," collects those assets' system events, and runs the combined model. Whether the first hint is a behavioral spike on a server or a configuration change on an endpoint, the design pivots to the other domain to confirm — the correlation can be entered from either side.

The defensive value is in suppressing the false positives that sink single-signal detection. A behavioral anomaly on a file server is ambiguous; a configuration change on a workstation is ambiguous; the two together, on machines that are actually linked by permissions or connections, are far less so. By requiring both a behavioral threshold and a combined configuration-behavior threshold to be crossed, and by drawing configuration from backups rather than from the possibly compromised live host, the cascade is structured to fire on the conjunction rather than on either half. The claims describe verification, not just detection — the second model's job is partly to confirm what the first one flagged.

The cost of this precision is breadth of telemetry and the integrity of the backup channel. The models are only as good as the events and configuration parameters they ingest, and the reliance on backup archives makes the freshness and trustworthiness of those archives part of the security boundary. But the underlying bet is sound: configuration-related threats are hard to catch because each piece looks normal, and the way to catch them is to stop looking at the pieces one at a time.