Adversary Emulation

Replaying saved records tests only the stages after collection: parsing and rule logic. It cannot show that the upgraded sensor still emits that event with the same fields, or that the forwarder still ships it. Only re-executing the real technique exercises the whole path.

A named, reachable person on each side of the exercise whose job is to answer one question fast: is this specific activity ours? They attribute or disown observed behaviour. They do not authorise it and they do not order a stand-down.

A scan proves a weakness is present. A pentest proves an operator could exploit it and how far the chain reaches. A red team proves whether your defenders detect and stop a realistic path to an objective.

A popularity list tests the techniques other organisations happen to report; a threat profile tests the ones the adversary interested in you actually uses. Only the second supports a claim about the intrusion you are likely to face.

No. A prevention proves the control convicted the behaviour, not that the SOC saw it. Record prevented, detected-only and undetected as three separate outcomes, because each one needs a different fix.

Atomic Red Team is an open-source library of small, per-technique tests mapped to MITRE ATT&CK. Running one atomic executes a short scripted action for a single technique, so you can check whether your telemetry recorded it and your detections fired.

A miss can sit at four stages: the record was never generated, no rule matched the record, no alert reached the queue, or nobody acted on the alert. The absence of an alert names none of them.

Prevent, primarily. A pod that runs privileged and mounts the node filesystem has almost no legitimate use, so admission control can make the technique impossible, while a detection only tells you it already happened. Detect the narrow exception paths the policy has to allow.

Choose atomic tests when the question is which behaviours you can see, because each result is isolated and diagnosable. Choose a chained campaign when the question is whether people and process turn a realistic sequence into a verdict.

Use Atomic Red Team to validate detection of one technique at a time; use CALDERA to chain techniques automatically through agents and a planner; use Cobalt Strike or Sliver when you need a live operator, an interactive C2 channel, and human decision-making the automated tools cannot supply.

Search the host's own audit log over the known window, against a positive-control host that does produce the record. No record on the host is a collection gap; a record present clears collection and moves the test to the rule.

Separate what is invariant about the technique from what is incidental to the person: user agent, source address, parameter spelling and call ordering are the operator. Then have a second person execute it differently, and re-open if it misses.

Treat the claim as unverified until a callback on a pre-recorded number produces a per-activity attribution: this host, this command, this time, this source. Keep containment and evidence collection running while you verify, and reopen anything the operators cannot account for.

Three: detect it, meaning a rule that fires next time; prevent it, meaning a configuration change so the technique stops working; or accept it, recorded with a reason and a named person. Leaving it in the report is not one of them.

Delivery lag sets the floor tempo: you cannot retest faster than records arrive. Measure the lag at the start, check the raw record before declaring a miss, and pipeline executions instead of one edit per pass.

Any change to something a detection depends on: the source's audit configuration or firmware, the agent or forwarder version, the network path to the collector, and the platform's ingest or normalisation schema. Re-run the specific tests that depend on the changed component, not the whole suite.

Two halves: the legal core — a signatory with authority, in-scope and explicitly out-of-scope systems, a dated window, prohibited actions — and fields a defender can check an alert against: operator source addresses, test markers, out-of-band deconfliction numbers.

An assumed-breach engagement begins with the operator already holding a foothold or valid credentials, so everything up to initial access is skipped. The edge and phishing detections are never exercised, and their silence proves nothing about them.

A named behaviour is a class, not a test. You must add the procedure: which application, which permission scope, which consent path, which target identity, plus the observable you expect and the criterion that decides pass or fail.

Only that the clear never completed. Windows Security 1102 is written when the audit log is cleared, so its absence is indistinguishable from nobody trying. The prevention event is your only positive evidence.

Diagnose why rows do not close before adding any more. Most stalls are one of three: no real owner, an owner who never agreed, or no stated closure test. Then stop intake, re-route what the owner cannot deliver, and explicitly accept the tail.

Rank by consequence of a single success, fragility of the telemetry path, and exposure to change since the last pass. Give a small permanent core the estate cannot survive missing, spend the rest on recently changed and single-source detections, and rotate the tail so nothing is untested indefinitely.

It proves one path to the objective existed and went unnoticed by the rules and people on duty that week. It does not say which stage failed, and it measures nothing the operator never attempted.

The block truncated the behaviour, so nothing downstream could fire. Check what telemetry still arrived, then re-run in a scoped, time-boxed detect-only window or against a variant the control does not convict.

It did not clean up after itself. Atomic Red Team runs the technique but only reverts it if you explicitly run the cleanup command. A test that passed in a lab leaves real artefacts — a scheduled task, a registry key, a dropped file — on a production host, plus no chaining, no decisions and no evidence capture. Those are all yours.

No. If the alert fired on Cobalt Strike's default artefacts — its stock malleable profile, default named pipe names or default certificate — you detected the tool's defaults, not the technique. Change the profile and the same behaviour would sail through. You proved the SOC catches an out-of-the-box beacon, not the tradecraft.

Between the rule matching and a human seeing it: the rule was disabled or in test mode, a scheduled search ran before the data was indexed, suppression swallowed the firing, or it was routed below the severity anyone reads.

No. First confirm from the audit records that the extra matches really are the pipeline, not a second unknown actor. Then stop tuning: an owner outside the room is involved, so the gap leaves the session still open.

Confirm the technique really executed, then treat it as a regression rather than a new gap: find what changed, scope every other detection sharing that dependency, and account for the blind window between the change and this discovery. It is a change-management finding, not a coverage backlog item.