RatHat besteht aus drei Hauptbestandteilen: der schädlichen Android-App, einem in Go geschriebenen Agenten und einem FRP-Client als Reverse-Proxy. Die App dient als Türöffner: Sie erlangt die Berechtigung für die Bedienungshilfen und missbraucht diese, um die Entwickleroptionen freizuschalten, das drahtlose Debugging zu aktivieren und den sechsstelligen ADB-Kopplungscode auszulesen. Damit koppelt sich die Malware lokal selbst an den ADB-Daemon und verlässt die Sandbox.

Der Go-Agent tarnt sich als native Bibliothek mit dem Namen “liblocal-service.so” und nutzt den erlangten Shell-Zugriff, um Befehle auszuführen, Persistenz einzurichten und Ausnahmen bei der Energieverwaltung zu setzen. Der FRP-Client baut einen dauerhaften, verschlüsselten Reverse-Tunnel zum Command-and-Control-Server auf. Die Tunnel-Konfiguration holt sich der Go-Agent vom C2-Server. Laut Zimperium verschafft diese Verbindung den Angreifern Zugang zum ADB-Daemon: “Es ist ein Allzweckweg in das Gerät hinein, der alles transportiert, was der Betreiber will – unabhängig vom eigenen Funktionsumfang der Malware.”

Das Befehlsrepertoire ist umfangreich. RatHat sammelt SMS-Nachrichten, Zugangsdaten, Dateien, den Sperrbildschirm-PIN, das Muster oder Passwort, Bildschirmaufnahmen, Tastatureingaben einschließlich in der Browser-Adresszeile eingegebener URLs sowie eine Liste installierter Anwendungen. Zusätzlich enthält die Schadsoftware einen vom Go-Agenten ausgeführten Keylogger auf Hardware-Ebene, der Fingerdrucke auf dem Bildschirm aufzeichnet.

Anzeige

Zum Abgreifen von Zugangsdaten blendet RatHat Overlays über bestimmten Apps ein. Der Bildschirm wird über Androids MediaProjection-API mitgeschnitten, SMS werden abgefangen. Installationsversuche unterbindet die Malware, indem sie ein gefälschtes Fehler-Overlay im Design des Google Play Store anzeigt.

Besondere Aufmerksamkeit widmen die Forscher der KI-Komponente. Der Accessibility-Baum des Geräts wird in XML überführt und an einen generativen KI-Assistenten geschickt. Dieser übernimmt nach Darstellung von Zimperium ausschließlich unbedenkliche Teilaufgaben: Er bestimmt die Mittelpunktkoordinaten eines benannten Ziels auf dem Bildschirm als JSON, um synthetische Klicks zu steuern, löst den tatsächlichen Bildschirmtext eines Ziels aus dem XML auf und gibt Navigationsbefehle wie SCROLL_DOWN aus.

Um der Analyse zu entgehen, bringt der Dropper vier Techniken mit. Beim Container Tampering werden einzelne Dateien im Paket als Verzeichnisse deklariert oder das Verschlüsselungs-Flag im ZIP-Header gesetzt, sodass Androids libziparchive sie ignoriert, Werkzeuge wie unzip und apktool aber nicht. Eine “Manifest Bomb” platziert undokumentierte Chunk-Header vom Typ 0x9999 in der Datei “AndroidManifest.xml”, die die native Laufzeitumgebung überspringt – automatisierte Analyseketten stürzen ab oder laufen in einen Zeitüberschreitungsfehler. Hinzu kommen vergiftete DEX-Bytecodes mit Pseudo-Instruktionen und ungültigem element_width-Attribut, an denen die Disassemblierung scheitert, sowie eine doppelte Zeichenkettenverschlüsselung nach dem Schema StringCrypto: Base64.

Zimperium verweist auf die mehrstufige Architektur, die Daemons außerhalb des App-Lebenszyklus und die Echtzeit-Entscheidungsschleifen mit generativer KI als Gründe dafür, dass klassische signaturbasierte Schutzmechanismen für Mobilgeräte hier nicht ausreichen.