Release: OneShot Run across the full OS matrix

OneShot Run executes one sample on every Windows sandbox image we maintain, back to back from one submission, returning a screen recording and a launch record for each. It shipped because one detonation on one build is a single observation, which cannot separate a harmless file from a missing dependency from a sample that read its surroundings and declined to run. Identical bytes across the matrix make that a comparison.

Key facts

Why one sandbox image is not enough evidence

A quiet run has several explanations and looks the same in all of them. The file needed a runtime the image lacks, or a function that arrived in a later build. It read the machine, decided it had landed somewhere it did not want to be, and exited politely. Or it was never handed its work at all, which is a broken run wearing the costume of a benign one.

Better scoring does not settle it, because the ambiguity sits in the evidence and not in the score. What settles it is a second run and a third with everything except the operating system held still. That is OneShot Run: fix the input, vary the image, let the difference between recordings carry the finding.

What changes between sandbox images

Build is the obvious axis and the least useful one stated abstractly: it covers unrelated mechanisms that read differently on a recording. An exported function present from one release onward draws a working window on the newer guest and a missing entry point error on the older one. A sample that branches on product type runs on the workstation images and sits idle on the servers. Present software is separate again: only the two workstation images carry an office suite, so a document renders there and nowhere else, a fact about the image rather than the sample.

Privilege is not an axis, and neither is locale. Every image launches under the same standard user token, never an administrator one, because a knob you could set per image puts a second variable into an experiment built to have one. A sample keying on language therefore looks identical on all six recordings, and that is not evidence no such check exists. Hardware exposure varies only where it must: Windows 11 boots through UEFI firmware with a virtual TPM and the others do not, while the rest of the device surface is held the same and kept narrow, for reasons the security page gives.

What makes running the whole matrix affordable

Wall clock on a matrix run is the sum of the per-image windows plus each bring-up, so bring-up decides usability. A cold boot to a settled desktop takes a couple of minutes, and six of those in front of six short windows is a run nobody waits for.

Guests are restored instead, from a live memory snapshot of a desktop that had already booted, signed in and gone quiet. Restore is seconds where a boot is minutes, and the machine the sample lands on has uptime behind it. A standby pool keeps guests restored and polling before any scan asks. One rule there was expensive: a standby counts as ready only once its own waiter has polled, because the hypervisor calling a domain active is a different claim, and a guest that is up but deaf sends every scan behind it to a cold boot.

A standby is never reused, and every guest writes to a throwaway disk layer over a read-only golden image, deleted when that image finishes. The domain pair is the exception: both machines cold boot, the price of a directory that is genuinely running.

What OneShot captures per run, and where the capture happens

Frames are read off the guest framebuffer by the host through the hypervisor. Nothing records from inside the session the sample is attacking, so a payload that ends every process it sees still leaves a recording of that happening.

Change detection alone is not a sound basis for a recording, and we measured why: a second dialog replacing a first in the same position moves the whole-frame average by less than a taskbar clock digit ticking over. A threshold quiet enough to ignore the clock drops the screen you wanted, so frames are kept on a timer as well as on change.

The run record is the other half. Its central decision is that "the guest came up" and "the sample ran" are answered separately, because a guest that boots and is never handed its work produces a spotless recording of an idle desktop, and calling that a success is how a broken run reads as harmless.

One live screen is interactive at a time, which follows from running images in turn. Keyboard and mouse are proxied into the guest over an authenticated path, withheld until the sample is in the machine. Next image, extend and end the run sit beside it.

How to read a matrix result when only one image detonates

Read the launch record before the pictures. Two images that both launched and drew different screens is a finding about the sample. An image where the launch never happened is a difference in whether the test ran, not in behaviour, and reading that as evasion is the costliest mistake here.

With that column clean, differences mean something. A window on the newer builds and a bare desktop on the oldest, launch recorded on both, points at a runtime the old image lacks; take that image to file analysis, where the API-level trace names what failed to resolve. A document that opens on one image only is the shell association, which document analysis instruments properly.

What a matrix run will not tell you

It shows what was drawn, not what was done. A sample that works silently over the network gives you a recording of a desktop that never changed, which is not evidence of a benign file. Injection, persistence, dropped payloads and the API-level picture belong to the instrumented modules; the platform overview maps question to module. Six builds are not every environment, archives are not unpacked, and a state that appears and vanishes between two stored frames can be missed.

Frequently asked questions

Does OneShot Run produce a malware verdict or a score?

No. OneShot Run runs no static parse, no behavioural scoring, no intelligence lookup and no AI, so the finished scan carries no score, no indicators and no technique mapping. What comes back is a screen recording per image and a record of whether the sample launched on it.

Do all the sandbox images run at the same time?

Workgroup images run in turn, one guest at a time, so a matrix run takes the sum of the per-image windows plus each bring-up. Exactly one live screen is interactive at any moment, and a console control moves to the next image early. The domain-joined pair is the one concurrent case.

Why restore from a snapshot instead of booting each sandbox image?

A cold boot to a signed-in, settled desktop takes a couple of minutes per image, and six of those in front of six short windows makes a matrix run impractical to sit through. Restoring a live memory snapshot takes seconds and hands the sample a machine with uptime behind it.

What does it mean when only one image in the run detonated?

Check whether the other images recorded a launch. Where the launch is missing, the test did not run there, commonly because an unrecognised extension was renamed and refused by the loader, and no conclusion about the sample follows. Where every image launched and only one drew anything, the difference belongs to the build.