AOMEI Backupper ist eine Backup- und Festplatten-Klonsoftware von AOMEI Technology, einem in Hongkong registrierten Anbieter. Wie das Fernwartungswerkzeug AnyViewer desselben Herstellers betreibt sie Hintergrunddienste, die regelmäßig über HTTPS bei den AOMEI-Servern nach Software-Updates und Werbe-Pop-ups fragen.

Zwei Dateien steuern diese Abfrage: down_html.ini benennt das herunterzuladende Update-Paket und die Prüfsumme, mit der das Programm es verifiziert. Notifycfg.ini teilt dem Benachrichtigungsdienst mit, was angezeigt und was ausgeführt werden soll. Keine der beiden Dateien wird kryptografisch verifiziert – und die Prüfsumme, die die Echtheit des Downloads belegen soll, steht in derselben unsignierten Datei, die den Download benennt.

Es wurde nach Angaben des ManageEngine-Labors keine Schwachstelle in der Software ausgenutzt, und es war kein Zutun der Nutzer nötig, außer dass das Programm installiert war und lief. Der Angreifer musste lediglich zwei Textdateien auf dem Server für wenige Minuten austauschen. Eine Backupper-Installation, die in einem dieser Fenster anfragte, zog das Paket des Angreifers in ihren eigenen Ordner; die Benachrichtigungsdatei sorgte dann für dessen Ausführung – mit den Rechten des startenden AOMEI-Prozesses. Auf den vom Labor untersuchten Maschinen genügte das, um Software systemweit zu installieren; die Rechteausweitung hing allerdings davon ab, wie der AOMEI-Dienst betrieben wurde.

Drei bestätigte Zeitfenster, elf Länder

GTIG und Mandiant bestätigten drei Manipulationsfenster und gehen davon aus, dass es weitere gab, die sie nicht beobachtet haben:

    1. Mai 2026: 10 Minuten, 05:40 bis 05:50 UTC
    1. Juli 2026: 6 Minuten, 08:33 bis 08:39 UTC
    1. Juli 2026: 5 Minuten, 10:35 bis 10:40 UTC

Betroffen waren ausschließlich Installationen, die während eines Fensters anfragten. Wer davor oder danach prüfte, erhielt saubere, echte Dateien – genau das macht den Angriff schwer auffindbar. GTIG beschreibt die Zielauswahl als opportunistisch: Es traf, wer zufällig in diesen Minuten abfragte.

Aus eigener Telemetrie identifizierte GTIG betroffene Organisationen aus IT-Dienstleistung, Telekommunikation und Hochschulbildung in elf Ländern: Australien, Brasilien, Indien, Pakistan, Portugal, Singapur, Südafrika, Spanien, Schweiz, Türkei und USA. Eine Gesamtzahl nannte GTIG nicht, hält die tatsächliche Zahl aber für höher. AnyViewer nutzt laut GTIG denselben Update-Ablauf, die beschriebenen Erkennungen betreffen jedoch Backupper. Keiner der beiden Berichte listet betroffene Backupper-Versionen auf; das ManageEngine-Labor untersuchte Version 8.3.0.

GTIG führt die Gruppe hinter der Kampagne als UNC7017 und nennt weder ein Land noch einen bekannten Akteur. Es handle sich um die erste Lieferkettenkompromittierung unter Windows, die das Team mit einem derart kurzen Zeitfenster beobachtet habe – sie umgehe „damit wirksam klassische punktuelle Triage und automatisierte Dateiscans".

Was auf den Rechnern landete

Auf einem betroffenen System entpackte ein Downloader, den GTIG CROSSROAD nennt, ein Paket in einen lokalen Radmin-Ordner, legte eine geplante Aufgabe an, die alle drei Stunden läuft, und löschte sich anschließend von der Festplatte. Das Paket enthielt eine echte, signierte Kopie des kommerziellen Fernwartungswerkzeugs Radmin. Das ManageEngine-Labor fand sie zwar abgelegt, aber nie aktiviert: kein Listener, keine Konfiguration, kein neues Konto. Die Fernsteuerung erfolgte stattdessen über ein separates Implantat, das von sich aus Verbindung zum Angreifer aufnahm.

Die geplante Aufgabe startet das signierte Radmin-Programm, das eine danebengelegte, vom Angreifer gebaute DLL lädt, die wiederum das Implantat SHINYROAD nachlädt. SHINYROAD bietet eine Remote-Shell und kann auf Befehl neuen Code nachladen und ausführen. Es kommuniziert mit einer einzigen fest einprogrammierten Adresse ohne Ausweichziel – wer diese Adresse blockiert, kappt die Kontrolle des Angreifers.

CROSSROAD läuft nicht überall: Es prüft den Standort des Rechners und bricht ab, wenn dieser in China liegt; ManageEngine ergänzte, dass es auch abbricht, wenn es bestimmte Sicherheitsagenten auf dem Host findet. Auf Maschinen, die diese Prüfungen passierten, beobachtete GTIG später ein zweites Werkzeug, das zusätzlich zu SHINYROAD nachgeladen wurde: das quelloffene Adaptix-C2-Framework, getarnt als Nitro-PDF-Software.

Credential-Abgriff ohne Codeausführung

Das Fenster vom 20. Juli enthielt einen zweiten Kniff, für den kein Programm ausgeführt werden musste. GTIG stellte fest, dass die Benachrichtigungsdatei so verändert war, dass sie ein unsichtbares Ein-Pixel-Pop-up öffnete, das per WebDAV auf eine Datei auf einem Server des Angreifers verwies – also auf eine entfernte Datei so zugreift, als läge sie lokal. Beim Rendern dieses Pop-ups kann Windows die NetNTLMv2-Authentifizierungsantwort des angemeldeten Nutzers an die Adresse des Angreifers senden, ohne dass für den Nutzer etwas sichtbar wird. Ein solcher Token lässt sich offline knacken oder weiterverwenden. Da kein Programm starten musste, konnte auch ein Rechner, auf dem die Backdoor blockiert war, diesen Token preisgeben.

Zeitleiste der Meldungen an AOMEI

Die Endpunktsoftware des ManageEngine-Labors registrierte die Aktivität erstmals am 28. Mai, als AOMEI Backupper bei zwei nicht miteinander verbundenen Kunden in unterschiedlichen Ländern Radmin installierte. Ein Kunde meldete den Vorgang am 7. Juni, das Labor informierte AOMEI noch am selben Tag. AOMEIs erste Erklärung lautete, die Inhalte seien auf dem Transportweg abgefangen und verändert worden.

Die Belege stützten diese Erklärung laut dem Labor nicht: Beide Rechner hatten die Dateien über HTTPS von AOMEIs eigenen Servern bezogen, aus verschiedenen Ländern und Netzen, und das Programm hatte das Paket über seinen normalen Update-Ablauf hereingeholt. Mitte Juli erfassten die eigenen Monitore des Labors eines der Fenster live und bestätigten damit, dass die Veränderung von AOMEIs Seite ausgeliefert wurde.

Mandiant benachrichtigte AOMEI am 17. Juli und übergab Indikatoren. Am 29. Juli teilte AOMEI Mandiant mit, man habe Korrekturmaßnahmen zur Absicherung der Server ergriffen. Das ManageEngine-Labor erklärte, es habe bis zur Veröffentlichung nicht unabhängig bestätigen können, dass die Kompromittierung eingedämmt sei. Wie die Angreifer die Möglichkeit erlangten, Dateien auf AOMEIs Servern zu ändern, geht aus keinem der beiden Berichte hervor. AOMEIs veröffentlichtes Changelog für Backupper führt bis einschließlich der aktuellen Version 8.5.0 vom 9. Oktober keine Änderung daran auf, wie das Programm Updates verifiziert; auch die Berichte nennen keine Version, die die Lücke schließt.

Empfohlene Prüfungen

Ein bereinigter Server säubert keinen befallenen Rechner: Der Downloader legte seine geplante Aufgabe an und stellte anschließend die lokale Update-Datei im Originalzustand wieder her – ein infiziertes System kann also unauffällig wirken, während auch die Downloadseite des Herstellers sauber aussieht. GTIG und ManageEngine raten Organisationen mit AOMEI-Software, den gesamten Zeitraum von April bis Juli zu durchsuchen. „Organisationen, die AOMEI-Software einsetzen, können nicht davon ausgehen, geschützt zu sein, nur weil der Hersteller serverseitig Korrekturmaßnahmen ergriffen hat", erklärten GTIG und Mandiant.

Eine Warnmeldung sollte nicht anhand der heutigen Downloadseite des Herstellers bewertet werden: Da die Dateien binnen Minuten zurückgetauscht wurden, liefert diese Seite fast immer echte Inhalte – was dazu geführt hat, dass Analysten echte Funde als Fehlalarme abtaten. Stattdessen sollten die in den Programmordnern zwischengespeicherten Dateien gesichert und Netzwerkprotokolle darauf geprüft werden, was genau zum Zeitpunkt des Alarms ausgeliefert wurde.

Auf dem Endpunkt ist zu suchen nach:

  • Geplante Aufgabe: RadminComponentRuntime beziehungsweise NitroRuntime für das nachgeladene Werkzeug
  • Datei: eine unsignierte upgrade-now.exe mit AOMEIs Herstellerangaben oder jedes Programm, das aus Backuppers html-Pop-up-Ordner läuft
  • Ordner: Angreiferdateien im lokalen Radmin-Anwendungsdatenordner

Im Netz empfehlen beide Teams, die genannte Angreiferinfrastruktur zu sperren sowie ausgehendes SMB (TCP 445) und WebDAV zu externen Adressen zu blockieren, um den Credential-Abgriff zu unterbinden:

  • Domains: storage-data[.]com, promotion.storage-data[.]com, aomei.storage-data[.]com
  • IP-Adressen: 8.210.84[.]56, 8.218.65[.]184, 47.239.60[.]117

GTIG veröffentlichte zu seinem Bericht YARA-Regeln, das ManageEngine-Labor Sigma-Regeln; beide Regelsätze stammen von den jeweiligen Forschern.