Tamper protection blocked your emulation technique — how do you learn whether a detection existed behind it?

## Why a block is an unfinished experiment The purpose of firing a technique at live defences is to learn what the defenders would have. When a prevention terminates the process at its first step, the technique never produced the behaviour the rest of the chain was supposed to observe. The exercise has learned one true thing - this control convicts this tool in this configuration - and has learned nothing at all about detection. Reporting that as coverage is the error; leaving the cell blank forever is the other error. ## Step one: harvest what survived, before running anything again A block is late in the sequence. Process creation typically happened first, so on a Windows estate look for the process-creation record: Sysmon Event ID 1, which carries the command line, the parent image and hashes, or Windows Security 4688, which carries the command line only where audit policy was configured to include it. Then check whether the prevention event itself reaches the SIEM, and if it does, whether anything keys on it. This matters because it changes the work item. If the telemetry is there, you do not have a visibility problem - you have an unwritten rule, and it can be written today against records you already hold. If the telemetry is not there, no re-run under any policy mode will help until collection is fixed. ## Step two: the detect-only window The only way to see the whole behaviour chain against the real stack is to let it run. That means putting the prevention policy into detect or audit mode - and it means doing it in the smallest form that answers the question: - one named host, not a machine group and never the estate - a bounded window measured in minutes, with an agreed abort - the endpoint owner's explicit sign-off, because they carry the risk of an unprotected machine - an analyst watching live, and the operator running one technique rather than a chain - policy verified restored afterwards, not assumed restored Where that sign-off is refused - and refusal can be entirely reasonable on a production workstation - the fallback is a lab host built with the same agent, the same policy and the same telemetry pipeline, accepting that the fidelity gap is real and stating it in the result. ## Step three: the variant Often the more informative run. Achieve the same effect with different tooling or a different parent, and see what happens. Three outcomes, all useful: the control convicts the variant too, which tells you the prevention is behavioural rather than tool-specific; the control lets it through and a detection fires, which is the answer you wanted without ever weakening a policy; or the control lets it through and nothing fires, which is the gap the exercise exists to find. ## What does not count as an answer Taking the stored record of the blocked attempt and replaying it through the rule engine to see whether the rule matches is not proof. It tests the rule's logic against one input you chose. What you are trying to establish is whether the record would be produced, arrive, match and surface *under the real conditions of the behaviour running* - and the only thing that demonstrates that is executing the behaviour. This is the specific reason emulation exists alongside rule testing rather than being replaced by it. Equally, the operator's report that "it got blocked" is a hypothesis about which defence acted. On a workstation with an endpoint agent, application control and script-block policies overlapping, confirm from the defender-side record which control convicted before you design the follow-up run. ## Recording the result The results table should be able to hold "prevented; detection unestablished" as a standing state, with an owner and a date for the follow-up run. That row is honest, it is actionable, and crucially it cannot be summarised into a coverage claim by someone reading quickly. When the follow-up runs, it resolves into prevented-and-detected or prevented-and-undetected, and only then does the technique leave the queue. ## The interview answer Lead with the diagnosis - the block truncated the behaviour, so no detection could fire and no evidence exists either way. Then give the ladder: harvest surviving telemetry first because it is free, then a scoped detect-only window with an owner's sign-off, then a variant. Close on the discipline: the row stays unestablished until one of those runs, and you do not accept a replayed record as a substitute for executing the behaviour.