QuimaRAT: Java-Based MaaS Targeting the Big Three (Win/Linux/macOS)
Just caught the LevelBlue report on QuimaRAT, and it’s a concerning evolution in the MaaS space. We’ve seen plenty of platform-specific RATs, but a Java-based malware capable of hitting Windows, Linux, and macOS with a single codebase? That lowers the barrier to entry significantly. The pricing ($150/mo to $1200 lifetime) suggests we’re going to see this crop up in commodity campaigns pretty fast.
The cross-platform nature relies on the JVM, which often flies under the radar compared to native binaries. Since it’s a "Remote Access" tool, we need to focus on behavioral detection rather than just static signatures. The persistence mechanisms usually involve creating scheduled tasks or systemd services that launch the JAR file.
For those hunting this, I recommend checking for child processes spawned by java.exe or javaw that spawn shells (like cmd or bash). You can use this quick KQL query for Sentinel to spot anomalies:
Process
| where ProcessVersionInfoOriginalFileName =~ "java.exe" or ProcessVersionInfoOriginalFileName =~ "javaw.exe"
| where InitiatingProcessFileName !in ("javaw.exe", "java.exe", "idea64.exe", "eclipse.exe")
| project Timestamp, DeviceName, FileName, CommandLine, InitiatingProcessFileName
Has anyone started building specific IOCs for QuimaRAT's C2 infrastructure yet? I'm curious if they are using standard TCP/HTTP callbacks or something more obfuscated to bypass firewalls.
Good catch on the behavioral angle. In my SOC environment, we see a ton of Java from devs, so alerting on every java.exe spawn creates fatigue. We've had success focusing on the network profile. QuimaRAT, like many RATs, tends to maintain a heartbeat. If you see a Java process maintaining a long-lived connection to an unknown IP on a non-standard port, that's your trigger.
Get-NetTCPConnection -OwningProcess (Get-Process -Name java).Id | Where-Object {$_.State -eq 'Established'} | Select-Object LocalAddress, RemoteAddress, RemotePort, OwningProcess
If the remote address isn't a known repo or internal server, isolate the host immediately.
The pricing model is the scariest part. At $150, script kiddies can afford to pivot away from basics like AsyncRAT. For Linux/Mac sysadmins, the key is tightening execution permissions. Don't allow users to execute JARs from /tmp or user download directories.
You can enforce this with a simple SELinux policy or just by auditing executable permissions:
find /home /tmp -name "*.jar" -perm -111 -ls
If you find executable JARs in those paths, kill the process and investigate. Most legitimate apps install to `/usr/share` or `/opt`, not a user's Downloads folder.
I'm currently analyzing a sample that matches this description. It uses a heavily obfuscated JAR (Allatori or similar protector) to hide the strings. Static analysis is a nightmare. I recommend extracting the class files and running them through a decompiler like jd-gui or fernflower, but be careful in the sandbox.
One interesting artifact I found was a specific User-Agent string hardcoded in the config. If you're proxying logs, look for Java applications sending requests with weird, non-browser UAs.
Building on the network profiling, don't overlook DNS anomalies. Java-based RATs frequently abuse DNS for C2 to bypass standard firewall rules. Keep an eye out for high entropy in subdomains or unusually long query lengths. I’ve deployed this KQL query to catch potential tunneling activity often linked to suspicious java.exe spawns:
DnsEvents
| where QueryType in ("TXT", "CNAME")
| where strlen(QueryName) > 50
| summarize count() by QueryName, ClientIP
Focusing on the parent-child relationship offers high-fidelity detection without needing to crack the obfuscation immediately. If you see java.exe spawned by MS Office or a script host, that’s a massive red flag compared to standard IDE usage. You can hunt for this anomaly with a simple process query:
DeviceProcessEvents
| where FileName =~ "java.exe"
| where InitiatingProcessFileName !in~ ("explorer.exe", "cmd.exe", "idea64.exe", "eclipse.exe")
massive red flag indeed. Since static analysis is difficult due to the obfuscation, hunting via process lineage is much more efficient. You don't need to decrypt the payload to spot that winword.exe shouldn't be spawning java.exe.
Here is a KQL query to help visualize this behavior in your logs:
DeviceProcessEvents
| where FileName =~ "java.exe"
| where InitiatingProcessParentFileName in~ ("winword.exe", "excel.exe", "powerpnt.exe")
| project Timestamp, DeviceName, Account, InitiatingProcessParentFileName
This catches the infection vector regardless of the specific RAT variant.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access