> ## Documentation Index
> Fetch the complete documentation index at: https://devlookout.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Detection attack validation

> Validate deterministic detections with replay and non-destructive live Linux scenarios.

> For the complete documentation index, see [llms.txt](https://devlookout.com/llms.txt). Markdown versions are available by appending `.md` to page URLs.

Run `lookout validate-detection-pipeline` on an installation, or `npm run test:attacks` in a checkout. The command uses private temporary data directories and never changes the surveyed network, host accounts, services, firewall, logs, backups, or cloud configuration.

The validation suite enforces one malicious and one near-miss scenario for every built-in deterministic rule. Raw Linux journal/audit, Zeek, Tailscale audit, or OpenTelemetry records enter the same production normalizers used by ingestion. The test then traverses capability planning, durable event storage, deterministic evaluation, finding retention, and Alert creation. Adding a built-in rule without a scenario makes the suite fail.

Expected outcomes are policy-aware:

* Every high or critical deterministic rule must create a finding and standalone Alert.
* Every medium rule must create a correlation finding and no standalone Alert.
* Every near-miss must avoid the target finding.
* Behavioral anomalies remain correlation evidence and cannot independently create an Alert or Incident.

This validates Lookout's processing path, not the configuration of a particular live sensor. A deployment is covered only when its detection plan reports the required capabilities as ready or explicitly degraded. For example, a passing Zeek replay does not prove that a network has deployed Zeek, and a passing OpenTelemetry service scenario does not prove that an application emits the required security attributes.

## Non-destructive live Linux validation

From the installed central Linux node, run:

```sh theme={null}
sudo lookout validate-live-linux <target-ip> <ssh-user> <private-known-hosts-file> <private-identity-file>
```

The target must be an already-enrolled Linux collector reachable through pinned OpenSSH host identity. The supplied user must support public-key authentication; noninteractive sudo is optional. The validation performs real rejected SSH authentications, a successful SSH login, `sudo -n /usr/bin/true` when authorized, and an ephemeral unprivileged TCP listener. It then waits for fresh Alerts produced through the target journal/survey collector, signed collector transport, central ingestion, and rule engine. The listener is killed in a `finally` cleanup path and the invalid temporary SSH key is deleted.

This safely live-tests authentication bursting, identity spraying, remote authentication followed by privilege use, listener creation, and remote authentication followed by listener creation. It appends the ordinary audit records created by those actions, but does not change accounts, credentials, installed services, routes, policy, existing log contents, backups, MFA, security controls, or cloud resources. Rules requiring those changes are reported as outside non-destructive live coverage.

Live adversary emulation belongs in disposable, snapshotted environments. It must be adapter-specific because actions such as disabling audit, clearing logs, changing routes, weakening MFA, exposing data, or disabling backups are destructive and cannot safely run during installation or against an arbitrary private network. A release should not claim live certification for an adapter until its lab performs the real action, captures the raw source record, observes the expected Lookout result, verifies the near-miss, and restores the snapshot. Lookout deliberately does not substitute injected records for that deployment-level certification.