A threat report says the crew phishes OAuth consent for mail-read scope. What turns that into an executable test?

## Technique, procedure, test case Three things get confused here, and interviewers separate them deliberately. - A **technique** is a class of adversary behaviour with a stable identifier, useful for labelling and reporting. - A **procedure** is one concrete way that behaviour was carried out: the tooling, the parameters, the sequence, the artefacts it leaves. - A **test case** is a procedure plus everything needed to run it and judge it: preconditions, execution steps, the observable you expect, the criterion for success, and the criterion for stopping. A plan that lists technique identifiers is a scope document. An operator handed only that will improvise a procedure, and the improvised one is what your results are actually about. ## What the report gives you and what it does not A profile paragraph typically gives the shape of the behaviour and the outcome. It rarely gives: - **Which consent path.** A user consenting for themselves and an administrator consenting on behalf of the tenant are different acts, leave different audit entries, and are gated by different tenant settings. If the estate blocks user consent outright, one variant is unexecutable and that fact is itself a finding about a preventive control. - **Which scope.** Read-only mail access and broader mailbox permissions are different grants and different subsequent behaviour. - **What the token is used for and how fast.** Slow paced reads and a bulk pull look nothing alike in volume-based signals. - **What the application looks like.** Display name, publisher state, redirect target: detections frequently key on exactly these attributes rather than on the behaviour. The honest response to each gap is the same: pick the variant that is plausible for your estate, record the assumption in the test case, and mark it as an open question for the intelligence side rather than silently deciding. ## Fidelity decides what a result means Emulation trades fidelity against safety and effort. If your implementation differs from the reported one in the attribute a rule keys on, a no-detection result is ambiguous: it may mean the estate is blind to the behaviour, or it may mean your application did not look like the one the rule was written for. That distinction is the difference between a detection-engineering finding and a note that your tooling was unrepresentative. The useful discipline is to state, per test case, which attributes are faithful and which are stand-ins. Faithful: the grant really happens, the token is really issued, the API really returns mail. Stand-in: the application is yours, the mailbox is seeded, the volume is bounded, nothing leaves the tenant. The claim you write afterwards is scoped to the faithful part. ## Expected observable and success criterion Every test case names, in advance, **where the evidence should appear**: the identity provider's audit trail for the consent event and the resulting delegated-permission grant, and the SaaS tenant's audit records for the mail reads made with that token. Naming it in advance is what makes the exercise diagnostic - if nothing appears in the log at all, that is a telemetry finding; if the record is there and no rule fired, that is a detection finding; if a rule fired and no analyst acted, that is a process finding. Writing the observable afterwards lets you rationalise whatever happened. Success criteria are separate from detection outcomes. "Did the operator obtain mail?" and "did anything fire?" are independent, and all four combinations are informative - including the uncomfortable one where the behaviour succeeded and an alert fired but nobody worked it. ## Variants are part of the design One technique usually deserves more than one test case, because a rule that keys on a single implementation will pass one variant and miss the next. Two or three procedures for the same behaviour - different scope, different consent path, a different application profile - turn a binary result into a description of how narrow the detection is. ## What the artefact looks like A good test case reads like an experiment: preconditions, steps precise enough that a different operator reproduces it, the expected observable and where to look for it, success criteria, abort conditions, and the assumptions you had to invent because the report was silent. That last section is what lets the next cycle improve the fidelity instead of repeating the same guess.