Four hundred hosts carry the same scheduled task, service and Run key — which artefacts decide rollout versus foothold?

### Why uniformity is weak evidence The instinct is to reason "it is on every host, therefore it is managed". The reason that fails in this environment is specific: a remote-management tool with standing execute rights over the whole estate is precisely the capability an intruder wants, and an intruder who has it produces the same fleet-wide uniformity by design. Sameness distinguishes *centrally deployed* from *host-by-host*; it does not distinguish *authorised* from *not*. Both branches are live, and the artefacts have to close it. The scenario is also a genuine **benign true positive** more often than not: the detection was correct that a scheduled task, a service and a Run key appeared across the estate and that a signed scripting interpreter now runs nightly. The behaviour is real. It is just authorised, and that is a different finding from a false positive — the rule saw what it claimed to see. ### The artefacts that carry identity **The task definition.** `C:\Windows\System32\Tasks\<path>` is an XML file. It carries the registration author, the principal the task runs as, the trigger, and the exact action path and arguments. Compare it byte for byte across a sample of hosts. A vendor rollout is machine-generated and identical; hand-made variation across hosts is worth explaining. The task's own namespace matters too — vendors register under their own folder rather than at the root. **Binary identity.** Two independent handles: the code-signing publisher on the file, and the SHA-1 recorded in the `InventoryApplicationFile` entries of `Amcache.hve`. The hash is the stronger of the two because it survives the file being deleted and can be matched against the vendor's published build. A valid signature says the binary is what that publisher shipped; it does not say the publisher's tool was doing authorised work on this host. **The service record.** System Event ID 7045 gives the service name, service file name, start type and the account. An install performed under the management tool's own service account, at the same minute across hundreds of hosts, is a very different picture from installs scattered across interactive accounts. **Registration timing across the fleet.** Not a timeline exercise, just a distribution: a push lands in a tight band or in deliberate waves. One host registering the same task two days later, or under a different author, is the outlier that deserves full treatment — and outliers are where this kind of case actually turns. ### The artefact that settles it The mechanism can be copied; the *content executed* is harder to disguise. A signed interpreter — a scripting host shipped by the platform vendor and legitimately used by the management tool — will run whatever it is pointed at, and the question is what it was pointed at. - The interpreter's **Prefetch file-reference list** names files it touched in roughly its first ten seconds, which usually includes the script path it loaded. A path inside the vendor's directory is one answer; a path under a temp or user directory is another. - A **Sysmon Event ID 1** record, where you have one, carries the full command line, which names the script directly. Security 4688 does the same only where the audit policy that populates the command-line field was enabled. - The script file itself has its own hash, and an Amcache or file-system record of when it arrived. This is the artefact the platform engineer is entitled to be shown, and it is the one to have in hand before the conversation. ### What you owe the engineer whose fleet you quarantined He will ask which artefact you believe shows his tool ran something it did not, and "it looked like persistence" is not an answer. Be able to say exactly what you had and what it did and did not prove: the task exists on four hundred hosts (registration), the interpreter ran nightly (Prefetch run counts and times), and — the open question — the script it loaded was or was not the vendor's. If the reference list resolves to the vendor path on every host you sampled, the branch is closed. ### Closing it, and closing it usefully Close as a benign true positive and record the artefact that separated the two branches, in the words the next analyst will search for: *the interpreter's Prefetch reference list resolves to the vendor script path; a non-vendor script path there is the discriminator*. That note is what stops the same alert costing four hundred hosts a second time. Two things it should not become: a claim that the tool can never be abused, and a decision made in the case notes about what the estate collects or suppresses in future — those belong to the people who own the detection and the tooling's privileges, not to the artefact reading. ### The residual risk to state plainly Benign this time is not benign forever. The same three artefacts are exactly what an intruder inside that management tool would produce, and the discriminator you wrote down — the content the interpreter loaded — is the one that would still hold. Say so in the note, and say what telemetry would have to exist for the next analyst to check it in minutes rather than hours.