![\"\"](\"https:\/\/www.intego.com\/mac-security-blog\/wp-content\/uploads\/2026\/05\/The-Hidden-Threat.jpg\")
<\/p>\n<\/p>\n
As security researchers, we often categorize threats by the operating system they target. We talk about \u201cmacOS malware,\u201d \u201cWindows stealers,\u201d or \u201cLinux threats.\u201d But modern malware delivery does not always stay neatly inside one operating system.<\/p>\n
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.<\/p>\n
Protection status:<\/strong> Intego\u2019s latest virus definitions now detect the payloads associated with this campaign as Java\/DiscordSteal.gen<\/strong> and Java\/Loader.gen<\/strong>. Intego users with up-to-date virus definitions are protected against these detected payloads.<\/p>\n Intego AV Labs analyzed a multi-stage malware campaign<\/a> 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.<\/p>\n The payloads associated with this campaign are now detected by Intego\u2019s latest virus definitions as Java\/DiscordSteal.gen and Java\/Loader.gen.<\/p>\n<\/div>\n 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.<\/p>\n 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\u2019s index. Using a simple targeted grep:<\/p>\n This immediately isolated a glaring anomaly hidden deep within a fake directory structure:<\/p>\n The threat actor had attempted to masquerade the primary exfiltration class as a benign image asset path.<\/p>\n With the exfiltration class identified, we dumped the raw strings directly from the compiled bytecode:<\/p>\n The obfuscator completely failed to protect the payload\u2019s core logic. The output revealed the entire exfiltration blueprint in plain text:<\/p>\n 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<\/span> was gone.<\/p>\n Instead, the builder randomized the internal structure of the JAR, injected heavily obfuscated junk classes, such as cF.class, cE.class<\/span>, and a\/dR.class<\/span>, and used dynamic method handles to stitch the malicious code together at runtime.<\/p>\n However, sophisticated builders are still written by humans, and humans make mistakes. During our analysis of the obfuscated cF.class<\/span> stager, we uncovered a useful piece of the attacker\u2019s operational security failure. Buried within the class\u2019s constant pool was a hardcoded string artifact:<\/p>\n This leftover developer comment was likely a remnant from the malware author testing the obfuscator\u2019s evasion capabilities against antivirus scanners. More importantly, it gave us a static fingerprint for this specific builder version.<\/p>\n That meant we did not need to rely only on decompiling the shifting logic. We could instead look for the builder\u2019s permanent fingerprints.<\/p>\n Our advanced extraction methodology focused on two key areas.<\/p>\n The malware builder intentionally corrupted the class file headers and constant pool indexes. When standard parsers, such as<\/p>\n , attempted to read these files, they failed with \u201ctruncated or malformed\u201d errors because they expected structurally valid Java compiled classes.<\/p>\n To bypass this, we abandoned structural parsers in favor of raw binary inspection. By using xxd<\/span>, 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:<\/p>\n 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.<\/p>\n 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.<\/p>\n By searching our raw hex dump for these mandatory dependencies \u2014 specifically java\/net\/ServerSocket<\/span>, used for process-instance locking, and java\/lang\/invoke\/LambdaMetafactory<\/span> \u2014 we bypassed the obfuscation entirely:<\/p>\n This raw extraction revealed the exact decimal byte offsets of the required artifacts, such as:<\/p>\n 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\u2019s randomization ineffective.<\/p>\n 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.<\/p>\n Detecting suspicious files before they run<\/strong><\/a> 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.<\/p>\n<\/div>\n A common question we hear is: \u201cIf the final payload is a Windows stealer, why should a macOS user care?\u201d<\/p>\n The answer comes down to how threats move in the real world.<\/p>\n 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.<\/p>\n To assist the security community in identifying this campaign, we have compiled the SHA-256 hashes of the identified JAR variants.<\/p>\n\nWhat did Intego AV Labs find in this Java stealer campaign?<\/h2>\n
The needle in the haystack: Isolating the payload<\/h2>\n
unzip -l sample.jar | grep -iE “steal|grab|webhook|token|send|upload”<\/div>\nminecraft\/durability\/png\/file_send.class<\/div>\nExtracting the C2: The plain-text blunder<\/h2>\n
unzip -p sample.jar minecraft\/durability\/png\/file_send.class | strings<\/div>\n\n
Note for authorized responders:<\/strong> When a hardcoded Discord webhook is exposed in plain text during an investigation, blocking it is not the only option. In authorized response workflows, the webhook can also be reported to Discord or disabled using Discord\u2019s webhook deletion endpoint, preventing the attacker from receiving additional data through that channel.<\/div>\nThe anatomy of the builder: Obfuscation and operational security failures<\/h2>\n
i used it for virustotal blacklists<\/div>\n1. Container deconstruction and bypassing anti-analysis<\/h3>\n
strings -t d<\/div>\nxxd -l 2048 cE.class > cE_hex.txt<\/div>\n2. Loader DNA mapping<\/h3>\n
grep “ServerSocket” cE_hex.txt<\/div>\n000006e0: java\/lang\/Except…<\/div>\n\nWhy can a Windows stealer still matter to Mac users?<\/h2>\n
Why macOS security matters here<\/h2>\n
\n
Indicators of compromise<\/h2>\n