As security researchers, we often categorize threats by the operating system they target. We talk about “macOS malware,” “Windows stealers,” or “Linux threats.” But modern malware delivery does not always stay neatly inside one operating system.
Intego AV Labs recently analyzed a multi-stage infection campaign targeting gaming communities. While the final payload was a Windows-based credential stealer, the delivery vector was a cross-platform Java JAR archive. This campaign shows why platform-specific security assumptions can be risky. Even when the final payload is designed for one operating system, the delivery chain can move through files, communities, and devices that are not limited to that platform.
Protection status: Intego’s latest virus definitions now detect the payloads associated with this campaign as Java/DiscordSteal.gen and Java/Loader.gen. Intego users with up-to-date virus definitions are protected against these detected payloads.
Intego AV Labs analyzed a multi-stage malware campaign targeting gaming communities through malicious Java JAR files disguised in mod-related folders. The delivery method is platform-agnostic, meaning the file can move across different operating systems even though the final payload observed in this campaign was a Windows-based credential stealer.
The payloads associated with this campaign are now detected by Intego’s latest virus definitions as Java/DiscordSteal.gen and Java/Loader.gen.
Diving into a massive, inflated JAR is always a classic needle-in-a-haystack situation. Threat actors frequently pad their archives with thousands of legitimate library files, such as org/jetbrains/annotations or org/intellij, to create noise and evade basic container-level heuristics.
To cut through the bloat in our initial sample, we avoided scanning the container as a whole and instead looked for behavioral naming conventions within the archive’s index. Using a simple targeted grep:
This immediately isolated a glaring anomaly hidden deep within a fake directory structure:
The threat actor had attempted to masquerade the primary exfiltration class as a benign image asset path.
With the exfiltration class identified, we dumped the raw strings directly from the compiled bytecode:
The obfuscator completely failed to protect the payload’s core logic. The output revealed the entire exfiltration blueprint in plain text:
While the first sample was sloppy, subsequent variants in this campaign proved much more sophisticated. The attackers used a polymorphic builder to generate unique wrappers for later downloads. In these variants, the easily identifiable file_send.class was gone.
Instead, the builder randomized the internal structure of the JAR, injected heavily obfuscated junk classes, such as cF.class, cE.class, and a/dR.class, and used dynamic method handles to stitch the malicious code together at runtime.
However, sophisticated builders are still written by humans, and humans make mistakes. During our analysis of the obfuscated cF.class stager, we uncovered a useful piece of the attacker’s operational security failure. Buried within the class’s constant pool was a hardcoded string artifact:
This leftover developer comment was likely a remnant from the malware author testing the obfuscator’s evasion capabilities against antivirus scanners. More importantly, it gave us a static fingerprint for this specific builder version.
That meant we did not need to rely only on decompiling the shifting logic. We could instead look for the builder’s permanent fingerprints.
Our advanced extraction methodology focused on two key areas.
The malware builder intentionally corrupted the class file headers and constant pool indexes. When standard parsers, such as
, attempted to read these files, they failed with “truncated or malformed” errors because they expected structurally valid Java compiled classes.
To bypass this, we abandoned structural parsers in favor of raw binary inspection. By using xxd, we ignored the broken Java Virtual Machine specifications and dumped the first 2048 raw bytes to isolate the constant pool located near the top of the file:
In practical terms, even when the malware author breaks normal parsing tools, the loader still needs enough recognizable Java structure for the JVM to link and execute it.
While the builder successfully randomized class names and broke standard parsers, it could not encrypt the core network and reflection libraries required by the JVM itself. The foundational skeleton had to remain in plain text.
By searching our raw hex dump for these mandatory dependencies — specifically java/net/ServerSocket, used for process-instance locking, and java/lang/invoke/LambdaMetafactory — we bypassed the obfuscation entirely:
This raw extraction revealed the exact decimal byte offsets of the required artifacts, such as:
By mapping these coordinates across different variants, we isolated the stager bytecode from the obfuscated junk. Because we anchored our detection on the constant pool strings that the JVM itself requires to link the code, we built precise structural detections that made the obfuscator’s randomization ineffective.
A Windows-based stealer can still matter to Mac users when the delivery file is cross-platform or moves through mixed-device environments. In this campaign, the malicious Java JAR file could be downloaded, stored, shared, or passed along from a Mac, even if the final payload was designed for Windows.
Detecting suspicious files before they run helps stop the infection chain earlier, before the file reaches a Windows PC, Windows virtual machine, shared folder, or another system where the payload can run.
A common question we hear is: “If the final payload is a Windows stealer, why should a macOS user care?”
The answer comes down to how threats move in the real world.
A Mac can become a blind spot in a mixed-device infection chain if security tools ignore files simply because the final payload targets another platform. That is why platform-aware detection matters, especially when files are shared between devices, virtual machines, gaming communities, and collaboration tools.
To assist the security community in identifying this campaign, we have compiled the SHA-256 hashes of the identified JAR variants.
| Variant | SHA-256 hash |
| Sample 1 — file_send.class Loader | 405a9d65546a9c3f28f407718061d7a818743c108332e5d08f9ec6b75cf2aa9b |
| Sample 2 — cF.class Loader | 818df90f630f338729258499e3fd02b649d345bdad07ff1080c737eb5040ba14 |
| Sample 3 — cE.class Loader | b77f44177f82965acb1d17754078753a7c3c6b80132a27f50ddc7b2608e9ee34 |
| Sample 4 — a/dR.class Loader | f3f1c00c8fed8d2df911d589195a8f076203e8afed2099307f911a456b661c27 |
Intego detection names:
