You have read a report describing an actor that uses scheduled tasks to run scripts from user-writable directories. Turn that into a threat hunt.

The hypothesis: if this actor is present in our environment, we would see scheduled tasks whose action invokes a script interpreter from a user-writable directory such as AppData, Temp or Public, created by a process that is not a legitimate installer or management agent.

That is testable and scoped, which "look for this actor" is not.

Data required: task creation telemetry from EDR, or Windows event ID 4698 if task auditing is enabled, plus process creation events so I can see the parent that created the task. Before anything else I would check we actually collect this and what the retention is, because the hunt is only meaningful over the window we can see.

Expected benign volume is the part people skip and it is the part that decides whether the hunt is feasible. Software updaters, endpoint management agents and backup tools create scheduled tasks pointing at user-writable paths routinely. So I would characterise the benign population first — group by task name, creating process, signer and target path — and only then look at what does not fit the baseline. Filtering on signed parent processes and known-good task name patterns usually reduces it to something reviewable.

Note what I am deliberately not doing: I am not hunting the specific task names or hashes from the report. Those are atomic indicators, cheap for the actor to change, and worthless a month from now. The behaviour is the durable part.

Outcomes. If I find something, it goes to IR and the pattern goes to detection engineering as a rule. If I find nothing, that is still a result — either we have raised confidence this technique is not present in the window we can see, or we have discovered that we cannot see it, which is a visibility gap finding worth reporting on its own. If the baseline turns out to be too noisy to detect on, that is also a finding: it tells us the detection needs a different observable.

Either way I would produce something durable — a Sigma rule, a documented gap, or a tuned baseline — and feed what I learned back into collection requirements, which is the Exploit and Analyse half of F3EAD.