Sandbox Verdict 'EVADER': RFQ Downloader's Debugger Checks and Stalls

A Sandbox Calls It "EVADER": Inside a Procurement-Themed Downloader's Stalling Act

A JavaScript downloader dressed as a routine purchase-order email doesn't just evade detection by accident — in this case, a sandbox measured the evasion and gave it a name. Zenbox returned a 100%-confidence verdict of "MALWARE/EVADER" against a script masquerading as "Anika RFQ NEW ORDER V01370P25080002.js" (a670ca27…), flagging behaviour that checks whether a debugger is attached and deliberately stalls execution for long periods before doing anything else. That single verdict, paired with a dedicated command-and-control node and a legitimate file-sharing service quietly pressed into service as a payload drop point, is the more interesting story here than the certificate hygiene alone — though the certificate hygiene turns out to matter too.

The cluster CTX Team pulled together is small — a handful of files, a domain, two IPs — but each piece locks into the others with unusual precision. A ZIP dropper and its embedded JS payload share a packer signature and near-identical threat labels; a domain and an IP share a certificate issuer and, more tellingly, the IP's own certificate names it as the domain's mail server; and a second IP, unrelated in ownership or geography to the first, carries a certificate for a public file-hosting brand that happens to match a URL circulating with the same file set. None of these bindings, on its own, would be remarkable. Together they read as a compact, purpose-built delivery-and-staging chain rather than a loose pile of coincidentally co-occurring indicators.

The RFQ Lure and the Varist-Packed Delivery Chain

The entry point is unglamorous by design. The ZIP file "RFQ-0001468BECRISA.zip" (74c272c9…) bundles exactly one child object — a JavaScript file — inside a container built to look like exactly what a procurement inbox receives dozens of times a week [T1566.001]. Sibling filenames recovered across the cluster reinforce the theme: "Purchase Order # 170826-5198.js," "RFQ-0001468BECRISA.js," "RFQ#PO - PO25-08-888.js." This is not a spoofed brand or a forged invoice logo; it's a generic business-correspondence wrapper, which is precisely what makes it durable — a lure this plain doesn't need to be refreshed every time a vendor name gets burned.

The ZIP and its embedded script are bound by more than theme. Both carry the same Varist packer signature and near-identical threat labels — trojan.sagent/crit on the archive, trojan.genericfca/sagent on the script — which confirms they are two stages of one delivery chain rather than two malware families that happen to travel together. Detection sits at 28 of 76 engines on the ZIP and 30 of 76 on the unpacked script, a middling but far from stealthy rate; whatever advantage this pair holds over defenders isn't coming from evading static signature engines. It's coming from what happens once the script actually runs [T1059.007], on a machine, past the point where most static scanning stops looking.

Stalling, Debugger Checks, and the Cost of Deliberate Evasion

That's where the sandbox verdict earns its place in the story. The script is tagged as obfuscated, and separately tagged with behaviour that checks for an attached debugger and stalls for long periods before executing — two checks that, combined, are a textbook detonation-delay pattern [T1497]. An analyst watching this land in an automated sandbox with a fixed execution window would plausibly see nothing: the process launches, sleeps, sleeps some more, and the sandbox times out before the payload logic ever fires. From inside a target's endpoint telemetry, the picture looks almost identical — a script process that spawns, briefly touches temp storage, and appears dormant for an uncomfortable stretch of time before any outbound connection shows up. That gap is exactly the window in which an automated detection pipeline decides there's nothing to escalate.

The choice carries a cost, though, and it's visible in the numbers. Building in stall logic and debugger checks buys time against sandbox and EDR triage, but it does nothing against static signature matching — which is presumably why 30 of 76 engines still flag the unpacked script even with the evasion logic intact. The operator traded blanket concealment for triage delay: a script that a scanner can still catch on disk, but that a behavioural pipeline with a short fuse may wave through. That's a rational bet against automated defenses tuned for speed over patience, and it is consistent with — though not proof of — an operator optimizing for volume delivery rather than a single high-value intrusion.

A Dedicated Mail/C2 Node Behind a Week-Old Certificate

Once the script executes, it has somewhere specific to reach. The domain trimnt.com resolves to exactly one address, 45.66.248.2, hosted on BlueVPS OU under AS62005. That alone would be a thin data point, but the certificate record closes the loop: both the domain and the IP carry the identical Let's Encrypt certificate issuer "YR1," issued the same week — the domain's certificate valid 2026-07-15 through 2026-10-13, the IP's valid from 2026-07-15 as well — and, critically, the IP's own certificate subject reads "mail.trimnt.com." That's not a shared-hosting fingerprint; it's the IP identifying itself, in its own TLS handshake, as the mail and C2 relay for this specific domain [T1071]. DNS records back this reading — trimnt.com's MX record points to mail.trimnt.com, and its SPF record whitelists 45.66.248.2 by IP — which means the operator built out a coherent, self-consistent mail-and-C2 identity rather than repurposing an anonymous VPS box on the fly.

The domain itself is young relative to the campaign window: registered 2026-04-14 through publicdomainregistry.com, with WHOIS fully GDPR-masked, giving roughly four months of runway before the current certificate and observed traffic surfaced. Multiple independent categorizations already tag it "Malware Sites," "known infection source," and "phishing and fraud" — a blocklist consensus that arrived faster than most legitimate small-business domains ever accumulate any reputation at all. Detection on the domain itself sits at 16 of 90 engines, modest for infrastructure this actively flagged, which suggests domain-reputation systems are still catching up to a node that has clearly already been circulated in phishing traffic.

What stands out on closer inspection is the timing discipline. The domain was registered in mid-April, but its operational certificate — the one actually fronting live traffic — wasn't issued until mid-July, roughly three months later. Registration and activation are not the same event, and the gap between them is worth noting rather than glossing over: it's consistent with an operator staging infrastructure in advance and holding it dormant until a campaign window opened, though the data here can only establish the two dates, not the reasoning behind the interval.

Borrowing catbox.moe: Staging Payloads Inside Legitimate Traffic

The second IP in this cluster, 108.181.20.35, tells a different story from the first, and the difference is instructive. It sits on Psychz Networks under AS40676 — a wholly separate autonomous system, registrar-independent of the BlueVPS node, with no shared certificate issuer. Its TLS certificate subject reads "catbox.moe" and "files.catbox.moe," issued by a different Let's Encrypt account ("YE2") than the trimnt.com cluster. Catbox.moe is a real, legitimate anonymous file-hosting service, and the certificate confirms this IP is genuinely serving that brand's traffic — it is very unlikely to be attacker-owned infrastructure in any conventional sense.

What ties it to this cluster at all is a URL circulating alongside the same file set: files.catbox.moe/vmq3z4.dat. The co-occurrence of a catalog-style file path on a legitimate public host, sitting next to a dedicated RFQ-themed downloader chain, suggests — though the pack has no captured network transaction to confirm it outright — that the downloader's second stage is fetched from this public service rather than from attacker-controlled infrastructure. If that inference holds, the tactical logic is clear: a request to files.catbox.moe generates no alert on its own, because the domain is benign, widely used, and unlikely to sit on any blocklist. Layering a malicious payload retrieval inside traffic to a legitimate file host [T1105] is cheap defense-in-depth for the attacker and a genuine blind spot for network-layer detection that keys on domain reputation rather than payload content.

The two IPs' certificates were issued within roughly 18 hours of each other in mid-July — 2026-07-14 for the catbox.moe node, 2026-07-15 for the trimnt.com/BlueVPS node — despite having nothing else in common architecturally. That near-simultaneous issuance, read against the earlier three-month gap between trimnt.com's registration and its activation, is consistent with an operator flipping multiple infrastructure elements live at once ahead of a coordinated push, rather than incrementally building out capability over time. It's a pattern worth flagging as inference: certificate issuance dates establish when TLS went live, not when the underlying relationship between the two nodes was first arranged.

Twin Loaders, Zero Detections: The Quiet Half of the Cluster

Two 64-kilobyte JavaScript files round out the file set, and they are the cluster's most ambiguous members. Both were first seen the same day, both carry identical file sizes, and both use mirrored naming conventions in their temp-path artifacts — one recorded as "131tmstwfswxa" alongside an alternate name "hqdmsubazlba," the other as "131tmstwfswxb" alongside "hqdmsubazlbb." That "a/b" pairing in otherwise arbitrary-looking strings is difficult to read as coincidence. It looks like templated or sequential output from the same build process — but it's worth being explicit that this is a naming-pattern inference, not a confirmed shared-builder finding: neither file carries an import hash or a code-signing certificate, so the harder technical linkage that would normally settle the question isn't available here.

Both scripts sit at zero detections out of 76 engines, a result that on its face looks like clean bills of health but is actually a measurement artifact: roughly a fifth of the engine base returns "type unsupported" against these files rather than an actual clean verdict, meaning a meaningful slice of the industry's detection coverage simply isn't evaluating this file type at all. That is a materially different situation from a file that 76 engines examined and 76 engines cleared. A SOC analyst triaging this pair off a VirusTotal score alone would reasonably deprioritize it — and that reasonable-looking triage decision would be wrong, given that a structurally near-identical script sitting in the same delivery chain (the RFQ-themed downloader) already draws 30 flags. The gap between "zero detections" and "zero risk" is exactly where this kind of cluster survives longest.

What a Scattered, Unattributed Lure Says About This Operator

No named threat actor or malware family attaches to this cluster in the available record, and the targeting picture that does exist argues against reading one in. The associated activity touches organizations across more than 40 countries and industries spanning manufacturing, energy, government, healthcare, telecom, and legal services — a spread far wider than a curated espionage target list, and one that reads as opportunistic distribution rather than a chosen victim set. A generic procurement lure paired with that breadth is consistent with a financially motivated downloader operation casting for any inbox that opens an attachment, though this framing remains an inference drawn from the shape of the targeting data rather than a confirmed classification.

That caveat matters, but it doesn't diminish what the operational picture shows on its own terms. A modestly resourced downloader operation assembled a sandbox-confirmed evasion technique, a dedicated mail-and-C2 domain with matching infrastructure identity, and a second-stage staging layer riding inside legitimate file-hosting traffic — three separate design choices that each cost more effort than the RFQ lure itself required, and that together look less like a one-off spray than an operator iterating toward something more durable. The certificate-issuance timing across both the dedicated node and the borrowed file host, taken together with the three-month gap between domain registration and activation, points toward advance staging rather than improvisation. None of these elements individually would carry much weight; braided together, they describe a cluster built with more discipline than its plain-text procurement lure would suggest at first glance — and a pattern worth watching for recurrence the next time a fresh domain surfaces on the same certificate-issuance cadence.