Platform: Agentless Detonation at the Hypervisor Layer

Analysis modules

Malwagon analyses executables and archives, URLs, command lines, office and PDF documents, kernel drivers, pip packages, and hashes you already hold, and it routes each submission to the module built for that kind of target.

A module decides which layers run. A file goes through static parsing and then a detonation; a URL is opened by a real browser; a hash is resolved against the intelligence layer without a detonation. The report you get back is shaped by the module that handled the submission.

File analysis: Upload an executable, script or archive, or give a link the analysis host downloads for you, and detonate it on a Windows or Linux sandbox while every layer runs.; PE / EXE / DLL, .NET, ELF, Go, scripts, archives, up to 128 MB, or a source URL
URL analysis: Open a link in a real headless browser inside a disposable Linux guest and record what the page actually does.; http:// or https:// URL
Command analysis: Paste PowerShell, CMD or bash and have the script itself treated as the sample.; PowerShell, CMD or bash script text
Document analysis: Open a maldoc in the application it was written for, on the one sandbox image that carries a full office suite.; .docx .docm .xlsm .xlsb .pptm .rtf .pdf .one .chm .htm .mht and the rest of the office document set
Kernel driver / BYOVD: Examine a Windows kernel driver as a bring-your-own-vulnerable-driver candidate rather than as an ordinary executable.; .sys, or any PE kernel driver image whatever it is named
Hash lookup: Ask what is already known about a sample you do not have, using only its digest.; MD5, SHA-1 or SHA-256 hex digest
OneShot run: Run one file across several sandboxes at once and get the screenshots back.; any file, one or more Windows sandboxes, or the domain-joined pair
Package analysis: Name a pip package instead of uploading one, and watch it install under a syscall tracer.; a pip requirement, for example requests or requests==2.31.0

What each module does

File analysis: The static, dynamic and AI layers all apply, and the detonation is yours to configure: operating system, workgroup or domain-joined network, run duration, standard or elevated token, working directory, start arguments, a PowerShell pre-script, internet on or off, and the memory, process and injected-PE dumps. The image you pick is the image that runs the sample, so a Linux binary needs the Linux sandbox selected. Up to ten supporting files can be dropped next to the sample so a loader finds the config or DLL it expects.
URL analysis: A screenshot is taken on every navigation, so a redirect chain through a lure into a landing page is a sequence you can read rather than a single final frame, and the content served at each URL is kept for download. Eight browser identities are selectable, covering Chrome, Edge, Firefox, Safari, and the Android and iPhone shapes, each carrying its own viewport, because a kit that serves a decoy to anything it does not recognise serves a different page to each of them. The run streams live over VNC while it happens.
Command analysis: The text is deobfuscated locally first, and only the local result is ever summarised for the AI layer. The script itself is not shipped anywhere. Windows commands detonate through cmd and PowerShell on the Windows 10 sandbox; Linux commands detonate through bash on the Ubuntu sandbox, with the same kernel telemetry, network capture and rule matching as any other run.
Document analysis: The image is pinned rather than selectable, because macros and OLE payloads only run if the application the document targets is really there to run them; the guest keeps the document extension and launches the file through its shell association. The static side reads VBA and legacy XLM macros, OLE embedded objects, remote template injection, DDE and DDEAUTO fields, PDF payloads, OneNote, RTF and CHM. A password protected archive is accepted when you give the password, so the document inside it is what detonates.
Kernel driver / BYOVD: The questions are different from a normal file scan: which primitive the driver hands to user mode, which IOCTL control codes reach it, which kernel imports it pulls, how it is signed, and whether it is one the world already lists as abusable. This is a static module. There is no kernel detonation, and the dynamic layer is disabled on the form rather than merely left unticked. A user-mode PE submitted here comes back saying so, which is an answer worth having.
Hash lookup: This runs the threat intelligence layer alone. No VM is started and nothing is detonated, so it answers in seconds. The hash goes to the reputation and feed sources; nothing else does, because there is no sample here to leave the platform in the first place.
OneShot run: Deliberately narrow: OneShot executes and photographs, and runs no static, dynamic, AI or intelligence layer. It is the fast way to see whether a sample behaves differently on Server 2012 R2 than on Windows 11, or what it puts on screen at all. In domain mode the domain controller and the joined client boot side by side and the sample runs on the one you choose, with the other live as its domain peer.
Package analysis: This is the supply-chain case: an analyst reading that something on an index is malicious has a name, not a file. The package is never downloaded on the analysis host. The guest fetches and installs it itself inside the Linux sandbox, which is what captures the install-time behaviour that, for a malicious package, is usually the whole attack.

The detonation environment

A sample runs inside a full virtual machine under a kernel level hypervisor on hardware we operate, not in a container, not in an emulator, and not against a partial reimplementation of the operating system.

The capture that matters most sits outside the guest, and it is the part of the platform we would ask you to look at hardest. Network traffic is recorded at the host tap the virtual machine is attached to, the screen is captured through the hypervisor, and guest RAM is taken as a dump of the running machine and reconstructed by a memory forensics framework afterwards. None of those three layers executes code inside the guest, so a sample that kills, unhooks or blinds whatever it can find in user space does not remove them.

Inside the guest there is a component as well, and it is described here rather than hidden: it supplies the API-level detail the outer layers cannot see, such as which registry key a write actually landed in. It is a second source, never the only one. Where the in-guest view and the outside view disagree, the disagreement is recorded rather than resolved for you.

The guest is also new every time. Where the options a run asks for allow it, machines resume from a live memory snapshot of a settled desktop rather than booting, and a pre-armed guest can begin executing the sample in about three seconds; runs that need a freshly defined machine, a domain pair or manual launch still boot. Either way the disk that ran the sample is discarded afterwards instead of being cleaned.

machine: Full virtual machines under a kernel level hypervisor. Not containers, not emulation of a subset of the operating system.
instrumentation: Packet capture, screen capture and memory forensics are taken from outside the guest at the hypervisor. An in-guest component adds API-level detail as a second source.
start time: Where the run's options allow a snapshot resume, a pre-armed guest begins executing the sample in about three seconds rather than after a boot.
images: Windows and Linux images are available. Free scans are pinned to Windows 10 22H2.
network: Free scans run network isolated with no egress. On paid plans internet egress is a per-scan choice.
machine state: Each run gets a clean machine. The disk is reverted after the run, never cleaned in place.

The run lifecycle

A detonation moves through the same six steps, and the live console names the step a run is currently in while you watch it.

restore
arm
deliver
execute and observe
collect
revert

Restore brings a guest back from a live memory snapshot, or boots one where the run's options rule a snapshot out. Arm starts capture and takes a baseline of the machine before the sample exists on disk. Deliver places the sample in the guest and launches it, or hands it to you to launch. Execute and observe is the run itself, watchable over VNC while it happens. Collect drains the telemetry, the packet capture, the artefacts and, where the scan asked for them, the memory and process dumps. Revert discards the disk.

Detections and intelligence

A finished scan produces a scored verdict, a set of MITRE ATT&CK techniques, detection rules generated from what the sample actually did, and indicator enrichment from threat intelligence feeds.

Scored verdict: Signals from the static, document, dynamic, memory, network and intelligence layers are weighted into a single score and a verdict. Every point of the score is traceable to the signal that produced it, so a verdict can be argued with rather than taken on faith. A score is evidence for an analyst to weigh, not a determination: it records what this sample did in this environment during this run, and a clean result is the absence of evidence in that one run rather than a clearance. The documentation sets out how the number is read.
MITRE ATT&CK mapping: Observed behaviour is mapped to ATT&CK tactics and techniques, and the mapping can be exported as an ATT&CK Navigator layer for use in your own coverage work.
Generated detection rules: Malwagon writes YARA, Sigma and Suricata rules from your own scan: YARA from strings and structure in the sample, Sigma from the process, registry and command line behaviour recorded during the run, Suricata from the network traffic it produced. The rules are shown in the report and can be exported for your own tooling.
Threat intelligence enrichment: Extracted indicators are checked against threat intelligence feeds that the platform refreshes on a schedule, so a domain, address or hash that is already known is flagged as known rather than rediscovered.
Retro-hunt: Paste a YARA rule and run it back over earlier scans you can see whose bytes the platform still holds, to find runs that match a rule you are working on. There is no library of user-authored rules applied to incoming scans; retro-hunt is the way a rule of yours meets the corpus. Retro-hunt is on the Pro and Team plans.

Alongside the rules, a report exports as STIX 2.1, as a MISP event, as a defanged indicator list, and as a PDF or DOCX narrative report.

Generated YARA rule illustration

rule Example_Generated_Rule
{
  meta:
    author = "Malwagon"
    source = "one scan"
  strings:
    $m1 = "Global\\ExampleMutex" ascii
    $s1 = "restore_files.txt" wide
    $s2 = { 8B 45 ?? 33 D2 F7 75 ?? }
  condition:
    uint16(0) == 0x5A4D and 2 of them
}

This rule is an example written for this page, not a rule shipped with the platform and not the output of any particular scan. It shows the shape of what the rule generator produces: a mutex name, a dropped file name and a code fragment taken from the run, assembled into a rule you can export. Rules are generated from your scans; the scanning corpus itself is maintained by us.

Data handling and access

Hash values and derived indicators are the only things that leave the platform; the sample itself never does.

Samples stay here: The sample you submit, and its raw contents, are not sent to any third party service. That is a design constraint in the platform, not a setting. Reputation lookups against external services are performed with hash values and derived indicators, which is enough to ask whether something is already known without handing over the artefact.
The AI layer never sees the bytes: The narrative layer is given locally derived material only: the behaviour summary, the API call sequence, the indicator list and non-sensitive extracted strings that the platform produced on its own hardware first. Obfuscated scripts are deobfuscated locally, and the AI layer is asked to interpret the local result. It is not given the sample.
Report visibility: On the free tier a report is public and appears in the public analyses index, which is the trade for scanning without an account. Paid plans scan privately, and a private report is visible only to you and, on a team plan, to your team.
Access surfaces: Beyond the web console there is a bearer-token REST API, included from the Pro plan up, and an MCP server, included from the Pro plan up as well. Both are described on the API and MCP page. Neither takes a file: a target is named as text, so a file is submitted by SHA-256 and uploading is done through the console.
Security detail: Isolation boundaries, data retention, deletion and reporting a problem to us are covered on the security page. Handling of personal data is covered in the privacy policy.

If a term in a report is unfamiliar, the glossary defines what the platform means by it, and the documentation walks through the analysis workflow end to end.