New Campaign: Trojanized Gaming Tools Dropping Java RATs via PowerShell
Just caught the Microsoft Threat Intelligence report regarding a new campaign targeting gamers with trojanized utilities. The threat actors are clever here—they aren't relying on the victim having Java installed. Instead, the malicious downloader stages its own portable Java runtime to execute a malicious JAR file (jd-gui.jar).
Since jd-gui is a legitimate decompiler, the file name might look innocent, but in this context, it's the payload. The initial access vector involves social engineering via browser and chat platforms, luring users in with "hacks" or "utilities."
Here is a KQL query to help hunt for this behavior, specifically looking for PowerShell spawning Java processes or interacting with suspicious JAR paths:
DeviceProcessEvents
| where InitiatingProcessFileName =~ "powershell.exe"
| where FileName =~ "java.exe" or FileName =~ "javaw.exe"
| where ProcessCommandLine contains "jd-gui.jar"
| project Timestamp, DeviceName, InitiatingProcessCommandLine, ProcessCommandLine
You should also look for the portable JRE folder structures appearing in user directories (like AppData\Local or Downloads) rather than Program Files.
How are you handling application allowlisting on endpoints where users insist on installing niche gaming tools? Is strict blocking the only way, or are you seeing success with behavioral rules?
Good catch on the portable JRE aspect. That's a classic technique to bypass version checks, but it stands out like a sore thumb in EDR telemetry.
For detection, we've had luck blocking unsigned binaries that try to extract archives into user profiles. A simple PowerShell constraint script block can help stop the initial staging if execution policy is enforced:
Get-ChildItem -Path $env:USERPROFILE\Downloads -Filter *.jar -Recurse | Where-Object { $_.Length -gt 5MB }
While not a perfect block, monitoring for large JAR drops in Downloads can flag this quickly.
The use of jd-gui is interesting social engineering. A gamer wouldn't normally need a Java decompiler, so the presence of that specific filename should be a high-fidelity alert regardless of the parent process.
I'd recommend adding a hash-based block for the known malicious portable JREs if you have access to threat intelligence feeds. Also, check your proxy logs for large downloads from non-standard ports associated with chat clients.
We see this often in pentesting. Users will disable AV just to run a 'cheat' or 'FPS booster.' The technical chain here is pretty standard, but the delivery method via chat platforms is the real concern.
If you can't block the tools, consider tightening PowerShell logging to force module logging and script block logging. This will capture the obfuscated download commands they usually use to stage that JAR file.
The bundling strategy definitely helps them evade environment checks, but it creates a weird process lineage. I’d focus on hunting for java.exe spawning outside of standard Program Files paths, specifically when the parent is a suspicious installer or PowerShell session.
Here’s a quick KQL query for hunting that behavior:
Process
| where ProcessName == "java.exe"
| where FolderPath !contains "Program Files"
| where InitiatingProcessName in ("powershell.exe", "cmd.exe")
| project Timestamp, DeviceName, FolderPath, CommandLine, InitiatingProcessCommandLine
Excellent analysis, everyone. Since PowerShell is the delivery mechanism, ensure Script Block Logging is enabled to catch the obfuscation layers these actors use. They often Base64 encode the download URLs. You can hunt for suspicious calls like Invoke-WebRequest targeting .jar files or attempts to bypass AMSI.
DeviceEvents
| where ActionType == "PowerShellScriptBlock"
| where AdditionalFields contains "Invoke-WebRequest" and AdditionalFields contains ".jar"
To add to the prevention angle, consider Application Whitelisting. Since they bundle a portable JRE, the java.exe typically lands in user writeable directories like Downloads. You can enforce policies to block unsigned binaries in these specific paths.
For hunting, refining the process lineage query helps separate noise from malicious activity:
DeviceProcessEvents
| where InitiatingProcessFileName == "powershell.exe"
| where FileName == "java.exe"
| where FolderPath !contains "Program Files"
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access