In an adversary emulation run, does a prevented technique count as detected?

## What the question is really testing Adversary emulation means deliberately executing a chosen attacker behaviour against defences that are switched on and in their production configuration, then recording what the defences did. The tempting output is a two-column table: technique executed, and pass/fail. That table is wrong, because "fail" for the operator and "success" for the defenders are not the same claim, and because two very different defensive results both look like a stopped operator. ## The three outcomes **Prevented.** An endpoint control matched the behaviour and stopped it: the process was terminated, the service-stop was refused by tamper protection, the script was blocked. This is a *control* result. It proves that an agent on the host convicted something. It does not prove that any detection logic exists over that behaviour, that a rule in the SIEM would have matched, that an alert was raised into a queue a human works, or that anyone would have noticed. In many estates the prevention event lands in the endpoint vendor's own console and is never forwarded, correlated or triaged. **Detected-only.** The technique ran to completion and produced an alert an analyst could act on. This is a *visibility* result: the behaviour was not stopped, but the SOC has a chance to respond to it. **Undetected.** The technique ran to completion and produced nothing anyone would see. Whether that was because no record was written, no rule matched, or nobody worked the alert is a separate attribution exercise; for the results table, the cell is simply "undetected". A fourth cell exists and is the only comfortable one: **prevented and detected**, where the control stopped it *and* a detection fired on evidence that reached the SOC. That is the only row where you may honestly claim the behaviour is both stopped and seen. ## Why the distinction is not pedantry A prevention is a single point of failure with no observation behind it. Consider a defence-evasion step on a Windows workstation: the operator tries to stop the endpoint sensor's service and then clear the Windows Security log. Tamper protection refuses the service stop and a prevention rule kills the log-clear. Excellent - but now ask what the SOC would see if the operator had used a variant the control does not convict, or if the prevention policy on that machine group had been in audit mode after a change window, or if the technique had run on a host where the agent was late installing. The answer, if the only record was the block, is nothing. The estate's entire knowledge of that behaviour rests on one control deciding correctly every time, forever. A prevented result is therefore not a coverage claim; it is a *deferred* coverage question. The honest row reads "prevented; detection status not established", and it stays that way until somebody establishes it. ## The remediations differ, which is why the cells must differ - **Prevented, not detected**: build a detection on whatever record survives the block, or forward the prevention event itself into the SIEM so the SOC learns about attempts. The work is a visibility work item, not a control work item. - **Detected-only**: the alert exists, so the questions are quality and response - did the alert say enough to act on, and would the response have been fast enough. Adding prevention may be the answer, or may be too risky for that behaviour. - **Undetected**: a detection has to be created, and until it is, that technique is invisible. Merge the first two cells and you fund the wrong work. Merge prevented into detected and you report coverage you do not have. ## What the operator's experience does not tell you The operator knows the command failed. That is the weakest available signal about the defence: an operator can be stopped by a control, by a broken command, by a missing privilege, or by an application-control policy nobody remembers deploying. The result you record must be sourced from the defender's records - the prevention event, the alert (or its absence), the queue - not from the operator's terminal. A red-teamer's "it got blocked" is a hypothesis about which defence acted, and on a workstation estate with several overlapping controls it is quite often the wrong one. ## What to say in an interview State the three outcomes, name prevention as a control result rather than a visibility result, and say plainly that a block can mask the absence of any detection behind it. Then add the operational consequence: the exercise must refuse to convert a prevented outcome into a coverage claim, because the day the control does not convict is exactly the day you need the detection that was never written.