Fake Android Toolkit Delivers Sandbox-Proof Python Spyware
A trojanized self-extracting archive posing as 'Android Win Tool v1.9.6' stages a PyInstaller-packed Python trojan and a secondary unsigned PE payload that beacon to parameterized HTTPS endpoints. The campaign is distinguished by deliberate layering of evasion techniques — long-sleep loops, unsigned executables, and a shared custom build artifact — across a purpose-built two-tier C2 infrastructure spanning four jurisdictions.
A Python Trojan in a Fake Android Toolkit: How One Operator Built a Sandbox-Proof Espionage Platform
A self-extracting RAR archive named "Android Win Tool v1.9.6" is circulating as a trojanized utility lure, staging a PyInstaller-packed Python trojan and a secondary unsigned PE payload that beacon to parameterized HTTPS endpoints across a purpose-built two-tier command-and-control infrastructure. The campaign — tracked by CTX Team under threat record CTXkz7eez4uc5 with severity 100 and confidence 85 — is distinguished not by any single technique but by the deliberate layering of evasion mechanisms: long-sleep loops that outlast sandbox timeouts, unsigned executables that nonetheless clear both automated analysis environments with CLEAN verdicts, and a shared custom build artifact that fingerprints both payloads to the same toolchain. The infrastructure binding is equally precise — four network nodes, one automated certificate pipeline, one registrant identity.
The Lure: Trojanized SFX Archive Masquerading as a Developer Utility
The campaign's entry point is a self-extracting RAR archive presented to victims as a legitimate Android device management tool [T1204.002]. The delivery mechanism is established directly by the batch launcher embedded inside the archive: a file named ~run.bat, whose alternate path names recorded in VirusTotal metadata tell the full story. The file appears both at C:\Users\trbis\Downloads\Android Win Tool v1.9.6\data\~run.bat — confirming a user-initiated download from what was likely a trojanized distribution site or forum post — and at C:\Users\<USER>\AppData\Local\Temp\RarSFX0\data\~run.bat, confirming the SFX extraction path that fires on execution.
The choice of lure is operationally deliberate. Android utility tools occupy a niche that attracts technically engaged users — developers, IT administrators, and enthusiasts who manage Android devices from Windows workstations. This audience is less likely to be running consumer-grade endpoint protection and more likely to have elevated privileges or access to sensitive enterprise systems. The lure does not target a mass-phishing audience; it targets a specific technical profile.
The batch file ~run.bat (SHA256: 526322589fa39b64752b778f95dbbd532833cc53a747aa236d96920f6f9a66c4) is the campaign's first active component, and it is more than a simple launcher. Despite being a DOS batch file — a format that antivirus engines routinely treat as low-risk — it carries a hit on the YARA rule Windows_API_Function authored by InQuest Labs, a signature designed to detect Windows API call strings embedded in non-executable file types where their presence warrants deeper investigation. Beyond that YARA match, the batch file accumulates three Sigma rule hits from the Sigma Integrated Rule Set: two rated high severity and one rated medium. For a plain batch file, this rule-match density is anomalous; it indicates the script either directly invokes Windows API functions through shell-level tricks or contains strings consistent with launching embedded PE payloads [T1059.003].
The file carries the sandbox evasion tag long-sleeps — a designation applied when a sample is observed executing deliberate delay loops that outlast the analysis window most automated sandboxes enforce. This tag co-appears on a companion text artifact (f02285fb90ed8c81531fe78cf4e2abb68a62be73ee7d317623e2c3e3aefdfff2), which is tagged long-sleeps and idle and has been observed in VirusTotal since 2015 across 422 submissions from seven sources. That decade-old artifact is an outlier in this collection — it shares no imphash, signer, or threat label with the June 2026 payloads — and may represent a generic evasion snippet reused across unrelated operations, or a false-positive inclusion in the collection. Its presence does not alter the core campaign picture, but it underscores that long-sleep evasion is a technique the operator has either sourced from common tooling or independently implemented.
The ~run.bat file itself registers 0/77 detections across all antivirus engines — a clean sweep that reflects how poorly the security industry handles malicious batch files when they do not contain overtly detectable shellcode. The YARA and Sigma hits are the only signals that distinguish it from a benign script.
The Payloads: A Shared Build Artifact Across Two Unsigned PE32+ Executables
Once the SFX archive extracts and the batch launcher fires, it stages two unsigned 64-bit PE32+ executables that form the campaign's active payload tier. Both were compiled in May 2026 and first appeared on VirusTotal within 24 hours of each other — the larger on 2026-06-11, the smaller on 2026-06-12 — suggesting a coordinated deployment rather than independent discovery.
The larger payload, tkzEegqmFY.exe (SHA256: 2dcf5725dc623010c2e956518c903c52fd326fb2c2254f39b831c2bd2fe04e90), weighs in at 53,719 KB — a size that immediately signals its construction method. The YARA rule PyInstaller authored by @bartblaze fires on this file, confirming it is a Python script compiled into a standalone Windows executable using the PyInstaller framework [T1027]. PyInstaller bundles the full CPython runtime, all imported libraries, and the target script into a single binary, which explains the 53 MB footprint. The format is operationally attractive for several reasons: it allows rapid payload iteration in Python without requiring a Python interpreter on the victim host, it produces a binary that static analysis tools struggle to decompile cleanly, and it generates a file size that some sandbox environments handle poorly due to resource constraints. The PE timestamp is 2026-05-03, placing compilation roughly six weeks before first observation.
The secondary payload (SHA256: 0a31a7033893e0fea12b2312345aa97f574eff5bf81bf0417cedb481eebba211) is considerably smaller at 802 KB and is packed with Varist rather than PyInstaller. Its PE timestamp is 2026-05-01, two days before its companion. It carries the threat label trojan.generics/filerepmalware and a categorisation that includes trojan, miner, and dropper — a combination that leaves open the possibility of cryptocurrency harvesting or secondary payload staging as collection objectives, though current evidence is too thin to conclude. Both payloads carry the overlay tag, indicating data appended beyond the PE's declared sections that may conceal additional payload material.
What binds these two executables most firmly — despite their different sizes, different packers, different imphashes (dcaf48c1f10b0efa0a4472200f3850ed for the PyInstaller sample, 2057790ae7855765d51bdc4142e62f9c for the Varist sample), and different threat labels — is a structural PE artifact that does not appear in standard compiler outputs. Both files contain a section named .fptable with entropy 0.0 and a size of exactly 512 bytes. A zero-entropy section of this size is not produced by MSVC, MinGW, or any common open-source toolchain; it is consistent with a custom builder or build template that inserts a fixed-size, all-zero placeholder section as part of its output. The presence of this identical artifact across both payloads, despite their otherwise distinct build profiles, is the strongest evidence that they share a common development pipeline — a reusable builder template that the operator applies to different payload types.
The .text sections of both executables register entropy in the 6.47–6.49 range, consistent with compiled code that has been processed but not aggressively compressed. The .rdata sections sit at 5.37–5.75, and the .rsrc sections at 5.53–5.78 — entropy profiles that do not immediately flag as packed to heuristic engines tuned for high-entropy detection.
The industry detection picture for both payloads reflects a campaign calibrated against the mainstream detection stack. The PyInstaller sample (tkzEegqmFY.exe) achieves 21/76 detections — 21 engines flag it, while 48 remain undetected and 6 report the type as unsupported. The Varist-packed secondary payload performs slightly worse from an evasion standpoint at 29/76, with 29 engines flagging and 37 undetected. Both figures represent meaningful detection gaps: roughly half the industry misses each payload. More operationally significant is the sandbox picture. Both Zenbox and C2AE returned CLEAN verdicts for the PyInstaller sample — Zenbox with 98% confidence, C2AE with an UNKNOWN_VERDICT — despite the 21/76 static detection ratio [T1497.003]. The Varist-packed payload similarly returned a CLEAN verdict from Zenbox at 99% confidence. The long-sleep tags on the batch file and companion text artifact provide the most plausible explanation: the payloads execute sleep loops that exceed the analysis window before performing any detectable malicious activity, allowing them to exit sandbox environments without triggering behavioural signatures.
Three zero-detection ASCII text files — update.log, setup.log, and install.log (all first seen 2026-02-23, all 0/77 detections) — were dropped alongside the payloads. Their naming pattern is consistent with installer-stage logging from a multi-component implant framework, suggesting the operator's tooling generates plausible-looking log artifacts as cover for the installation process. All three use CRLF line terminators, consistent with Windows-native tooling.
All seven files in the dossier set are unsigned — there is no code-signing certificate in this campaign. The absence of signing is a deliberate tradeoff: obtaining a valid code-signing certificate creates an attribution surface, while unsigned executables, when paired with effective sandbox evasion, can achieve comparable bypass rates against endpoint controls that rely primarily on behavioural analysis.
The Infrastructure: Jurisdictional Fragmentation as Operational Doctrine
The campaign's network infrastructure is not improvised. Across four nodes — two IPs and two domains with active C2 roles — CTX Team identified a consistent pattern of deliberate jurisdictional fragmentation, automated certificate management, and WHOIS obfuscation that collectively indicate an operator who has invested significant effort in infrastructure longevity and attribution resistance.
The primary active C2 node is neuralpulsecore5.sbs, resolving to 154.86.119.78 on AS 197574 (ExpressHost Ltd). The domain was registered on 2026-04-22 — just 52 days before detection — through Dynadot (registrar ID 472). Its nameservers are a.dnspod.com, b.dnspod.com, and c.dnspod.com, a DNS resolution service operated by Tencent Cloud. The use of DNSPod nameservers for a domain hosted on Netherlands infrastructure registered through a US-based registrar represents a deliberate jurisdictional split: DNS resolution runs through Chinese-operated infrastructure, the VPS sits in the Netherlands under AFRINIC registration with a Seychelles administrative contact, and the domain itself was registered through a US registrar. No single jurisdiction has visibility into the full operational picture. The IP's TLS certificate subject — nl01.spbeyes.com — suggests a dedicated VPS provisioned specifically for this campaign rather than a shared hosting environment.
This node carries the campaign's highest network detection ratio at 20/91, with one community malicious vote. It is the most flagged network IOC in the set and the one most likely to appear on threat intelligence blocklists.
The secondary node — file-end.com resolving to 209.42.27.175 on AS 204800 (WHG Hosting Services Ltd, RIPE NCC, registered in the United Kingdom) — presents a different operational profile. The domain is considerably older, registered on 2025-09-11, making it 275 days old at the time of detection. Its nameservers (ns1.mysecurecloudhost.com through ns4.mysecurecloudhost.com) and the TLS certificate subject on its hosting IP (cpcontacts.abysat.com.br) are entirely unrelated to the campaign's other domains. The Brazilian domain in the TLS subject, combined with the IP's RIPE NCC registration under a UK company, suggests this server is either a compromised shared-hosting environment or a rented node where the operator does not control the underlying TLS configuration. The domain registers 0/91 detections — it has not yet been flagged by any network security vendor — which may explain its continued use as a secondary or fallback node.
The third domain, mayfiles.vip (created 2026-04-11, 61 days old), resolves to 173.252.167.50 — an IP not present as a campaign IOC in the current dataset. Its role is not fully established, but its TLS certificate (issued by Let's Encrypt intermediate YR1, valid from 2026-06-04 to 2026-09-02) and its cPanel-style subject alternative names (cpanel.mayfiles.vip, cpcalendars.mayfiles.vip, cpcontacts.mayfiles.vip) suggest a hosting panel environment that may serve a staging or payload-hosting function not yet fully observed. It registers 1/91 detections.
The binding element across file-end.com and mayfiles.vip is not technical but administrative: both domains share the identical registrant company hash 4b7a0912c26a13e2 in their WHOIS records, both list Iceland (Reykjavik, Capital Region) as the registrant country, and both use Namecheap (registrar ID 1068) with withheldforprivacy.com email addresses as WHOIS privacy cover. This is not coincidence — it is the same operator registering multiple campaign domains under the same Namecheap account identity, using Iceland-based privacy protection to frustrate registrar-level attribution and takedown requests. The shared company hash is a durable fingerprint: even as the operator rotates domains, any new registration under the same Namecheap account will carry the same hash, enabling prospective tracking of additional infrastructure.
Across all four network nodes, the certificate management pattern is uniform and automated. Every node carries an 89-day Let's Encrypt TLS certificate — the maximum validity period Let's Encrypt issues — provisioned through three different intermediates: R13 (used by file-end.com, valid 2026-05-14 to 2026-08-12, and by 209.42.27.175, valid 2026-04-13 to 2026-07-12), YR1 (used by mayfiles.vip, valid 2026-06-04 to 2026-09-02), and E8 (used by 154.86.119.78, valid 2026-05-05 to 2026-08-03). The spread across three different Let's Encrypt intermediates within a seven-week provisioning window (2026-04-13 to 2026-06-04) is consistent with a single automated ACME client managing certificate rotation across the entire infrastructure. Manual certificate management does not produce this pattern; scripted ACME automation does. The operator does not need to touch the infrastructure to maintain valid TLS across all nodes — the pipeline handles it.
The shared R13 issuer between file-end.com and 209.42.27.175 — confirmed through the TLS certificate issuer common name on both IOCs — establishes that these two nodes are operated as a unified C2 node rather than coincidentally co-located. The operator provisioned TLS for both through the same ACME pipeline, and the domain resolves directly to the IP.
The Beacon Protocol: Parameterized HTTPS Endpoints and Session Encoding
The implant's command-and-control communication pattern [T1071.001] is documented through two URLs observed on the primary C2 node:
neuralpulsecore5.sbs/doero?param=JXGWwd2Nmlp691SHhIISneuralpulsecore5.sbs/list?param=JXGWwd2Nmlp691SHhIIS
The two endpoints share an identical parameter value — JXGWwd2Nmlp691SHhIIS — across different URL paths. This pattern is consistent with a C2 protocol where the parameter encodes a victim or session identifier that the implant presents to the server on each contact, and the server returns different responses depending on the endpoint: /doero likely handles check-in or registration, while /list likely retrieves a task queue or command list. The parameter value itself has the character distribution of a base64-encoded or randomly generated session token, though its precise encoding is not established.
All C2 communication runs over HTTPS, with the TLS layer provided by the automated Let's Encrypt certificates described above. The use of HTTPS for C2 traffic is standard practice for evading network-level inspection, but the parameterized URL structure — rather than, say, POST body encoding or custom protocol framing — suggests the operator has chosen simplicity and reliability over protocol sophistication. A Python-based implant (consistent with the PyInstaller payload) would implement this pattern with a few lines of the requests library, making it easy to modify the endpoint paths or parameter names between campaigns without rebuilding the core implant logic.
The threat record categorises this collection as C2 servers, tagged as spyware with espionage motivation at severity 100 and confidence 85. The specific collection mechanism — what the implant exfiltrates once it has established C2 contact — is not directly observable. The primary payload's categorisation includes miner and dropper alongside trojan, which suggests the possibility of cryptocurrency harvesting or secondary payload staging as collection objectives, though current evidence is too thin to conclude. The operator's operational security posture — Iceland-privacy WHOIS, multi-jurisdictional hosting, automated certificate rotation — is consistent with an actor prioritising deniability and longevity over rapid monetisation, which in turn is more consistent with persistent espionage collection than opportunistic financial fraud.
Data Gaps and the 19 Unassessed Payloads
The campaign's indicator set lists 26 file SHA256 hashes, but only 7 have been assessed for type, detection, and tags. The remaining 19 file hashes — including entries such as 8feb81a85463230b9df6626e464fe8c143bc38eebb44fd072ffc9824b5cf41f6, 4f0aad3eedfdd088e6df1faf3f93a96a5ea064695d30a1db075535dec403101f, and e7a58bc8adc7cd2b9f26c155d17539e83dfce701b9e913394d09cab530018e59 — cannot be assessed from current evidence.
This gap is analytically significant. The .fptable build artifact — entropy 0.0, size 512 bytes — that fingerprints both assessed PE payloads to a shared builder template is a durable structural signature. If additional variants of these payloads exist among the 19 unassessed hashes, they would likely carry the same section artifact, making them identifiable through PE section analysis even without AV detection. The operator's use of a reusable builder template implies that additional variants are probable rather than merely possible.
The infrastructure confidence score for this campaign sits at medium (47/100). Five of seven files lack imphash data, making build-pipeline clustering unreliable beyond the .fptable structural match. Four of seven lack sandbox verdicts, meaning behavioural claims for those samples require hedging. All seven are unsigned, removing the code-signing attribution surface entirely. The two PE payloads with sandbox verdicts are the most analytically grounded samples in the set, and their consistent sandbox evasion despite meaningful static detection ratios is the most operationally significant finding.
The outlier status of 209.42.27.175 — the only IP in the set on AS 204800 (WHG Hosting Services Ltd), with a TLS subject (cpcontacts.abysat.com.br) entirely unrelated to the campaign domains — warrants a note of caution. This IP may be a compromised or multi-tenant shared hosting server rather than a dedicated operator-controlled node. If so, the operator's control over it may be less stable than their control over the dedicated ExpressHost VPS at 154.86.119.78, and it may be rotated or lost without affecting the primary C2 tier.
What This Campaign Signals About Evasion-First Espionage Infrastructure
The "Android Win Tool v1.9.6" campaign is not technically novel in any single dimension. SFX archive lures are a well-documented delivery mechanism. PyInstaller-packed Python payloads are common in commodity malware. Long-sleep sandbox evasion is a technique that has been observed for years. Let's Encrypt certificate automation is standard operational practice. What makes this campaign analytically interesting is the deliberate, layered assembly of these components into a system that is specifically calibrated against the detection stack most defenders rely on for automated triage.
The operator has made a clear calculation: sandbox evasion is more valuable than code-signing. A signed binary creates an attribution surface — the certificate serial number, the signing CA, the certificate-to-first-seen gap — that threat intelligence teams can pivot on. An unsigned binary that defeats sandbox analysis leaves defenders dependent on static signatures, and the 21–29/76 detection ratios suggest those signatures are not yet universally deployed. The YARA rule PyInstaller fires on the primary payload, and the Windows_API_Function rule fires on the batch launcher, but neither of these is a campaign-specific signature — they are generic indicators that will co-fire on thousands of unrelated samples.
The shared .fptable build artifact is the campaign's most durable fingerprint and the one most likely to enable prospective detection of additional variants. A PE section with entropy 0.0 and exactly 512 bytes is not a common compiler output; a YARA rule targeting this specific section name, size, and entropy combination would be narrow enough to avoid significant false-positive noise while catching any payload produced by the same builder template.
The infrastructure's multi-jurisdictional design — DNSPod nameservers for a Netherlands-hosted domain registered through a US registrar, Namecheap domains with Iceland-privacy WHOIS, AFRINIC-registered hosting with a Seychelles administrative contact — reflects an operator who understands that takedown requests and attribution efforts are jurisdictionally constrained. A request to Namecheap to suspend file-end.com does not affect neuralpulsecore5.sbs, which is registered through Dynadot. A request to ExpressHost to null-route 154.86.119.78 does not affect 209.42.27.175 on WHG Hosting. The operator has distributed their infrastructure across enough jurisdictions and providers that no single takedown action disrupts the full campaign.
The automated ACME certificate pipeline is the infrastructure's most mature characteristic. An operator who manually manages TLS certificates will eventually let one expire, creating a detection opportunity when the C2 domain goes dark or starts serving self-signed certificates. An operator running scripted ACME automation will maintain valid TLS across all nodes indefinitely, with 89-day rotation cycles that keep the certificate fingerprints fresh and limit the window during which a specific certificate serial can be used as a stable tracking pivot. The spread across three Let's Encrypt intermediates — R13, YR1, and E8 — within a seven-week provisioning window suggests the ACME client is configured to accept whatever intermediate Let's Encrypt assigns, rather than pinning to a specific issuer, which further limits the usefulness of issuer-based tracking.
The registrant company hash 4b7a0912c26a13e2 — shared across file-end.com and mayfiles.vip in Namecheap WHOIS records — is the single most actionable attribution pivot in the current dataset. It is a durable operator identity that will persist across domain rotations as long as the operator continues to use the same Namecheap account. Any new domain registered under this account identity, with Iceland registrant country and withheldforprivacy.com email cover, is a candidate for campaign infrastructure expansion. The operator's demonstrated preference for Namecheap as a registrar, combined with the .vip and .com TLD choices and the DNSPod nameserver pattern on the primary C2 domain, provides a registration fingerprint that warrants ongoing monitoring.
No named actor or group has been attributed to this campaign. No widely-reported prior campaign matches this specific cluster. The espionage motivation and spyware classification are established by the threat record at confidence 85, but the operator behind this infrastructure remains unattributed. What the evidence does establish is an operator with the technical sophistication to build and maintain a purpose-designed evasion-hardened collection platform — one that has invested more in infrastructure longevity and detection avoidance than in payload sophistication, and whose most durable fingerprints are structural rather than behavioural.