NIKKE confirms PC launcher tampering; client fix does not clean infected PCs

The November 3 original analysis reports four altered JavaScript files on Level Infinite’s official CDN loading an external script, which used the PC launcher’s embedded Chromium bridge to download a LuaJIT remote-access agent. The researcher analyzed one affected machine and static payload code, and labels additional users’ observations as reported evidence. Commands could read files, execute programs and capture screenshots; the analysis also identifies browser/credential theft capabilities and a Windows Chrome persistence path. Capability is not proof that every secret was stolen. No victim total or confirmed aggregate wallet loss is established.

The operator’s readable official excerpt acknowledges possible third-party script tampering and dates a client fix to November 4 around 02:30 UTC+9 (November 3 17:30 UTC). The researcher still observed a modified FeedList script on two CDN nodes at November 3 22:26 UTC. WormW subsequently reports that all four known official assets returned clean bodies during its November 4 07:14–07:20 UTC recheck, including both canonical and cache-busting FeedList requests. It cannot fully distinguish origin from intermediate cache state. These statements concern different layers: client updates, origin cleanup, CDN caches and already infected hosts. Do not treat the notice as proof that every cached copy or infected machine is clean. Earlier verification could read only an initial-notice excerpt; the full follow-up and manual guidance have now been read, as detailed below.

The report corrects earlier advice: the PlatformExperienceHelper parent is legitimate Chrome content, and onominan.tmp is not an infection marker. The attacker’s initial CDN/publishing access remains unknown. The cited research did not analyze mobile clients; the later vendor manual explicitly says mobile was unaffected. L3 reflects a widely used launcher and documented malicious distribution, while the operator now confirms file tampering and full execution/victim scope is still unresolved.

November 4 original-research update: MotherSphere now reports all four known files clean on four checked CDN nodes for both hosts at 11:20 UTC, while a checked public scan still received modified FeedList at 00:48 UTC. Its observed nodes took clean copies between 03:12 and 03:21 UTC. These observations extend, rather than invalidate, the earlier WormW recheck above; they do not prove a global purge. Preserve logs and cached Local Storage before clearing the documented launcher cache, including compressed .ldb files. Older reported payloads use additional temporary filenames and hashes, so absence of the latest hash does not establish safety. The initial CDN/publishing access and full victim scope remain unresolved.

Optional evidence checker: The report now links its author’s NIKKE Launcher Check; release v0.5.1 was published November 4 at 13:39 UTC. The documentation describes a local scanner and distinguishes script exposure, agent infection, no traces found and missing installation. These are tool verdicts, not a complete forensic determination. Preserve the cache before cleanup and redact any shared report. Manual investigation, persistence removal/rebuild and clean-device secret rotation remain necessary when compromise is suspected. The tool was not executed or independently audited for this article.

November 4 late research revision: Google Play Games PC exposure is user-reported, with installation/process pivots C:\NIKKE_GOOGLE, Launcher\nikke_launcher_google.exe and %APPDATA%\nikke_launcher_google; it is not a complete vendor scope assessment. The front-end was rebuilt, but FeedList retains its URL, so preserve evidence before clearing each variant’s cache. At 22:59 UTC the researcher still observed the two original malicious domains resolving to 89.127.233.127; DNS resolution does not prove the server recovered or was still issuing malicious commands.

If a run ends with startup failed: EIO: invalid UTF-8 in string immediately after k2f_chan registered, without an adopted, resuming or agent started as line, the researcher’s code inspection identifies non-ASCII Windows usernames as a possible system-information encoding failure. That run likely stopped before receiving a server ID. However, its l.js was not captured and subsequent behavior is unknown: the agent downloaded and ran, so suspected-infection cleanup still applies. v0.5.2 reports this separately as loaded but startup failed. Although the analyzed agent has no built-in scheduled-task, Run-key, service, WMI or Startup-folder persistence code, arbitrary commands could install additional persistence; do not limit investigation to the known CLSID. Static browser scanning takes cookies only from Chromium browsers and logins.json/key4.db from Firefox; arbitrary file-reading capability remains, and capability does not prove actual cookie or password exfiltration.

November 4 official follow-up: Level Infinite now confirms Windows launcher tampering and asks users who launched since September 27 15:41 UTC+9 (06:41 UTC) to check. It says mobile was unaffected, superseding our earlier limitation that the research did not cover mobile. Its retrospective dates malicious distribution to October 30 03:52 UTC+9 (October 29 18:52 UTC); researcher-reported logs begin October 23. Both accounts are retained, so the later date is not an exclusion rule. Domain hijacking and the CDN/network entry route remain part of the vendor’s investigation rather than an independently established complete root cause.

The vendor dates replacement of three scripts to November 3 17:04–17:23 UTC and the remaining script’s CDN refresh to November 4 03:09 UTC, with gradual rollout afterward. It announced official-client ACE scanning/removal from November 4 23:00 UTC, requiring consent to delete associated logs, DLLs and registry entries: preserve evidence first. This feature was not run here. Neither its claim that remaining DLLs cannot execute nor a missing pop-up proves a fully clean host; arbitrary commands could have installed other persistence. The manual also calls for full/Defender Offline scans, password changes, key/token rotation and support reports for suspected losses. No confirmed loss total or completed financial compensation is published in these notices.

The vendor also plans stronger monitoring, integrity verification for external launcher resources and a review of feature permissions. These are announced preventive measures, not independently verified completed controls or evidence that existing infections were removed.

November 5 research update: Preserve evidence before reopening the updated launcher: one reported clean installation lost debug.log without consent. The researcher’s 14:39 UTC revision also reports insightjs.com suspended since 02:05 UTC and non-resolving at 09:09 UTC. This does not reverse prior access. The unrelated fake cleanup domain is a separate lure, not evidence of a common operator.

November 6 collection limits: MotherSphere’s author replies distinguish one build uploaded on November 3 at 14:56 GMT from earlier builds that have not all been examined. Its browserscan covers %LOCALAPPDATA%\Google\Chrome\User Data, %LOCALAPPDATA%\Microsoft\Edge\User Data, %LOCALAPPDATA%\BraveSoftware\Brave-Browser\User Data, %LOCALAPPDATA%\Vivaldi\User Data and %APPDATA%\Opera Software\Opera Stable. It also copies Firefox key4.db and logins.json from %APPDATA%\Mozilla\Firefox\Profiles, but not Firefox cookies. Ungoogled Chromium’s %LOCALAPPDATA%\Chromium\User Data is outside that command’s built-in list, not outside the agent’s arbitrary file-reading or execution capabilities.

In that build, a browser-held exclusive lock can prevent the cookie-database copy, without similarly protecting the Chromium saved-password database. The command also skips cookie files larger than 4,194,304 bytes or when collect_cookies is false. These are command-specific limits: another run with the browser closed, arbitrary file commands, another build or the unexamined Chrome DLL can change exposure. Launcher logs and hourly SRUM byte totals cannot show which commands ran or what was stolen; a small upload or a clean scan is not clearance.

The same replies say creds reads last_user.dat and psd.dat in the standard/HMT launcher folders, selects a saved account and decrypts its stored password. A missing psd.dat prevents that build’s password retrieval through this command, but its absence today does not prove it was absent earlier. The command skips the Google variant’s folder, yet arbitrary file reads still reach it; its file format remains unverified. These clarifications do not establish actual exfiltration of every password or a safe launcher variant.

Further November 6 author clarifications: browserscan reads cookie site, name and encrypted value, returning entries with path, profile and key rather than the raw SQLite file. l.js reads this JSON in base64url chunks (up to 2 MiB by default); the original controlling l.js was not captured, so possible transport compression/encryption and SRUM byte totals cannot establish which data left. Opera GX’s %APPDATA%\Opera Software\Opera GX Stable is outside the analyzed built-in list, but arbitrary file commands can still read it. Browser locks apply only to that moment’s cookie copy, not later launches, saved passwords or the unexamined browser DLL.

The author also identifies login_ticket and biz_ticket in tinyget.mem.log and dated Launcher/log/tinyget logs as readable through cat or download; their permissions and lifetime have not been tested. The analyzed agent has no phone/router-specific code or network scanner. However, it can read Phone Link data stored on the PC, and arbitrary execution could reach local-network administration or interact with a linked phone. Those are possible routes, not observed propagation. Seek support for ticket revocation, preserve/redact logs as above, and check linked devices or saved router credentials without asserting they were compromised.

November 7 author guidance: The analyzed chrome_install creates its Chrome-named directories even if Chrome is absent. While the persistence key is set, Chromium-based applications can also load the DLL; the author cites Steam’s web helper and Alt1 observations on one PC. Absence of Chrome therefore cannot exclude persistence. Do not roll Windows back to investigate: System Restore can restore the registry key and DLL and permit execution again. Read the existing journal before rebuilding, or inspect a previous-version folder without restoring or executing its contents. SRUM measures process traffic roughly by hour; even a large burst does not identify which data left. Proxy-level rejects and checking the actual old-session list complement, rather than replace, the existing cleanup and clean-device credential steps.