Angreifer schleusten eine Backdoor über die eigenen Update-Server von AOMEI Backupper ein

AOMEI Backupper ist Windows-Software für Backup und Festplattenklonen. Sie unterhält außerdem einen Hintergrunddienst, der die Server von AOMEI Technology nach Update-Hinweisen und Pop-up-Inhalten abfragt. Zwischen Mai und Juli 2026 änderten Angreifer während kurzer Zeitfenster, was diese Server zurückgaben, und jede installierte Kopie, die in einem davon nachfragte, lud eine Backdoor herunter und führte sie aus.

Zum Weiterlesen: Brevo-Lieferkettenangriff schleuste ClickFix-Malware über einen gestohlenen Cloudflare-Schlüssel ein · Angreifer nutzten die App-Identität von ConnectWise Cloud Backup für Anmeldungen in Microsoft-365-Tenants.

Google Threat Intelligence Group und Mandiant haben die Kampagne in der Woche des 13. Oktober 2026 gemeinsam mit dem Threat Analysis Lab von ManageEngine offengelegt. The Hacker News und ManageEngine veröffentlichten am 16. Oktober ausführliche Darstellungen.

Die Berichte sagen nicht, wie die Angreifer Schreibzugriff auf AOMEIs Infrastruktur erlangten. Sie zeigen aber, was dieser Zugriff einbrachte: eine Supply-Chain-Kompromittierung, die keine Phishing-Nachricht, keine nachgebaute Download-Seite und keinen Fehler im Backup-Programm brauchte. Die Software tat, wofür sie gebaut war, und die Nutzlast kam über den Update-Kanal des Herstellers selbst.

Drei Zeitfenster, und wahrscheinlich mehr

GTIG und Mandiant bestätigten drei Manipulationsfenster. Das erste lief am 28. Mai 2026 zehn Minuten lang, von 05:40 bis 05:50 UTC. Das zweite dauerte am 16. Juli sechs Minuten, von 08:33 bis 08:39 UTC. Das dritte dauerte am 20. Juli fünf Minuten, von 10:35 bis 10:40 UTC. Die Überwachung von ManageEngine erfasste die Änderung vom 16. Juli unabhängig, während sie geschah.

Die Forscher sagten, es habe wahrscheinlich weitere Fenster gegeben, mit Manipulationen bis zurück in den April 2026. Diese Schätzung zählt mehr als die drei bestätigten Daten. Eine Kampagne mit so kurzen Fenstern braucht nicht viele Versuche, um viele Rechner zu erreichen, denn Ziel ist jeder, der zufällig eine Update-Prüfung ausführt, während die Datei verändert ist.

GTIG identifizierte betroffene Organisationen in IT-Diensten, Telekommunikation und Hochschulwesen in 11 Ländern: Australien, Brasilien, Indien, Pakistan, Portugal, Singapur, Südafrika, Spanien, Schweiz, Türkei und die Vereinigten Staaten. Es nannte keine Gesamtzahl und sagte, die tatsächliche Zahl sei vermutlich höher. Keiner der beiden Berichte schreibt die Kampagne einem Staat zu oder nennt einen Akteur. GTIG führt die Gruppe als UNC7017.

Der Update-Pfad vertraute sich selbst

Der Update-Ablauf von Backupper nutzt zwei Konfigurationsdateien, down_html.ini und Notifycfg.ini. Sie sind nicht signiert. Sie sagen dem Programm, was es herunterladen und welchen Pop-up-Inhalt es anzeigen soll, und keine der beiden ist kryptografisch authentifiziert. Die Prüfsumme, mit der ein Download verifiziert wird, steht in derselben nicht authentifizierten Datei, die den Download benennt, ein Angreifer, der die Datei ändern kann, kann also auch den Wert ändern, der ihre Echtheit belegen soll.

HTTPS schützte die Übertragung. Es schützte nicht den Inhalt, denn der Inhalt kam von AOMEIs eigenen Hosts und wurde über eine gültige Verbindung ausgeliefert. Das ist der Teil der Geschichte, der über diese Malware-Familie hinaus relevant ist. Transportsicherheit beantwortet die Frage, ob ein Server der ist, der er zu sein vorgibt. Sie sagt nichts darüber, ob die Datei, die dieser Server herausgibt, vertrauenswürdig sein sollte.

GTIG beschrieb die Kampagne als die erste Windows-Supply-Chain-Kompromittierung, die es mit so kurzen Manipulationsfenstern gesehen habe. Der Bericht sagte, der Ansatz habe die punktuelle Triage und das automatisierte Datei-Scannen wirksam umgangen. Eine Datei, die sechs Minuten lang bösartig und danach echt ist, lässt einem Scanner, der einmal hinschaut, wenig.

Derselbe Update-Ablauf wird von AnyViewer genutzt, AOMEIs Remote-Desktop-Werkzeug, und GTIG nennt AnyViewer ebenfalls als Ziel. Die Berichte konzentrieren sich auf Backupper, die Zahl der AnyViewer-Installationen, die während eines Manipulationsfensters nachfragten, ist also unbekannt.

Von einer Benachrichtigung zu einer geplanten Aufgabe

Die Kette vom 20. Juli zeigt, wie weit die Manipulation reichte. Die veränderte Benachrichtigungsdatei richtete das Pop-up in der App auf eine mitgelieferte ausführbare Datei namens upgrade-now.exe. Die Datei trug AOMEI-Herausgebermetadaten, war aber unsigniert, und ihre Produktzeichenfolge lautete „AOMEI Update Compent“, mit falsch geschriebenem „component“.

Ihre Ausführung installierte einen echten, signierten Radmin Server von Famatech. Neben dem signierten Radmin-Starter FamItrfc.exe platzierte der Dropper eine angreifereigene DLL namens BlkScrDl.dll. Der signierte Starter lud die DLL aus seinem eigenen Ordner, ein klassisches Sideloading. Diese DLL lud das Implantat RuntimeComponent.dll, die Backdoor, die GTIG SHINYROAD nennt. Das Implantat registrierte sich als COM-Server innerhalb des signierten dllhost.exe-Surrogats und trug eine eingebettete, verschlüsselte PocketPy-Nutzlast. Für Persistenz sorgte eine geplante Aufgabe namens RadminComponentRuntime, die alle drei Stunden laufen sollte.

Die bösartigen Teile waren der unsignierte Dropper, die seitlich geladene DLL und das Implantat. Alles, was sie berührten, war signiert oder ein legitimer Windows-Prozess. Deshalb ist die Aktivität allein mit einer Prüfung der Dateireputation schwer zu erfassen.

ManageEngine führt den Dropper als CROSSROAD. Er löschte sich nach der Nutzung selbst, prüfte die öffentliche IP-Adresse des Hosts und stoppte, wenn sie nach China verortet wurde oder die Verortung fehlschlug, und stoppte, wenn er bestimmte Endpoint-Sicherheitsagenten fand. Diese Prüfungen deuten auf eine sorgfältige, gezielte Operation statt auf eine breite, wahllose Kampagne. Sie bedeuten auch, dass ein Rechner außerhalb der Zielgruppe die Nutzlast nie ausgeführt haben muss, selbst wenn er den Dropper geladen hat.

Das Implantat verband sich mit einem fest einprogrammierten Command-and-Control-Endpunkt, 8.218.65.184 auf Port 41397, ohne Ausweichoption. Die Adresse wird erst zur Laufzeit entschlüsselt, sie steht also nicht in der ruhenden Datei. Dieser einzelne Endpunkt ist eine Schwäche im Design des Implantats: ausgehenden Datenverkehr dorthin zu blockieren, trennt den einzigen Steuerkanal, den die Forscher fanden. Adressen sind flüchtig, und diese stammt aus der Analyse der Forscher und nicht von AOMEI.

Während des Fensters vom 20. Juli fand GTIG außerdem, dass die Benachrichtigungsdatei so geändert wurde, dass sie ein unsichtbares Pop-up von einem Pixel öffnete. Das Pop-up verwies auf eine entfernte Datei über einen WebDAV- oder UNC-Pfad. Sein Rendern könnte Windows dazu bringen, die NetNTLMv2-Authentifizierungsdaten des angemeldeten Nutzers an den Angreifer zu senden, ohne dass auf dem Bildschirm etwas sichtbar wäre und ohne dass ein Programm ausgeführt würde.

Dieser zweite Pfad ist wichtig, weil er die übliche Annahme umgeht, ein Supply-Chain-Angriff müsse Code liefern. Ein solches Datenleck mit Zugangsdaten kann später, aus einem anderen Netz und mit einem anderen Werkzeug, gegen Systeme genutzt werden, die die Backdoor nie ausgeführt haben. Die Forscher stellen es als eine Fähigkeit dar, die sie in der manipulierten Datei beobachteten, nicht als Beweis, dass Zugangsdaten aus jedem betroffenen Netz abgezogen wurden.

Was AOMEI wusste, und wann

Die Endpoint-Software von ManageEngine markierte die Aktivität am 28. Mai 2026, am Tag des ersten bestätigten Fensters. Ein Kunde brachte sie am 7. Juni zur Sprache, und ManageEngine informierte AOMEI am selben Tag.

AOMEIs erste Erklärung war, der Inhalt sei auf dem Transportweg abgefangen worden. ManageEngine sagte, die Beweise stützten das nicht, weil beide Endpunkte die Dateien über HTTPS von AOMEI-eigenen Hosts in verschiedenen Ländern abriefen. Mandiant informierte AOMEI am 17. Juli. AOMEI antwortete am 29. Juli, seine Server seien gesichert.

AOMEI hat über die Meldung korrigierender Maßnahmen hinaus keine eigene Darstellung veröffentlicht. Das lässt die Ursache offen. Die Berichte beschreiben die Manipulation im Detail und beschreiben nicht, wie die Angreifer hineinkamen, die Frage, ob derselbe Zugangsweg geschlossen ist, ruht also auf der Zusicherung des Herstellers und nicht auf öffentlichen Beweisen.

Auch die Produktseite ist ungelöst. AOMEIs Changelog für Backupper, am 16. Oktober 2026 geprüft, nannte bis zur aktuellen Version 8.5.0, veröffentlicht am 9. Oktober, keine Änderung daran, wie das Programm Updates verifiziert. Auch der betroffene Versionsbereich ist nicht vollständig dokumentiert. ManageEngine untersuchte Version 8.3.0 und sagte, es habe 8.3.0 und später beobachtet. Wenn die Update-Dateien weiterhin nicht unabhängig authentifiziert werden können, hätte eine künftige Server-Kompromittierung denselben Weg zum selben Ergebnis.

Warum ein sauberer Scan wenig beweist

Die defensive Lehre läuft dem Instinkt zuwider, eine Datei zu prüfen und weiterzugehen. Ein Endpunkt, der den Dropper während eines Fünf-Minuten-Fensters geladen und ausgeführt hat, kann einen eine Woche später erstellten Scan bestehen, weil die lokale Update-Datei, die er hinterließ, auf die echte Version wiederhergestellt wurde. Was bleibt, ist verhaltensbasiert: eine geplante Aufgabe, eine Radmin-Installation, die niemand angefordert hat, eine DLL neben einer signierten Binärdatei, ein Prozess, der mit einer ungewöhnlichen Adresse spricht.

Das ist das Argument dafür, Endpoint-Telemetrie aufzubewahren und zu durchsuchen, statt sich auf punktuelle Reputation zu verlassen. Es ist auch das Argument dafür, einen Update-Server als Teil der Angriffsfläche zu behandeln. Ein Hersteller, der seine Konfigurationsdateien signiert und Prüfsummen über einen separaten, authentifizierten Kanal liefert, beseitigt die konkrete Schwäche, die hier genutzt wurde. Kurzlebige signierte Manifeste würden das Fenster weiter verengen, denn eine auf dem Server veränderte Datei würde beim Client die Verifikation nicht bestehen.

Nichts davon hilft einem Netz, das die Nutzlast bereits ausgeführt hat. Die praktische Empfehlung, die daraus folgt, ist, nach den Komponenten der Kette zu suchen, die Command-and-Control-Adresse an der Peripherie zu blockieren und ein sauberes Antiviren-Ergebnis als Beginn einer Untersuchung zu behandeln statt als ihr Ende.

„Die traditionelle punktuelle Triage und das automatisierte Datei-Scannen wirksam umgehen.“ — Google Threat Intelligence Group, über UNC7017, 16. Oktober 2026

Was zu beobachten ist

Drei Dinge sind noch offen. Das erste ist AOMEIs eigene Darstellung des Eindringens, die sagen würde, wie die Server erreicht wurden und ob sich die Update-Verifikation geändert hat. Das zweite ist die unabhängige Bestätigung, dass die Server sauber sind; die einzige Aussage bisher ist die des Herstellers. Das dritte ist die Zahl der Betroffenen. 11 Länder sind eine Untergrenze, zusammengestellt aus GTIGs Sichtweite.

Für Verteidiger ist die nützliche Frage, ob irgendein Rechner im Bestand während eines der Fenster eine Update-Prüfung ausgeführt hat und ob die Telemetrie, um das zu beantworten, noch existiert. Die meisten Organisationen bewahren vermutlich keine sechs Monate an Prozess- und Netzwerkdaten auf. Die, die es tun, können eine Infektion von einem Zufall unterscheiden.

Die Technik hängt nicht von AOMEI ab. Jeder Updater, der einem unsignierten Manifest von demselben Server vertraut, von dem er es bezieht, hat dieselbe Exposition. Der nächste Bericht könnte andere Software betreffen.

Titelbild: „Toshiba 1 TB External USB Hard Drive.jpg“ von Editor182, gemeinfrei, via Wikimedia Commons.