How to detonate a sample interactively in a live VM

Some samples will not run without a human. Take the keyboard in a disposable VM, drive the payload yourself, and keep a record good enough to defend.

Automated detonation fails in a predictable set of ways. A password-protected archive. An installer with a Next button. A loader that only fires on a second launch, after a reboot, or when a document is scrolled. A payload that checks for mouse movement before it deigns to unpack. In each case the automated report comes back thin, and the honest reading is not “benign” but “nothing happened, because nothing made it happen”.

For analysts looking for a free malware analyzer, interactive analysis provides a way to investigate samples that automated detonation cannot fully execute or explain.

An interactive session is the answer. It gives you a real disposable virtual machine, a live desktop you control, and four panels that update as the sample executes — process tree, per-process detail, live IOCs, and a raw behavior stream.

BEFORE YOU START  Interactive sessions need a free account — one live VM per account at a time. Automated analysis needs no account at all. Sessions are premium compute and spend credits, so plan the session before you launch it rather than exploring on the clock.

1. Decide whether you actually need to be in the room

Interactive analysis is one of the most valuable capabilities in a malware analyzer, but it is also one of the most expensive in credits and in your own attention. Spend it on samples that will not yield otherwise.

Go interactive when

Stay automated when

The sample is inside a password-protected archive, or asks for a passphrase.

The automated run already produced a full process tree, network capture and dropped files.

It is an installer, or anything with a dialog that must be dismissed or accepted.

You need a verdict for a ticket and the fused score plus evidence rows already answer it.

A document needs to be opened, scrolled, or have content explicitly enabled.

You are processing volume. Interactive does not scale and is not meant to.

The automated report is thin or degraded, and you suspect a guardrail rather than an inert file.

The sample is already well documented in the corpus and matches a known family cleanly.

You suspect sandbox evasion — checks for uptime, cursor movement, recent documents, screen resolution.

You have no specific hypothesis. “Let me poke at it” burns credits and produces notes nobody can reproduce.

You need to reach a specific stage: an exfil attempt, a ransom note, a C2 command, a browser credential grab.

2. Write the session plan first

Before you launch, write down three things. It takes a minute and it is the difference between an analysis and an anecdote.

  1. The question. “Does this loader fetch a second stage when the archive password is supplied?” is a question. “See what it does” is not.
  2. The actions you intend to take, in order. Every click you make is now part of the experiment, and an undocumented click is an uncontrolled variable.
  3. The stop condition. What you will have seen when you are done — or the time at which you stop regardless.

3. Configure the guest

Open Live (/live) and set three controls.

Operating system

Windows, Linux or Android. Match the sample, and match the plausible victim: a Windows loader that checks for a domain-joined host behaves differently from one that does not care, and your session is where you find that out.

Network

Mode

Behavior

Use it for

Simulated (INetSim)

A fake internet. DNS resolves, services answer plausibly, nothing leaves the lab.

The default and the right first choice. You learn what the sample asks for without telling anyone that you asked.

Full internet (MITM capture)

Real egress with traffic intercepted and captured, including TLS.

Retrieving a genuine second stage or live C2 configuration — the one thing simulation cannot give you. Accept that the operator can see the connection.

No network

Fully isolated.

Separating on-host behavior from network noise, and for ransomware where you want the encryption behavior without any chance of reaching real infrastructure.

OPERATIONAL SECURITY  A Full internet session tells the operator that their sample is being analysed, from an address they can see, at a time they can record. For commodity malware this costs nothing. For a targeted intrusion it can burn the investigation. Start simulated, escalate deliberately, and never escalate on a sample tied to a live engagement without deciding that the payload is worth the disclosure.

Sample

Attaching a file is optional — the guest will auto-run it on launch. Leave it empty when you want the clean desktop first: to stage the sample yourself, to set up a plausible user environment, or to open an archive with a password you already have.

4. Launch and drive

Press launch and the status moves off IDLE as the VM comes up. From there you have a real desktop. Some tradecraft that pays for itself:

  • Behave like a user before you behave like an analyst. Move the mouse, open a folder, type something. Evasive samples check for exactly the emptiness that a fresh automated sandbox has.
  • Do one thing at a time and watch the panels between actions. If you click three things and a process spawns, you have lost the causal link that made the session worth running.
  • Never enter a real credential, a real token, or a real account. If a sample wants a login, use an obviously synthetic one. Whatever you type is going to the operator.
  • Let it sit. Sleep timers, scheduled tasks and second-stage delays are common. A minute of nothing is a result — and one worth noting.
  • Try the second launch. Plenty of loaders install on the first run and only act on the second, or after a reboot.
  • Note the negative results. “Opened the document, enabled content, waited two minutes, no child process” is a finding, and it is the finding automated analysis could not give you.

Where you would rather not drive by hand, the session can auto-detonate the attached sample and let you watch instead. That is a reasonable middle ground for samples you expect to run cleanly but want to observe live.

5. Read the four live panels

Panel

What streams into it

What to watch for

Process tree

Processes as the guest agent reports them, building live.

The parent-child chain. winword.exe → cmd.exe → powershell.exe is the whole story of a maldoc in three nodes. Injection shows up as an unexpected parent.

Detail

Select a process for its command line, its parent and its activity.

The command line is where the payload usually is — encoded blobs, download URLs, LOLBin arguments. Copy it verbatim into your notes.

Live IOCs

Contacted domains and IPs, dropped files, registry changes, and a running verdict hint.

The first outbound contact and its timing relative to your last action. Dropped-file paths tell you the persistence design.

Behavior stream

Raw process, file, registry and network events.

Ordering. The stream is where you see that the registry write happened before the network call, which changes what the malware was doing.

The running verdict hint is a hint. It moves as evidence accumulates and it is not the fused verdict — that comes from the completed report.

6. Capture evidence as you go, not afterwards

The VM is disposable, and so is everything you did not write down. During the session, collect:

  • The exact command lines from the detail panel, copied not retyped.
  • The process tree shape at the moment of interest.
  • Every IOC with the action that preceded it — an indicator without its trigger is much harder to hunt for later.
  • Screenshots of anything visual — a ransom note, a fake dialog, a credential prompt. These carry a report to a non-technical reader better than any log.
  • Your action log: what you clicked, in what order, at roughly what time.

When the session ends, the sample still has an automated report in the corpus. Pull it up and use it as the durable artifact — the report carries the fused verdict, the engine results and the exportable indicators, while your session notes carry the causality. Together they are defensible; separately, neither is.

7. Limits worth knowing before you plan a day around this

  • One live VM per account at a time. Two analysts on one account will collide.
  • Sessions spend credits, and free detonations are capped per day — 20 per day on the free tier, 500 on Pro, with higher interactive volume and a priority detonation queue at team scale.
  • A submission waits for a real sandbox slot rather than degrading to a lesser analysis, so a busy queue means waiting, not a quieter result.
  • There is no macOS sandbox. Mach-O samples get static analysis and lightweight emulation only, which no amount of interactive time changes.

Common mistakes

Mistake

Why it bites

Launching without a question

You will spend the session exploring and finish with notes that reproduce nothing.

Clicking fast

Causality is the only thing interactive analysis has that automation does not. Rapid clicking throws it away.

Using full internet by default

You disclose your interest to the operator for no analytical gain on most samples.

Entering a real credential to “see what happens”

You already know what happens. The operator receives it.

Concluding “benign” from a quiet session

You showed that the sample did not act under the conditions you created. Say exactly that.

Relying on the running verdict hint

It is a live indication, not the fused verdict. Cite the report.

Leaving the session as the only record

The VM is disposable. Notes taken afterwards from memory are the weakest evidence you can file.

Where this leaves you

Interactive time is worth spending only when automation genuinely can’t answer the question — a password, a dialog, a suspected evasion check. MalwareAnalyzer gives you a disposable environment to investigate those cases interactively, while preserving the automated report as the durable artifact. Write the question and the stop condition before you launch, then drive slowly enough to keep the causal link between what you clicked and what the panels showed.

The habit worth keeping: your session notes and the automated report are only defensible together. The report carries the fused verdict and the exportable indicators; your notes carry the causality — the command lines, the trigger behind each IOC, the order things happened in. Neither one stands in for the other, and a quiet session means the sample didn’t act under the conditions you created, not that it’s benign.

Scroll to Top