How do you tell whether the SOC detected your emulation technique or just the operator's noise?
answer
- attribute the fire before claiming it
- read the rule, not the outcome
- thresholds and bursts mean tempo
- re-run paced, relocated, renamed
- loud actors exist, keep the rule
basics
~10 sRead which rule fired and what it keyed on. A threshold or a burst window is a detection of the pass, not the technique. Re-run it paced, from another host and account.
solid answer
~50 sAn emulation pass has a signature a real intruder does not: dozens of discovery commands inside a minute, from one host under one account, with default tool names and a scripted parent. If the SOC caught it, find out on what. Pull the alert and read the rule: if it keys on a count in a window, a rare burst, or an aggregation across commands, the conviction was tempo, not technique. Then run the honest second pass - one technique at a time, spaced over hours, from a different host and account, with renamed or built-in tooling - and see whether anything fires. Record both rows. Detected under exercise tempo and undetected when paced is a legitimate result, and far more useful than a single tick. The tempo rule is not wrong and should stay; it simply does not earn a technique coverage claim.
go deeper
Know that an exercise pass is much faster and more concentrated than a real intrusion, so an alert may have fired on the pace rather than on the technique you were testing.
Explain how to attribute a fire by reading what the rule keys on - a threshold or aggregation over a window versus a specific command line or parent-child relationship - and what the analyst's triage note reveals.
Design the quiet re-run: paced, different host and account, non-default tooling, one technique per window, and report both rows rather than collapsing them into a single tick.
Hold the line on what the results table may claim when leadership wants a clean number, and keep the tempo rule funded even though it did not earn the technique coverage the exercise was after.
## The problem An operator on a time-boxed exercise behaves nothing like an intruder with months. To get through a plan in an afternoon they run discovery commands back to back - account enumeration, system information, process and share listing - from a single foothold, under a single account, with tools whose names ship with the framework, all spawned from one scripted parent. Every one of those is a difference from a real operator, and any of them can be what the SOC actually convicted. When an alert fires, the exercise wants to write "detected" against the technique. The honest question is whether the detection was of the *behaviour* or of the *pass*. ## Establishing which one it was Go to the alert, not to the outcome. Read what the rule keys on: - a **count or threshold** over a window - more than N distinct discovery commands from one host in five minutes - is a tempo detection - an **aggregation** across otherwise unremarkable events is a tempo detection - a **rare-parent or rare-tool** clause may be either, depending on whether the rarity comes from the tool being uncommon in the estate or from the operator's default binary name - a clause matching the **specific command line or parent-child relationship** of the technique is a behaviour detection Then read the analyst's triage note. "Lots of commands in quick succession from one workstation" is the tell that a human convicted on volume. So is the alert arriving after the tenth command rather than the first. ## The quiet re-run The experiment that settles it is a second pass with the exercise artefacts removed: - one technique per window, spaced over hours rather than seconds - a different source host and a different account from the first pass - built-in or renamed tooling rather than framework defaults - a realistic parent process rather than a scripted launcher - nothing else running, so any fire is unambiguously attributable to that technique If something fires again, the detection is of the behaviour and the coverage claim is real. If nothing fires, you have learned the more valuable thing: the estate catches operators who hurry and misses the same technique when it is paced - which is exactly how a real intruder would run it. ## What to do with the result, and what not to do Record both rows separately: detected under exercise tempo, and the paced outcome. Do not collapse them into one tick. Do not delete or weaken the tempo rule. Loud actors are real - automated tooling, commodity intrusions and hurried operators all produce bursts, and a rule that catches them has genuine value. The defect is the *claim*, not the rule. What the result should produce is a detection work item for the technique itself, sitting alongside a tempo rule that stays exactly where it is. And be careful about the inverse error. If the paced re-run fires nothing, that is a result about this technique in this estate at this time; it is not a statement that the estate is blind, and it is not an invitation to argue that the tempo detection was a false positive. It was a true detection of a real burst; it simply did not prove what the results table wanted it to prove. ## The wider habit The general form of this question is: what property of my test, rather than of the attacker behaviour, could have caused the defence to act? Other versions show up constantly - the operator's account was newly created and the alert keyed on account age; the operator worked from a jump host that never runs interactive sessions; the tooling was unsigned and the conviction was on signature status rather than behaviour. Each of those turns a technique coverage claim into a claim about the exercise's own artefacts, and each is found the same way: read the rule, then re-run with that property removed. ## The interview answer Say that an emulation pass has a tempo and a shape a real operator does not, so a fire has to be attributed before it can be claimed. Attribute it by reading the rule's logic and the analyst's note. Settle it with a paced, relocated, renamed re-run. Then report both outcomes and resist both the urge to claim technique coverage and the urge to kill the tempo rule.
- Isn't a volume or tempo detection still valuable?Yes, and it should stay. Plenty of real intrusions are loud - automated tooling and commodity operators produce exactly those bursts. The defect is writing detected against the technique on the strength of it. Keep the rule, and raise a separate work item for a detection that keys on the behaviour itself.
- What exactly changes between the first pass and the quiet re-run?Pacing, source host, account, tool naming and parent process, and the number of techniques in flight. Change them together and you remove the exercise's own artefacts; run one technique per window so that any alert is attributable to that technique rather than to the combination.
- The analyst says they noticed the burst rather than any rule firing. How is that recorded?As a human observation of exercise tempo, which is weaker than a rule for the results table because it depends on that analyst, that shift and that queue depth. It is worth noting because it shows a person watching, but it cannot be relied on to repeat and it is not technique coverage.
A shop alarm that trips because someone ran through the door has not proved the shop detects shoplifting. It proved it detects running.
saying these in an interview costs you the question
- Counts an analyst spotting a burst as technique coverage
- Deletes the tempo rule as a false positive
- Runs every technique back to back from one host
- Never reads which rule actually fired
- Treats the paced re-run's silence as proof the estate is blind