Fake KMSPico Activator Cluster Traces to Adware Builder, Not APT10

A Fake Windows-Activator Lure Wrapped in a Reused Builder

A trojanized copy of KMSPico — the pirated-software crowd's favorite "free" Windows and Office activation tool — is the lure carrying an entire adware-bundler cluster: six installers and a companion batch script, all packaged inside Nullsoft Installer (NSIS) self-extracting archives and all first seen within a roughly nine-month window spanning April 2015 to January 2016. Two of the installers share an identical import-table hash, an identical PE build timestamp, and an identical rich-header fingerprint. Two others, branded under different adware family names, share the exact same purchased code-signing certificate. A fifth trips the same crowdsourced YARA rule as the first despite carrying a completely different threat label. None of that is subtle sandbox evasion or custom implant engineering — it is the fingerprint of a commodity installer-builder-as-a-service operation, reused and redistributed rather than freshly engineered for each release.

The lure itself follows a familiar shape: a user searching for a way to bypass Windows or Office licensing downloads what presents itself as "KMSPico 10.0.6" or "KMSPico 10.0.9," runs it voluntarily, and the NSIS wrapper drops and executes a secondary payload from disk [T1204.002]. That single design choice — hide the payload behind a tool people are actively searching for and willing to run past their own better judgment — buys the operators a delivery channel that needs no exploit, no phishing infrastructure, and no privilege escalation. It costs them nothing in sophistication, but it also caps what the payload can plausibly do: this is a chain built to monetize installs, not to establish quiet, long-term footholds inside a target network.

From inside a target environment, this chain would rarely trigger a SOC alert on its own. A user-initiated download of a self-extracting archive, followed by that archive dropping and running a bundled executable, looks structurally identical to thousands of legitimate installer flows a helpdesk sees every week. What makes it visible after the fact is exactly what shows up across these seven files: multi-engine antivirus consensus that climbs into the high fifties and sixties out of roughly 75 vendors, and sandbox verdicts that return unambiguous malicious classifications once the sample is actually detonated rather than merely observed at the download stage.

One Build Pipeline, Two Installers

The clearest piece of hard evidence in this cluster is a build-lineage match between two files carrying the same lure branding. A KMSPico 10.0.6 installer (081ab0d9…f018) and a size-variant twin bundled under a "revenyou" subfolder (48c686077…f19d) share the identical import hash 7fa974366048f9c551ef45714595665e, the identical rich-header hash 81c790eab65ff0be64a9029444dd0f7f, and the identical PE compile timestamp of 2009-12-05 — a stale build date relative to either file's actual appearance, consistent with a reused compiler artifact rather than a fresh build for each release. The two files were first seen roughly seven months apart, on 2015-04-25 and 2015-11-30 respectively, and differ in size (694 KB versus 339 KB) and in packaging details — the earlier file carries two Sigma rule matches at medium and low severity, the later one trips the crowdsourced YARA rule "NSIS" and four low-severity IDS signatures tied to ICMP probing behavior.

That combination is worth sitting with. A shared import table and rich header describe the same compiler environment and the same set of statically linked functions; a shared, out-of-date PE timestamp describes an artifact that traveled with the builder rather than being regenerated each time. Read together, they support an inference the individual facts alone don't: the operators were not writing new code for each KMSPico-branded release across 2015 — they were re-running a builder against a template and shipping the output under cosmetically different folder names and file sizes. That is a lower-effort operating model than maintaining bespoke tooling, and it explains why the two payloads, despite arriving seven months apart, still register as functionally identical at the binary level.

Both files also carry a matching behavioral signal that reinforces the build-lineage read: two independent sandboxes — Tencent HABO and Dr.Web vxCube — return a malicious verdict on both, a 2-for-2 consensus that leaves little ambiguity about what either binary does once executed, whatever ambiguity remains about who built it. Detection sits at 60 of 75 engines on the first file and 56 of 73 on the second, both comfortably majority-flagged, though a double-digit number of engines — including a scattering of mobile-focused and regional vendors — miss both samples outright. That gap between "most engines agree" and "not all engines agree" is itself informative: it describes a family well enough characterized to be broadly caught by heuristic and signature-based detection, but not novel or targeted enough to draw universal recognition.

A Purchased Certificate Reused Across Adware Families

The defense-evasion layer of this cluster runs through a single purchased code-signing identity: a certificate issued to "Great ApPs TlD," chained through thawte's SHA256 Code Signing CA to a valid thawte root, carrying serial number 34 C5 B2 3C D2 01 3A F3 CA 72 DE 68 56 63 EB DB [T1553.002]. That exact certificate — same signer name, same serial, same issuing chain — appears on two files that VirusTotal labels as two different adware families: the KMSPico-branded installer already discussed (081ab0d9…f018, labeled adware.outbrowse/bundler) and a second payload dropped to %TEMP%\beeiifgbea.exe (4741708405…318d2, labeled adware.outbrowse/mikey and separately flagged under the popular name browsefox). Both files were first seen on the same date, 2015-11-30. Both verdicts fail signature validation for the identical reason: the certificate is not within its validity period relative to the verification clock, even though the chain itself resolves to a trusted thawte root.

The certificate's own validity window was 2015-11-16 through 2016-01-27 — a roughly ten-week lifespan. That window matters for reading the timeline correctly: on the date both signed files first surfaced, November 30, 2015, the certificate was fully live, not expired: the payloads were signed with a code-signing identity that was, at the moment of signing, still inside its stated validity period. It only fails present-day verification because that ten-week window has long since closed relative to any check performed after January 27, 2016. What the two files demonstrate, then, is not an operator using an already-dead certificate to lend false legitimacy — it's a purchased signing identity being shared across two differently monetized payloads on the same day, before that identity's clock ran out. That is a distinct and more interesting fact than certificate misuse after the fact: it points toward one signing resource being distributed to, or shared between, more than one adware-affiliate payload during the narrow window it was usable.

Buying a code-signing certificate costs money and requires some minimal identity verification with the issuing CA — a real (if thin) barrier that self-signing skips entirely. That the operators cleared that barrier once and then stretched the resulting identity across two differently branded outputs on the same day suggests the certificate was treated as reusable infrastructure rather than a one-time cost of doing business for a single payload. The most defensible read of the file-level evidence is build-and-signing reuse across a short, deliberate window, not a long-running campaign stretching the same purchased identity across years — the certificate itself only had ten weeks to give.

A Second Builder, a Cruder Signature Enters the Chain

Roughly five weeks after those two thawte-chained payloads shipped — and about three weeks before that certificate's own validity window lapsed — a different signing practice shows up in the same lure family. An installer named inst.exe (50b48a1f…dca1a), carrying alternate names spanning "KMSPico10.0.9," "WindowsLoader2.4," and an unrelated webcam-driver downloader string, surfaced on 2016-01-04 signed with a self-issued certificate under the name "www.nosite.site" — a certificate whose issuer and subject are the same entity, terminating in a root that no trust provider recognizes. That signing date, 06:23 AM on 2016-01-04, is recorded directly on the file. The same day produced a companion batch script, installkms.bat, a bare DOS text file with zero of 54 engines flagging it and no import hash or signature data of its own — the kind of lightweight launcher that typically rides alongside a heavier payload rather than serving as one.

The shift matters less as a timeline curiosity than as evidence of a second, cruder actor or builder touching the same lure brand. Buying a CA-chained certificate from thawte and paying to keep it valid is a meaningfully different operational posture than self-signing a certificate that terminates in an untrusted root — the latter buys nothing in the way of trust from a verifying system and exists mainly to satisfy an installer's own internal signature check rather than to pass Windows' trust chain. That inst.exe also carries an unusually high-entropy resource section (7.86, versus 6.6 in its own code section) is consistent with a packed or compressed secondary payload riding inside the resource table rather than the executable body — a packaging choice distinct from anything seen in the thawte-signed pair. Detection still lands at 56 of 73 engines, comparable to the earlier files, which tells a useful negative: whatever separates this installer's build and signing practice from the Great ApPs TlD cluster, it did not buy it materially better evasion against multi-engine detection.

A third variant, marketed openly as "KMSPico 10.0.9.exe" (05784a67…3d86), also surfaced on 2016-01-04 — the same day as the self-signed installer and the batch script — but carries a completely different import hash, a different rich-header fingerprint, and a Gentee-packed high-entropy section (7.98) rather than NSIS-native packaging. What ties it back to the rest of the cluster is not build lineage but a shared crowdsourced YARA rule, "NSIS," also present on the first KMSPico installer discussed above — a packaging-level match spanning two files that VirusTotal assigns to entirely different adware families (outbrowse/bundler versus amonetize/outbrowse). A shared packaging fingerprint across unrelated family labels is the kind of evidence that argues for a common installer-builder-as-a-service tool circulating among multiple adware affiliates, rather than one actor's proprietary codebase reappearing under different aliases.

Weak, Disconnected Infrastructure

The network layer of this cluster is thin, and it does not connect cleanly to anything in the file evidence above. A single domain, download-way.com, registered through GANDI SAS on 2015-08-26 — several months before the certificate-signed pair surfaced — carries a flag indicating signs of command-and-control-style traffic, yet returns zero detections across 89 engines. Its own WHOIS record shows a clientHold status alongside a redemptionPeriod flag and an update timestamp of October 2016, and the domain no longer resolves. Nothing in the record ties it by shared registrar, shared name server, shared certificate, or shared resolution history to any of the seven files or to the one IP address also present in this set. Its operational window at least overlaps the file cluster's active period, which is a coincidence worth noting rather than a link worth asserting — no shared technical axis binds the domain to the payloads beyond that rough contemporaneity.

The one IP address, 104.156.230.210, sits on AS 20473 (The Constant Company, LLC — the autonomous system associated with Vultr's hosting fabric) and returns zero of 89 detections. Its only associated TLS certificate, issued through Let's Encrypt under the intermediate "YR1" for the subject "bluebloom.org," carries a validity window of 2026-07-31 through 2026-10-29 — a full decade removed from the 2015-2016 file cluster it otherwise sits alongside in this record. That gap is large enough that the certificate almost certainly describes an unrelated later use of the same address rather than any infrastructure the KMSPico-branded payloads actually reached out to; IP addresses recycle between wholly unconnected tenants on shared hosting providers as a matter of course, and nothing here indicates this address was contemporaneous with the file activity. Taken together, the domain and the IP describe two isolated, low-confidence infrastructure notes rather than a coherent hosting backbone: whatever this cluster's operators used for distribution or callback in 2015 and 2016, neither surviving indicator here documents it with any real specificity, and the meaningful cohesion in this material sits entirely at the file layer — the shared build lineage, the shared certificate, the shared packaging signature — rather than in domains or IP infrastructure.

An Espionage Label That Doesn't Fit the Evidence

Feed metadata attributes this cluster to Red Apollo — tracked elsewhere under aliases including APT10, menuPass, and Stone Panda — tagged to Japan and coded as espionage-motivated. Nothing among the seven files matches that profile: threat labels read outbrowse, amonetize, and browsefox across the board, sandbox verdicts return generic adware/bundler classifications rather than anything resembling an espionage implant, and no observed sample carries a secondary payload beyond the bundled browser-hijacking and ad-injection components already described. The observed evidence — a reused NSIS builder, a purchased-then-shared code-signing certificate, a cross-family packaging fingerprint — is more consistent with commodity adware bundling distributed through a builder-as-a-service model than with the espionage tradecraft the label implies. Whether that mismatch reflects an actual historical link this evidence simply doesn't surface, or a stale and mislabeled attribution carried forward from an unrelated intake, isn't something the available indicators settle either way — but the build-lineage and certificate-reuse findings here carry substantially more forward-looking analytic value than the attribution does.

What This Cluster Actually Demonstrates

Set the actor label aside and what remains is a fairly legible picture of how low-effort monetization tooling gets built and distributed. A single builder produced at least two binaries seven months apart without meaningful code changes; a single signing identity, purchased and valid for roughly ten weeks, was stretched across two differently branded payloads on the same day; a packaging fingerprint tied to NSIS installer generation shows up across payloads that antivirus engines classify as unrelated families. None of that required custom malware development, privilege escalation, or persistence engineering — the entire chain runs on a user's willingness to download and execute a tool promising something for free [T1204.002], with detection evasion resting on volume and certificate churn rather than technical sophistication.

That combination — reused builders, short-lived purchased certificates, and packaging tools shared across nominally separate "families" — describes an ecosystem where the adware-affiliate economics reward speed and reuse over engineering investment. A ten-week certificate gets exactly enough mileage to cover a signing window and gets discarded once it lapses; a builder gets reused across months of output because rebuilding from scratch adds cost without adding evasion value against detection engines that are already flagging the family at majority consensus regardless. For defenders and analysts triaging file sets that arrive with high-confidence actor labels attached, the more durable signal is rarely the label itself — it's whether the build lineage, the signing chain, and the packaging fingerprint actually resemble the tradecraft the label claims. Here, across every axis with real evidentiary weight, they don't.