AOMEI Backupper update channel lieferte eine backdoor aus
AOMEI Backupper verbreitete nach Angaben der Google Threat Intelligence Group (GTIG), Mandiant und des Threat Analysis Lab von ManageEngine während mehrerer kurzer Zeiträume zwischen Mai und Juli 2026 über seinen regulären update process eine von Angreifern kontrollierte backdoor. Windows-Computer, die während dieser Zeiträume die update servers kontaktierten, konnten das schädliche package ohne weitere Handlung des Benutzers herunterladen und ausführen.
AOMEI Backupper ist eine Software für Backups und das Klonen von Datenträgern, die Hintergrunddienste ausführt und regelmäßig über HTTPS, eine verschlüsselte Verbindung zur Übertragung von Webdaten, Kontakt mit den Servern von AOMEI aufnimmt. Der update process stützt sich auf zwei Textdateien. Die Datei down_html.ini gibt das package an und enthält dessen checksum, einen Wert, mit dem geprüft wird, ob eine heruntergeladene Datei einer erwarteten Kopie entspricht. Notifycfg.ini steuert Werbebenachrichtigungen und teilt der Software mit, was sie anzeigen oder ausführen soll.
Das Programm überprüfte keine der beiden Dateien kryptografisch. Seine checksum war in derselben unsignierten Datei gespeichert, die den Download angab. Dadurch konnte ein Angreifer, der beide Dateien auf dem Server verändern konnte, ein anderes package einsetzen und eine dazu passende checksum bereitstellen. ManageEngine erklärte, dass keine software vulnerability ausgenutzt wurde. Das schädliche package wurde über die vorgesehenen Update-Schritte der Anwendung abgerufen, im eigenen Ordner von Backupper abgelegt und mit den Berechtigungen des AOMEI-Prozesses gestartet. Auf den vom Labor untersuchten Systemen reichten diese Berechtigungen für eine systemweite Installation aus, wobei der verfügbare Zugriff davon abhing, wie der service ausgeführt wurde.
GTIG und Mandiant bestätigten drei Zeiträume, in denen die Server manipuliert wurden: am 28. Mai von 05:40 bis 05:50 UTC, am 16. Juli von 08:33 bis 08:39 UTC und am 20. Juli von 10:35 bis 10:40 UTC. Sie gehen davon aus, dass es möglicherweise weitere Zeitfenster gab. Computer, die unmittelbar vor oder nach diesen Minuten eine Prüfung durchführten, erhielten echte Dateien, was spätere Untersuchungen erschwert. GTIG bezeichnete die Auswahl der Ziele als opportunistisch, weil eine Infektion davon abhing, wann die jeweilige Installation zufällig Kontakt mit dem Server aufnahm.
Die telemetry von GTIG identifizierte betroffene Organisationen in den Bereichen IT-Dienstleistungen, Telekommunikation und Hochschulbildung in Australien, Brasilien, Indien, Pakistan, Portugal, Singapur, Südafrika, Spanien, der Schweiz, Türkiye und den Vereinigten Staaten. GTIG nannte keine Gesamtzahl und erklärte, die tatsächliche Zahl sei wahrscheinlich höher. Die für die Aktivität verantwortliche Gruppe wird von GTIG als UNC7017 geführt, doch es wurden weder ein Land noch ein bereits bekannter Akteur genannt. GTIG erklärte, dies sei die erste software supply chain compromise gewesen, auf die die Gruppe gestoßen sei und bei der derart kurze Windows-Update-Zeitfenster genutzt wurden, um point-in-time checks und automatisierte Datei-Scans zu umgehen.
Die Erkennungen betreffen Backupper, obwohl GTIG erklärte, dass AOMEIs Remote-Desktop-Software AnyViewer denselben update flow verwendet. Keiner der beiden Forschungsberichte nennt alle betroffenen Backupper-Versionen. ManageEngine untersuchte Version 8.3.0. The Hacker News prüfte am 16. Oktober das changelog von AOMEI und fand bis einschließlich Version 8.5.0, die am 9. Oktober veröffentlicht wurde, keine aufgeführte Änderung an der Update-Verifizierung. Keiner der Berichte nennt eine Backupper-Version, die die Schwachstelle bei der Verifizierung behebt.
Auf kompromittierten Computern entpackte ein downloader namens CROSSROAD Dateien in einen lokalen Radmin-Ordner, erstellte einen scheduled task, der alle drei Stunden ausgeführt wurde, und entfernte sich anschließend selbst. Zu den Dateien gehörte eine legitime, signierte Kopie des Remote-Administrationsprogramms Radmin. ManageEngine fand für Radmin weder einen aktiven listener noch eine Konfiguration oder ein neu erstelltes Konto. Stattdessen startete der scheduled task das signierte Programm, das eine in der Nähe abgelegte und vom Angreifer erstellte Dynamic Link Library (DLL) lud, also eine Datei mit Code, den ein anderes Windows-Programm ausführen kann. Dieser Code lud SHINYROAD, ein implant, das eine remote command shell sowie die Möglichkeit bereitstellte, weiteren Code abzurufen und auszuführen.
SHINYROAD kommunizierte mit einer einzigen fest vorgegebenen Adresse und verfügte über kein Ersatzziel, sodass das Blockieren dieser Adresse die Kontrolle des Angreifers unterbrechen konnte. CROSSROAD prüfte außerdem den Standort des Computers und beendete sich in China. ManageEngine erklärte, dass es sich beendete, wenn bestimmte security agents vorhanden waren. Auf Systemen, die diese Prüfungen bestanden, beobachtete GTIG später das Open-Source-Adaptix-command-and-control (C2) framework, eine Software, mit der Anweisungen an kompromittierte Computer gesendet werden, das als Nitro-PDF-Software getarnt ausgeliefert wurde.
Beim Vorfall vom 20. Juli kam außerdem eine Methode zum Einsatz, für die kein Programm ausgeführt werden musste. Die veränderte Benachrichtigungskonfiguration öffnete ein unsichtbares Fenster mit einer Größe von einem Pixel, das über WebDAV, eine Methode, mit der entfernte Dateien wie lokal verfügbare Dateien behandelt werden können, auf eine vom Angreifer gehostete Datei zugriff. Windows konnte daraufhin die NetNTLMv2-Authentifizierungsantwort des angemeldeten Benutzers an die Adresse des Angreifers übertragen. Diese Antwort konnte potenziell wiederverwendet oder einem Offline-Knacken des Passworts unterzogen werden. Folglich konnte ein Computer, der die backdoor selbst blockierte, dennoch Authentifizierungsmaterial offengelegt haben, ohne dem Benutzer etwas anzuzeigen.
ManageEngine erklärte, seine endpoint software habe die Aktivität erstmals am 28. Mai erkannt, als Backupper Radmin bei zwei nicht miteinander verbundenen Kunden in unterschiedlichen Ländern installierte. Ein Kunde meldete das Ereignis am 7. Juni, und das Labor informierte AOMEI noch am selben Tag. AOMEI führte die veränderten Inhalte zunächst auf eine Abfangaktion während der Übertragung über das Netzwerk zurück, doch laut ManageEngine stützten die Beweise diese Erklärung nicht. Beide Computer hatten HTTPS verwendet, um die Dateien über den normalen update process von den Servern von AOMEI abzurufen, obwohl sie sich in unterschiedlichen Netzwerken und Ländern befanden. Das Labor beobachtete später während eines aktiven Zeitfensters im Juli, dass veränderte Dateien von der Seite AOMEIs ausgeliefert wurden.
Mandiant informierte AOMEI und übermittelte am 17. Juli indicators. AOMEI teilte Mandiant am 29. Juli mit, Korrekturmaßnahmen zur Absicherung der Server ergriffen zu haben. ManageEngine hatte die Eindämmung zum Zeitpunkt der Veröffentlichung seines Berichts nicht unabhängig bestätigt. Die Methode, mit der der Zugriff auf die Server erlangt wurde, ist weiterhin unbekannt, und eine serverseitige remediation entfernt keine malware, die bereits auf Windows-Systemen installiert wurde.
GTIG und ManageEngine empfehlen, AOMEI-Installationen über den gesamten Zeitraum von April bis Juli zu untersuchen. Ermittler sollten nach scheduled tasks mit den Namen RadminComponentRuntime oder NitroRuntime, einer unsignierten upgrade-now.exe mit AOMEI-Publisher-Angaben, aus dem „html pop-up“-Ordner von Backupper gestarteten Programmen und Angreiferdateien im lokalen Radmin-Anwendungsdatenordner suchen. Zwischengespeicherte Anwendungsdateien und Netzwerk-records vom genauen Zeitpunkt des Alerts sind besonders wichtig, weil der downloader die lokale Update-Datei wiederherstellte, nachdem persistence eingerichtet worden war.
Die veröffentlichten network indicators sind storage-data[.]com, promotion.storage-data[.]com, aomei.storage-data[.]com, 8.210.84[.]56, 8.218.65[.]184 und 47.239.60[.]117. Die Berichte empfehlen außerdem, ausgehenden Server-Message-Block-(SMB)-Datenverkehr über TCP-Port 445 sowie externe WebDAV-Verbindungen zu blockieren, um die Methode zum Abfluss von Zugangsdaten einzuschränken. GTIG veröffentlichte YARA detection rules, während ManageEngine Sigma rules bereitstellte. The Hacker News erklärte, keine der beiden Regelsammlungen getestet zu haben.