Half your WMI persistence hunt needs a human to read the consumer's command line. What do you promote?
answer
- not everything found by hand becomes a rule
- one half is a fact, the other is a judgment
- a keyword list is broad and trivially avoided
- a silenced rule is worse than a documented hunt
- detect not-known-good instead of looks-bad
basics
~20 sSplit it. Promote the half you can state as a decidable claim — a binding created outside the known management accounts — and keep the half that needs a human judgment on the command line as a documented recurring hunt. Encoding looks-suspicious as a keyword list buys a noisy rule and a false sense of coverage.
solid answer
~50 sI promote the decidable half and refuse to fake the rest. The binding-creation half can be written as a rule: a `__FilterToConsumerBinding` created by an account outside the small set our deployment and management tooling uses, with the consumer record joined in so the alert carries the command. That is a claim a stranger can dispose of. The other half — deciding whether `wscript.exe //B C:\ProgramData\...\hc.vbs` is a health check or someone's loader — is a human reading a script body, and a keyword list approximating that judgment is a rule I will end up silencing within a month. With two of us and no capacity for another noisy rule, that trade is unaffordable. So the judgment half stays a recurring hunt with the hypothesis, the query and the cadence written down. What would change my mind is a maintained list of approved consumers, because then the rule matches *not in the approved set*, which is decidable.
go deeper
Recognise that some findings depend on a person's read of context and cannot be turned into a rule. Be ready to say that a scheduled hunt is a legitimate answer rather than an admission of failure.
Explain why a suspicious-keyword approximation fails in both directions — it matches legitimate automation and is trivially avoided — and what a decidable claim looks like by contrast.
Show the split in action: promote the structural half with an owner and triage notes, keep the judgment half as a documented recurring hunt or as enrichment, and price the option of a maintained approved-consumer list.
Own the honesty of the coverage story. Set the norm that a partial promotion is stated as partial, and be prepared to refuse a rule your team cannot work rather than accept one that will be silenced.
## The situation A hunter has found WMI event subscription persistence by hand. Their query returns every binding created in the estate over a window, and they then read each consumer's command line and decide, one by one, whether it is a management agent doing its job or something they do not recognise. On a monthly cadence, with a person doing the reading, that works fine. You are the detection engineer being asked to make it a rule. The question is not *can I schedule this* — you can — but *which part of this is expressible as a claim a stranger can act on*. ## The two halves are not the same kind of thing **The structural half is decidable.** "A `__FilterToConsumerBinding` was created by an account outside the set used by our deployment and management tooling" is a statement about facts present in the records. You can enumerate the approved accounts, the logic is stable, and a match is explainable without knowing anything about the payload. Join the consumer record so the alert carries the command line, add the owner and the triage note, and it is a rule. **The semantic half is not.** "This command line looks like a loader" is a judgment a human makes from context: what this estate normally runs, what this account normally does, whether the file path is one of ours, and whether the script body reads like automation or like obfuscation. Attempting to encode it produces a keyword list — `powershell`, `-enc`, `hidden`, `.vbs` — that is simultaneously too broad (legitimate automation uses all of it) and trivially avoided (a name that avoids your keywords passes). You do not get a detection; you get an approximation with an unearned air of authority. ## Why encoding it anyway is worse than not On a two-person detection team the arithmetic is brutal. A rule that fires three times a day, each firing requiring a human to read a script body and reach a verdict, is ninety judgments a month — which is more work than the monthly hunt was, dressed as alerts that imply a verdict is owed within an SLA. The predictable ending is that the rule gets silenced, and the team is then in the worst of all states: the work is not being done, and the record says it is. There is a second cost. A promoted rule is understood by everyone else as *this technique is handled now*. An approximation quietly converts "we hunt for this and a person judges it" into "we detect this", and the difference only surfaces during an incident. ## The disposition that is actually honest 1. **Promote the structural half** as a narrow rule with an owner, a threshold, and triage notes naming the benign producers. 2. **Keep the semantic half as a recurring hunt**, with the hypothesis, the query, the cadence and the person who runs it all written down. A scheduled hunt is a legitimate control. It is only embarrassing if it is undocumented. 3. **Say which is which.** When someone asks whether WMI event subscription persistence is covered, the answer is: binding creation by unexpected accounts alerts; payload assessment is a hunt on a stated cadence. A middle option exists and is often the best of the three: promote the semantic half as **enrichment rather than an alert**. The logic still runs, but instead of raising its own claim it decorates something else — a binding alert already carries the consumer's command line, and a host with an unrecognised consumer is worth a note on any other alert about that host. Enrichment costs no queue capacity and loses nothing. ## What would make the un-automatable half automatable The move that actually works is inverting the question. "Is this command line malicious?" is undecidable from the record. "Is this consumer in the set our configuration management is known to create?" is decidable, if — and only if — someone maintains that set. Detecting *not known good* instead of *looks bad* turns a judgment into a lookup. That is a real engineering proposal with a real cost: somebody owns the approved list, it has to be updated when tooling changes, and a stale list produces exactly the noise you were avoiding. Whether that cost is worth paying is a capacity question, and it is a much better conversation to have than an argument about keyword lists. The candidate who reaches this inversion, and prices it honestly, is showing the judgment the question is looking for. ## The general principle Not everything a hunter can find is something a rule can assert. The skill being tested is telling the difference before you deploy, saying so plainly, and keeping the residue as a named, scheduled hunt rather than pretending it does not exist.
- The hunter argues a keyword list on the consumer command line is better than nothing. What is your answer?It is worse than nothing if the result is a rule we mute and a coverage claim we cannot defend. Better than nothing would be a narrow rule we genuinely work, plus the keyword logic running as enrichment that decorates other alerts rather than raising its own. Same signal, no queue cost, no false claim that the technique is detected.
- What would make the script-body judgment automatable rather than a recurring hunt?A maintained set of approved consumers and command lines from configuration management. The rule then matches what is not in that set, which is a lookup rather than a judgment. The cost is real — somebody owns the list and updates it when tooling changes, and a stale list is noisy — so it is a capacity decision, but it is the only version of this that becomes a rule.
- How do you record the half that stayed a hunt, so it is not just forgotten?Write it up as a named recurring hunt with the hypothesis in one sentence, the query, the cadence, and the person who runs it. The point is that it exists as a scheduled commitment somebody owns rather than as a memory. A hunt on a stated cadence is a legitimate control; an undocumented intention is not.
A metal detector at a door is a rule; deciding whether the object in someone's bag is a problem is a person's job. Wiring the detector to alarm on anything metal does not automate the second job, it just makes the first one useless.
saying these in an interview costs you the question
- Encodes a keyword list and calls the technique detected
- Promotes everything and plans to fix the noise later
- Drops the finding because it cannot be made into a rule
- Ignores who will actually work the resulting alerts
- Never considers enrichment instead of a new alert