Midnight-Mimosa-Malware steckt in Android-Firmware und erreicht mehr als 150 Länder

Kompromittiertes Smartphone vor dem ersten Einschalten

Tausende Android-Geräte in mehr als 150 Ländern sind von Midnight Mimosa betroffen. Bei dieser Malware-Kampagne wird Schadsoftware in die Telefon-Firmware eingeschleust, bevor Käufer ihre Geräte einschalten. Bitdefender identifizierte mindestens 32 getarnte Apps, die im Rahmen der Kampagne installiert wurden, sowie 13 Google-Play-Apps mit demselben Code für Werbebetrug, die mit der Steuerungsinfrastruktur kommunizierten.

Die am 8. Oktober 2026 veröffentlichten und am 9. Oktober aktualisierten Ergebnisse beschreiben eine Operation, die über einen Zeitraum von etwa zwei Jahren beobachtet wurde. Zu den betroffenen Geräten zählen günstige Smartphones mit MediaTek-Plattformen, Fälschungen mit Modellnamen von Apple und Samsung sowie Geräte, die sich als Doogee S200 X und Cubot KINGKONG X ausgeben.

Die zentrale Erkenntnis im technischen Bericht von Bitdefender lautet, dass sich die Infektion nicht darauf beschränkt, dass Käufer eine verdächtige App herunterladen. Eine schädliche Systemkomponente wird mit dem Gerät ausgeliefert, verfügt über umfangreiche Berechtigungen im Betriebssystem und kann ohne Nachfrage beim Besitzer weitere Software installieren.

Dadurch ist die Bedrohung ungewöhnlich schwer zu beseitigen. Wer eine unerwünschte Wetter-App oder App-Sperre löscht, entfernt womöglich einen sichtbaren Teil der Operation, lässt aber die Komponente unangetastet, die sie installiert hat. Die Forscher beobachteten, dass Payloads auf denselben Geräten wiederholt auftauchten und verschwanden.

Die Untersuchung hat jedoch auch Grenzen. Sie konnte nicht feststellen, wer die Malware in die Firmware eingeschleust hat. Die Forscher fanden Code, der Datenverkehr über infizierte Telefone weiterleiten kann, doch ihr Testgerät erhielt keine Weiterleitungsaufträge. Den Betreibern standen sensible Berechtigungen zur Verfügung, ihr Einsatz wurde während der Analyse jedoch nicht beobachtet.

Die versteckte Komponente, die Installationen steuert

Die Untersuchung begann, als Bitdefenders Verhaltenserkennung com.android.system.lite meldete. Der Name und die allgemeine Bezeichnung System ließen auf eine gewöhnliche Android-Komponente schließen, doch ihr Verhalten war anders: Sie installierte und entfernte unbemerkt andere Apps und aktivierte wiederholt sensible Zugriffsrechte.

Die Komponente hatte kein sichtbares Launcher-Symbol. Sie war für die Android-Plattform signiert, lief als Systemnutzer und war so konfiguriert, dass sie dauerhaft aktiv blieb. Zu ihren Berechtigungen gehörten das Installieren und Löschen von Paketen, das Erteilen von Berechtigungen für andere Apps und das Ändern sicherer Einstellungen. Diese Möglichkeiten gehen weit über das hinaus, was einer App normalerweise zur Verfügung steht, die ein Besitzer selbst herunterlädt.

Die Forscher fanden denselben schädlichen Kern später auch unter anderen Namen, darunter com.android.sys.prot, com.android.sys.gmsprot und com.android.sys.bcprot. Ein weiteres von Smartphone-Besitzern gemeldetes Paket, com.android.non.szcz, wurde derselben Familie zugeordnet. Verschiedene Versionen verwendeten unterschiedliche Namen und teilweise auch unterschiedliche Signaturzertifikate.

Das ist für Erkennung und Bereinigung wichtig: Ein einzelner Paketname steht nicht für die gesamte Bedrohung. Auch auf einem Telefon ohne com.android.system.lite kann eine andere Version derselben Schadsoftware vorhanden sein. Das gemeinsame Verhalten und der zugrunde liegende Code sind aussagekräftigere Erkennungsmerkmale als die Bezeichnung in der Android-App-Liste.

Wie aus der Ferne geladener Code das Verhalten des Telefons verändert

Ein Großteil der schädlichen Logik war in einer nativen Bibliothek namens libeasy.so verborgen und nicht im gewöhnlichen Code der System-App zu sehen. Bei der Initialisierung nutzte die Bibliothek RC4-Verschlüsselung, um ein eingebettetes Framework von etwa 142 KB zu verbergen und anschließend wiederherzustellen.

Dieses Framework rief Konfigurationen von einem Command-and-Control-Server ab, also einem entfernten Dienst, über den Betreiber infizierte Geräte steuern. Es konnte DEX- und JAR-Dateien herunterladen und laden, Formate, in denen ausführbarer Android- und Java-Code verpackt wird. Dadurch konnten die Betreiber das Verhalten des Geräts auch nach dem Verkauf ändern.

Die Forscher identifizierten drei Plugin-Familien. Eine davon, zugeordnet zu com.wz.sdk.DxFactory, verarbeitete fingierte Werbeeinblendungen und Klicks. Die anderen, zugeordnet zu com.earnsdk.lib.DxFactory und com.gogo.third.lib.DxFactory, unterstützten die unbemerkte Installation und Entfernung anderer Apps. Letztere verfügte außerdem über WebView-Funktionen.

Die Systemkomponente fungierte somit als dauerhafter Steuerungsmechanismus und nicht als einzelne, unveränderliche Werbe-Malware. Das Entfernen der aktuellen Payload würde sie nicht daran hindern, am nächsten Tag eine weitere abzurufen. Durch das Laden von Code aus der Ferne und das Erteilen privilegierter Berechtigungen konnte sie außerdem potenziell mehr tun, als während der Untersuchung beobachtet wurde.

Getarnte Alltags-Apps machen aus gefälschten Klicks Einnahmen

Der erkennbare Hauptzweck der Operation war offenbar, Geld zu verdienen. Die Forscher fanden mindestens 32 unterschiedliche Payload-Apps, die als Wetterdienste, App-Sperren, Dateimanager, Symbol-Tools, Texterkennungsprogramme und Audio-Editoren getarnt waren. Einige boten tatsächlich Funktionen, andere erfüllten die Aufgabe, die ihr Name nahelegte, nicht in nennenswertem Umfang.

Ein Beispiel, com.mobile.applock.wt, gab sich als App-Sperre aus, verfügte aber weder über die nötige Benutzeroberfläche noch über den erforderlichen Code für diese Funktion. Die App war für den Nutzer verborgen und diente als weiterer Malware-Dropper, also als Programm, das zusätzliche Schadsoftware einschleust. Zu den weiteren identifizierten Payloads gehörten com.dmstudio.weather, com.dl.guard.lock und picturetranslate.extractor.text.lite.

Die Tarn-Apps enthielten legitime Software Development Kits (SDKs) für Werbung. Mit solchen Werkzeugen können Apps Werbung anzeigen und für Werbeaktivitäten vergütet werden. Dadurch erhielt der betrügerische Datenverkehr eine App- und Werbe-ID, der Einnahmen gutgeschrieben werden konnten.

Die Bitdefender-Sicherheitsforscher Adrian Mihai Gozob und Alex Baciu beschrieben die Aufgabenteilung zwischen der dauerhaft installierten Systemkomponente und den Tarn-Apps:

Die System-App selbst registriert die gefälschten Einblendungen und Klicks nicht.

Die Steuerungskomponente lieferte Anweisungen, Zeitvorgaben und künstliche Interaktionen, während die Werbe-IDs zu den Tarn-Apps gehörten. Die Apps kommunizierten über gemeinsame Dienste und meldeten dieselbe Geräte-ID an eine Infrastruktur, zu der auch ein als Wetter-API getarnter Steuerungsdienst gehörte. So wurden scheinbar unabhängige Dienstprogramme zu einer koordinierten Werbeoperation verknüpft.

Die technische Analyse ergab automatische Klicks ohne Berührung durch den Nutzer, zufällig ausgewählte Werbeziele, Tageslimits und Zeitabstände zwischen fingierten Interaktionen. Außerdem identifizierten die Forscher eine automatische Meldung von Conversions nach einem Timer von 60 Sekunden. Diese Steuerungen konnten die gefälschten Aktivitäten dosieren, statt ununterbrochen identische Ereignisse zu erzeugen.

Google Play ist sowohl Ziel von Umgehungsversuchen als auch Verbreitungsweg

Bevor die Malware eine Payload installierte, deaktivierte sie vorübergehend com.android.vending, die Google-Play-Store-App. Anschließend aktivierte sie die App wieder; außerdem gab es eine Schutzvorkehrung, die sie wiederherstellte, sobald der Nutzer anwesend war. Bitdefender wertete dies als wahrscheinlichen Versuch, der Erkennung durch Play Protect zu entgehen, nicht als Beweis dafür, dass jede Installation die Prüfung umging.

Einige Varianten manipulierten zudem die Installationsvermerke von Android, sodass von der Malware installierte Software den Anschein erweckte, aus Google Play zu stammen. Dadurch konnte eine unbekannte App weniger verdächtig wirken, wenn ihr Besitzer überprüfte, woher sie kam.

Die Werbemechanismen nutzten auch Aktivitäten, die ohne Aufforderung des Nutzers geöffnet wurden, sowie Einblendungen über anderen Apps. Eine Werbefläche war als sicher gekennzeichnet und erschien daher nicht in Screenshots oder Bildschirmaufzeichnungen. Der Bericht beschreibt sowohl verborgene Werbeaktivitäten als auch aufdringliche Einblendungen. Die Operation war also nicht ausschließlich unsichtbar.

Google Play diente außerdem als eigenständiger Verbreitungsweg. Die Forscher identifizierten 13 veröffentlichte Apps, die denselben Code für Werbebetrug enthielten und mit der Infrastruktur von Midnight Mimosa kommunizierten. Sie verwendeten 13 verschiedene Signaturzertifikate und mindestens zwei Entwicklerkonten mit den Namen fivedev und CPS Developer.

Diese Store-Apps hatten nicht die erweiterten Berechtigungen der vorinstallierten Systemkomponenten. Dieser Unterschied ist erheblich: Durch den Download erhielt eine App nicht automatisch dieselben Möglichkeiten zur unbemerkten Installation wie eine kompromittierte Firmware-Komponente. Trotzdem konnten die Apps auch außerhalb ihrer eigenen Benutzeroberfläche Werbung anzeigen, etwa wenn der Besitzer das Telefon gerade nicht aktiv nutzte.

Zum Zeitpunkt der Berichterstattung waren zumindest einige der damit verbundenen Apps offenbar noch verfügbar; Google hatte auf eine Anfrage um Stellungnahme nicht umgehend reagiert. Ein bestätigter Zeitplan für ihre Entfernung liegt nicht vor. Die Befunde zu Play zeigen, dass sich das Risiko nicht auf gefälschte Hardware oder bereits bei der Herstellung kompromittierte Telefone beschränkte.

Proxy-Registrierung wurde beobachtet, aktive Weiterleitung nicht

Eine weitere Payload, com.mobile.applock.en, enthielt eine TCP-Proxy-Komponente. Ein Proxy leitet Internetverkehr im Auftrag anderer weiter. Stammt die Verbindung von einem gewöhnlichen Smartphone-Besitzer, kann der Datenverkehr so wirken, als käme er von dessen Internetadresse und nicht von der Partei, die ihn tatsächlich steuert.

Die Komponente registrierte Geräte bei einem entfernten Server und konnte Anweisungen erhalten, eine Verbindung zu bestimmten Zielen herzustellen und Datenverkehr weiterzuleiten. Solche Funktionen könnten ein Netzwerk aus der Ferne gesteuerter Geräte unterstützen, also ein Botnetz, und durch den Verkauf des Zugriffs auf diese Verbindungen eine weitere Einnahmequelle schaffen.

Bitdefender bestätigte, dass die Proxy-Infrastruktur die Registrierung seines Testgeräts akzeptierte. Während der Tests erhielt das Gerät jedoch keine Weiterleitungsziele. Die Untersuchung wies somit die Registrierung und die Fähigkeit zur Weiterleitung nach, nicht aber eine aktive Weiterleitung auf diesem Testgerät.

Dieselbe Einschränkung gilt für DDoS-Angriffe, bei denen ein Ziel mit Datenverkehr von vielen Geräten überlastet wird. Die Forscher nannten eine mögliche Beteiligung an Botnetzen und solchen Angriffen als denkbare Einsatzgebiete. Die Ergebnisse belegen weder, dass Midnight-Mimosa-Telefone einen konkreten Angriff ausführten, noch, wer Zugriff auf ihre Verbindungen kaufte.

Welche Geräte und Länder tauchten in den Ergebnissen auf?

Mexiko, Frankreich und Italien standen bei der geografischen Verteilung an der Spitze, gefolgt von den Vereinigten Staaten, Deutschland, Brasilien und Spanien. Die Zahlen umfassen Tausende unterschiedliche Geräte über einen Zeitraum von etwa zwei Jahren. Eine genaue Gesamtzahl für die Kampagne wurde nicht genannt. Es handelt sich um erkannte Fälle, nicht um eine vollständige Erfassung aller verkauften infizierten Telefone.

Mehr als 11 % der kompromittierten Geräte gaben sich als KINGKONG X aus, ein Modellname, der mit Cubot verbunden ist. Mehr als 4 % identifizierten sich als S200 X, das mit Doogee verbunden ist. Zusammen machten diese beiden gemeldeten Modellgruppen mehr als 15 % der erkannten Fälle aus. Auch das Cubot Kingkong 9 wurde in Berichten über die Untersuchung genannt.

Die 15 am häufigsten vertretenen Telefonmarken entfielen auf 35,8 % der infizierten Geräte. Rund 64 % wurden der Gruppe „Sonstige“ zugeordnet; die angegebene Zahl ist gerundet. Die Verteilung deutet auf einen zersplitterten betroffenen Markt hin und nicht auf eine Operation, die sich auf eine einzige bekannte Marke beschränkt.

Zu den gefälschten Modellbezeichnungen gehörten i17 Pro Max, i16_Pro_Max, 17_Pro_Max, S25 Ultra, S24 Ultra und Note 18 Ultra. Auch der Tablet-Name iPadAirPro tauchte auf. Diese Bezeichnungen wurden von günstigen Android-Geräten gemeldet und sind kein Beleg dafür, dass echte Apple- oder Samsung-Produkte die Malware enthielten.

Modellkennungen sind nur bedingt verlässliche Belege, da sich die Identität eines Geräts durch Software falsch darstellen lässt. Der Nachweis auf bestimmten Modellen bedeutet außerdem nicht, dass jedes unter diesen Namen verkaufte Gerät infiziert war. Die technischen Befunde betreffen betroffene Geräte und Firmware-Versionen, nicht alle MediaTek-Produkte oder alle Telefone der genannten Marken.

Firmware-Zertifikate belegen keine Verantwortlichkeit

Ein Teil der betroffenen Firmware war mit Zertifikaten signiert, die den Namen Shenzhen Zediel trugen. Die Signatur ist wichtig, weil sie die schädliche Komponente mit einer Firmware verknüpft, der das Gerät vertraut. Für sich genommen belegt sie jedoch weder, wer die Malware eingeschleust hat, noch, ob dem Zertifikatsinhaber ihre Präsenz bekannt war.

Gozob und Baciu schränkten ausdrücklich ein, was ihre Untersuchung zur Zuordnung der Verantwortung feststellen konnte:

Wir können lediglich bestätigen, dass Zertifikate mit dem Namen Shenzhen Zediel zur Signierung der Firmware auf betroffenen Geräten verwendet wurden.

Berichte beschrieben das Unternehmen hinter dem Namen unterschiedlich: teils als Hersteller von Android-Geräten, teils als mutmaßlich mit einem Mainboard-Entwickler verbunden. Diese Beschreibungen klären die Verantwortung nicht. Bitdefender fand außerdem betroffene Telefone ohne Firmware-Zertifikate mit dem Namen Zediel. Die Signaturidentität ist daher weder eine vollständige Erklärung noch ein allgemeingültiges Erkennungsmerkmal.

Mögliche Stellen, an denen die Malware eingeschleust worden sein könnte, sind ein Original Design Manufacturer, ein Firmware-Integrator, ein Logistikpartner oder ein anderer Akteur in der Vertriebskette. Der Bericht legte sich auf keine davon fest. Bestätigt wurde, dass die Malware bereits vor dem Verkauf der betroffenen Telefone in der Firmware enthalten war.

Berichte von Besitzern zeigen, warum das Löschen von Apps nicht ausreicht

Besitzer von Cubot- und Doogee-Telefonen berichteten, dass verdächtige Apps nach dem Entfernen erneut installiert wurden. Ein Besitzer eines Doogee Fire 3 Max gab an, dass ein offizielles Firmware-Update die Infektion eingeführt habe, eine Rückkehr zu einer älteren Firmware-Version sie beseitigt und die erneute Installation des Updates sie zurückgebracht habe. Dabei handelt es sich um Berichte von Nutzern, nicht um eine unabhängig bestätigte Historie aller betroffenen Firmware-Versionen.

Einige Besitzer erklärten, spätere Updates der Hersteller hätten die Infektionen beseitigt. Die Hersteller hatten nicht öffentlich erläutert, wie der schädliche Code in die betroffene Firmware gelangte. Zusammengenommen sprechen die Berichte dafür, Firmware-Versionen bei Untersuchung und Reparatur einzubeziehen, statt anzunehmen, dass das Löschen einer heruntergeladenen App das Problem beendet.

Die Untersuchung und die anschließende Berichterstattung belegen im Wesentlichen folgenden Ablauf:

• Über einen Zeitraum von etwa zwei Jahren beobachtete Bitdefender Tausende betroffene Geräte in mehr als 150 Ländern.
• Am 8. Oktober 2026 veröffentlichte Bitdefender seine Untersuchung zu Midnight Mimosa.
• Am 9. Oktober 2026 wurde der technische Bericht aktualisiert.
• Laut Berichten vom 12. Oktober waren die mit der Kampagne verbundenen Google-Play-Apps und die Verantwortung für die betroffene Firmware weiterhin ungeklärt.

Bitdefender zufolge erfordert die Bereinigung Maßnahmen an der Firmware oder die Deaktivierung der schädlichen Komponente über die Android Debug Bridge, meist ADB genannt. ADB ist ein Werkzeug, mit dem ein Computer für Debugging- und Verwaltungsaufgaben mit einem Android-Gerät kommunizieren kann. Eine Komponente zu deaktivieren ist nicht dasselbe, wie kompromittierte Firmware durch eine nachweislich saubere Version zu ersetzen.

Es wurde weder ein allgemeingültiger Bereinigungsbefehl noch eine bestätigte Liste sauberer Firmware-Versionen veröffentlicht. Besitzer sollten sich beim Händler oder Hersteller nach einer geprüften Lösung oder einem Austausch erkundigen, statt davon auszugehen, dass ein Update sicher ist, nur weil es als offiziell bezeichnet wird. Solange der Status ungeklärt ist, ist es ratsam, bekannte betroffene Geräte nicht für Bankgeschäfte oder die Authentifizierung sensibler Konten zu verwenden und darauf keine wichtigen Informationen zu speichern.

Die Bedenken betreffen auch sensible Zugriffsrechte, deren Nutzung die Forscher nicht beobachteten. Bedienungshilfen und der Zugriff auf Benachrichtigungen wurden wiederholt gewährt und entzogen; außerdem waren SMS-Berechtigungen vorhanden. Wenn aus der Ferne bereitgestellter Code diese Funktionen aktiviert hätte, hätte er Bildschirminhalte, Benachrichtigungen oder Verifizierungscodes offenlegen können. Das ist ein nachgewiesenes Risiko, aber kein Beleg dafür, dass Midnight Mimosa während der Analyse solche Daten stahl.

Die wichtigsten Punkte

• Midnight Mimosa wurde in Android-Firmware entdeckt, bevor die betroffenen Geräte Käufer erreichten.
• Bitdefender beobachtete über einen Zeitraum von etwa zwei Jahren Tausende betroffene Geräte in mehr als 150 Ländern.
• Die Operation installierte mindestens 32 getarnte Payload-Apps; 13 Google-Play-Apps verwendeten denselben Code und dieselbe Infrastruktur für Werbebetrug.
• Systemberechtigungen ermöglichten unbemerkte Installationen, das Erteilen von Berechtigungen und das Laden von Code aus der Ferne.
• Die Proxy-Registrierung wurde bestätigt, eine aktive Weiterleitung von Datenverkehr auf dem Testgerät jedoch nicht beobachtet.
• Firmware-Signaturzertifikate belegten weder, wer die Malware eingeschleust hatte, noch eine Beteiligung der Zertifikatsinhaber.
• Das Entfernen der Tarn-Apps allein beseitigt die dauerhaft installierte Komponente nicht. Zur Bereinigung sind Maßnahmen an der Firmware oder die Deaktivierung dieser Komponente erforderlich.