Itch.io, the beloved playground for indie developers, has recently found itself at the center of a sophisticated social‑engineering scheme. Attackers masquerading as fans or fellow creators post comments that promise fresh, polished builds. In reality, they hand out a zip file that looks like a legitimate update but is a carefully crafted delivery vehicle for Lumma Stealer, a stealthy information‑stealing payload.

At first glance, the bait is almost too clean. The archive contains a handful of innocuous files that would pass a quick glance by a casual gamer. The real danger lies in the single executable, named game.exe, which hides malicious code that triggers only after a series of environmental checks.

How the Bait Is Deployed

New accounts are spun up on Itch.io and flooded with templated comments on popular titles. Each comment includes a link that claims to host an “updated build.” The link points to Patreon, a platform that many indie developers use for funding and community engagement. When users click the link, they are prompted to download Updated Version.zip. The file name itself feels familiar – it echoes the update naming conventions of many legitimate game releases.

Once the archive is unpacked, most of its contents are harmless. However, the heart of the attack is the game.exe file. Analysts discovered that this binary is actually a Node.js application compiled into a Windows Portable Executable using a tool called nexe. This technique is noteworthy because it bundles all runtime dependencies into a single file, eliminating the need for a separate Node.js installation and making the malware more opaque to casual inspection.

Inside the Malicious Executable

The first step for the attackers is to reverse‑engineer the executable. Using a custom decompiler, researchers extracted an obfuscated JavaScript file named mains.js. When deobfuscated, the script revealed a series of asynchronous functions that perform a battery of anti‑analysis checks before any payload is unleashed.

These checks are layered and meticulous. The malware queries the system for total RAM and the number of CPU cores, aborting if the numbers fall below thresholds typical of sandbox environments. It also cross‑references the logged‑in user against a hardcoded list of names associated with malware analysis labs. If a match is found, execution stops immediately.

Further scrutiny is applied to running processes. The script scans for well‑known debugging, traffic‑analysis, and reverse‑engineering tools such as IDA, x64dbg, Wireshark, Burp Suite, and Process Hacker. The presence of any of these processes triggers an immediate halt. To add another layer of defensive evasion, the malware queries Windows Management Instrumentation for video adapter names, refresh rates, and disk drive models. Indicators of virtualization—names like VMware, VirtualBox, or generic virtual disk models—cause the script to abort as well.

Why These Checks Matter

It might seem excessive for a single malicious file to perform so many checks, but each one serves a purpose. By ensuring the environment looks like a real user’s machine, the attackers can confidently drop the final payload without the risk of being detected or analyzed in a sandbox. The checks also help avoid accidental execution in corporate or research environments where the malware could be flagged prematurely.

Reflective Loading: A Stealthy Execution Technique

Once the script clears all tests, it decodes a Base64 string and writes a DLL called modules.node into the user’s temporary directory. This DLL is a Node.js native module, exposing functions such as napi_register_module_v1 and node_api_module_get_api_version_v1. These exports allow the JavaScript runtime to interact directly with native code, a capability that the attackers exploit to keep the stealer in memory.

A second Base64 blob, identified as a variant of Lumma Stealer, is decoded and passed into the module. The Node.js N-API functions napi_create_function and napi_set_named_property are then used to load and execute the stealer reflectively. Because the code never writes the final payload to disk, traditional file‑based detection mechanisms struggle to catch it.

Across multiple Patreon URLs and spam accounts, researchers noted small variations in the compiled binaries. Variable names were shuffled, encoding methods altered, and in some instances, WMI queries were replaced with equivalent PowerShell commands. These modifications signal an active, adaptive campaign—an attacker continuously refining the malware to stay ahead of defensive tooling.

What Developers and Players Should Watch For

While a single malicious file can cause significant damage, the broader lesson is that trust on open platforms can be exploited in surprising ways. Developers should verify the authenticity of any external update links, especially those that come from comments or user‑generated content. Players, on the other hand, should be wary of any download that claims to be an “updated version” from a source they do not personally recognize, even if it appears to come from a familiar developer.

In practical terms, a quick verification step—such as checking the checksum of downloaded files against a known value posted by the developer—can provide an additional layer of safety. For developers hosting on Patreon, consider using Patreon’s own download system or a separate, dedicated hosting service that offers version control and integrity checks.

Looking Ahead: The Battle Between Trust and Malice

As indie game ecosystems grow, so does the temptation for attackers to piggyback on the community’s collaborative spirit. The use of Node.js and nexe, combined with reflective loading, shows that even seemingly simple platforms can become launchpads for advanced threats. The key to staying ahead lies in vigilance, transparency, and a willingness to adopt more robust verification practices. By fostering a culture of careful scrutiny—both on the developer and consumer sides—the indie community can preserve its openness while mitigating the risk that comes with it.