Trojanised KMSAuto Delivers SmokeLoader via Three-Layer Evasion Stack
A fake Windows activation tool distributed through a crack-hosting site has been confirmed as the delivery vehicle for SmokeLoader. The infection chain relies on AutoIT compilation, aPLib decompression, UPX packing, and active sandbox-fingerprinting — an evasion investment inconsistent with opportunistic piracy-site distribution. CTX Team attributes the campaign to Smoky Spider, with Mongolia as the targeted region.
A Crack in the Activator: How a Trojanised KMSAuto Lure Delivers SmokeLoader Through a Three-Layer Evasion Stack
A trojanised Windows activation tool distributed through a software-piracy hosting path has been confirmed as the delivery vehicle for SmokeLoader, with the full infection chain relying on a deliberately engineered evasion stack — AutoIT compilation, aPLib decompression, UPX runtime packing, and active sandbox-fingerprinting — that goes well beyond what commodity pirated-software distributors typically invest in concealment. CTX Team has been tracking this cluster under threat ID CTXeek7x2h7hk, attributed to actor Smoky Spider and geo-tagged to Mongolia, with the campaign window running from first observation on 30 April 2024 through the most recent telemetry on 10 June 2026.
The delivery mechanism is disarmingly simple: a user in Mongolia seeking a free Windows activator downloads what presents as "Windows Loader.exe" from a crack-hosting site. The file's recorded distribution path — 3rsload.net.Windows.Loader.v2.2.2/Windows Loader.exe — is embedded verbatim in the sample's alt-name metadata, placing initial access squarely on a software-piracy hosting site rather than any actor-controlled infrastructure [T1059]. What makes this campaign analytically interesting is not the lure itself but the evasion architecture layered beneath it: the operators invested in a multi-stage obfuscation chain that is inconsistent with purely opportunistic pirated-software distribution and points toward a deliberate collection objective.
The indicator set for this cluster is small — three file hashes — and carries significant caveats that the analysis below addresses directly. One of the three files is entirely uncharacterised; a second carries a decade-long VirusTotal history that complicates campaign attribution. The strongest evidence concentrates in a single dropper sample, and the analytical conclusions drawn here reflect that ceiling.
The Lure Stage: Trojanised Activator as Voluntary Execution Vector
The initial-access mechanism requires no exploitation, no spear-phishing attachment, and no drive-by delivery infrastructure. The operator's bet is simpler: a user seeking pirated Windows activation software will voluntarily execute whatever file a crack-hosting site presents as the tool they want.
The KMSAuto sample (sha256 2f2aba1e074f5f4baa08b524875461889f8f04d4ffc43972ac212e286022ab94) carries a meaningful name of "Windows Loader.exe" and popular names including keygen, kmsauto, and winactivator — the exact vocabulary a user would expect from a Windows activation bypass tool [T1204.002]. Its alt-names record the full distribution path: C:\Users\user\AppData\Local\Temp\hsvcfw2p.d0l\3rsload.net.Windows.Loader.v2.2.2\Windows Loader.exe, which traces the file to a crack-hosting site operating under the 3rsload.net domain. The path structure — a temporary directory containing a folder named after the hosting site and the tool version — is consistent with a packaged archive downloaded from a piracy site and extracted by the user before execution.
The dropper sample (sha256 4b421d1ad37a767bf593ff539892aad26d8e78385ee138f170beb66f501786f7) presents under the threat label trojan.strictor/keygen with popular names strictor, keygen, and crck, and its meaningful name is recorded as d2ee58df046da09f8c0cc57d57e4d76f.virus — a hash-derived filename that suggests it was submitted to VirusTotal from a malware-analysis context rather than from a live user system. First seen on 13 May 2022 with a single submission from a single source, this sample has a narrow and clean submission profile that reduces noise and makes it the stronger of the two indicators for campaign analysis.
The pairing of these two files under a single campaign cluster suggests a staged delivery model: the KMSAuto loader presents the activator interface to the user while the AutoIT dropper carries the actual payload. Whether the two files are co-delivered in the same archive or whether the KMSAuto component drops or downloads the AutoIT dropper as a second stage is not directly observable — without C2 or staging infrastructure, the handoff mechanism between the two components cannot be confirmed.
Both files are unsigned Win32 PE32 executables in the 3–4 MB range. Neither carries a code-signing certificate, which rules out any certificate-based infrastructure fingerprinting and means any supply-chain framing for this campaign requires an explicit caveat. The absence of signing is itself a minor signal: operators who invest as heavily in runtime evasion as this cluster demonstrates sometimes forgo code-signing precisely because the evasion stack is expected to carry the load against static and dynamic analysis.
The Evasion Stack: Three Obfuscation Layers Before the Payload Fires
The most analytically significant aspect of this campaign is the depth of the evasion architecture. Across both samples, CTX Team identified three distinct obfuscation mechanisms operating at different layers of the execution chain, plus a fourth capability — active environment-fingerprinting — that runs as a pre-execution gate before any malicious activity proceeds.
UPX runtime packing on the loader. The KMSAuto sample's PE magic field reads "PE32 executable (GUI) Intel 80386, for MS Windows, UPX compressed" — the runtime packer is declared in the file header itself. Its PE section layout confirms the structure: a UPX0 section at zero entropy (the decompression stub placeholder) and a UPX1 section carrying entropy 8.0 across 591,360 bytes — maximum-entropy content consistent with a fully packed payload. Packers PEiD and F-PROT are recorded in the build provenance. The YARA rule UPX (authored by kevoreilly, sourced from the CAPEv2 repository) fires twice on this sample, confirming runtime unpacking as the primary static-analysis evasion layer [T1027.002]. On top of the packing, the susp_b64_enc YARA rule (authored by RussianPanda) also fires twice, indicating base64-encoded content embedded within the packed binary — a second layer of encoding that would survive a naive UPX unpack without further decoding.
AutoIT compilation and aPLib decompression on the dropper. The dropper sample takes a different approach. The YARA rule AutoIT_Compiled (authored by @bartblaze, sourced from the bartblaze/Yara-rules repository) fires on sha256 4b421d…, identifying the executable as a compiled AutoIT script — a legitimate Windows scripting language whose compiled output is a standalone executable that embeds the interpreter and script together. AutoIT compilation is a well-established technique for wrapping malicious payloads in a benign-looking executable format, and the compiled binary's behaviour is not directly readable from static analysis of the PE structure alone.
The second YARA hit on this sample is aPLib_decompression (authored by @r3c0nst, sourced from the fboldewin/YARA-rules repository), which detects aPLib decompression code — a compression library not commonly associated with commodity malware builders. The combination of AutoIT compilation as the outer wrapper and aPLib as the inner decompression mechanism is a deliberate pairing: the AutoIT script, when executed, calls the aPLib decompression routine to unpack the second-stage payload from the binary's resource section at runtime.
The resource section tells the story in numbers: the .rsrc section of sha256 4b421d… is 2,356,224 bytes in size — 2.25 MB — and carries entropy 8.0, the maximum value on the Shannon entropy scale. A 2.25 MB resource section at maximum entropy in a 3,103 KB file means that roughly 76% of the file's total size is a compressed or encrypted payload sitting in the resources, waiting to be decompressed at runtime. The .text section, by contrast, registers entropy 6.68 across 581,120 bytes — elevated but not maximum, consistent with compiled code rather than packed payload. The imphash for this sample is bd3825b6e0410966f0c31f64b6c7644a, and the vhash is 036056655d15756210b02002300a46z161d013zf2za0030e039z.
The C2AE sandbox verdict for sha256 4b421d… is unambiguous: malicious, with named families SmokeLoader and Zenpack. This is the only sandbox verdict available for this sample (1/1 sandboxes returning malicious), and it provides the direct link between the AutoIT/aPLib dropper and the SmokeLoader payload family. The execution flow the evidence supports is: AutoIT-compiled executable launches → aPLib decompression routine unpacks the 2.25 MB .rsrc payload → SmokeLoader is executed in memory [T1059.003].
The sandbox-evasion gate. Before any of the above executes maliciously, both samples apply active environment-fingerprinting to determine whether they are running in an automated analysis environment. The YARA rule sandboxdetect_misc (authored by AlienVault Labs, sourced from the AlienVault-Labs/AlienVaultLabs repository) fires on both sha256 4b421d… and 2f2aba… — the only YARA rule that co-fires across both distinct samples in this cluster, and the binding axis across the cluster at a cohort size of 3 (with the KMSAuto SHA256 appearing twice due to duplicate rule firings within that sample).
The KMSAuto sample's behavioural tags make the fingerprinting capabilities explicit: detect-debug-environment, checks-bios, direct-cpu-clock-access, long-sleeps, idle, checks-disk-space, calls-wmi, and checks-user-input. These tags map directly to the MITRE sub-technique set listed in the campaign's threat metadata: T1497.001 (System Checks — the BIOS and disk-space queries), T1497.002 (User Activity Based Checks — the user-input monitoring), and T1497.003 (Time Based Evasion — the long-sleep and direct CPU clock access). The via-tor tag on the KMSAuto sample additionally suggests Tor-routed network activity, though without confirmed C2 infrastructure, the specific routing cannot be confirmed.
The OS X Sandbox verdict for the KMSAuto sample returns the classification "EVADER" — a sandbox-specific label that directly confirms the evasion-detection behaviour rather than simply inferring it from YARA hits. Dr.Web vxCube returns malicious; Zenbox returns harmless; C2AE returns undetected. The 2/4 split sandbox verdict is consistent with a sample whose evasion logic successfully defeats some automated analysis environments while failing in others.
The layering is deliberate and graduated: static analysis is addressed by UPX packing and base64 encoding (loader) and AutoIT compilation with aPLib decompression (dropper); dynamic analysis is addressed by the environment-fingerprinting gate that checks BIOS strings, CPU clock behaviour, disk space, and user activity before proceeding. An analyst running either sample in a standard sandbox may see nothing malicious if the fingerprinting checks fail — which is precisely the operational value of investing in this stack.
Detection Landscape: Where the Engines Stand and What They Miss
The detection picture across both samples is moderately strong in aggregate but reveals meaningful gaps at the individual engine level that are worth examining.
The dropper (sha256 4b421d…) achieves a detection ratio of 49/77 engines flagging malicious, with 24 undetected and 4 returning type-unsupported. The flagging engines include a broad cross-section of the major AV ecosystem. Twenty engines still miss this sample entirely, including Alibaba, Avast-Mobile, Baidu, SentinelOne, Trapmine, and Webroot — a mix of regional engines and some endpoint-focused products that might be expected to catch a sample with this detection profile. The community vote for this sample is 0 harmless / 0 malicious, and its reputation score is 0 — it has not accumulated the community signal that would assist reputation-based blocking, consistent with its single-submission, single-source profile and its relatively recent first-seen date of 13 May 2022.
The KMSAuto sample (sha256 2f2aba…) presents a more complicated picture. At 45/76, its detection ratio is slightly lower than the dropper's, and 20 engines miss it — including AVG, Avira, F-Secure, DrWeb, and Avast, which flag the dropper but not the loader. More significantly, the community vote for the KMSAuto sample is 302 malicious against 1,102 harmless, with a reputation score of +1000. This is a heavily net-positive community reputation for a file that 45 engines flag as malicious — a direct reflection of its decade-long history as a widely distributed Windows activation tool that many users have submitted and voted harmless.
The KMSAuto sample was first seen on 3 April 2014 and has accumulated 10,815 submissions from 3,735 unique sources across a span of more than twelve years. Its last-seen date in the telemetry is 10 June 2026. This submission profile is categorically different from the dropper's single-submission, single-source profile, and it is the primary reason CTX Team treats this sample as an outlier within the cluster. A file with this submission history and community reputation could plausibly be present in a campaign dataset as an incidental co-submission — a user who downloaded the real KMSAuto tool alongside the trojanised dropper, or a researcher who submitted both files together from a piracy-site analysis. The analyst's outlier assessment is direct: the KMSAuto sample is "an unusually long-lived, widely distributed PUA/hacktool that predates the campaign window by nearly a decade and carries a split community verdict, making its role as a campaign component ambiguous."
The sandboxdetect_misc YARA co-fire across both samples is the strongest argument for treating the KMSAuto file as a genuine campaign component rather than an incidental submission — the sandbox-evasion logic is present in both files, and its presence in a decade-old activator tool is not self-explanatory. But this single shared YARA axis is not sufficient to resolve the ambiguity, and the overall confidence assessment for this cluster reflects that ceiling.
The third file in the indicator catalog — sha256 6f5afec574510cb154c1ca98aa28bd8e51dd0934cc3b6ef3bf75020c4730f06a — is entirely uncharacterised. It cannot be placed in any cluster, chain stage, or analytical frame, which limits the completeness of any toolchain assessment for this campaign.
SmokeLoader: The Payload and Its Attributed Capability Profile
The C2AE sandbox verdict naming SmokeLoader as the delivered payload for sha256 4b421d… connects this campaign to a well-documented modular loader family attributed in the threat feed to actor Smoky Spider. The MITRE technique set listed in the campaign's threat metadata — T1055.011 (Extra Window Memory Injection), T1057 (Process Discovery), T1082 (System Information Discovery), T1112 (Modify Registry), T1113 (Screen Capture), T1485 (Data Destruction), T1559.002 (Dynamic Data Exchange), T1562.001 (Disable or Modify Tools), T1564.004 (NTFS File Attributes), and T1622 (Debugger Evasion) — is consistent with SmokeLoader's documented capability profile as a multi-stage loader that conducts host reconnaissance, modifies registry keys for persistence [T1112], and can deliver additional payloads through process injection [T1055.011].
It is important to be precise about what the evidence directly supports versus what is inferred from family attribution. The C2AE sandbox verdict provides direct evidence that the AutoIT/aPLib dropper delivers SmokeLoader. The MITRE technique set in the threat metadata is attributed to the campaign as a whole, and its consistency with SmokeLoader's known behaviour is an inference from family attribution rather than from direct behavioural log evidence in the sandbox outputs. No direct sandbox behavioural evidence for screen capture [T1113], registry modification [T1112], or process injection [T1055.011] is visible in the per-sample sandbox outputs — these are attributed by implication from the named family, not from observed sandbox events.
The second named family in the C2AE verdict — Zenpack — appears alongside SmokeLoader in the malware classification output. Zenpack is associated with a packing or protection layer rather than a distinct payload family in some classification frameworks, which would be consistent with the AutoIT/aPLib dropper's role as a packing and decompression wrapper for the SmokeLoader core. The relationship between the two named families in the verdict is not further characterised.
The command-and-control layer for this campaign is entirely unobserved. The via-tor tag on the KMSAuto sample suggests that Tor routing may be involved in network communications, but without a confirmed C2 address or protocol capture, this remains a behavioural tag rather than a confirmed infrastructure observation. The unobserved C2 layer is the most significant gap for follow-on detection and attribution work — SmokeLoader's injection and payload-delivery capabilities are only operationally meaningful if the C2 channel through which additional payloads are fetched can be identified and monitored.
The application window discovery technique [T1010] and query registry technique [T1012] listed in the threat metadata are consistent with SmokeLoader's host-enumeration behaviour — gathering information about running processes [T1057] and installed software to shape follow-on payload delivery decisions. The indicator removal techniques [T1070, T1070.004, T1070.006] suggest the operator is concerned with forensic persistence on compromised hosts, consistent with a collection objective that requires sustained access rather than a smash-and-grab financial operation.
Actor Context and the Mongolia Targeting Tag
The threat feed attributes this campaign to Smoky Spider with espionage listed as the stated motivation and Mongolia as the targeted region. The attribution confidence is recorded at 85, and CTX Team's overall cluster confidence is assessed as low (score 17) given the small indicator set and the gaps described above — the attribution to Smoky Spider and the SmokeLoader family is grounded in the sandbox verdict and threat metadata, but the broader campaign picture is incomplete.
The combination of an espionage motivation tag and a geographically specific Mongolia targeting tag is analytically notable against the backdrop of a crack-hosting delivery mechanism. Software-piracy lures are typically associated with financially motivated campaigns — ransomware precursors, credential stealers, cryptocurrency miners — where the operator benefits from broad, indiscriminate infection. An espionage motivation with a specific geographic focus suggests a different operational model: the crack-hosting delivery casts a wide net across Mongolian users seeking pirated Windows activation tools, and the SmokeLoader payload — with its host-enumeration and additional-payload-delivery capabilities — allows the operator to filter for targets of interest post-infection and deliver targeted follow-on implants only to systems that meet collection criteria.
This inference — that the geographic focus reflects post-compromise filtering rather than pre-selected targeting — is consistent with the delivery mechanism but is not directly evidenced. The confidence on this analytical read is low, and it should be treated as a hypothesis that follow-on infrastructure visibility could confirm or refute. No widely-reported prior campaign with confident attribution to Smoky Spider operating this specific delivery model in Mongolia comes to mind from the available evidence, and no documented operational arc for this cluster has been established — meaning the current cluster cannot be placed in a known campaign sequence with confidence.
Evidence Ceiling and What Remains Unanswered
This campaign cluster sits at the intersection of two analytical tensions that are worth naming directly, because they affect how the findings should be weighted by practitioners consuming this intelligence.
The first tension is between the evasion sophistication and the indicator sparsity. The obfuscation stack — AutoIT compilation, aPLib decompression, UPX packing, base64 encoding, and active sandbox-fingerprinting across both samples — represents a level of investment in detection evasion that is inconsistent with purely opportunistic pirated-software distribution. Operators who build this kind of layered evasion architecture are typically trying to protect a payload that has operational value beyond a single infection wave. Yet the indicator set for this campaign contains only three file hashes, two of which resist confident characterisation. The evasion investment is visible; the operational infrastructure it protects is not.
The second tension is between the KMSAuto sample's decade-long history and its presence in a campaign cluster attributed to a specific actor with a specific geographic focus. The sandboxdetect_misc YARA co-fire is the binding axis, and it is a genuine shared signal — but a single YARA rule hit connecting a 2014-vintage activator tool to a 2022-vintage dropper is a thin thread. The KMSAuto sample's 10,815 submissions from 3,735 unique sources, its +1000 community reputation, and its 1,102 harmless votes against 302 malicious votes all point toward a file that has circulated widely as a legitimate (if legally questionable) tool. Its role as a deliberate campaign component rather than an incidental co-submission cannot be confirmed, and the analysis above treats it accordingly.
What the evidence establishes with confidence is the dropper's capability profile: sha256 4b421d… is a confirmed AutoIT-compiled dropper with an aPLib decompression stub, a 2.25 MB maximum-entropy resource section, a confirmed SmokeLoader sandbox verdict, and three YARA rule hits (AutoIT_Compiled, aPLib_decompression, sandboxdetect_misc) that collectively characterise its build pattern and evasion logic. This single sample is the analytical anchor for the campaign, and it is strong enough to support the tradecraft conclusions drawn here even as the broader cluster picture remains incomplete.
The uncharacterised third file (sha256 6f5afec…) represents the most significant unknown in the toolchain. An uncharacterised file that appears alongside a confirmed SmokeLoader dropper in a campaign cluster could be anything from a second-stage payload to a persistence component to an unrelated file that was incorrectly associated with the cluster. Until it can be characterised, the full scope of the toolchain is not visible.
What This Evasion Investment Signals About the Operator's Posture
The analytical takeaway from this campaign is not primarily about SmokeLoader — a well-documented family with a long operational history — but about the evasion architecture the operator chose to wrap around it. The combination of AutoIT compilation, aPLib decompression, UPX runtime packing, base64 encoding, and active sandbox-fingerprinting across both the loader and dropper stages reflects a deliberate, layered approach to defeating both static and dynamic analysis that exceeds what is typical for commodity pirated-software distribution.
aPLib is the detail that stands out most. UPX packing and AutoIT compilation are common enough in the pirated-software ecosystem that their presence alone would not be analytically significant. But aPLib — a compression library with roots in the demoscene, not in mainstream malware toolkits — is a less common choice that suggests either a specific builder template or a deliberate selection for its lower detection profile relative to more commonly flagged compression libraries. The aPLib_decompression YARA rule (authored by @r3c0nst) was specifically written to detect this decompression code in malware contexts, which implies the technique has been observed in malicious use often enough to warrant a dedicated detection rule — but not so commonly that it is caught by generic packing detectors.
The sandbox-evasion logic is the other signal worth examining in terms of operational intent. Checking BIOS strings, monitoring CPU clock behaviour, querying disk space, and watching for user input are not techniques that a financially motivated operator distributing ransomware or a cryptocurrency miner through a crack site needs to invest in — those campaigns benefit from high infection volume and do not require the payload to survive sandbox analysis. An operator who invests in this level of environment-fingerprinting is protecting a payload that needs to execute only on real targets, not in analysis environments. That operational posture is more consistent with a collection objective — where a false positive in a sandbox could expose the campaign before it reaches its intended targets — than with a volume-based financial operation.
The espionage motivation tag and Mongolia geographic focus, taken together with the evasion investment, suggest an operator who is using the crack-hosting delivery vector as a cost-effective initial-access mechanism while relying on SmokeLoader's post-infection enumeration capabilities to identify and selectively service targets of intelligence value. The delivery surface is broad and opportunistic; the payload capability is modular and selective. That combination — wide-net delivery with targeted follow-on — is a pattern that makes the absence of C2 infrastructure visibility particularly consequential. Until the command-and-control layer for this campaign becomes observable, the full scope of what the operator is collecting from Mongolian systems that pass the fingerprinting gate remains unknown.