XWorm RAT Hides Behind Purchase-Order ZIP and Pre-Armed Wildcard Infrastructure
A campaign first logged 18 June 2026 uses an eleven-kilobyte purchase-order ZIP to deliver an evasion-hardened VBS downloader that ultimately installs XWorm RAT. The operator provisioned wildcard Let's Encrypt certificates and a shared White Label Services hosting layer weeks before the first malicious file appeared, pointing to a planned infrastructure preparation cycle rather than opportunistic deployment.
##Purchase-Order ZIP Conceals a Three-Stage XWorm Delivery Chain Built on Pre-Armed Wildcard Infrastructure
A compact, eleven-kilobyte ZIP archive named PO-000172483.zip is the opening move in a campaign that unfolds across five deliberate stages — evasion-hardened VBS execution, a stealthy compile-after-delivery intermediate, and XWorm RAT C2 over a Turkish-geolocated IP whose hosting fabric was provisioned weeks before the first malicious file appeared on the internet. The operator did not improvise: both campaign domains received 89-day Let's Encrypt wildcard certificates and were tied to a single White Label Services LLC provisioning layer before the delivery chain went live in mid-June 2026, pointing to a planned infrastructure preparation cycle that distinguishes this cluster from opportunistic commodity deployments.
CTX Team registered the campaign on 18 June 2026, with the earliest file submission dated 16 June. The indicator set spans 20 countries and 13 industry verticals — from manufacturing and government to aerospace and healthcare — consistent with broad, financially motivated targeting rather than a narrowly scoped intrusion.
The Lure: A Routine Business Document That Isn't
The delivery vehicle is deliberately unremarkable. PO-000172483.zip (SHA-256: 96aba981...) is an eleven-kilobyte ZIP archive whose filename mimics a standard purchase-order document — the kind of file that procurement, finance, and operations staff open without hesitation dozens of times a day. The archive was submitted to analysis from the path /tmp/eml_attach_for_scan/c6fd7d35e87c39ccaff297f2d957c241.file, confirming email attachment delivery [T1566.001]. Twenty of 76 scanning engines flag the container as malicious — Microsoft, Sophos, and Symantec among them — but 40 engines return clean, and five timed out entirely.
Inside the ZIP sits a single child file: PO-000172483.vbs, also named sleestak_payload_1.vbs, a 2,088-kilobyte VBS script that constitutes the campaign's primary execution stage. The outsized file size — nearly two megabytes for a script — suggests significant embedded content or deliberate obfuscation padding, a common technique for defeating size-threshold heuristics in email gateways. The ZIP's internal timestamp records the archive as packed on 16 June 2026 at 21:50:56 UTC, placing construction within hours of the first observed submission.
The purchase-order lure is effective precisely because it requires no social engineering beyond the filename. In sectors where vendor correspondence is high-volume and time-sensitive — manufacturing, wholesale, retail, engineering — the implicit authority of a PO number suppresses the hesitation that might otherwise accompany an unexpected attachment.
Inside the VBS: Evasion Architecture Before a Single Payload Byte Downloads
The VBS script (SHA-256: 3dcfb2e1...) is where the campaign's operational investment becomes visible. Rather than executing a straightforward download-and-run sequence, the script layers multiple evasion mechanisms that collectively suppress static detection to 11 of 76 engines — a remarkably low rate for a file that both Zenbox and CAPE Sandbox return unambiguous malicious verdicts on.
The script is tagged with four behavioural indicators that together describe a deliberate anti-analysis architecture: calls-wmi, macro-powershell, detect-debug-environment, and long-sleeps. The WMI and PowerShell invocations [T1059.005] are the execution mechanism — rather than spawning child processes directly, which would generate immediately detectable process-tree artefacts, the script routes execution through Windows Management Instrumentation and PowerShell, both of which are legitimate system components that many endpoint controls treat permissively. The debug-environment detection and sleep delays [T1497.001] address the sandbox problem: the script probes for analysis-environment indicators before proceeding and inserts extended pauses that exhaust the time budgets of automated sandboxes, causing them to terminate without observing the malicious behaviour.
The result is a file that 49 of 76 engines classify as undetected despite confirmed malicious behaviour. Notably absent from the flagging list are a number of widely deployed endpoint platforms — the gap between the 11 engines that flag and the 49 that do not represents a meaningful detection blind spot for organisations relying on those controls.
The rule signal is correspondingly rich. The VBS triggers 14 Sigma matches across two rule sets: two critical-severity hits from the Joe Security Rule Set and four high-severity, seven medium-severity, and one low-severity hit from the Sigma Integrated Rule Set. Two IDS rules also fire: ET EXPLOIT_KIT Unknown EK Landing Feb 16 2015 b64 2 M1 (high severity, Proofpoint Emerging Threats Open) and ET DROP Spamhaus DROP Listed Traffic Inbound group 7 (medium severity). The first of these — the base64 exploit-kit landing rule — is consistent with a base64-encoded download stage embedded in the script that reaches out to the operator's staging infrastructure to fetch the next-stage payload. The Spamhaus DROP rule firing against the same file indicates that the C2 or staging infrastructure the script contacts was already listed on a reputation blocklist at the time of analysis.
The VBS carries fuzzy hashes (ssdeep: 96:5+aRr+aRr+aRr+aRr+aRr+aRr+aRr+aRr+aRr+aRr+aRr+aRr+aRr+aRr+aRr+aD:rSBZSeR24Fd8vB9Jbty4z80; TLSH: T189A5808EF0346BB1379CFB73044CDDAAB489AC31307A5F625E5A219B256469B91F1CF0) that provide a clustering handle for future submissions, but all three files in the campaign lack code-signing certificates and import-table hashes, preventing build-pipeline attribution through those conventional axes.
The Intermediate Ghost: C# Source Dropped to Temp and Compiled at Runtime
Between the VBS downloader and the XWorm terminal payload, a third stage appears that is operationally the most novel element in the chain — and the most uncertain.
A 4-kilobyte ASCII text file (SHA-256: 3ee1bf1a...) carries five observed naming variants, all following the pattern guardian_src_[UUID].cs, and one of its recorded paths is %TEMP%\guardian_src_92b418039c5240b0b3198db13659663e.cs. The naming convention — a fixed prefix combined with a unique hexadecimal identifier — is consistent with a dropper that writes a C# source file to the user's temporary directory with a per-execution unique name, then invokes the .NET compiler (csc.exe or the Roslyn compiler service) to produce a binary that is never written to disk as a recognisable executable [T1027.004]. Each compilation run would produce a unique binary hash, defeating hash-based detection entirely.
The YARA rule Windows_API_Function (InQuest Labs) fires on this file. The rule's own description is instructive: it detects Windows API function references commonly found in embedded executables, and explicitly notes that when it fires on a non-executable file type, "deeper investigation may be warranted." A C# source file referencing Windows API functions is precisely the scenario the rule was designed to flag — the source code contains the API call patterns that will become executable behaviour after compilation.
Zero of 77 scanning engines flag this file. That is not a clean verdict; it is an invisibility artefact. A plain-text .cs file with no executable structure presents nothing for signature-based engines to match against, and without sandbox execution of the compilation-and-run sequence, behavioural engines have no observable malicious activity to classify.
The temporal relationship of this file to the June 2026 campaign is genuinely uncertain and should be treated as such. The file was first seen on 8 October 2025 — approximately eight months before the VBS and ZIP files appeared — and its last submission is recorded as 15 January 2026. CTX Team's analyst notes flag this pre-campaign first-seen date as an outlier: the file may represent an earlier version of the same toolchain, a shared builder component reused across multiple campaigns, or a coincidental match on the naming pattern. The compile-after-delivery inference is analytically supported by the file's characteristics, but its direct functional link to the June 2026 delivery chain is not confirmed by sandbox evidence and should be read accordingly.
Infrastructure: A Two-Tier Hosting Architecture Prepared Weeks in Advance
The campaign's infrastructure tells a story of deliberate preparation. Two domains and one IP address constitute the observable hosting fabric, and the provisioning timeline for all three predates the first malicious file submission by days to weeks — a pattern inconsistent with reactive, opportunistic infrastructure setup.
The throwaway staging domain. basefile.click was registered on 9 June 2026 via Spaceship, Inc. — nine days before CTX Team's analysis timestamp and a week before the first payload submission. The domain was immediately delegated to ns1.whitelabelservices.us and ns2.whitelabelservices.us, and a Let's Encrypt wildcard certificate (*.basefile.click, issuer YR2, serial 612d39cad88012a99e1441f1c7b5fce9fd1) was issued the same day, valid from 9 June 2026 through 7 September 2026 — an 89-day span. The wildcard subject alternative name is operationally significant: it allows the operator to deploy arbitrary subdomains under basefile.click without requesting a new certificate for each one, enabling flexible payload hosting paths. The observed URL basefile.click/optimized_MSIljune.png exploits exactly this flexibility — the PNG file extension is used to disguise what the analyst assesses is likely an MSI or executable payload, a content-type masquerading technique [T1071.001] that can bypass gateway controls filtering by extension or MIME type. No HTTP response data is available to confirm the actual content served at that path, so the payload type remains unverified.
The domain resolves to the A-record 45.136.5.4 and carries a detection ratio of 12 of 91 engines — low enough to pass most reputation-based controls at the time of campaign activity.
The aged legitimate domain. brenmayasociados.com presents a contrasting profile. Registered on 21 February 2020 via GoDaddy.com, LLC, and hosted on HostGator nameservers (ns4001.hostgator.com, ns4002.hostgator.com), the domain is 2,309 days old at analysis time — the kind of aged, previously legitimate domain that carries inherent reputation weight. Its detection ratio is 13 of 91 engines, and its reputation score sits at zero, consistent with a domain that has not previously been flagged in major threat-intelligence feeds. A fresh 89-day Let's Encrypt wildcard certificate (*.brenmayasociados.com, issuer R13, serial 55c5131f6ee7d8b6c20727a0eb1090b7962) was issued on 26 May 2026 — three weeks before the campaign's active file dates — indicating the operator re-armed this existing domain for the current operation. Whether brenmayasociados.com was compromised or purchased cannot be determined, but the pattern of an aged domain receiving a fresh wildcard certificate immediately before a campaign launch is consistent with operator preparation of a high-reputation HTTPS host.
The C2 IP. 203.202.232.149 sits on ASN 44382, operated by Fiba Cloud Operation Company, LLC, under RIPE NCC jurisdiction, geolocated to Turkey. The netblock 203.202.232.0/24 was allocated on 7 May 2026 — six weeks before the campaign's active window — with RIPE WHOIS recording the organisation as White Label Services, LLC (ORG-WLSL1-RIPE), address listed as 1309 Coffeen Avenue STE 1200, Sheridan WY, with the geofeed URL https://geofeed.whitelabelservices.us/geofeed.txt. The IP carries a self-signed TLS certificate with both issuer and subject set to wembolsar.com (CN=wembolsar.com, serial eb) — a hallmark of actor-controlled C2 infrastructure, where the operator generates a certificate for a domain they control and uses it to encrypt C2 traffic without involving a public certificate authority. Detection sits at 19 of 91 engines, with a reputation score of -11 and one community malicious vote.
A temporal anomaly warrants attention. The self-signed certificate on 203.202.232.149 was first observed on 17 June 2025 — nearly a year before the netblock containing the IP was allocated on 7 May 2026. This is not a typical provisioning sequence: certificates are normally issued after infrastructure is stood up, not before the IP space exists. The analyst notes this as an outlier requiring further investigation. Possible explanations include certificate reuse across infrastructure rotations (the certificate was generated on earlier infrastructure and redeployed when the operator moved to this netblock), a data artefact in the certificate-transparency or passive-DNS record, or a more complex infrastructure history involving the wembolsar.com domain. Certificate-transparency log investigation and passive DNS pivoting on wembolsar.com are the indicated next steps to determine whether this domain anchors a broader actor-controlled cluster predating this campaign.
The shared provisioning thread. The cohort analysis surfaces a binding axis that ties the staging domain and the C2 IP together: both are provisioned through White Label Services LLC. basefile.click's nameservers point to ns1.whitelabelservices.us and ns2.whitelabelservices.us; the RIPE WHOIS for 203.202.232.149's netblock names White Label Services, LLC as the organisation and references the same entity's geofeed. This shared provisioning layer suggests the operator sourced both components — payload staging and C2 — from the same reseller account or infrastructure provider, creating a trackable fingerprint across otherwise distinct infrastructure elements.
The second cohort axis is the identical 89-day Let's Encrypt wildcard certificate pattern across both campaign domains. basefile.click received its certificate on 9 June 2026; brenmayasociados.com received its on 26 May 2026 — a 14-day window immediately preceding the 16–17 June 2026 payload dates. The matching certificate lifespan, wildcard SAN structure, and pre-campaign issuance timing across two domains registered through different registrars and hosted on different nameserver infrastructure is not coincidental. It indicates a single operator preparing HTTPS infrastructure across both domains in a coordinated pre-launch phase.
XWorm at the End of the Chain: Commodity RAT, Deliberate Delivery
CAPE Sandbox names XWorm as the terminal payload delivered by the VBS downloader chain. XWorm is a commodity remote-access trojan with a well-documented capability set: keylogging, clipboard monitoring, file exfiltration, screenshot capture, and reverse shell functionality. Its presence at the end of this chain is consistent with financially motivated intrusion — credential harvesting, data theft, or establishing persistent access for follow-on monetisation — and with the campaign's broad multi-sector, multi-region targeting profile.
Zenbox classifies the VBS file as MALWARE/SPREADER/EVADER with 84% confidence, the SPREADER classification suggesting the implant may attempt lateral movement or further distribution once established. The EVADER classification aligns with the observed sandbox-evasion tags. Both sandbox verdicts are unambiguous: this is not a borderline detection.
The C2 architecture routes XWorm's traffic over HTTPS [T1071.001] to 203.202.232.149, with the self-signed wembolsar.com certificate providing TLS encryption that prevents content inspection by network controls that do not perform SSL/TLS interception. The use of a self-signed certificate rather than a Let's Encrypt certificate for the C2 IP — in contrast to the Let's Encrypt wildcard certs used on the staging domains — may reflect a deliberate operational choice: the C2 channel benefits from encryption but does not need to pass browser or gateway certificate-validation checks, while the staging domains serving files over HTTPS benefit from certificates that won't trigger browser warnings if a victim navigates to them directly.
What is operationally notable about this XWorm deployment is not the RAT itself — it is the delivery chain constructed around it. Most commodity XWorm campaigns observed in the wild rely on simpler delivery mechanisms. The layering of a purchase-order ZIP lure, a 2,088-kilobyte evasion-hardened VBS with WMI and PowerShell execution paths, a probable compile-after-delivery C# intermediate stage, and pre-armed wildcard HTTPS infrastructure represents a meaningful investment above the baseline for XWorm distribution. The guardian_src_*.cs staging artifact's zero-detection rate and per-execution unique hash behaviour — if the compile-after-delivery inference holds — would defeat hash-based endpoint controls entirely, leaving behavioural detection as the primary viable control layer.
No novel XWorm variant or previously undocumented C2 protocol modification is confirmed. The campaign's distinctiveness lies in the delivery architecture, not the payload.
No Attribution, Broad Exposure, and a Fingerprint Worth Tracking
No actor or threat group attribution is established for this campaign. The targeting — 20 countries spanning Europe, Asia, the Americas, and the Middle East, across 13 industry verticals including manufacturing, government, healthcare, telecommunications, aerospace, agriculture, automotive, and wholesale — is consistent with financially motivated or opportunistic threat activity rather than a narrowly focused state-aligned operation. The purchase-order lure is sector-agnostic by design: it is most effective wherever procurement and vendor correspondence is routine, which describes virtually every commercial and government organisation in the target geography. No geopolitical or state-aligned motivation is supported by the evidence, and the historical arc for this cluster is thin — no widely reported prior campaign with confident attribution maps cleanly onto this infrastructure and tooling combination.
The confidence level on this campaign assessment is medium. The VBS downloader and ZIP container are well-evidenced: dual sandbox confirmation, 14 Sigma rule hits, IDS rule matches, and clear detection by multiple engines. The C2 IP and staging domain infrastructure is grounded in WHOIS and certificate data. The compile-after-delivery C# stage is analytically supported but not sandbox-confirmed, and its temporal relationship to the June 2026 campaign introduces genuine uncertainty into the chain reconstruction.
What the campaign signals most clearly is the operational maturity gap between the payload and the delivery mechanism. XWorm is available to any buyer; the infrastructure preparation cycle documented here is not. Wildcard TLS certificates were issued and White Label Services provisioning was completed weeks before the first malicious files appeared, indicating a planned launch rather than a reactive one. The shared provisioning layer across the C2 IP and the payload-staging domain — White Label Services LLC appearing in both the nameserver delegation for basefile.click and the RIPE WHOIS for 203.202.232.149's netblock — is a durable infrastructure fingerprint that should survive individual component rotation. Operators who change their payload or staging domain but retain the same reseller account will carry this fingerprint into their next campaign.
The temporal anomaly on the C2 IP certificate — observed approximately a year before the netblock was allocated — is the most significant open question in this investigation. If wembolsar.com anchors a broader actor-controlled infrastructure cluster predating this campaign, certificate-transparency log enumeration and passive DNS pivoting on that domain could surface earlier operations and provide the historical arc currently missing. ASN 44382 (Fiba Cloud Operation Company, LLC) and the ns1/ns2.whitelabelservices.us nameserver pair are the two most tractable pivots for expanding the observable infrastructure perimeter beyond the indicators currently observed. The operator's decision to concentrate both staging and C2 provisioning through a single reseller layer is, ultimately, the operational choice that makes this campaign traceable.
