Guide: isolating guests while keeping hypervisor-level capture
Why sandbox isolation and network capture pull against each other
An analysis sandbox owes you two things at once, and they work against each other: the sample has to stay inside a boundary it has no route across, and every network move it makes has to be recorded. Hold both by putting the recording below the guest, on the virtual interface the hypervisor hands the machine, and by settling the egress question in host code at detonation time rather than trusting an option the submission carried. Anything inside the guest belongs to the sample's world; anything below it does not.
| Question | Short answer |
|---|---|
| Where capture runs | On the host, on the virtual interface the guest's NIC attaches to. |
| What survives a killed agent | The packet record, DNS, TLS handshake metadata, connection timing. |
| How HTTPS endpoints are recovered | Server name from the cleartext handshake, plus after-the-run decryption when the guest exported keys. |
| Who decides egress | One host-side function, where the virtual network is chosen. |
| Free and anonymous runs | A segment with no forwarding path defined on it. |
Where packet capture belongs in a sandbox
An in-guest agent is worth having. It is the only vantage point that knows which process opened a socket and with what command line, and packets never supply that. It is also a process on a machine the sample controls, with a lifetime a hostile program can end. Treat it as attribution, never as the record itself.
The packet record is written by a host process attached to the guest's virtual interface. The guest emits frames, the host writes them, and nothing in the guest's process list corresponds to the recording. A sample that spends its first seconds killing monitoring software still leaves a connection record behind.
The same logic governs artifact collection: dropped payloads are read from the machine's disk overlay after the guest is gone, so a killed agent costs nothing there either.
What a hypervisor vantage point can and cannot see
No single vantage point answers everything, so writing the blind spots down is part of the design: a report that hides them reads as clean.
| Vantage point | Evidence it produces | What it cannot answer |
|---|---|---|
| Capture on the guest's virtual interface | Connections and timing, DNS queries and answers, handshake fields including server name and client fingerprint, cleartext HTTP headers | Plaintext inside TLS without keys; which process owned a flow |
| In-guest agent | Process tree, command lines, file and registry activity, which process reached the network | Anything after a sample stops it |
| Disk overlay read after shutdown | Dropped payloads and written files, hashed for static re-analysis | Ordering and timing |
| Simulated services on the isolated segment | Whether the sample would have spoken, and the shape of its first request | What the real server would have replied |
Two habits keep those rows honest. Response bodies stay out of the stored analysis document, so content a sample was moving is never copied into a report others can open; headers, status and size carry the meaning. Vendor and operating system noise is filtered from the derived views, and the count removed is published beside the result, because a filtered panel and a silent one look identical.
Recovering HTTPS endpoints without pretending to break TLS
Much of what a defender needs from an encrypted flow sits outside the encryption. The client hello is cleartext, so the requested server name, the offered protocols and the shape of the client stack are readable passively. That shape, expressed as a JA3 or JA4 fingerprint, is an indicator by itself, and matching it against locally held threat data needs no external service. The same capture gives resolved addresses and connection cadence.
Payload recovery is where the limits sit. When the guest's TLS library honors a session key log, the host decrypts the captured traffic after the run and reads the requests inside. That covers clients built on the common open source TLS stacks, browsers included, which is what makes it useful for URL analysis. The native Windows transport exports nothing of the kind, so a sample using it yields host and timing without a path.
What follows is a labeling rule. Every recovered endpoint records whether it was decrypted or read from handshake metadata alone, and the report carries both counts. Terminating TLS at a proxy with a planted trust anchor is legitimate, but it changes what is measured: a sample that checks its peer behaves differently against a changed transport.
Deciding egress once, at detonation time
Submission options travel with the request. That is fine while every writer of an option is a signed-in user on a form you control, and it stops being fine once an unauthenticated intake path exists. An option dictionary is the part of a scan an attacker can most nearly influence, so it cannot be what decides whether a live sample gets a route out.
Put the decision in one host-side function, called where the virtual network is selected, and let it ask what a request cannot answer for itself: does this plan permit an internet-capable run, and is the submission anonymous. Every detonation path calls it, so the form setting becomes the first of two gates rather than the only one.
The other half is structural. The isolated network has no forwarding defined on it, so there is no route off the segment to misconfigure. A run allowed egress gets a different network, and its boundary rules must be in place before the sample starts; if they cannot be installed the scan does not start, and if a previous grant cannot be withdrawn neither does the next. A missing rule is no rule, so absence means stop.
Reserving internet-capable runs for paid plans has an operational reason: a controllable machine with a route out, free to anyone with an email address, is a machine somebody else can commit an offence from. The reasoning behind each boundary sits under security; file analysis inherits the same gate.
What an isolated run proves, and what it does not
An isolated detonation answers a narrower question than people assume. It shows what a sample does when name resolution fails and nothing answers: whether it retries, what it falls back to, what it writes, how it persists. Silence there is not evidence that a sample has no command and control, and for a family whose behavior lives behind a first successful connection it is a structural false negative. Simulated services on the segment answer, often enough to draw out a first request.
Before reading a quiet report as benign, check that the sample actually launched. A guest that never executed the file and a sample that ran and did nothing produce similar documents, and the discriminator is whether the process started, not whether telemetry arrived. Read a run as one experiment under stated conditions: this operating system, this duration, this network posture. The platform keeps those beside the result, and the terms used here sit in the glossary.
Containment work is never finished, and no honest write-up claims a boundary cannot be crossed. What a design offers is few decision points, all host-side, each failing toward the closed state.
Frequently asked questions
Where should packet capture run in a malware sandbox?
Capture belongs on the host, attached to the virtual interface the hypervisor gives the guest. Recording there sees the frames the guest sends and receives, and puts nothing inside the analysis machine for a sample to find and stop. An agent in the guest adds attribution, never the evidence itself.
Can a sandbox read HTTPS traffic without breaking TLS?
Partly, and the split matters. The handshake is cleartext, so the requested server name, the protocols offered and the client fingerprint are readable passively. Paths and bodies need session keys, which only some client stacks export. Mark which endpoints were decrypted, so nobody reads a host as a full request.
Does an isolated detonation still produce network indicators?
Yes, though a narrower set. Name resolution attempts, connection attempts, handshake fingerprints, timing and retries are recorded even when nothing answers, and simulated services can draw out a first request. Families that work only after a connection succeeds look quieter than they are, so an isolated run is one condition, not a verdict.
Should a sandbox trust the submitter's internet setting?
No. Submission options arrive with the request and can be influenced by whoever sends it, especially on unauthenticated intake paths. Decide egress in host code when the virtual network is chosen, checking the account's entitlement rather than the option. Keep the form setting as an early gate, and leave the isolated network without a forwarding path.