QuimaRAT: Java’s Cross-Platform Promise Turned Into a $150 Attack Kit

Java’s portability is being used against you. LevelBlue SpiderLabs published their analysis last week of QuimaRAT, a Java-based remote access trojan sold as a subscription service — $150 per month, $1,200 for lifetime access. The selling point is the same as Java itself: write once, run anywhere. One JAR file, the same payload, three operating systems. If you run Java, you’re in scope.

One JAR, Three Operating Systems

QuimaRAT is organized as an Apache Maven project — two pom.xml files, standard directory structure. It looks, structurally, like a legitimate Java application. Embedded inside the JAR are Java Native Access (JNA) native libraries for Windows, Linux, and macOS across multiple CPU architectures. The same runtime that makes your Spring Boot app portable makes the RAT portable too.

The feature list from the dark web listing: 70+ modules, AES-256 encrypted command traffic, “FUD” (Fully Undetectable) claims for Windows and Linux, SmartScreen bypass, no visible UI elements. Modules are not baked into the JAR — they’re delivered, loaded, and swapped out dynamically via the C2 server. The operator can upgrade capabilities post-compromise without touching the initial payload.

C2 communication runs over TCP by default, with WebSocket, TLS, and HTTPS as fallback channels. There’s also a Pastebin-based C2 rotation mechanism: if the primary C2 goes down, the RAT checks a Pastebin URL for updated server addresses. The operator can switch infrastructure without rebuilding or redeploying the payload.

How It Gets In: The Browser Cache Trick

The initial delivery is smarter than most security awareness training prepares people for. The Quima Loader — a separate component in the MaaS package — uses a browser-cache delivery technique. The victim lands on a fake CAPTCHA page or a spoofed software update prompt. While the page loads, the actual JAR payload is quietly stored in the browser’s cache. A secondary “harmless” loader binary then retrieves and executes the cached payload locally. No download dialog. No suspicious extension. No file saved to the Downloads folder.

The builder generates payloads in multiple formats depending on the target: JAR, EXE, APP, SH, BAT, VBS, LNK, Office macros, Control Panel applets. The attacker picks the format most likely to land given the delivery channel.

Persistence: Platform-Aware, Automatic

After execution, QuimaRAT installs persistence using each operating system’s native mechanisms. The same JAR detects the OS and applies the right method:

• Windows: Registry Run keys, Scheduled Tasks, and the Startup folder
• Linux: .desktop autostart entries and @reboot cron jobs
• macOS: A LaunchAgent plist with KeepAlive: true

Before committing to persistence, the RAT verifies the environment — checking for virtualization or sandbox indicators — and ensures only one instance is running via a Java FileLock on a .lock file in the OS temp directory.

Why Developers Are a Target

Most QuimaRAT coverage focuses on end-user risk. The developer angle is underplayed. Developer machines are valuable targets: they hold production credentials, database access, signing keys, API tokens, and source repository access. Enterprise Java environments — Spring Boot, Kafka, Hadoop clusters, Android build systems — all have JREs installed by definition.

The MaaS model means $150 buys someone a complete attack platform with a GUI panel. The skill floor for running this is low. The potential target pool — everyone with a JVM — is enormous.

What to Watch For

Static detection is hard because the payload is obfuscated and the final modules are encrypted plugins delivered at runtime. Behavioral detection is the more reliable path:

• Long-running java processes with -cp pointing to /tmp/ or %TEMP%
• New Registry Run keys, Scheduled Tasks, or Startup folder entries created by a Java process
• New LaunchAgent plists with KeepAlive: true pointing to a Java executable
• New @reboot crontab entries executing Java
• Outbound TCP or WebSocket connections from JVM processes to unfamiliar addresses
• Java processes making periodic HTTP requests to Pastebin (C2 rotation indicator)

What to Do Now

1. Remove JREs from hosts that don’t need them. If a server isn’t running Java, remove the runtime entirely. It eliminates this threat class on those hosts.
2. Verify Maven dependencies. Check checksums, pin versions in your lockfiles, and monitor transitive dependencies for unexpected updates. A malicious JAR introduced as a dependency is a valid QuimaRAT delivery vector.
3. Restrict outbound connections from JVM processes. If your Java application has a known network profile, enforce it with egress filtering. Unexpected connections to Pastebin from your API server are a red flag.
4. Audit your Java process baseline. Know which Java processes run on each host and what their startup arguments look like. A process loading classpath from /tmp/ is not normal.
5. Review LaunchAgents, Run keys, and crontabs regularly. Automated monitoring for new persistence entries — especially from Java processes — catches post-compromise activity early.

LevelBlue has published IoCs and a full technical writeup. Broadcom Security Center has added protection for QuimaRAT components. If your environment uses Java, this threat report is worth fifteen minutes of your time now rather than a post-incident debrief later. Full initial coverage from The Hacker News has additional context.