File analysis

Sample

Any content type, 1 byte to 128 MB. Upload it, or hand over a http/https link and the analysis host fetches it for you.

Supporting files

Up to 10 more files, 32 MB each and 64 MB together, written into the same directory as the sample before the guest boots.

Protected containers

A password opens zip (ZipCrypto and AES), 7z, rar, cab, arj and lzh. The payload inside is what detonates, not the wrapper.

Detonation images

Seven, all live: six Windows client and server builds and a Linux desktop, plus a two machine Windows domain pair.

Run duration

10 s to 600 s, 120 s by default, extendable by two minutes from the live view while the run is still going.

Report

18 sections in five groups, with ATT&CK Navigator layer, STIX 2.1, a sharing event bundle, defanged IOC text, PDF and DOCX exports.

What the module takes in

The submitted name decides nothing. Typing is done on the bytes, and the content is what routes the sample: an upload called invoice.pdf that opens as a PE is analysed as a PE, and a file with no extension at all is identified the same way as one whose extension matches its bytes.

The static chain genuinely parses PE32 and PE32+ in every guise the format takes (EXE, DLL, SYS, SCR, OCX, CPL, COM, MSI), managed .NET assemblies, ELF for 32 and 64 bit in both endiannesses across x86-64, x86, aarch64, arm, mips and ppc64, Go-compiled binaries, Windows shortcut files, compiled script executables, Python source and Python packaging artifacts, and text and script payloads. Where the bytes open as a document, whether PDF, RTF, OLE, OOXML, OneNote, CHM, HTML or MHT, the document engine runs in addition to the general chain, and a PE whose imports and subsystem read as a kernel driver additionally gets the BYOVD analyzer. Neither of those re-routings changes the image you picked. The guest you chose is the guest that runs the sample.

What happens if the sample fights the sandbox instrumentation?

It keeps recording, because most of the recording is not inside the guest for the sample to reach. A run starts by restoring a golden image from a live memory snapshot of a settled desktop onto a copy-on-write overlay created for that run alone. That sandbox is a full virtual machine under a hypervisor on hardware this platform operates: a Windows or Linux install with its own kernel, brought back from a snapshot of a desktop that had already been up for a while, so the sample arrives on a machine with uptime, running services and a user profile that has been used. The sample, its supporting files and the launch task are written into that overlay offline, before the machine is powered on, so there is no staging step inside the guest for a sample to watch and no download for it to fingerprint. When the run ends the overlay is deleted, and the golden image underneath it is opened read-only, so state does not carry from one run into the next.

Four of the seven recording layers are agentless: they sit on the analysis host and observe the guest from outside it. The packet capture is taken at the hypervisor link, the screen is read from the framebuffer the guest paints into, the memory image is a copy of guest RAM taken host-side, and the dropped files are carved out of the run's own disk overlay once the machine is gone. None of the four is a process in the guest's operating system, so a process list does not show them and unhooking inside the guest does not reach them. Terminating something in the guest stops nothing on the host side of the boundary.

The in-guest component is a second source and not the only one. It supplies the API-level arguments the outside layers have no way to reconstruct, and a run in which the sample refuses, unhooks or removes it still has its network, its screen, its memory image and its dropped files. That is what the placement buys: detail from inside and durability from outside, with the report naming which of the two produced a given row.

Three sensors of different privilege therefore watch the same run, and where they disagree the disagreement is the finding. A thread whose start address lies outside every loaded module, present in the memory image and absent from the API stream, says more than either source would say on its own. So does a process the in-process monitor never announced turning up in a pool scan that the kernel's own object list does not mention. The monitor's own activity is identified and excluded, so instrumentation work is not charged to the sample.

Attribution, and the machine's own noise

A Windows desktop is busy whether or not you detonate anything on it, so every file, registry and network row carries an in-scope flag and the basis for it, derived from the sample's process tree and the pid it was actually launched as. Machine-wide activity is kept and labelled, neither deleted nor promoted, rows that name no actor are counted as their own class, and the summary counts are recomputed after demotion, so a chip on the page reports the same number of operations the table underneath it holds.

What is read off the bytes

Static analysis does not wait for the machine. It runs on the host while the guest is restoring, arming and detonating, under a hard budget, so it costs the analyst no wall-clock time at all. If it does outrun that budget the scan still completes and the static row is recorded as failed with its reason, which is a different report from one that quietly omits a layer.

Nothing you submit is executed on the analysis host. Parsers run inside a namespace jail with no network, a read-only view of the host filesystem, a private tmpfs, dropped capabilities and an unprivileged uid. The line is drawn by what a tool does with the bytes, not by how well it is confined: reading a structure is host work, and anything that would interpret, emulate or install goes to a guest.

The static document carries one key per layer and every key is present on every file scan, whether that layer had something to say or not, so an absent layer and an empty one are not the same thing to anything reading the JSON. The layers cover content typing and MIME identification, hashing, whole-file and per-section entropy, PE structure, Rich header decoding, exploit mitigation posture, .NET metadata and decompilation, ELF structure, Go build metadata, packer and protector detection, compiler and linker signature identification, code signing, entry-point disassembly, the anti-analysis instruction scan, strings, capability categorisation, secret detection, configuration extraction, compiled-script recovery, shortcut analysis, YARA, antivirus signatures, container extraction, and IOC derivation.

Structure, and what it is worth

PE parsing produces the header and optional header, then the section table with its characteristics and the section the entry point lands in. Next comes the import table, where every function is annotated against a 56-entry suspicious-API-to-ATT&CK map, and the export table is read out with it. The resource tree follows, each resource carrying a digest with its entropy and a detected content signature, and the application icon is rebuilt from it as a renderable icon file. Version info and the embedded manifest come next, as do the debug directory and TLS callback presence. The Rich header is decoded into its per-tool records, which is a fingerprint of the machine the binary was built on and it survives a forged compile timestamp; the linker build recorded there is compared against the optional header's own linker version as a tamper check. Nine exploit mitigations are graded strong, partial or weak for the binary under analysis, with the reason for each grade stated. Managed samples additionally give up their unmanaged import table, which the native import directory cannot show at all, and are decompiled to C# with the sample's own types separated from the bundled library and compiler-emitted types so the review is over code somebody wrote.

Is high entropy the same as packing?

No, and this module does not treat it as such. A compressed container reads as high entropy, and so does a media file. A resource-heavy installer reads the same way, which is why the number on its own decides nothing here. A packing verdict is fused from signals that have to agree: section-name signatures for around 24 packer and protector families, entropy of executable sections specifically, sections that are both writable and executable, virtual against raw size anomalies, code sections with zero raw size, import sparsity together with the fingerprint of dynamic API resolution, an entry point that sits outside every section or in the last one or in a writable one, overlay presence and overlay entropy, embedded PE images or high-entropy blobs in the resource tree, literal packer markers, and TLS callbacks. Signals fuse per family. What comes out is a packed flag with a confidence beside it, a named family where one is identifiable, and a routing recommendation into detonation. Where the bytes are a container or a document or a media file, the entropy signals are left out of the fusion, because high entropy is what those formats produce by design.

Four installer builders and seven .NET obfuscators and protectors are recognised separately from packers. An installer is a distribution choice and an obfuscator a source-level one; neither is the same claim as compression at the section level.

Why does a signed file come back unverifiable?

Because the chain usually cannot be completed from inside an isolated environment, and the report publishes that fact under its own name. Chain building needs a network for revocation and a platform trust store to anchor against, and an isolated analysis environment has neither. Collapsing that into a red cross would be a claim about the file that the run did not support, so verification is published as three separate fields. The digest check against the file's own bytes is real and local, the chain evaluation is offline and says so, and the two are kept apart, each published under its own name.

A heuristic and a cryptographic check are never collapsed into a single verdict. Each is published under its own name, in the section that owns it, so a guess is never printed with the weight of a verification.

Strings, capabilities, secrets and configuration

Strings are extracted as ASCII and UTF-16LE and then filtered against runs of opcode bytes that happen to print, which is what separates a real string from disassembly noise; emulation recovers stack strings, tight strings and strings the sample decodes with its own routine. API use is categorised into 20 behaviour categories: process injection, code execution, anti-debug, anti-VM, stalling, persistence, discovery, credential access, defense evasion, network and C2, cryptography, ransomware, keylogging, screen capture, privilege escalation, service manipulation, registry, dynamic API resolution, shutdown and hooking, all from a 147-entry Windows and 29-entry ELF map, each carrying ATT&CK ids and a severity tempered by context. Names resolved dynamically are recovered out of the extracted strings and folded in, as are managed P/Invoke names, so a sample that resolves everything at runtime does not present as importless. Capability detection runs a 1,045-rule corpus mapped to ATT&CK and a behaviour catalogue, cached per byte identity so re-scanning the same file returns instantly.

Secret detection uses 238 anchored detectors. They cover private keys, cloud provider credentials, source-control and CI tokens, package-registry tokens, chat and webhook URLs, mail and SMS providers, payment processors, model provider keys, database connection strings, observability and identity providers, social platforms and wallet material. Every match is redacted at the head and tail. Beside it runs a categorised corpus of 121 malicious-string markers in seven categories. Configuration extraction pairs a self-contained beacon configuration decoder with dispatch to 74 named-family parsers. The decoder reads transport, port, sleep and jitter, the C2 list, the user agent, the POST URI, the kill date, the watermark, the DNS idle value and the host header. Decoded C2 becomes a high-confidence indicator and not another string.

The anti-analysis instruction scan reads the executable sections for the primitives a sample uses to work out where it is: RDTSC and RDTSCP timing, the CPUID hypervisor probe, the SIDT, SGDT, SLDT and SMSW descriptor-table red pills, IN port I/O, INT 3 concentration, INT 2D and ICEBP. Each is reported with its concentration and its ATT&CK id, under a severity tempered by context: one RDTSC reads a timer, and a tight loop of them is a stalling check.

The sandbox you configure

The image you pick is the image that runs the sample; there is no silent re-routing to something the platform would rather run. Community accounts reach three of the seven images and paid plans reach all of them.

Around that choice sits a detonation surface an analyst shapes per run. Part of it answers a check the sample makes before it will run at all; the rest gives a loader the conditions it was written for, or buys back time the run would otherwise spend waiting.

When the sample needs the rest of its kit

A first stage is often not a program that does anything by itself. It reads a configuration file that sat beside it in the archive, or a DLL expects its data file in the same directory, or a script decrypts a blob it looks for by name. Detonate that stage alone and it exits at its first read; the report is then a truthful account of a program that did nothing, which is a fact about the harness, and it tells you nothing about the sample.

Up to ten supporting files, 32 MB each and 64 MB together, are written into the same directory as the sample in the offline injection step, before the guest is powered on. The first stage finds the layout it was built for, and it finds the files already present, with nothing arriving mid-run for it to notice. Those files are the environment, not submissions: they are not typed, scored or reported as samples of their own. Where the kit arrived as one protected container, the password opens it host-side and the payload within is what is detonated, with the wrapper recorded but not run.

What a finding rests on

A rule name printed in red is not evidence, it is a citation with the source removed. Every YARA match in a report shows which of the rule's declared strings actually matched and out of how many, how many instances there were, a short escaped window of the matched bytes, the corpus the rule came from and that corpus's tier, the exact number of points the match contributed, and a sentence saying why. That sentence includes the case where the answer is zero.

rule             fam_loader_generic_b
corpus           curated family set, benign-tested, may name a family
strings matched  3 of 7 declared, 6 instances
preview          $s2  "Global\\%s-%04x"
                 $s5  "%s\\%s.tmp"
contribution     the points this match added to the score, with a
                 sentence saying why it was worth that much

The corpus is over fourteen thousand rules across roughly fifteen hundred files, and it is scanned with real external variables supplied, being filename, extension, file type and digest, so filename-aware rules both fire and hold fire the way their author intended. The file's storage path and its owner are deliberately supplied empty, which keeps a rule's matching surface on the sample itself and off where this platform put the file or whose account submitted it.

A vote is a distinct rule identity from a distinct upstream repository, so a rule that two projects both redistribute counts once and not twice. Before the report calls anything a family it wants corroboration from independent sources, and an uncorroborated candidate is printed as named but not established, which is a different sentence from an attribution and is written as one. Candidates are listed with the repositories that contributed them and the standing each one was published with.

The family set is curated by hand, and the build records what it refused: 942 rules with no string literals, 355 that name no family, three whose name is a predicate or a technique and no family at all, two that rest on a single string, two quarantined and one whose strongest string was four bytes long. The set that survives is scanned against 1,200 benign files and ships only at zero hits. Rules that merely describe a file, saying it is 64-bit, that it has an overlay, that it is a DLL, are classified as structural and shown among the file properties, so an ordinary signed binary does not collect red rows for being what it is.

The report grades its own evidence

Coverage is published as requested-against-actual pairs, so the difference between what you asked for and what the run delivered is printed, and never left to be inferred. A confidence grade with a stated meaning sits on top of it, and a decision word carries a qualifier sentence written to stay inside what was actually observed.

image        requested  windows10        actual  windows10
duration     requested  300 s            actual  300 s
network      requested  isolated         actual  isolated
sources      kernel trace, api monitor, packet capture, audit log
executed     yes, the launch root pid was observed
confidence   Observed
decision     suspicious
qualifier    behaviour was recorded and attributed to this sample;
             no family reached independent corroboration

Behaviour is matched against a Sigma corpus of over two thousand feed rules, with an engine that skips rules using aggregations, correlations or temporal proximity, because half-evaluating one and publishing the half would be a result the data does not support. Persistence is answered from a real before-and-after diff of the machine's autostart surfaces, matched against a catalogue of 90 named methods in eight families with their ATT&CK ids, where a Run key and a RunOnce key are two distinct methods and an image-file-execution debugger and a silent-process-exit monitor are two more; a runtime finding is strong evidence, and a bare static string reference is carried as a hint and kept out of the method list, so a mention in the bytes is never printed as an observed persistence method. Timestamp manipulation is raised from the writes the sensors recorded. Living-off-the-land abuse is matched over observed command lines across 31 binaries and 36 patterns, each requiring a distinctive abuse argument and not the binary's mere presence, and loaded or dropped kernel drivers are cross-referenced against a corpus of over two thousand driver identities for the BYOVD case.

Memory findings are subtracted against a per-image, per-dumped-process benign baseline that is captured deliberately and is not learned from live scans, so a decoded payload still scores while the managed runtime that every dump on that image contains does not. Across sources, certainty comes from independent layers agreeing with each other, and repetition inside any one layer does not stand in for that agreement. Similarity search runs over six independent fingerprints and reports, for each neighbour, the band it fell in and which fingerprint spoke.

What this module does not do

No file submission over the API or MCP

Both surfaces accept only text-named modules: hash, URL, command and package. File analysis is console work, and that constraint is written into the code and is not an oversight to route around.

Host-side emulation is switched off on purpose

The shellcode and dropper emulator reports itself unavailable with its reason stated. Emulation buys triage speed, and buying it would mean running submitted code on the analysis host, which this platform does not do.

The static machine-learning score is not a model here

The layer returns a small structural heuristic, labelled as one on the page, and it reaches the AI layer under that same name, so it is not quoted downstream as a model verdict.

The in-guest record is scoped, and the report says to what

Each guest-side layer publishes the operation classes it can stand behind, and the behaviour document is written against that published scope, so a class the sensors do not claim is stated as unclaimed and never inferred from a silence. Part of the scoping is deliberate: activity that every clean machine performs constantly is left out by design, which is what keeps an ordinary system library load off the dropped-payload list.

Static unpacking covers one packer family

Everything else is detected, named, and routed to detonation with the report saying so explicitly, so an unattempted unpack never reads as an empty result.

A chain cannot be completed offline

Most legitimately signed software therefore lands on unverifiable, published under its own name. That is a limit of an isolated environment, not a finding about the file.

The layer selection is not what it looks like

Static and dynamic analysis default on; the AI layer is a checkbox that defaults off; the intelligence layer is not selectable at all and runs whenever the sample has a hash, unless Ultra Privacy is set.

Ultra Privacy destroys what it covers

Sample bytes, artifacts and analysis records are purged when the run finishes and every export route returns 404 afterwards, so there is nothing left to re-analyse, to build a rule from, or to match in a retro hunt.

Corpora come from third parties on a refresh schedule

Family attribution, configuration extraction and web-shell scoring depend on them, so the report names the corpus, its tier and the date it was retrieved, and claims no proprietary intelligence source of its own.

Retro hunt and similarity are bounded

Similarity compares against a window of recent visible samples and returns a ranked shortlist; retro hunt works to a scan budget. Each of them reports the bound it reached, so a short answer is not read as an exhaustive one.

Memory forensics covers 19 techniques across 12 behaviour categories, and the report names which of them ran on a given scan. A technique that fires as readily on a clean machine as on a sample is not shipped, so the count on this page is what the layer can stand behind, not the length of a feature list.

Where this module hands off