BRITTLE COMPASS

Note Source summary. My own static analysis of all three installers and lab execution of the second and third (reliability A; findings within each build checked by more than one method, credibility 2), plus public reporting from Acronis, ANY.RUN, BleepingComputer victims and Steam and Reddit users, graded individually under References. Grades and confidence terms are explained in How I rate things. The main gap: I can’t see who controls the infrastructure or how many people were hit.

What I observed #

Two things in that table are the core of this page. First, the version numbers on the site don’t match the builds. The app version column is the version field in each installer’s Electron package.json (the Windows file version agrees for the first two): “1.2.5” says 3.0.3 and “1.2.6” says 1.0.0, so the site’s numbering is presentation. Those values aren’t a release sequence either; three distinct implementations, three unrelated numbers. Second, a day after the first two were retrieved, the “1.2.6” download returned a different installer with a different payload, a different command-and-control design and a different kit. The page, the password and the download gate didn’t change. I use the site’s labels on this page because that’s what a victim saw; the build pages say which is which.

Key judgments #

1. Probably one operator. One operator running the site, the gate and all three builds is the best explanation (moderate confidence). The same delivery path also fits a shared lure, a distributor reselling access, or a handover, and I can’t see who controls the infrastructure. (What I observed, Alternatives)
2. Bought or licensed tooling. I assess with moderate confidence that the two Java payloads (1.2.6 and 2.0.0) come from commercial kits rather than from whoever runs the lure. I have no comparable evidence either way for the 1.2.5 build. The 1.2.6 build carries a licence identifier that its own exfiltration relay uses as a routing key, and a builder watermark stamped into third-party library classes; the 2.0.0 build authenticates to its panel with a customer-style licence key. That evidence supports the commercial-tooling assessment. A licence string or panel key alone doesn’t identify a supplier or prove a purchase. (How it changed)
3. More fake games coming. The cluster is likely (55–80%) to relaunch under a new fake game name. I hold that with low confidence, because the precedent comes from public reports of earlier lure names that I haven’t tied to these samples myself. (Who this is)
4. Turkish-speaking tooling, maybe. I assess with low confidence that the people building at least the 1.2.6 and 2.0.0 kits work in Turkish, based on Turkish command names, resource names and status strings. That’s language context, not attribution; a kit sold internationally would look the same.

Who this is #

There’s no established vendor name for this cluster, so BRITTLE COMPASS is my provisional tracking name. It names the delivery cluster, not the malware: one password-gated website, the download service behind it, and the builds delivered through them. The malware families already have names, and this cluster has used more than one.

The first activity I observed directly is 14 October 2026, when I retrieved the first two builds. Some of the infrastructure is older: the 1.2.6 build’s Discord bot account was created on 14 September, the 1.2.5 build’s Discord server on 15 September, and the lure domain was registered on 25 September. Those are creation dates. They show the pieces existed, not that the campaign was running then. Public records show an earlier lure, sikimoris[.]com, on GitHub Pages with the same site template from July 2026 ^[7]. That’s possible related activity, not established history.

The lure #

According to victim reports, it starts with a stranger on Discord who made a game and would really like you to try it ^{[3, 5, 6]}. The game has a website, a trailer and a download button. The download is password-protected, which sounds like a closed beta; keeping scanners and sandboxes out is a plausible second purpose.

The lure site was registered on 25 September 2026 and served from GitHub Pages. Its download form talks to a Cloudflare Worker, kanegrocerys.colemankathryn2692.workers[.]dev, in two JSON POSTs taken from the page’s own script: one checks the password, the other asks for the file.

POST hxxps://kanegrocerys.colemankathryn2692.workers[.]dev
  {"check": true, "password": "<password>"}                          -> {"ok": true}
  {"password": "<password>", "inviter": "<referrer>",
   "user": "<chosen name>", "version": "<build>"}                    -> {"downloadUrl": "<Dropbox link>"}

(formatted for readability)

The installers are 110–135 MB and contain no game at all. The form also sends a chosen name and a referrer along with the password, which fits tracking which recruiter brought in which victim; I can’t see what the Worker does with them.

How it changed #

The changes look like switching tooling rather than developing one tool. The first two builds were packaged on Electron versions about twenty months apart, with the later build on the older stack. The 1.2.6 build’s relay is keyed by a licence string, and its builder watermark (MicroFlow 4.0) is stamped into 3,108 of its 3,112 class files, third-party libraries included. The 2.0.0 build has neither; it authenticates to its panel with a key of the form PANEL-XXXX-XXXX-XXXX and tags every stolen-data archive “Palenkova”.

The 2.0.0 build’s command channel is a self-hosted panel, not Discord. Detection built only around the Discord bot traffic of 1.2.6 would miss it entirely.

What a victim loses #

Which build ran changes the answer, so each item says where it comes from:

• Browser data. Saved passwords, cookies, autofill and history from 20 to 45 browsers depending on the build (static, all three). Chrome’s App-Bound Encryption is targeted in all three builds by borrowing a SYSTEM token (static). Success depends on the browser and the build; a Firefox Primary Password defeats the 2.0.0 build’s Firefox decryption (static).
• Discord. Tokens from the client and browsers (all three). The 1.2.5 and 1.2.6 builds also modify the Discord desktop client to capture logins and TOTP setup secrets, and to block logout and session management (static); the 2.0.0 build modifies it to capture login, two-factor and billing flows (static). Victims report accounts taken over with the two-factor setting changed ^{[3, 5]} (reported). The modification lives in Discord’s own files and survives removal of the malware.
• Cryptocurrency wallets, if 1.2.5 or 2.0.0 ran. Both carry long lists of wallet targets (static); 2.0.0 took all 11 wallets planted in the lab, out of 100 configured targets. 1.2.6 has no wallet collector.
• Steam account data, if 2.0.0 ran and Steam was installed. It targets Steam login files and tokens (static); in the lab it collected the account name, and I haven’t seen the token theft work (lab).
• Files. 1.2.5 takes documents, keys and source code automatically (static). 1.2.6 automatically took only .txt files in the lab, and 2.0.0 took no loose documents automatically (lab), but both give the operator a shell that can retrieve files accessible under the payload’s privileges.
• The machine. 1.2.6 and 2.0.0 give the operator a remote shell, keylogging and screenshots (lab). 2.0.0 also makes the machine a SOCKS proxy for the operator and carries a flood module for attacking third parties (static).
• Files, encrypted, if the operator chose to run the ransomware command in 1.2.6 or 2.0.0 (static; neither runs on its own).

Alternatives, assumptions and what would change this #

• Alternative: several operators sharing one lure. Someone could be renting out the site and gate. Different licence identifiers or panel keys served through the same gate at the same time would support this.
• Alternative: one developer, not a customer. The builds could come from one person moving between toolchains. I don’t favor it: a licence-keyed relay, a customer-style panel key and a watermark stamped into unrelated libraries all fit kits sold to many customers. The same watermark or key format turning up only in this cluster’s samples would be weak support for it, unless the comparison covered a broad set of samples.
• Key assumption: the earlier lure names belong to the same cluster. If that’s wrong, the cluster’s directly observed history starts on 14 October 2026, and judgment 3 has no precedent behind it.
• What would change judgment 1: builds for independently controlled customers served through the current gate at the same time. A later build turning up behind a different gate wouldn’t; that’s a change of infrastructure, not of operator.

What to do #

If someone ran a “game” from one of these sites, in this order:

1. Isolate the machine. Take it off the network before doing anything on it, and keep it powered on if the operator may have encrypted files.
2. From a different, clean device, revoke sessions first, then change passwords: email, then Discord, then Google, then anything saved in the browser. A password change doesn’t reliably end existing sessions, so sign out every session with each provider’s own controls first.
3. Fix Discord from that clean device: sign out every session, change the password, remove and re-enroll two-factor so a new secret is issued, and regenerate backup codes. Don’t sign in to Discord on the infected machine again.
4. Move cryptocurrency to new wallets created on a clean device if the build was 1.2.5 or the 2.0.0 replacement.
5. Work out which build ran. Start from the leads on the build pages: %LOCALAPPDATA%\java\ and a scheduled task App_<username> point to 1.2.6; %LOCALAPPDATA%\emre\ and a Run value emre point to 2.0.0. Those are leads to investigate, not proof. Confirm with the installer or payload hashes. All three builds modify the Discord client, so a modified client alone doesn’t identify one, and a failed install or a cleanup attempt can remove the other artifacts.
6. Rebuild machines infected with either Java build (1.2.6 or 2.0.0). Both support remote commands and running additional payloads, so removing the original malware can’t establish that the machine is clean. That’s a response posture; whether the operator actually used the shell on a given machine is a separate question that only host or network evidence answers. For 1.2.5, for which no remote-shell capability was identified in the analyzed sample, removing the modified Discord client and the application is a reasonable minimum, but rebuilding is still safer.
7. Uninstall and reinstall Discord with its application data deleted, on the rebuilt or cleaned machine.

For organizations: hunt for Electron applications that ship a private Java runtime next to a JAR. That combination is unusual, and both of this cluster’s Java builds have it. Treat a hit as a lead and confirm it against hashes and process activity.

Infrastructure #

File hashes, host artifacts and detection rules are on the build pages: 1.2.5, 1.2.6, 2.0.0.

Related reporting, not linked to this cluster #

References #

1. Acronis Threat Research Unit, “Threat actors go gaming: Electron-based stealers in disguise”, July 2025. acronis.com (opens in a new tab) (B2: fake-game Electron stealers using similar packaging; a technique comparison, not this cluster)
2. ANY.RUN, “MicroStealer” malware trends page. any.run (opens in a new tab) (B2 for the family label; not a match to these samples)
3. BleepingComputer forums, “Stealer Ransomware Plugin-Dev7 Gang (.cryptedmicro) Support Topic” and related victim threads, May–October 2026. bleepingcomputer.com (opens in a new tab) (F3: unverified victim reports)
4. CYFIRMA, “Technical Analysis of Lucid Stealer: Execution, Capabilities, and C2 Infrastructure”, 10 August 2026. cyfirma.com (opens in a new tab) (B2)
5. Steam Community discussions warning about fake game copies used as lures, thread 1 (opens in a new tab) and thread 2 (opens in a new tab). (F3)
6. Reddit r/starcraft, “Warning: Discord scam targeting the SC2 community”. reddit.com (opens in a new tab) (F3)
7. PhishDestroy, historical record for sikimoris[.]com. phishdestroy.io (opens in a new tab) (C2)