x.com/lukOlejnik/status/2049822204599087472

The linked SentinelOne research says svcmgmt.exe — the carrier sample tied to fast16.sys — “was uploaded to VirusTotal nearly a decade ago” but “still receives almost no detections: one engine classifies it as generally malicious.” That means it was not literally undetected on VirusTotal.

So the post overstates the finding. The accurate version is that the sample had very few detections, not zero detections. The same SentinelOne article also specifically names svcmgmt.exe as the VirusTotal-uploaded sample, so phrasing this as the whole worm simply “sat undetected” is less precise than the source supports.

This sentence overstates what the linked research concludes. SentinelOne writes that this kind of sabotage “would be foiled by verifying calculations on a separate system.” It then says that if multiple systems share the same network and security posture, the wormable carrier would spread there too, reducing the chance that an independent calculation would differ from the corrupted one.

That is materially different from “eliminating the possibility” of a clean cross-check. The source describes a tactic that makes detection harder in a shared environment, not impossible in general.

The linked SentinelOne analysis describes fast16.sys as highly selective. It says the driver only treats a file as a valid target when it is an .EXE and carries Intel compiler metadata, and that the strongest matches were a small set of high-precision engineering/simulation programs such as LS-DYNA, PKPM, and MOHID.

That means network-wide deployment did not imply “calculations on every machine” would be corrupted. Only machines running the targeted software — and specifically targeted executables matching the driver’s rules — would have their numerical results altered.