Controlled defensive security laboratory

Practice detection decisions with evidence you can inspect.

MIRAGE is a local-first SOC lab for deterministic telemetry replay, ATT&CK-aware detections, analyst disposition practice, and repeatable evaluation. It is built to explain what a rule needs, what it found, and where its conclusion must stop.

See the workflow Read the detection guide

Safe by design Controlled synthetic telemetry and an optional private lab fixture.

Rule-first Versioned thresholds, telemetry prerequisites, and explicit caveats.

Evidence-led Scenario results, analyst history, integrity checks, and CI evidence.

Practical use cases

Six controlled exercises that make a detection useful.

Each exercise has a declared expected result. Positive scenarios show a defined rule path; benign and boundary scenarios show what should not become an alert.

Regression-proof a rule change

Replay the full credential-to-decoy-to-discovery story and confirm that every intended rule still appears with the same traceable evidence.

Full pipeline story

Practice contextual authentication triage

Compare a success after repeated failures with the source, window, and documented benign boundary before assigning a disposition.

Credential probe

Prove a false-positive boundary

Run ordinary administrative activity and verify it produces no case, rather than treating an absence of alerts as an assumption.

Benign admin activity

Test the exact threshold edge

Run one fewer failure than the configured threshold to demonstrate that the rule’s trigger is intentional and observable.

Threshold boundary

Separate sustained pressure from retries

Compare a longer source-bound failure sequence with scheduled service retries and a one-event-below boundary before escalating the controlled signal.

Low-and-slow pressure

Inspect change context, not a change alone

Require a matching login, a short time window, and an explicitly unapproved synthetic marker before raising the controlled case.

Policy-change context

Detection contract

A rule is more than a technique label.

Rule	What it demonstrates	Required evidence	Analyst boundary
Repeated SSH authentication failures	T1110 — Brute Force	Failure event type, source, time, and account candidate	A threshold match is suspicious in the lab, not a production verdict.
Successful login after repeated failures	T1078 — Valid Accounts	Source-bound failure sequence and later success inside the window	Legitimate users can make mistakes; evaluate the surrounding context.
Multi-stage decoy engagement and discovery	T1087 — Account Discovery	Credential activity, decoy interaction, and allowlisted discovery evidence	One inventory command alone does not form the complete lab story.
Low-and-slow authentication pressure	T1110 — Brute Force	Source-bound failures, count, minimum time span, and maximum correlation window	Scheduled retries and just-below-threshold sequences remain documented controls.
Unapproved synthetic access-policy change after login	T1098 — Account Manipulation	Source-bound login, synthetic change event, time window, and explicit approval-state marker	This is a lab-only context exercise; it does not inspect or alter real access policies.

Catalog traceability

Versioned strategies, analytics, and controls.

Catalog v1.2.0 separates the defensive strategy from the analytic implementation. Every rule records an analytic version, change class, positive scenario, and negative or edge control before it is presented as validated evidence.

Strategy ID Defines the defensive question shared by one or more analytics.

Analytic version Shows the versioned implementation that produced a lab result.

Control contract Requires positive, benign, and threshold or context evidence.

Start here

Move from a change to an explainable result.

Read the contract. Review the rule threshold, expected benign case, ATT&CK context, telemetry prerequisites, and triage questions.
Run the matching scenario. Use the controlled scenario to generate only the data needed for the stated exercise.
Inspect the case. Validate the timeline, risk factors, analyst disposition boundary, and evidence integrity status.
Verify the outcome. Check the evaluation matrix and run the test, type, build, browser, and security gates before sharing a change.

Repository evidence