Dunkle SaaS-artige Produktoberfläche auf einem Monitor, umgeben von roten Malware- und Warnsymbolen als Visualisierung von Malware-as-a-Service.

QuimaRAT: Malware-as-a-Service mit Vertriebsoberfläche

von

QuimaRAT ist als technische Geschichte nur halb interessant. Java-RAT, plattformübergreifend, modular, Builder, Plugin-Architektur, Tarnungsversprechen: Das alles gehört dazu. Die eigentliche Pointe liegt aber woanders. Hier wird Malware-as-a-Service so inszeniert, als wäre es ein normales Softwareprodukt.

Die öffentlich sichtbare Seite wirkt zunächst wie die Produktseite eines kleinen Nischenanbieters: Startseite, Pricing, FAQ, Screenshots, Demo-Video, Terms of Service, Privacy Policy, Kontaktkanäle, Checkout. Genau das macht QuimaRAT als Fall interessant. Nicht nur der Schadcode ist das Thema, sondern die Vertriebsoberfläche.

Der Originalreport von LevelBlue verschiebt die Einordnung zusätzlich. Es gibt nicht nur Marketing, sondern auch einen analysierten Java-RAT-Kern mit modularer Architektur. Trotzdem bleibt die Zuordnung zwischen Webseite, Forum- und GitHub-Werbung, Screenshots, Protokolloberfläche und tatsächlich implementierter Funktionalität ungleichmäßig. Gerade diese Unschärfe macht den Fall brauchbar.

Nicht der RAT ist hier das Auffällige, sondern das Produktgefühl

Die naheliegende Schlagzeile wäre: Malware wird jetzt Java. Das ist nicht falsch, aber zu dünn. QuimaRAT wird als plattformübergreifender Java-RAT für Windows, macOS und Linux beworben. Die sichtbare Marketingoberfläche spricht von mehr als 70 Modulen, mehreren Transportmodi, AES-256, einem Builder, verschiedenen Ausgabeformaten und Stealth-Versprechen.

Der stärkere Befund liegt in der Form. Bei QuimaRAT sieht man sehr direkt, wie weit sich Malware-as-a-Service von der alten Untergrundästhetik gelöst hat. Statt nur in Foren, Chatgruppen oder halbversteckten Kanälen aufzutauchen, wird hier eine öffentliche Produktoberfläche gebaut, die sich an normalen SaaS-Konventionen orientiert.

Produktisierung bedeutet eben nicht nur: viele Features. Produktisierung bedeutet Kundenführung, verständliche Pakete, Support-Erwartung, wiedererkennbare Oberfläche und wiederholbarer Kaufprozess. Weniger Bastelware, mehr Angriffsprodukt.

Die Webseite ist stimmig. Das macht sie nicht automatisch echt

Die bequeme Einordnung wäre: Das ist der offene Webshop eines laufenden MaaS-Angebots. So weit würde ich auf Basis der Seite allein nicht gehen.

Wichtig ist: Auf das RAT selbst wird dort öffentlich nicht direkt verlinkt. Sichtbar sind Marketing, Screenshots, Versprechen, Preise, Hashes, Supportkanäle und rechtliche Kulisse. Nicht sichtbar ist ein belastbarer öffentlicher Beleg dafür, dass diese Vertriebsoberfläche zuverlässig genau den beworbenen Service liefert. Es kann ein echter Dienst sein. Es kann ein Marketing-Frontdoor für ein anderes Vertriebsmodell sein. Es kann auch ein Scam oder ein nur teilweise funktionierendes Scam-Produkt sein.

Darum sollte man den Befund sauber halten: Die Seite belegt die Vermarktungslogik. Sie beweist nicht automatisch Echtheit, Qualität oder Liefertreue des Angebots.

Aus demselben Grund verlinke ich sie hier bewusst nicht direkt. Wenn eine Seite möglicherweise Scam, Marketingfront oder realer Vertriebsweg für Malware ist, dann ist ein öffentlicher Bloglink dorthin nicht neutral. Und selbst wenn sie echt wäre, wirkt das nicht wie etwas, dem man zusätzliche Reichweite geben sollte.

Diese Vorsicht schwächt die Beobachtung nicht. Im Gegenteil. Selbst wenn die Seite teilweise oder vollständig Scam wäre, bleibt die Form aufschlussreich: Malware-Angebote müssen heute nicht mehr wie Szene-Geraune aussehen. Es reicht, wenn sie glaubwürdig genug wie ein Softwareprodukt aussehen.

Dazu passt ein Detail, das man nicht glattbügeln sollte: Die Preisangaben sind nicht konsistent. Die Pricing-Seite nennt 200, 400, 600, 800 und 2.400 Dollar. Die FAQ nennt 200, 500, 900, 1.500 und 3.200 Dollar. LevelBlue zeigt beziehungsweise zitiert wiederum 150, 300, 500, 700 und 1.200 Dollar. Das kann an verschiedenen Kanälen oder Zeitständen liegen. Es kann auch schlicht Schlamperei oder Scam-Geruch sein. In jedem Fall ist es ein gutes Gegengift gegen zu glatte Gewissheit.

Der technische Kern macht die Sache belastbarer

Die Berichterstattung von *The Hacker News* und vor allem der Originalreport von LevelBlue helfen an genau diesem Punkt weiter. LevelBlue beschreibt QuimaRAT als plattformübergreifenden Java-RAT für Windows, Linux und macOS und analysiert ein konkretes Sample: `SWFT.jar`, SHA-256 `bb0fbcb1e47ec04aa55555f3769fbc6f09694de1e9baae59260356b26b5af6a7`. Damit reden wir nicht nur über eine hübsche Webseite, sondern auch über einen untersuchten technischen Kern.

Der Report beschreibt eine modulare Java-Struktur mit `rat-common` und `rat-client`, Netty für Netzwerkkommunikation, Gson für JSON-Verarbeitung, Maven-Shade-Relocation von auffälligen Paketnamen in unauffälligere Namespaces und eingebetteten JNA-Native-Libraries für Windows, Linux und macOS. Dazu kommen Konfigurationslogik, Single-Instance-Schutz, Binder-Ausführung, OS-Prüfung, Anti-VM- und Sandbox-Erkennung, OS-spezifische Persistenz und ein Pastebin-basierter Mechanismus zur Aktualisierung von C2-Hosts.

Besonders wichtig ist die Plugin-Architektur. Laut LevelBlue enthält der analysierte Base-Client nur einen Teil dessen, was das Protokoll benennt: 235 Kommandos im Protokoll, davon 23 im untersuchten Basissample implementiert und 212 zunächst nur als Protokolloberfläche sichtbar.

Das ist keine Kleinigkeit. Es bedeutet aber auch: 235 Kommandos sind kein Beweis für 235 sofort nutzbare Features. Die stärkere Aussage ist nüchterner und deshalb besser: QuimaRAT ist als erweiterbares Ökosystem angelegt, bei dem Funktionen zur Laufzeit per Plugin, Payload oder Modul nachgeladen werden können.

Dadurch verschiebt sich die Geschichte weg von „ein Schadprogramm mit Webseite“ und hin zu einer Werkzeugkette für Kunden. Builder, Konfiguration, Persistenz, C2-Recovery, Plugin-Loading, Dateioperationen, Surveillance-Oberfläche, Credential-Recovery-Vokabular, Post-Exploitation-Vokabular. Nicht alles davon ist im Basissample bewiesen. Aber die Architektur zeigt, worauf das Ding zielt: nicht bloß Schadcode, sondern vorbereitete Bedienkette. Genau das ist SaaS-Logik: nicht nur Funktion verkaufen, sondern Reibung senken.

Die Oberfläche wirkt normal. Das ist das Problem

Die Screenshots machen den Punkt praktisch sichtbar. Zu sehen sind unter anderem Dashboard, Client-Übersicht, Scheduled Tasks, Activity Log, Module Manager und Builder. Das ist nicht elegant im Sinne guter Produktgestaltung. Aber es ist konsistent genug, um wie ein bedienbares Produkt zu wirken.

Noch deutlicher wird es im Builder. Dort tauchen Zielplattformen, Ausgabeformate, Startup- und Persistence-Optionen, Anti-VM- und Sandbox-Checks, String Encryption, Obfuskation und ähnliche Schalter auf. Ohne jede Dramatisierung ist klar, wofür diese Kombination gedacht ist: nicht für normalen IT-Betrieb, sondern für möglichst reibungsarme Paketierung, Tarnung und Persistenz auf fremden Systemen.

Die juristische Fassade auf den Legal-Seiten ändert daran nichts. Wenn Terms of Service und Privacy Policy von Education, Parental Monitoring, Systemadministration und autorisierten Security-Tests reden, während die Produktseiten Keylogging, Credential Recovery, Evasion, Stealth und FUD-Scans vermarkten, ist das keine ernsthafte Abgrenzung. Das ist dieselbe Funktionalität mit einem rechtlichen Feigenblatt daneben.

Besonders hübsch ist der eigene Warnhinweis im Umfeld von Punkt 3.5 der Terms: Nutzung ohne Autorisierung und Zustimmung sei strikt verboten und könne strafbar sein. Inhaltlich stimmt das. Nur wirkt es neben Kontaktwegen wie Proton-Mail, Telegram und Tox, neben FUD-Scan, Credential-Recovery-Claims und Stealth-Versprechen nicht wie Compliance. Eher wie ein juristischer Rauchmelder in einer Benzinbar.

Java ist Mittel zum Zweck, nicht die Pointe

Man kann QuimaRAT leicht falsch lesen. Die schwächere Lesart wäre: Malware wird jetzt Java. Die bessere Lesart ist: Malware-as-a-Service wird sichtbarer wie normales SaaS verkauft.

Java unterstützt hier das plattformübergreifende Verkaufsversprechen, vereinheitlicht die Geschichte und gibt dem Angebot ein brauchbares technisches Narrativ: ein Codepfad, mehrere Plattformen, ein gemeinsamer Builder. LevelBlue bestätigt, dass der analysierte Client tatsächlich Java-basiert ist, Java SE 8 adressiert und über JNA native Betriebssystemfunktionen anspricht.

Gleichzeitig zeigt der Report die Grenze des Cross-Platform-Versprechens. Manche Fähigkeiten, etwa In-Memory-Shellcode-Ausführung über Windows Kernel32, sind klar Windows-spezifisch. „Cross-platform“ heißt also nicht, dass jede Funktion auf jeder Plattform gleichwertig vorhanden ist. Es heißt eher: derselbe Produktkern kann mehrere Zielumgebungen bedienen.

Genau deshalb passt QuimaRAT gut zu einer Linie, die hier schon mehrfach Thema war. In Claude Mythos ist gefährlich, aber nicht magisch ging es darum, dass neue Technik nicht plötzlich Magie erzeugt, sondern Reibung senkt. In Alte Security, schnelle Angreifer war der Punkt ähnlich: Alte Schwächen werden unter besseren Arbeitsbedingungen schneller und billiger ausnutzbar. Und in Der gefährlichste Angriff ist oft schon eingeloggt stand die operative Nutzbarkeit vorhandener Zugänge im Vordergrund.

QuimaRAT fügt dem keinen magischen neuen Angreifer hinzu. Es zeigt, wie Angriffslogik als Produkt verpackt wird.

Was Verteidiger daraus mitnehmen sollten

Die banale Lehre wäre: Cybercrime professionalisiert sich. Das stimmt, ist aber zu flach. Interessanter ist etwas anderes: Man sollte kriminische Angebote nicht erst dann ernst nehmen, wenn sie besonders untergründig aussehen. Die sichtbare Form kann ausgesprochen bürgerlich wirken: Landing Page, Produktnavigation, FAQ, Support, Terms, Pricing, Checkout.

Für Verteidiger ist außerdem die Unterscheidung aus dem LevelBlue-Report wichtig. Nicht jedes Protokollwort ist ein bestätigtes Feature im Basissample. Gleichzeitig wäre es gefährlich, QuimaRAT deshalb kleinzureden. Ein dünner Core mit Plugin-Lader kann in der Praxis unangenehmer sein als ein fettes statisches Implantat, weil die eigentliche Fähigkeit erst nach der ersten Verbindung, durch Module, Payloads oder nachgeladene Komponenten sichtbar wird.

Hunting nur auf Panel-Labels, Enum-Strings oder Marketingnamen wäre entsprechend schwach. Relevanter sind Core-Verhalten, Persistenzspuren, C2-Registrierung, Plugin-Cache, Modul-Loading und Folgeaktivität.

Die Grenze verläuft deshalb nicht zwischen hübscher und hässlicher Software. Sie verläuft zwischen legitimer Software und Software, deren Produktqualität direkt dazu dient, unautorisierte Überwachung, Paketierung, Auslieferung und Fernzugriff skalierbar zu machen.

QuimaRAT ist genau deshalb ein brauchbares Beispiel. Nicht weil die Seite zweifelsfrei belegt, dass hinter ihr ein stabiles Premium-MaaS-Angebot steckt. Sondern weil sie zeigt, wie wenig Malware-as-a-Service heute noch wie Underground aussehen muss, um weiterhin genau das zu sein.

Quellen und Hinweise