About Malwagon
What Malwagon is
Malwagon is an automated malware analysis sandbox: you submit a file, URL, command, document or driver, it is analysed and detonated in isolated virtual machines, and you get back a scored verdict together with the evidence behind it.
A submission runs through several analysis layers. Static analysis parses the file format and runs YARA rules, capability identification, obfuscated string recovery, packer and entropy checks, named signature scanning, code signature validation, disassembly, secrets scanning and configuration extraction. Document analysis reads office document and OOXML macros, XLM, OLE embedded objects, template injection, CHM, PDF, OneNote, RTF and DDE. Dynamic analysis detonates the sample and records ETW kernel telemetry, memory forensics against a per-OS benign baseline, hypervisor level introspection, and network capture with rule based detection and JA3 and JA4 fingerprints. URL analysis drives a real headless browser and captures a screenshot per navigation. An AI layer then writes a narrative over the locally derived data.
The score is not the report. Findings are shown with what produced them: the process that made the call, the ETW record, the packet, the matching rule. You can follow a verdict back to its evidence, disagree with it, and export the underlying indicators as an ATT&CK Navigator layer, STIX 2.1, a MISP event, a defanged IOC list, or a PDF or DOCX report. Malwagon also generates YARA, Sigma and Suricata rules from your own scans so a single analysis can become a detection you keep.
The platform page describes each analysis module in detail, and the public analyses index shows finished reports you can read without an account.
How it is built
Malwagon runs full virtual machines under a kernel level hypervisor on hardware the team operates, and takes its telemetry at the hypervisor and kernel layer rather than from a monitoring agent running beside the sample.
That last point is the design decision the rest of the platform is built around. A sandbox that installs a monitoring agent inside the guest gives the sample something to look for, and modern malware does look: it enumerates processes, services, drivers, loaded modules and named objects, and goes quiet when it finds an analysis tool. The design goal here is to leave nothing of that kind in the sample's way. The recording happens underneath the operating system, in the hypervisor and in the kernel trace, so it does not depend on a component running next to the code under analysis.
Guests do not cold boot for each run. They resume from live memory snapshots of an already settled desktop, so a sample starts executing about three seconds after it is submitted instead of after a full Windows boot. That matters for more than impatience: a machine restored from the same memory snapshot every time is a machine whose baseline is known, which is what makes it possible to subtract normal operating system behaviour from what the sample actually did.
Images cover Windows and Linux, and while a sample is running you can open a live view of the machine over VNC and interact with it, click through an installer, dismiss a dialog, or simply watch. When the run ends the machine is discarded and the next scan starts from the snapshot again.
The principles it is built on
Five decisions shape the platform. They are design decisions about how it is built, rather than policy statements about how it is meant to be used.
- Samples never leave the platform
- The bytes you submit are analysed on the platform's own infrastructure and are not forwarded to any third-party service. It is a design invariant of the analysis pipeline, not a setting on an account.
- Only hashes and derived indicators ever reach a third party
- Reputation lookups send hash values and indicators produced by analysis, such as a domain or address the sample contacted. They do not send the sample.
- The AI layer sees locally derived summaries, never the sample bytes
- The narrative layer receives a behaviour summary, an API call sequence, an indicator list and extracted strings, all produced locally first. Obfuscated script is deobfuscated on the platform and the AI comments on that local result.
- Analysis runs on infrastructure the team operates
- Detonation happens on machines the team operates and configures, not on rented per-scan capacity. It is what makes hypervisor-layer telemetry, live memory snapshots and custom guest images possible in the first place.
- Verdicts are shown with their evidence
- A number on its own cannot be checked. Each score contribution is shown with the finding that produced it, so an analyst can confirm it, dismiss it, or take the evidence somewhere else.
The security page describes how isolation and data handling work in practice.
Who it is for
Malwagon is designed for the people who have to decide, quickly, whether a specific file or link is dangerous.
It is built for incident responders triaging what was found on a host; for detection engineers who want the generated YARA, Sigma and Suricata rules and the retro-hunt, so one sample turns into coverage; for SOC analysts who want a second reading of an alert before closing it; and for threat researchers using the similarity and campaign clustering to place a sample next to the ones it resembles. Anyone who has been sent an attachment they do not trust can also submit it and read the report without an account.
The plans page shows what each tier includes, and the documentation covers the workflows and the REST API and MCP server.
Getting in touch
Questions about the platform, plans, or a specific report go through the contact page.
If you believe you have found a vulnerability in Malwagon, the security page explains how to report it and what to include. The same page covers how to request that a report be taken down.
Current component health is on the status page. If something looks wrong there and you cannot tell whether it affects your scan, get in touch and say which scan you mean.