You get a link you don't trust. Static checks look at the URL string, the domain's age or a blocklist, which is exactly what attackers optimize against, and they say nothing about what the page does. Hosted scanners answer part of it but are black boxes: you can't see how the browser was set up, how traffic was captured, or how often the page lied to the scanner. Opening it on your own machine is the one thing you must not do.

1. 01

   A fresh microVM for every link

   Each URL gets a Firecracker microVM restored from a snapshot with Chrome already running, about a quarter of a second before navigation starts. A guest agent drives Chrome over a DevTools Protocol pipe and streams the evidence back over vsock. When the visit ends, the VM is destroyed and nothing survives except the evidence.

2. 02

   Two witnesses

   The browser reports requests, redirects, forms and the DOM from inside. The host watches from outside: an eBPF program on the VM's TAP device records flows and the TLS ClientHello SNI, a resolver logs DNS, the firewall logs blocked attempts and a pcap is written. The report reconciles both views, and a disagreement between them is itself a finding.

3. 03

   Fails closed

   Each VM sits in its own network namespace with no route to the host, the LAN or cloud metadata addresses. Live traffic leaves only through a WireGuard tunnel in a separate namespace, so if the tunnel drops there is no route at all. The daemon refuses to serve until its own isolation self-test passes.

4. 04

   Jailed and confined

   Every Firecracker process runs under the jailer as its own unprivileged user, in a chroot with seccomp, cgroup limits on memory, tasks and CPU, rate-limited network and disk, and an SELinux policy module. The guest is treated as hostile, so reports are built by an unprivileged helper and everything the guest says is evidence, not truth.

5. 05

   No proxy in the middle

   There is no man-in-the-middle proxy, so servers see a real Chrome TLS fingerprint. Chrome's key log ships back with the capture so traffic can be decrypted offline, and every report comes with a HAR export.

6. 06

   Cloaking measured, not assumed

   Browser countermeasures are switchable snapshot profiles, so the same URL opens under six of them at once. On 172 fresh candidates from Certificate Transparency logs, only the HeadlessChrome User-Agent ever changed what a site showed, and every case was infrastructure such as Cloudflare's bot challenge, not a phishing kit.

7. 07

   Indicators scored against labels

   Report indicators flag details forms on free hosting, brand lures, fake human checks and phishing kits recognised by page structure. Each rule is scored against labelled runs and held-out sets from live feeds, then replayed across every stored run to count false alarms before it stays.

8. 08

   A dashboard on top

   A NestJS service with Postgres and a BullMQ queue talks gRPC to the daemon, and a Next.js dashboard submits URLs, lists runs and renders the redirect chain, network graph and screenshot. Hostile data is shown as text and never linked, and the daemon stays the only privileged component.

242 ms

snapshot restore to navigation

p50 under the jailer, p95 306 ms, on the development laptop

123 MiB

memory per running microvm

three clones running chrome at once, host memory measured

172

fresh urls under every profile

certificate transparency candidates, the cloaking study

5,385

stored runs replayed per rule

every new indicator is checked against them for false alarms