Sixty-Two Quarantines at Shift Change

Do not mass-release, and do not mass-hold. Split the population by evidence.

• Release the 59 with task-scheduler parentage after confirming the script hash, signer, and command line match the deployment package. That is a false positive from an encoded-command rule, and the clinical impact of holding a PACS controller is real and immediate.
• Hold the 3 with wscript.exe parents. A script launched by Windows Script Host did not come from the scheduled task; releasing them into the same batch would launder a genuine alert as noise.
• Stop the bleeding on the tuning side only after containment of the three: do not apply a tenant-wide exclusion during an active burst, because an exclusion is global and irreversible-in-effect for every future alert of that shape.

Reasoning The blast radius of being wrong is asymmetric. Releasing 59 benign hosts costs you one repeat alert. Releasing the 3 outliers may hand an attacker the same trusted-script path everyone else is on, with an exclusion covering it. So: restore clinical service by exception, keep the anomalous set contained, and make the change tenant-wide only once the three are understood.

Cheapest discriminating evidence first, and pivot on the parent, not the payload.

1. Process tree on the three hosts: what is wscript.exe's own parent, what .vbs/.js file was executed, and where does that file live? A dropped file in %TEMP%, %APPDATA%, or a user-writable share is a strong signal; a file in a signed software directory is not.
2. Command line and file hash of the script: compare against the IT deployment package by hash. Same hash, different parent means something else is invoking the approved script - that is execution-hijack behaviour and worth escalating regardless of payload.
3. Timing: did the three fire inside the same window as the mass burst, or before/after? Isolated timing suggests an independent, pre-existing intrusion that the burst has now camouflaged.
4. Pivot on identity and network: which user account, and did any of the three attempt outbound connections in the alert window?

Judgement The key insight is that an alert storm is a cover opportunity. The attacker's best day is the day 59 false positives are being released by hand. Treat the three as a separate incident with separate evidence handling, and explicitly tell the help desk that the exclusion request is paused pending these three - otherwise the exclusion will be applied by someone else while you triage.

Deny the tenant-wide hash exclusion as written; scope it instead.

A bare hash or filename exclusion disables detection for exactly the technique most abused in script-based intrusions - an encoded PowerShell command - and it applies to 4,100 endpoints, including the ones with no legitimate need for this script.

Scoped alternative

• Exclude by the combination: signer certificate + file path + parent process (task scheduler) + the specific host group that runs maintenance. Combined conditions are far harder to satisfy maliciously than any single field.
• Time-box the exclusion and set a review date; require re-approval.
• Keep the encoded-command detection enabled for everything outside that combination.

Residual risk to state explicitly

1. Anyone who can run the signed script through the scheduler inherits the exclusion - so protect who can create scheduled tasks on the scoped group.
2. Encoded commands remain a legitimate-looking path for attackers; you have traded a small amount of noise for a small amount of blind spot, which is why the time box and review date matter.
3. The real fix is upstream: stop deploying maintenance scripts as base64-encoded one-liners. Recommend the IT change, because every future deployment of this shape will re-trigger the same storm.