Detection Invariants and Adversary-Controlled Features

Durable detection begins by asking what must remain true

Suppose an attacker wants a cloud application to read a victim’s mail. The attacker can change the application’s name, logo, publisher text, redirect address, and the time at which consent is requested. Those details may be useful context, but none is necessary to the objective. If your analytic depends on them, the attacker can often evade it without changing the attack.

For the chosen consent path, some identity must grant authority to an application, and the application must use that authority against the mail resource. Those state transitions are more stable. An invariant is a property that must hold for a specified behavior path to succeed under stated conditions.

The conditions matter as much as the property. The grant is invariant only if the attacker uses delegated consent rather than stolen administrator credentials or an existing application. The later mail access is observable only if the provider records it with identifiers that can be related to the grant. An invariant is therefore a reasoned, conditional claim—not an unchangeable law of attackers.

Separate attacker-controlled, environment-controlled, and necessary features

A useful review places features into three groups. Attacker-controlled features include filenames, command spacing, user-agent strings, domains, and timing when the attacker can select them freely. Environment-controlled features include provider identifiers, audit schemas, network architecture, and policy outcomes. Necessary features are actions or state changes the path requires.

The groups can overlap. An attacker may influence a process name, but the operating system assigns a process identifier. The environment may normalize a cloud operation name, but the attacker chooses which operation to invoke. Classification is not about the field alone; it is about who can change the value, at what cost, and without breaking the objective.

This analysis improves analytic design. A command-line substring may remain useful for a known campaign, but it should not carry the same coverage claim as a required privilege transition. You can use changeable details to prioritize or enrich a result while anchoring the detection in behavior that has a stronger relationship to the objective.

Trace the invariant to a real observation point

An invariant that leaves no accessible evidence cannot support an operational detection. You need to ask where the state transition occurs and what records it. A privilege assignment may be visible in the identity provider’s audit log. Its later exercise may be visible only in a separate service. A file encryption effect may be necessary to ransomware, but a sensor that records only process starts may see merely a possible precursor.

Observation changes meaning. A network sensor can record that encrypted bytes moved to a destination; it cannot usually prove which files were inside. A controller audit log can record that a logic download was accepted; a network copy of the request may show only that it was attempted. The invariant exists in the modeled behavior, while the sensor supplies bounded evidence about it.

Record the observation point, field semantics, expected latency, entity keys, and blind spots. This keeps a durable behavioral idea from turning into an overconfident implementation claim.

Use counterexamples to test whether the invariant is real

Try to construct a successful path in which the proposed invariant does not occur. If you claim that data exfiltration requires a large outbound transfer, a low-and-slow channel is an immediate counterexample. If you claim that persistence requires a new account, reuse of an existing delegated application disproves it. Counterexamples do not make behavioral reasoning useless; they define the path more honestly.

Also test ordinary activity that contains the same property. Administrators grant authority, backup systems move data, and deployment controllers create privileged workloads. A necessary property can still be common. The analytic may need sequence, ownership, process state, or approval context to make it useful.

The threat model to detection hypothesis process gives these tests a home. The threat path supplies the conditions. Counterexamples narrow them. Benign alternatives identify required context. The resulting hypothesis predicts evidence without claiming that one invariant proves malicious intent.

Build portfolios from complementary invariants

No single invariant covers every path to an objective. Credential theft, malicious consent, session replay, and workload-identity compromise can all produce unauthorized access through different state transitions. A portfolio should represent those paths separately, with explicit overlaps and gaps.

This lets you adapt without losing the reasoning. If an attacker changes a filename, the behavioral detection may remain valid. If the provider removes an audit event, the invariant may still describe the threat while the local coverage becomes degraded. If attackers shift to another path, the original analytic has not failed; the portfolio has revealed a scope boundary that may deserve a new requirement.

The discipline is to preserve layers: the adversary objective, the selected path, the invariant under its conditions, the observation available locally, and the analytic that evaluates that evidence. When those layers are collapsed, “behavior-based” becomes marketing language. When they remain separate, it becomes a precise explanation of why a detection may be harder to evade and exactly where it can still fail.