RatHat macht Androids eigene Debugging-Tools und generative KI zum dauerhaften Kontrollkanal

Eine neu identifizierte Android-Schadsoftwarefamilie namens RatHat kombiniert den Missbrauch von Accessibility, autonomes ADB-Pairing, Overlay-Angriffe zum Diebstahl von Zugangsdaten, native Hintergrunddienste und eine KI-gesteuerte Navigation durch Benutzeroberflächen. Forschende berichteten am 17. September 2026 über die Schadsoftware und schreiben ihren Betrieb in China ansässigen Bedrohungsakteuren zu.

RatHat erreicht seine Opfer über schädliche Anzeigen, SMS-Phishing, manipulierte Download-Seiten, Portale von Drittanbietern und Foren. Diese Kampagnen bringen Nutzer dazu, außerhalb von Google Play gehostete APK-Pakete per Sideloading zu installieren.

Nach der Installation und der Erteilung von Accessibility-Berechtigungen kann RatHat Wireless Debugging aktivieren, eine Verbindung zum lokalen Android-ADB-Dienst des Geräts herstellen und Shell-Zugriff erlangen. Seine Komponenten können den Zugriff anschließend aufrechterhalten, selbst wenn das Opfer die sichtbare Android-Anwendung entfernt.

Per Sideloading installierte APKs öffnen den Weg für den Missbrauch von Accessibility

Die ursprüngliche APK fungiert als Dropper für die primäre RatHat-Nutzlast. Außerdem enthält sie Schutzmechanismen, die eine automatisierte Untersuchung, das Debugging und das Reverse Engineering erschweren sollen.

Die Infektion beruht in hohem Maß auf Social Engineering. Android-Nutzer müssen das Paket außerhalb von Google Play installieren und anschließend Berechtigungen erteilen, die der Anwendung weitreichende Kontrolle über die Benutzeroberfläche geben.

Accessibility-Dienste stehen im Zentrum des Angriffs. Sie wurden zwar entwickelt, um die Interaktion mit Geräten zu erleichtern, können bei missbräuchlicher Verwendung aber auch dazu dienen, dass eine Anwendung Elemente der Benutzeroberfläche beobachtet und simulierte Aktionen ausführt.

Nach Erhalt dieses Zugriffs kann RatHat durch die Android-Einstellungen navigieren, die Entwickleroptionen aktivieren, Wireless Debugging einschalten und den sechsstelligen Code für das ADB-Pairing auslesen. Dadurch kann die Schadsoftware eine lokale Debugging-Verbindung herstellen, ohne dass ein vom Angreifer kontrollierter Computer physisch angeschlossen sein muss.

Diese Methode des selbstständigen Pairings verschafft RatHat Zugriff auf eine ADB-Shell und auf Funktionen, die über die direkt in der schädlichen Anwendung implementierten Möglichkeiten hinausgehen. Ähnliche Mechanismen wurden bereits bei den Android-Schadsoftwarefamilien ToxicPanda und RedHook beobachtet.

Die betroffenen Android-Versionen wurden nicht offengelegt. Derzeit liegen keine Namen schädlicher Pakete, Hashes, Domains, IP-Adressen oder anderen kampagnenspezifischen Indikatoren vor.

Drei Komponenten sorgen für redundente Persistenz

RatHat verwendet drei miteinander kooperierende Ebenen, statt sich auf ein einzelnes Android-Paket zu verlassen.

Die erste Ebene ist die schädliche Anwendung selbst. Sie verwaltet den Accessibility-Zugriff, aktiviert Debugging-Funktionen, installiert weitere Komponenten, zeigt Phishing-Overlays an, fängt Kommunikation ab, zeichnet den Bildschirm auf und verhindert die Deinstallation.

Bei der zweiten Komponente handelt es sich um einen Go-basierten lokalen Agenten, der als liblocal-service.so getarnt oder verpackt ist. Der Agent läuft mit den über den lokalen ADB-Daemon erlangten Zugriffsrechten und kann vom Angreifer vorgegebene Befehle ausführen, Ausnahmen von der Akkuverwaltung anfordern, Persistenz einrichten sowie Tastatureingaben oder Bildschirmberührungen erfassen.

Der Agent überprüft außerdem, ob die Android-Schadsoftware noch installiert ist. Wurde die Anwendung entfernt, kann er sie erneut installieren.

Die dritte Ebene ist ein FRP-Reverse-Proxy-Client. Berichte über RatHats Architektur zufolge trägt die zugehörige Bibliothek den Namen libmedia_codec.so. Die Komponente erhält ihre Tunnelkonfiguration über den Go-Agenten und baut eine persistente Rückverbindung zur Command-and-Control-Infrastruktur auf.

Dieser Tunnel verschafft den Betreibern unabhängig von RatHats integrierten Befehlen einen universell einsetzbaren Zugang zum ADB-Daemon des Geräts. Dadurch kann der Zugriff auch dann aufrechterhalten werden, wenn einzelne Funktionen der Schadsoftware gestört werden.

Die Persistenz funktioniert in beide Richtungen. Die Android-Anwendung kann den lokalen Agenten wiederherstellen, wenn dieser beendet wird oder verschwindet, während der Agent die Anwendung erneut installieren kann. Wird lediglich das App-Symbol oder das sichtbare Paket entfernt, kann das Gerät daher weiterhin kompromittiert sein.

RatHat greift außerdem aktiv in die Deinstallation ein. Die Schadsoftware bricht den Android-Bestätigungsdialog ab und zeigt einen gefälschten Fehlerbildschirm im Stil von Google Play an. Dadurch entsteht beim Opfer der Eindruck, die Entfernung sei aus einem legitimen Systemgrund fehlgeschlagen.

Generative KI interpretiert aktuelle Android-Bildschirme

Das herausragende Merkmal von RatHat ist ein KI-gestützter Kontrollmechanismus, der die aktuelle Benutzeroberfläche interpretiert, anstatt vollständig auf festen Koordinaten und vordefinierten Skripten zu beruhen.

Die Schadsoftware serialisiert die aktuelle Android-Accessibility-Hierarchie als XML. Diese Darstellung sendet sie anschließend an einen nicht näher bezeichneten, weit verbreiteten Assistenten für generative KI.

Das KI-System wird Berichten zufolge für drei Aufgaben eingesetzt:

• Ein benanntes Benutzeroberflächenelement finden und seine Mittelpunktkoordinaten im JSON-Format zurückgeben.
• Den aktuell von einem ausgewählten Element angezeigten Text auslesen.
• Navigationsanweisungen wie SCROLL_DOWN erzeugen.

Dadurch entsteht eine dynamische Entscheidungsschleife. Ändert eine Schaltfläche ihre Position, zeigt eine Anwendung einen anderen Text an oder erfordert ein Bildschirm das Scrollen, kann die KI den aktualisierten Accessibility-Baum interpretieren und die nächste Aktion vorschlagen.

Starre Automatisierungen brechen häufig zusammen, wenn Anwendungen ihre Layouts, Sprachen oder Benutzeroberflächenzustände ändern. RatHats Ansatz ermöglicht es Betreibern stattdessen, ein Zielelement zu beschreiben und einen Teil der Navigation an den KI-Dienst zu delegieren.

Die Identität des Assistenten ist unbekannt. Die Forschenden haben weder das Modell noch den Anbieter, das Kommunikationsprotokoll, die Kontostruktur oder die Frage offengelegt, ob der Dienst direkt oder über eine von den Angreifern kontrollierte Infrastruktur angesprochen wird.

Diese Funktion macht die Schadsoftware nicht in jeder Hinsicht autonom. RatHat ist weiterhin auf eine umfassende Kontrollarchitektur, Command-and-Control-Anweisungen, Accessibility-Zugriff und lokale ADB-Ausführung angewiesen. Die KI reduziert jedoch den Aufwand für die Betreiber, jeden Bildschirm manuell zu bedienen oder für jede Variante der Benutzeroberfläche eigene Skripte zu pflegen.

Bankbetrug ist nur ein Teil der Bedrohung

RatHat kann HTML-Overlays über Banking- und Kryptowährungsanwendungen legen, um Zugangsdaten abzugreifen. Außerdem kann die Schadsoftware SMS-Nachrichten und Benachrichtigungen abfangen und dadurch möglicherweise für die Authentifizierung verwendete Einmalpasswörter auslesen.

Die Überwachungsfunktionen erstrecken sich auf das gesamte Gerät. Dazu gehören:

• Erfassen von PINs, Passwörtern und Entsperrmustern für den Sperrbildschirm.
• Aufzeichnen von Zugangsdaten, die in Anwendungen eingegeben werden.
• Überwachen von Textänderungsereignissen und Tastatureingaben.
• Erfassen von URLs, die in Browser-Adressleisten eingegeben werden.
• Aufzeichnen von Bildschirmberührungen über den Go-Agenten.
• Erstellen von Screenshots und Aufzeichnungen über Androids MediaProjection API.
• Sammeln von Dateien und einer Liste der installierten Anwendungen.
• Fernsteuern von Anwendungen und Systemeinstellungen.
• Ausführen beliebiger Befehle über die ADB-Shell.

Der Reverse-Tunnel vergrößert die Auswirkungen, da er über ein festgelegtes Menü von Schadsoftwarefunktionen hinaus dauerhaften Zugriff ermöglicht. Ein Betreiber mit einem Zugang zum ADB-Daemon kann Shell-Funktionen nutzen, die das kompromittierte Gerät bereitstellt.

RatHat stellt daher eine Gefahr für Bankkonten, Kryptowährungsdienste, private Nachrichten, gespeicherte Dateien, Authentifizierungscodes und Geheimnisse zum Entsperren des Geräts dar. Bildschirmaufzeichnungen und die Überwachung von Berührungen können außerdem Informationen offenlegen, die durch herkömmliche Credential-Overlays nicht erfasst würden.

Die Kampagne folgt einem breiteren Muster von Android-Bedrohungen, die per Sideloading installierte Pakete für invasive Überwachung einsetzen. Ein weiteres aktuelles Beispiel ist die Mantax-Otax-Schadsoftware, die ebenfalls über APKs außerhalb von Google Play verbreitet wurde, sich hinsichtlich ihrer Funktionen und Architektur jedoch von RatHat unterscheidet.

Manipulierte APK-Strukturen erschweren die Untersuchung

Die Entwickler von RatHat verwenden mehrere Anti-Analyse-Techniken, um in Androids eigenen Parsern und gängigen Reverse-Engineering-Tools unterschiedliches Verhalten auszulösen.

Einige Dateien werden als Verzeichnisse deklariert oder mit dem ZIP-General-Purpose-Encryption-Flag versehen. Androids libziparchive kann diese Einträge ignorieren, während Dienstprogramme wie unzip und apktool sie anders verarbeiten.

Die AndroidManifest.xml enthält undokumentierte 0x9999-Chunk-Header. Die native Android-Laufzeit überspringt diese Strukturen, automatisierte Analysesysteme können jedoch abstürzen, in eine Zeitüberschreitung laufen oder das Paket nicht parsen. Außerdem soll das Manifest eine Größe von 61 MB erreichen – ein ungewöhnlicher Umfang, der Analyse-Pipelines zusätzlich belastet.

RatHat fügt darüber hinaus ungültige DEX-Pseudoanweisungen mit einem fehlerhaften element_width-Attribut ein, was Disassembler beschädigen kann. Ein als StringCrypto: Base64 bezeichnetes Verfahren zum Schutz von Zeichenfolgen erschwert die statische Untersuchung zusätzlich.

Diese Schutzmaßnahmen verschaffen keinen direkten Zugriff auf das Gerät. Sie sollen die Klassifizierung verzögern, widersprüchliche Ergebnisse in verschiedenen Tools erzeugen und die Zuverlässigkeit automatisierter Malware-Analyseprozesse verringern.

Die Forschenden gehen davon aus, dass RatHat von in China ansässigen Akteuren betrieben wird. Chinesischsprachige an das KI-Subsystem gesendete Prompts stützen diese Einschätzung, eine bestimmte Bedrohungsgruppe wurde jedoch nicht bestätigt. Die Zuordnung bleibt vorläufig.

Die Erkennung muss über die sichtbare Anwendung hinausgehen

Nutzer sollten APKs meiden, die über unaufgeforderte Textnachrichten, Anzeigen, Foren, Phishing-Seiten oder unbekannte Download-Portale beworben werden. Anwendungen sollten keinen Accessibility-Zugriff erhalten, sofern ihre legitime Funktion dies nicht eindeutig erfordert.

Die unerwartete Aktivierung der Entwickleroptionen oder von Wireless Debugging ist ein ernstzunehmendes Warnsignal. Nutzer sollten außerdem ungeklärte ADB-Pairing-Aufforderungen, Anfragen nach Ausnahmen von der Akkuverwaltung, verdächtige Berechtigungen für Bildschirmaufzeichnungen und Anwendungen untersuchen, die bei der Entfernung Fehler im Stil von Google Play anzeigen.

Scans mit Google Play Protect können helfen, schädliche Anwendungen zu erkennen. Die unabhängigen Dienste von RatHat machen die Reaktion jedoch komplizierter, als lediglich eine APK zu löschen.

Unternehmen und Teams für mobile Sicherheit sollten nach Folgendem suchen:

• Nicht autorisierte Accessibility-Dienste.
• Unerwartete Aktivierung von Wireless Debugging.
• Nicht erkannte lokale ADB-Pairing-Ereignisse.
• Native Bibliotheken mit den Namen liblocal-service.so oder libmedia_codec.so.
• Ungewöhnlicher Datenverkehr eines FRP-Reverse-Proxys.
• Persistente Prozesse, die die Entfernung der Anwendung überstehen.
• Wiederholte Installation eines zuvor gelöschten Pakets.
• Gefälschte Google-Play-Bildschirme, die einen Fehler bei der Deinstallation anzeigen.

Die Bibliotheksnamen allein sind kein ausreichender Infektionsnachweis und sollten gemeinsam mit Prozess-, Paket-, Netzwerk- und ADB-Aktivitäten bewertet werden.

Ein vollständiges Verfahren zur Behebung wurde von keinem Anbieter veröffentlicht. Da RatHats Go-Agent die Entfernung der primären Anwendung überstehen und sie anschließend erneut installieren kann, müssen Incident-Responder überprüfen, ob auch der über ADB zugängliche Dienst und der Reverse-Tunnel vollständig entfernt wurden. Andernfalls beseitigt eine scheinbare Entfernung möglicherweise nur den sichtbarsten Teil der Kompromittierung.