Eine neue Android-Car-Malware richtet sich gezielt gegen Android-basierte Fahrzeug-Headunits. Dabei geht es nicht um einen klassischen App-Download aus einem Store, sondern um eine Angriffsroute, die in vorhandene Software-Update-Funktionen eingebaut ist. Kaspersky hat die Bedrohung im Juni 2026 entdeckt und beschreibt eine mehrstufige Lieferkette, die am Ende unauffällig im Hintergrund arbeitet.
Im Kern missbraucht die Kampagne legitime Update-Mechanismen, um schädliche Komponenten nachzuladen. Auf diese Weise lassen sich unerwünschte Werbung ausspielen, zusätzliche Module installieren und zugleich die Grundlage für ein Proxy-Botnet schaffen.
Warum Car-Headunits ein attraktives Ziel sind
Eine Headunit ist das zentrale Bedien- und Medien-Hub im Fahrzeug. Sie bündelt Multimedia-Funktionen und kann in Teilen auch Steuerfunktionen beeinflussen. Je nach Fahrzeug kann sie werkseitig verbaut sein oder als Nachrüstung ausgetauscht werden.
Da Android-Headunits sowohl im Aftermarket als auch bei werksseitig ausgelieferten Fahrzeugen verbreitet sind, lässt sich über sie ein großer Anteil typischer Apps und damit potenziell auch Malware erreichen. Für Angreifer kommt außerdem hinzu, dass viele dieser Geräte über einen SIM-Karten-Slot verfügen. Dadurch ist ein direkter Internetzugang für Navigation, aber auch für Updates möglich.
Wie die Android-Car-Malware über Updates geliefert wird
Die Sicherheitsforscher ordnen die Aktivität mit hoher Wahrscheinlichkeit einer Gruppe zu, die im Rahmen der Auswertung eines größeren Ad-Fraud- und Residential-Proxy-Schemas namens BADBOX öffentlich gemacht wurde. Bereits im Jahr 2025 reichte Google Klage gegen mehrere nicht näher benannte Beteiligte in China ein, die angeblich am BADBOX-Botnet und seiner Infrastruktur beteiligt waren.
In dem beschriebenen Fall nutzt die Android-Car-Malware die Update-Funktion in mehreren Modellen von DoFun-Headunits. Nach dem verantwortungsvollen Disclosure wurde der konkrete Missbrauch der Software-Verteilungskette behoben.
Der Startpunkt ist eine legitime System-App namens TWCore mit dem Package-Namen com.tw.core. Diese App ist dafür vorgesehen, Analysedaten zu sammeln und die Headunit-Software in Form von APK-Dateien zu aktualisieren. Dazu verwendet sie einen MQTT-Message-Broker, der über das Subdomain-Setup aufgerufen wird.
Die APK-Datei wird anschließend in einem spezifischen Cache-Pfad abgelegt, damit sie zur Installation bereitsteht. Genau an dieser Stelle setzt die Manipulation an: Die Angreifer weaponisieren den Update-Kanal, um statt harmloser Updates eine bisher unbekannte Schadsoftware zu platzieren.
Von einem Dropper zur nächsten Stufe
Der eingesetzte Dropper wird als JarService bezeichnet. Seine Aufgabe ist es, einen Loader zu starten und Informationen an eine Angreifer-Serverinfrastruktur zu senden. Das geschieht über eine HTTP-POST-Anfrage.
Als Antwort liefert der Server einen Link, über den der nächste Payload-Baustein heruntergeladen wird. Auffällig ist dabei, dass der Name der Payload eine Versionsreferenz enthält, zum Beispiel dex3.68. Dadurch kann Kaspersky mehrere Varianten identifizieren, indem die Versionen schrittweise abgerufen werden (innerhalb eines abgeleiteten Bereichs).
Damit endet die Kette nicht bei einem einzelnen Nutzerprozess. Stattdessen wird die Malware als normale User-Anwendung installiert, verfügt jedoch über keine sichtbare Bedienoberfläche. Sie läuft im Hintergrund und ist auf unauffällige Persistenz ausgelegt.
Unauffällige Hintergrundarbeit und Steuerung via C2
Nach der Installation kommuniziert die Malware standardmäßig im Abstand von etwa 90 Minuten mit einem Command-and-Control-Endpunkt. Dabei werden Informationen über das infizierte Gerät und die Konfigurationsversion übertragen.
Wenn die Konfiguration veraltet ist, antwortet der C2-Server mit aktualisierten Einstellungen. Dazu gehören neue Adressen sowie neue Pfade für weitere HTTP-Anfragen. Falls eine Aktualisierung nicht erforderlich ist, liefert der Server stattdessen numerische Befehlselemente. Diese werden als productId bezeichnet.
Die Malware mappt diese Kennungen auf konkrete Befehlsdetails und speichert die Ergebnisse als serialisiertes JSON-Objekt über die SharedPreferences-API. Auf dieser Basis kann sie unterschiedliche Funktionen ausführen, ohne dass dem Nutzer eine grafische Oberfläche auffällt.
Befehle der Malware: Werbung, Module und Datenabgriff
Die Android-Car-Malware unterstützt laut Analyse neun Befehle. Sie sind darauf ausgelegt, unerwünschte Werbung zu triggern, Ad-Fraud-Funktionen umzusetzen und weitere bösartige Module nachzuladen. Zusätzlich kann sie umfangreiche Geräteinformationen sammeln.
Zu den abgefragten Daten gehören unter anderem die Displayauflösung, das Gerätemodell, der Kennname des verbundenen WLANs sowie die MAC-Adresse. Damit lässt sich die Zielumgebung gezielt anpassen oder für spätere Kampagnen segmentieren.
Die beschriebenen Befehle lauten:
- return: gibt einen Wert aus SharedPreferences zurück
- copy: setzt Inhalte in der Zwischenablage (Clipboard)
- http: führt eine POST-/GET-HTTP-Anfrage zu einer angegebenen Ressource aus
- web: öffnet einen Link in WebView und kann dort JavaScript ausführen
- loadlib: nicht vollständig umgesetzt
- loadlib2: lädt beliebigen Code von einer URL herunter und führt ihn aus
- loadlib3: nicht vollständig umgesetzt
- deeplink: öffnet eine URL im Browser
- traceroute: prüft die Erreichbarkeit über einen ICMP-„Ping“
Reverse-Proxy-Modul und Nähe zu bestehenden Kampagnen
Besonders relevant ist, wie die Angreifer zusätzliche Komponenten nachladen. In der Analyse wird beschrieben, dass vor allem die Befehle loadlib2 und http genutzt werden, um das Modul zhima zu laden.
Dieses Reverse-Proxy-Modul wurde laut Angaben bereits von einem Emergency Response Team von Nokia Deepfield im vergangenen Monat dokumentiert. Es wird selektiv ausgeliefert und soll sich in bestimmten Szenarien über kompromittierte IPTV-Apps ausbreiten können, die auf günstigen Android-TV-Boxen installiert sind.
Im aktuellen Fall sorgt die Kombination aus Update-Missbrauch und Befehlslogik dafür, dass die Fahrzeug-Headunit nicht nur als „Transportweg“ dient, sondern auch als Plattform für weitere Aktionen. Dadurch entsteht eine Verbindung zwischen Fahrzeug-Infrastruktur und den typischen Elementen von Proxy- und Ad-Fraud-Operationen.
Warnsignal für die Automobil-Sicherheitslage
Die Forscher betonen, dass dies der erste dokumentierte Fall sei, bei dem eine Malware eine gezielt angepasste Infektionskette für Car-Headunits nutzt. Gerade weil die Lieferroute über legitime Systemfunktionen erfolgt, kann die Erkennung deutlich erschwert werden.
Auch wenn Maßnahmen gegen das Umfeld der BADBOX-Operationen in der Vergangenheit verfolgt wurden, laufen offenbar weiterhin einzelne Aktivitäten, die mit entsprechenden Akteuren verbunden sind. Betroffen können damit weiterhin Geräte weltweit sein.
Für Betreiber und Hersteller ist das ein klares Signal: Moderne Automotive-Plattformen benötigen einen besonders robusten Schutz gegen Malware—nicht nur an der Fahrzeuginfrastruktur selbst, sondern auch bei den Komponenten, die Updates ausführen und Software nachladen.
Was Fahrzeugnutzer und Betreiber daraus ableiten können
Auch wenn Endnutzer nicht alle technischen Details kontrollieren, lässt sich der Handlungsbedarf klar formulieren: Updates sollten konsequent durchgeführt werden, sobald Hersteller oder Anbieter sie bereitstellen. Wer im Fahrzeugbetrieb Admin- oder Management-Zugänge für das System hat, sollte zudem die Update- und Kommunikationswege im Blick behalten.
Für Organisationen, die Flotten verwalten oder Nachrüstlösungen einsetzen, gilt: Transparenz über verwendete System-Apps und deren Updatepfade hilft, Auffälligkeiten schneller zu erkennen. Besonders kritisch ist alles, was auf vermeintliche Firmware- oder App-Updates aus internen oder externen Quellen hinausläuft.
Die Android-Car-Malware-Geschichte zeigt, wie schnell aus einer Funktion für legitime Aktualisierungen eine Einfallstore werden können.
Fazit
Die gemeldete Kampagne macht deutlich, wie gezielt eine Android-Car-Malware über eingebaute Update-Mechanismen von Android-Headunits verteilt werden kann. Von TWCore als legitimer System-App bis zur Hintergrundinstallation ohne Benutzeroberfläche nutzt die Angriffslogik einen mehrstufigen Weg, um Werbung zu manipulieren, zusätzliche Module nachzuladen und C2-Kommunikation aufzubauen.
Für die Automotive-Sicherheit ist das ein dringendes Warnsignal: Software-Verteilung und Update-Kanäle müssen als besonders schützenswert betrachtet werden, weil sie sonst zum Werkzeug für schädliche Kampagnen werden.
Quelle: https://thehackernews.com/2026/08/android-car-malware-spreads-through.html
