Documentation
Getting started
The shortest path from a suspicious file to a verdict is to drop it on the scanner on the home page, with no account and nothing to install: each source address may run three free scans per day.
- Submit
- Queue
- Detonate
- Report
A free scan is fixed by the platform rather than configured by you. It runs on Windows 10 22H2, on a network-isolated machine with no internet egress, with the static and dynamic layers enabled, and the resulting report is publicly viewable. Where a pre-armed guest is standing by, it resumes from a live memory snapshot instead of booting and the sample is detonated about three seconds after the scan starts; the rest of the wait is the run itself plus the post-run collection.
A paid plan is what unlocks the things a fixed run cannot give you: the other images, a longer run, internet egress, private reports, the API, and the full set of detonation options below. Plans and their limits are on the pricing page. You can also read other people's completed runs without an account through the public analyses index.
Submitting a sample
Malwagon accepts eight kinds of submission, and each one is its own module with its own intake, because a URL, a pip package and a kernel driver are not answered by the same questions.
- File Analysis
- The general case. The file is stored, hashed, taken apart statically and detonated on the image you pick. You can also give a link instead of an upload: the platform host downloads the bytes and they take the same path an upload would.
- PE, DLL, .NET, ELF, Go, scripts, archives, Python, LNK
- Document Analysis
- For a sample that opens in an application rather than executing on its own. It is pinned to the Windows 10 image that carries a full office suite and a PDF reader, so macros, OLE objects and template injection actually run inside the application the document was written for.
- DOC, OOXML, PDF, RTF, OneNote, CHM, HTML, MHT
- URL Analysis
- A link, visited by a real headless browser inside a disposable Linux guest. Every navigation is screenshotted and every response body is kept, so a redirect chain that ends in a download is readable end to end. You choose the browser identity the site is shown.
- http and https links
- Command Analysis
- The script text is the sample. It is deobfuscated locally first, then executed in the guest, which is what turns a one-line encoded launcher into a readable chain of what it actually did.
- PowerShell, CMD, bash
- Hash Lookup
- A digest you already have and want context on. This module runs the intelligence layer only: no file is stored and nothing is detonated, so it answers what is known about those bytes, not what they do.
- MD5, SHA-1, SHA-256
- Package Analysis
- The supply-chain case, where you have a package name and not a file. Nothing is downloaded on the platform host: the guest fetches and installs the package itself under a syscall tracer, which is where a malicious package usually does its work.
- pip requirement, name or name==version
- Kernel Driver
- A Windows kernel driver judged as a BYOVD candidate: which primitive it hands to user mode, which control codes reach it, how it is signed, and whether it is already published as abusable. This module is static analysis only; there is no kernel detonation, and no detonation option applies to it.
- .sys and any kernel-mode PE
- OneShot Run
- Execution across one or more images with the screen captured and nothing else. It produces screenshots only: no static, dynamic, intelligence or AI layer runs, so use it to see what a sample looks like on six Windows versions rather than to get a scored report.
- any uploaded file
One sample may be up to 128 MB. Alongside it you may send up to ten supporting files, each up to 32 MB and up to 64 MB in total; these are dropped next to the sample in the guest, which is how you supply a config file, a DLL or another dependency the sample needs before it will run. A free scan takes the fixed environment described above: Windows 10 22H2 with no internet connection.
Analysis options
Analysis options belong to signed-in accounts: a free scan uses settings the platform fixes, while an account configures the image the sample lands on and nearly everything about the run around it.
Three layers can be selected independently and at least one must be on: Static, Dynamic and AI. Static and Dynamic are on by default; Kernel Driver is the exception, where the form disables Dynamic outright rather than leaving it unticked. The table below covers the detonation options offered by File and Document Analysis; URL Analysis takes the browser identity instead, Hash Lookup and Kernel Driver take none, and OneShot takes the image set, the run duration and the internet switch.
| Option | What it does | Values |
|---|---|---|
| Operating system | The image the sample is detonated on. The image you pick is the image that runs the sample, so send an ELF to the Linux sandbox rather than to a Windows one. | Windows Server 2012 R2, Server 2016, Windows 10, Windows 11, Server 2022, Server 2025. File Analysis adds Ubuntu 24.04; Document Analysis is pinned to Windows 10. Default: Windows 10 |
| Network environment | Whether the guest is a standalone machine or a member of a live Active Directory domain, for malware that only acts inside one. | Workgroup, or Domain-joined. Domain runs on the joined pair only: Server 2016 and Windows 10 |
| Execution duration | How long the sample is left running before collection starts. Your plan sets its own ceiling within this range. | 10 to 600 seconds. Default: 120 |
| Internet connection | On gives the guest real egress so a sample can reach its infrastructure. Off puts it on the isolated network with no route off the segment. | On or off. Default: on for File, Document and Package Analysis. OneShot leaves it off, and URL Analysis has no such switch |
| Execution mode | Whether the platform launches the sample or you do it yourself, live over the VNC console, while capture waits for the process. | Run automatically, or run manually. Default: automatic |
| Execution privilege | The token the sample runs with. Document Analysis does not offer this: a document opens through the shell association at the interactive user's own token. | Standard user, or Administrator. Default: Administrator. A free scan is fixed to standard user |
| Work path | The directory the sample is written into before it is launched. Some samples behave differently depending on where they were dropped. | Desktop, Downloads, %TEMP%, %APPDATA%, %PROGRAMDATA%, System32, or a custom path. Default: Desktop |
| Start arguments | Command-line arguments passed to the sample when it is launched. | Free text |
| Pre-script | PowerShell executed in the guest before the sample, to stage a file, a registry value or any other precondition the sample expects. | PowerShell text |
| Memory dump | Captures guest RAM and reconstructs it with a memory forensics framework after the run. It adds time to the collection, so it is opt-in. | On or off. Default: off |
| Process dump | Dumps the sample's own process images, which is where a packed payload is readable once it has unpacked itself. | On or off. Default: off |
| Injected PE dump | Carves executable, writable private regions out of the memory image, which is where injected code and self-unpacked payloads live. | On or off. Default: off |
| Custom memory YARA rule | A YARA rule of your own, run host-side against this scan's process memory dump after the run, to hunt a payload that only exists once it has decrypted itself. It applies to this scan and is not added to any standing rule set. | YARA rule text |
| Bypass sleep | Shortens long delays a sample uses to outlast an analysis window. | On or off. Default: off |
| Mouse simulation | Moves the pointer and interacts with the desktop, for samples that wait for a sign of a human before acting. | On or off. Default: off |
| Automatic unpack | Unpacks a container so the file inside it is what gets detonated, rather than the container. | On or off. Default: off |
| Fake user artifacts | Populates the guest with the traces of an in-use machine, so a sample checking whether the desktop is a real person's finds one. | On or off. Default: off |
| Run as | Forces how the sample is launched instead of letting the content decide, for a payload delivered under a misleading name or extension. | Auto, exe, DLL, MSI, SCR, JS, VBS, WSF, HTA, PS1, BAT, document. Default: auto |
| DLL export | The export name or ordinal to call for a DLL sample. Left blank, the DLL is registered instead. | Export name or #ordinal |
| Archive password | The password for a protected archive. The inner file is extracted and detonated as the sample; the password is consumed at submission and not stored. | Free text |
| Guest time zone | Sets the guest clock's zone at runtime, for region-gated malware that only acts in the geography it targets. | Ten zones, from US Pacific through Europe, Turkey and India to China and Japan, or no override. Default: UK |
| Guest locale | Sets the guest language and regional format, for the same reason: some families check the keyboard and the locale before doing anything. | Thirteen locales, or no override. Default: English (UK) |
| Clock override | Moves the guest clock so a time-gated payload reaches its trigger date during the run. | A signed offset in days, hours or minutes such as +30d, -2h or +90m, or a date such as 2027-06-01 |
| Minimum uptime | Idles before launch until the guest has been up this long, so a sample that treats a young machine as a sandbox proceeds. | 0 to 600 seconds. Default: 0 |
| Guest vCPUs and RAM | Presents a larger machine, for the low-core and low-memory checks used as sandbox tests. Either choice provisions a machine on demand instead of taking one from the warm pool, so the run starts more slowly. | Default (2) or 4 vCPU; default (4 GB) or 8 GB |
| Trace depth | The kernel event budget for the run. Deep keeps more of a long or busy run intact; light trims the trace for faster triage. | Light, normal, or deep. Default: normal |
| Browser identity | URL Analysis only. What the sandbox browser tells the site it is, because a page that serves a decoy to anything it does not recognise is a different page under a different identity. | Eight user agents. Default: the sandbox default |
Reading a report
A report is built to be read in one direction: the verdict tells you where you stand, the sections beneath it are the evidence that produced it, and the exports at the end are how it leaves the platform.
- Verdict and score
- The header carries a 0 to 100 score, a label, the sample's identity and hashes, and the conditions the run actually had. Read the run conditions first: an isolated run and a 30-second run explain a thin report before anything else does.
- Summary
- The overview answers what the sample is, what it can do, how it is reached, and which analysis layers ran, followed by a plain list of the signals that moved the verdict. It is the section to read when you only have a minute.
- Static findings
- What the file is without running it: headers, sections and entropy, imports and exports, resources, signing and certificate state, packer detection, YARA rule and capability matches, recovered configuration, extracted strings and secrets, and the disassembled entry point. For a document it is the macro, OLE and template surface instead.
- Process tree
- Everything that ran during the detonation, as a tree, with each node's own activity attached to it. Selecting a process filters the report to what that process did, which is how a launcher is separated from the payload it started.
- File and registry operations
- What the sample wrote, read, renamed and deleted on disk and in the registry. Most of it comes from the kernel trace; the exact key a registry write landed in is resolved by the in-guest monitor, because the kernel event carries the value name without the key path. Persistence has its own section because an auto-start entry is the finding, not the write.
- Network capture and DNS
- Traffic is captured at the hypervisor, so it is recorded whether or not the sample cooperates. The section covers DNS queries, connections, HTTP and HTTPS endpoints, TLS fingerprints and network rule alerts. HTTPS paths are recovered from exported session keys where the sample's TLS stack supports it, and where it does not, the host from the handshake is still shown.
- Dropped and injected artifacts
- Everything that came out of the run: dropped files, carved objects, unpacked payloads and captured memory regions, each stored by content hash and downloadable as a password-protected archive. Cross-process injection is listed separately, because the target process matters as much as the payload.
- Memory forensics
- When memory collection is enabled, the guest's RAM is reconstructed by a memory forensics framework from outside the guest, and findings are compared against a benign baseline for that image so ordinary operating-system behaviour does not read as a discovery. In-memory strings, in-memory YARA matches and executable private regions live here.
- MITRE ATT&CK
- Observed behaviour is mapped to ATT&CK techniques, so the run can be compared with the reporting your team already reads and exported as a Navigator layer.
- Generated detection rules
- YARA, Sigma and Suricata rules are generated from this scan's own evidence and shown in full with the finding each one came from, and each downloads in its own tool's file format. They are a starting point produced from one run, and should be reviewed and tuned against your own data before you deploy them.
- AI narrative
- A written summary, threat assessment and kill-chain walkthrough. It is available on every plan rather than sold as an upgrade, and is a layer you switch on per scan; a free scan without an account runs the static and dynamic layers only. The AI layer never receives the sample: it reads locally derived data only, such as the behaviour summary, the API call sequence, indicators and extracted strings.
How the verdict and score work
The score is a single number from 0 to 100 that aggregates weighted signals from every analysis layer that ran, and the label is read directly off that number: 70 and above is malicious, 35 to 69 is suspicious, and below 35 is clean.
Every point is attributable. The report lists which layer contributed what and why, so the score can be argued with rather than taken on trust. A fourth label, unknown, is used when there is nothing to judge or when the evidence is missing: no layer produced a result, a layer the scan asked for failed, or a sample that should have executed did nothing at all. Unknown is deliberately not clean, because an untested claim has not been cleared.
A score is evidence for an analyst, not a determination. It describes what this sample did in this environment, in this run, under the options that run was given. A clean label means that this run produced no signals above the threshold; it is not a statement that the file is safe, and it cannot be, since a sample that detects the environment, waits out the window, needs infrastructure that was offline or requires a trigger the run did not supply will produce a quiet report. Read the run conditions and the layer coverage alongside the number, and treat a scored report as one input to your own judgement.
Exporting
Every completed report can leave the platform in a structured form, from the Report section at the end of the rail.
- ATT&CK Navigator layer
- The techniques observed in the run, as a layer file you can open directly in Navigator.
- STIX 2.1 bundle
- The indicators and relationships from the run in STIX 2.1, for a threat intelligence platform.
- MISP event
- The same evidence shaped as a MISP event.
- Defanged IOC list
- The indicators as plain text, defanged, for pasting into a ticket or an email without making anything clickable.
- PDF and DOCX narrative reports
- The written report with its executive summary, assessment, kill chain, evidence tables and screenshots, in either format.
- Generated YARA, Sigma and Suricata rules
- Downloaded from the Rules section of the report, each in its own tool's file format, along with the finding each rule was written from.
- Packet capture and the sample itself
- The run's PCAP, and the sample as a password-protected archive. Both require signing in; neither is offered to an anonymous reader of a public report.
Two things do not exist, so that you can plan around them: a report has no CSV export, and there is no video export anywhere. The screen captures taken during a run are replayed as a timeline in the browser rather than rendered into a video file.
Visibility and retention
Scans are public by default, private on the plans that include private scans, and can be shared with your organization as a separate, deliberate act rather than as a side effect of joining a team.
A public report is readable by anyone with the link and is listed in the public analyses index. A private scan is visible to its owner. Organization visibility shares one scan with your team, and is chosen per scan, so joining a team never republishes anyone's back catalogue.
Ultra Privacy is the strictest setting and it is destructive by design. The scan is forced private, the intelligence and AI layers are skipped so that no hash and no indicator from it is sent to any external service, and the sample, its artifacts and its analysis are deleted the moment analysis finishes. The report page then shows a tombstone instead of a report: there is nothing left to render, nothing to export, and nothing for us to restore. Use it when the material must not persist, and take what you need from the run while it is on screen.
Samples never leave the platform in any mode. Only hash values and derived indicators are ever sent to a third party, and only when the scan permits it. How long data is kept, what is stored, and how to request an export or an erasure are set out in the privacy policy; the controls around the analysis environment itself are described on the security page.
Automating
Automation goes through the bearer-token REST API, included from the Pro plan up, or the MCP server, both included from the Pro plan up. Both are documented in the API reference.
The one thing to design around before you write any integration: the API has no file upload. A submission names its target as text, so to analyse a file you submit its SHA-256, which the platform looks up or detonates depending on whether it already holds those bytes. Uploading is done through the console. The five endpoints otherwise cover submitting a scan, submitting in bulk, polling status, reading a finished report and looking a hash up.
Questions
The questions that come up most often about running scans and reading what comes back.
- Do I need an account to run a scan?
- No. Each source address gets three free scans per day with no account and no payment. Those runs use a fixed environment, Windows 10 22H2 with no internet, and their reports are public. A paid plan is what unlocks the other images, longer runs, internet egress, private scans and the API.
- Does my sample leave the platform?
- No. Detonation, static analysis and storage all run on hardware Malwagon operates. Third parties only ever receive hash values and derived indicators, and an Ultra Privacy scan sends neither.
- What does the AI layer actually see?
- Locally derived data only: the behaviour summary, the API call sequence, the indicator list and extracted strings. The sample bytes are never sent to it. For scripts, deobfuscation happens locally first and the AI comments on the local result.
- Can I upload a file through the API?
- No. There is no file upload endpoint. Submit the file's SHA-256, or upload it through the console. This is the single most common surprise when writing an integration.
- Can I run my own YARA rules against every scan?
- Not as a standing rule set. Malwagon generates YARA, Sigma and Suricata rules from your scans for you to export, and retro-hunt, on the Pro and Team plans, lets you run a rule you paste in back over earlier scans you can see whose bytes the platform still holds. There is no library of user-authored rules applied automatically to incoming scans, and no way to upload one into the scanning corpus. A single scan can also carry a YARA rule of your own for its memory dump.
- Can a kernel driver be detonated?
- No. The kernel driver module is static analysis only: it examines the driver's imports, control codes, signing state, control-flow integrity and known-abused status. Loading kernel code in a guest is not something the platform does today, and the module offers no detonation options for that reason.
- My report shows no network activity. What does that mean?
- Check the run conditions in the header first. If the run had no internet connection, a sample that tried to reach out could not, and the empty section says nothing about whether it tried. If the run did have internet, it means no connection, DNS query or handshake was attributed to the sample during the window it was given.
- Can I watch the machine while the sample runs?
- Yes. The live view streams the guest's screen over the browser while the scan is running, and you can take the keyboard and mouse to click through an installer or a dialog. A domain-joined run streams both machines side by side.
- Why did the same file score differently on two runs?
- Because a dynamic verdict is a record of one execution. A different image, a different duration, internet on instead of off, a locale or clock the sample cares about, or infrastructure that answered on one day and not the next will each change what there is to observe. Compare the two runs with the scan diff before assuming the platform disagreed with itself.
- Does a clean verdict mean the file is safe?
- No. It means this run produced no signals above the scoring threshold, under the options this run was given. Samples that detect the environment, wait out the window, need a trigger or need infrastructure that was unavailable all produce quiet reports. Treat clean as an absence of evidence in one run, not as a clearance.
- How long does a scan take?
- When a pre-armed guest is standing by the sample starts about three seconds after the scan begins, because that guest resumed from a live memory snapshot rather than booting. A run that needs a freshly defined machine, the domain pair or a manual launch boots instead and takes minutes to reach the same point. After that the wall clock is the run duration you chose, from 10 to 600 seconds, plus post-run collection, which is longer when memory and process dumps are enabled.
- What happened to my scan if it says timed out or failed?
- A scan carries its lifecycle on the report: queued, provisioning, running, analyzing, then completed, failed, cancelled or timed out. A failure names its reason on the page. A report that is missing a layer says so explicitly rather than showing an empty section, because a gap in the evidence is not a clean result.