OneShot run

Input

Exactly one uploaded file, over 0 and up to 128 MB. No source link, no hash, no supporting files, no archive password, no pre-script and no start arguments: this form carries bytes and a guest list, and nothing else.

Guests

One to six Windows builds spanning Server 2012 R2 to Server 2025, or the fixed domain-joined pair. The Linux sandbox is not offered on this module.

Window

10 to 600 seconds per image, 120 by default, capped by plan before a credit is debited. An image finishes early once the sample has drawn what it draws and the guest goes quiet.

Layers

None. No static parse, no behavioural scoring, no threat intelligence, no AI narrative. The pipeline branches here and returns before all of them, and the scan completes with an empty verdict.

Output

A screen recording per image, and a per-image record of whether that guest came up, whether the sample actually launched, and how long it took to launch.

Billing

One credit per selected image. Every other module on this rail is one credit for the whole scan, and the arithmetic is shown before you submit.

A module that executes and photographs, and runs nothing else

The other six modules on this rail all end in a verdict. OneShot never reaches one, and that is a property of the code path and not a setting you turned off: the scan branches here and returns before the static layer, before the behavioural layer, before the AI layer, and before the threat-intelligence enrichment that every other module gets whether you tick anything or not. There is no verdict at the end, no score, no tags, no IOCs, no technique mapping, no rule hits and no process tree. What comes back is the screen, per image, with a plain statement of whether the file ever started.

That narrowness buys two answers no scored report gives you cleanly. The first is build dependency. A loader can resolve an API that only a newer runtime carries and fall over on an older one; the same installer can quietly no-op on the oldest image you still have in production. The second question is blunter, and analysts ask it constantly during triage: what does this thing put on screen? A ransom note, a fake updater, an error dialog, a decoy document, or nothing at all. One submission answers both, on real hardware-virtualized guests, with the same bytes on each one.

What kind of machine does the sample run on?

Each image is a full virtual machine under a hypervisor, on hardware the operator owns and administers. No container stands in for Windows and no emulator approximates it: the guest is a real Windows installation with a disk, a desktop, a signed-in profile and documents sitting on it. Its disk is a disposable layer stacked on a read-only golden image, and that layer is thrown away when the image finishes, so what one sample writes is not carried into the next image or into anybody else's run.

On the standard isolated path the guest does not boot for you. It is restored from a live memory snapshot of a desktop that had already booted, signed in and settled, so the machine the sample lands on is a used workstation with uptime behind it and its own idle background activity, and the restore takes seconds where a cold boot takes minutes. Domain runs and staged manual-execution peers are the exception: they come up cold, and the section below says what that costs you.

The recording is taken from outside that machine. Frames are read off the guest framebuffer by the host through the hypervisor, so the capture is not a process inside the session the sample is attacking. The one component that does live in the guest is asked for a single fact, the launch, and it supplies detail the outside view cannot: the report says so where that detail came from.

One sample, up to six Windows builds, one recording each

Selecting six images is a differential experiment, not one analysis repeated six times by hand. The wall clock follows from that: it is roughly the sum of the per-image windows plus each bring-up, not the longest of them. A short window across many builds and a long window on one or two are the two shapes that work well; a long window on every image is a long run, and the submission page states a measured per-image start estimate drawn from this deployment's own recent scans, marks which images are already standing by, and moves when you toggle internet access because that selects a different guest.

An image an operator has taken out of rotation, or whose golden is missing, is gone from the picker before you choose it, so no selection fails at run time for want of an image. If one fails during a run it fails alone, with a reason written into that image's row, and the remaining images continue. A failure at the containment boundary is the exception. That one is raised and it ends the image outright, because the only other way for it to finish is to hand you a guest whose isolation was not what the plan said.

What "behaviour that depends on the build" actually means

The phrase covers several unrelated mechanisms, and they do not read the same way on a recording. Knowing which one you are looking at is most of the work, because two of them are facts about the sample and the rest are facts about the image it landed on.

What does the guest do with the file you send?

OneShot has no file typing of its own and no unpacking stage. The extension on the name you submitted is the routing decision inside the guest, which is worth understanding before you submit, because it decides whether anything runs at all. Three treatments exist and there is no fourth.

invoice_2287.docm    name kept      opened through the shell association
updater.exe          name kept      launched on the desktop, standard token
helper.dll           name kept      launched on the desktop, standard token
stage2.bin           renamed        loader refuses a non-PE: nothing executes
delivery.zip         renamed        nothing is unpacked, nothing runs

A domain controller and a joined client, up at the same time

A large class of samples is uninteresting on a lone workgroup box and behaves normally the moment a domain exists around it. What such a sample looks for first is whether it landed on a joined machine, and on a standalone guest the answer sends it down the path it takes when it has arrived somewhere it did not want to be. The recording you get is a program declining to do anything. That is not a milder version of the test you wanted; it is a different test with a different answer, and the pair is what makes the first one available at all.

Membership is not one flag that a guest could be told to report. A joined machine has a computer object in the directory and a machine account behind it, an interactive session backed by a domain account, policy that arrived when it booted, and name resolution that answers for the domain. Those are separate facts, held in separate places by different parts of the operating system, and a sample that cares about the answer usually reads more than one of them before it commits. On the pair every one of them is true at the same time, because the controller is a Windows Server genuinely holding the domain and the client is genuinely joined to it. Nothing is standing in for the directory, so nothing has to hold up under a second question.

Choosing domain mode replaces the image selection with the fixed pair. That pair is checked against your plan while you are still on the form, so a refusal reaches you before you have uploaded anything and before a credit is debited. Both machines boot on a dedicated isolated segment and run concurrently, and each machine's start time is written into the stored record, so "they ran at the same time" is a fact you can audit later, off timestamps in your own scan.

Which machine you nominate is the one real decision this mode asks of you, and both answers are defensible. Nominate the client for anything that arrives the way a delivered file arrives: on a user's desktop, under a user's token, with a user's view of the domain, which is the situation most samples were written for. Nominate the controller when the question is what the sample does with a directory and elevated surroundings in the same place, and leave the client up as the domain peer it will look for. Either way the second machine is live for the whole window, so the choice moves where the sample starts and changes nothing about what exists around it.

The machine you do not nominate

The second machine is the more useful half of the design. The sample is placed on its desktop under its own name and deliberately not started, so you can execute it there by hand over the live console, at a moment you choose, from a machine and a session with a different relationship to the domain than the target has. A payload that does something meaningful only when it is launched on a controller gets exactly that opportunity while the domain around it is up. So does one that behaves differently under a human hand than under an automated launcher.

The peer earns its place even if you never touch it. It is a real member of the domain for the whole window, which is what makes the target's checks answer truthfully, and its screen is recorded throughout, so a message box, an installer or a logon prompt that appears there is evidence about lateral behaviour that a single-guest run cannot produce. Two recordings come back from a domain run whether you interacted with one, both or neither.

Both recordings carry capture offsets from the same run, which is what makes a two-machine test readable a month later. Launch the file on the peer partway through the window and that moment is locatable on the peer's own recording; go to the same offset on the target's recording and you can see whether anything arrived there, and how long after. A single guest cannot pose that question at all, because the question is about what one machine did to another while both were up.

What the pair writes down

The record for a domain run carries what a single-image run does, per machine, and two facts that only exist because there are two machines: which of them was the target and which was the live peer, and the start time of each. The console labels the roles while the run is live and the finished report repeats them, so a reader who opens the scan a month later does not have to work out which screen was which. Ending the run closes both machines, and neither is left running because the other stopped first.

Recorded from outside the guest, and reported as two separate claims

The screen half of the output does not depend on anything the sample can reach. No recorder, driver or capture agent sits inside the machine, so a payload that ends every process in its session or takes the whole guest down does not remove the frames already written: the thing making them was never in the session it attacked. What such a payload leaves behind is a recording of it happening, up to the moment the screen stopped changing. The in-guest component reports one fact, the launch, and the recording does not rely on it.

Whole-frame comparison alone is not enough to build a recording on, and the capture here is designed around that limitation. A second dialog that replaces a first one in the same position scores below any threshold that also has to ignore a blinking cursor and a clock digit, so change alone would drop the screen you most wanted. Frames are therefore kept on a timer as well as on change, and the timer tightens at the start of the run and around your own actions on the console. The frame showing what was on screen when the run ended is kept past the storage bound, and past a comparison that would have discarded it. A byte-identical screen is not stored twice. It is recorded as a repeat annotated onto the frame it duplicates, so the timeline keeps the instant without keeping the picture again.

The second half of the output is the run record, and its central design decision is that "the VM came up" and "the sample ran" are answered separately. A guest that boots and is never handed its work produces a perfectly clean recording of an idle desktop, and reporting that as a success is how a broken run gets read as a harmless file. It is reported as a failure with a reason.

While the run is still going

The console is interactive, not a progress bar. Input is proxied into the running guest through an authenticated, permission-checked path with a staging gate that withholds keyboard and mouse until the sample is actually in the machine, so nobody clicks on a desktop that does not have the file on it yet. Three controls sit beside it.

Next image

Ends the current guest and starts the next one in the queue. The recording made so far is kept and the image is reported with the outcome it reached.

Extend

Adds a fixed step to the guest currently running, up to a hard total cap, for when a sample is mid-installer as the window runs out.

End run

Closes every machine, including both halves of a concurrent domain pair, and writes the images it never reached into the report as skipped.

How do you read two recordings of the same sample?

The report gives you one player per image, labelled with that image, carrying its frame count and the window it covered, and it says so on the card when the run was ended early. Playback follows the real capture offsets, so a quiet stretch plays as a quiet stretch and a burst plays as a burst; any frame can be opened full size to read dialog text off it. On a domain run the two players are labelled with their roles, and the one where the sample ran is marked.

Start with the launch record, not the pictures. Two images that both launched and then drew different screens is a finding about the sample. An image that never launched is not a difference in behaviour at all, it is a difference in whether the test ran, and reading it as evasion is the most expensive mistake available on this module. Once the launch column is clean, the differences between recordings are worth something.

The discipline that makes this work is that the input is fixed. The same bytes reach every guest under the same name, with the same privilege, on the same disposable disk arrangement, so a difference between two recordings has nowhere to come from except the build. That is the whole reason the module has no tuning controls: a knob you could set per image would put a second variable into an experiment with one.

What this module does not do

It shows what was drawn, not what was done

A sample that runs silently and works over the network produces a recording of a desktop that never changed, and that recording is not evidence of a benign file. Injection, persistence, C2, dropped payloads and the API-level picture live in file analysis, which instruments the guest and scores what it sees.

Privilege is fixed and not selectable

OneShot launches the sample with a standard, non-elevated user token, and no control on this form changes that. A sample that needs elevation to show its behaviour will show you a failed elevation instead.

There is no detonation tuning

The controls file analysis carries are not on this form at all: start arguments, type and export overrides, pre-scripts, work paths, environment shaping, and the memory, process and injected-image dumps. The one thing you can vary during a OneShot run is yourself: the live console passes real keyboard and mouse into the guest.

Archives are not unpacked

Neither is anything else with an unrecognised extension. It is renamed on the way in, so the loader refuses it and nothing executes. The report says exactly that, so a still desktop always arrives with its explanation attached.

Workgroup images run in turn, not together

Only the domain pair is concurrent. The live console is explicitly a queue with a control to move to the next image, and the wall clock is the sum of the windows plus the bring-ups.

Timed coverage has a gap you can reason about

Not every grab is stored, so a state that appears and vanishes between two stored frames can be missed. A raw frame stream would close that gap and would carry no bound that keeps it inside a report; the recording is the deliberate trade, and it is why the timer runs alongside change detection at all.

The recording starts once there is a desktop to photograph

A grace period covers the boot screen. On the fast restore path the guest already has a desktop and this costs you very little; on a domain pair, which cold-boots, it covers part of the way there.

The recording is bounded per image

The budget is a storage bound, not a judgement about the sample. Reaching it ends that image's recording for the remainder of its run, the report says that it was reached, and the end-of-run frame is still taken.

Documents need an image with an office suite

On a server image there is no association to open one with, so the recording shows a desktop and nothing else. That is a correct observation about the image, and it is why the matrix above names which images carry one.

Exports flatten the grouping

The PDF and DOCX reports embed a leading set of screenshots labelled by number, up to a bound. Per-image players, real-time offsets and repeat annotations exist on the web report only.

Console only

OneShot is not on the agent-facing MCP surface, which accepts no bytes for it, and not on the anonymous landing lane, which refuses it outright. It is a signed-in module.

Monthly credits run 20, 100, 500 and 5,000 across those four rows, and the one-credit-per-image rule is what makes a six-image OneShot the most expensive single submission on the platform. Egress is the one setting the form does not decide at all: the network a guest is attached to is chosen at the moment of attachment, from the set of plans that may have it, so a hand-crafted request asking for internet on a plan without it gets an isolated segment and no error worth exploiting. Community and anonymous traffic are structurally isolated, not isolated by a default that a request could argue with.

Where this module hands off