Build1 publisher3 min readPublished
A decoy binary's launch path came back from VirusTotal as gsvnywygooow
A Rust canary submitted to VirusTotal under a fake product name sent back OS build, uptime, core count and parent process from the environments that ran it, and its DNS heartbeat escaped runs that never posted a dossier.
The Engineer · Build desk
What happened
- A Rust canary shipped as ZeroToken Engine, a claimed LLM token-metering bypass, was submitted to VirusTotal, where it collected environment metadata, tried to send it home, waited and exited.
- Each run reported OS version, uptime, CPU and memory sizing, its own launch path, hostname, username, and any running process matching a fixed list of analysis tools.
- Reports arrived on two channels keyed by a random eight-byte run ID and landed in SQLite on a DigitalOcean droplet, with Caddy handling HTTPS and an authoritative DNS server taking the encoded lookups.
- The preserved snapshot holds 353 event rows across 21 run IDs, 338 of them DNS heartbeats and 15 of them full HTTPS dossiers.
- Fifteen run IDs turned up on both channels and six reached the collector only through DNS, all inside a single five-hour capture on September 12, 2026.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A manifest pairing submissions to destinations would turn these 21 run IDs into a count of sandboxes; there isn't one, so the snapshot cannot be used to size analysis coverage.
- exposure A submitter handing an unknown file to a sandbox is also handing the file's author an environment profile, down to the hostname, the username and the name the sandbox gave the file.
- decision Anyone running detonation infrastructure has to decide whether outbound name resolution from the sample network is worth keeping, since it was the one channel that worked in all 21 runs.
Four checkpoints per execution across 21 runs puts the ceiling at 84 DNS messages: Boot, Profiled, Networked and Dwell, the last after a default 45-second wait [10]. The recorded DNS rows run about four times that ceiling, roughly four arrivals for every checkpoint the program tried to send [1]. The write-up does not account for the multiplier. The totals do support a per-run count, because the random eight-byte run ID is the join key between the small DNS messages and the richer HTTPS record [8][12].
The DNS side works without the sample reaching the collector at all. The heartbeat is CBOR, converted to base32 text, then split into labels short enough to fit inside a domain name, and the lookup itself carries the message to the author's authoritative DNS server [9]. Resolution is done by whatever recursive resolver the analysis environment already trusts. Six runs delivered on that channel only [14], and adding those to the fifteen seen on both channels accounts for every run ID in the snapshot [2].
Run 0861ae2dd3f77c72 sent its first heartbeat at 06:52:09 and its dossier a second later: Windows 10 build 19044, four CPUs, 4195 MiB of RAM, parent process explorer.exe, and 50 seconds of uptime [16]. That uptime puts the host's boot near 06:51:20 [6]. The stored reverse-DNS name for the HTTPS source address pointed to Google Cloud infrastructure [17]. Its first Dwell observation arrived 46 seconds after Boot, one second past the configured delay, so the process was allowed to live through its own wait [17][5].
Six of the fifteen HTTPS dossiers, 40 percent of them, described the same Linux template between 08:21 and 10:30 UTC: CentOS 7, four CPUs, 1837 MiB of RAM, one shared hostname and username [18][3]. The distributed Linux build was called zerotoken-patch, and those six reported a path ending in gsvnywygooow [18]. The basename looks machine-generated. The launch-path field, in the write-up's words, captured "a detail that network addresses alone would have missed" [19].
The counts stop short of a census. The preserved records leave the author's own test runs unlabelled, and no submission-time manifest exists, so every recorded run ID sits in the totals [7]. According to the write-up, they "describe an exploratory capture, without establishing a count of independent analysis services" [7]. For the six CentOS dossiers to say anything about a named vendor's sandbox, the capture would have to pair each submission with where it went. The reviewed code installed nothing and collected no document contents or credentials, and detecting a VM added a field to the report instead of suppressing execution [5].
One execution is enough to give up an OS build, a core count, a memory size, a parent process and the filename the environment chose [4][16]. The DNS channel carries a summary value as well: run 5c5ab77e22747178 began appearing at 09:19:40 with a fingerprint of 7, combining flags for a recognised VM network-interface prefix, low resources or a fresh boot, and a process-name match against the tool allowlist [20].
What to watch
- A repeat capture that labels the author's own runs and pairs each submission with its destination. That pairing is what would turn 21 run IDs into a coverage figure.
- Whether the six DNS-only runs came from blocked HTTPS egress or from execution ending before the post, separable with an HTTP fallback channel.
- Whether analysis environments begin randomising hostname and username the way one of them already randomised the executable's basename.