AOMEI Backupper Angriff: Version 8.5.1 reagiert auf die Backdoor

Hinweis: Dieser Beitrag wurde mit KI-Unterstützung erstellt und automatisiert veröffentlicht.

Der AOMEI Backupper Angriff brauchte keine Sicherheitslücke: Angreifer änderten minutenweise zwei Textdateien auf den Servern des Herstellers. Wer in genau diesen Minuten nach Updates fragte, lud sich eine Backdoor herunter. Heute, am 20. Oktober 2026, hat AOMEI mit Version 8.5.1 reagiert.

AOMEI Backupper Angriff: drei Fenster von fünf bis zehn Minuten

Google Threat Intelligence Group (GTIG), Mandiant und das Threat Analysis Lab von ManageEngine (METAL) haben die Kampagne am 15. und 16. Oktober 2026 veröffentlicht. Google führt die Gruppe als UNC7017 und nennt ausdrücklich kein Land und keinen bekannten Akteur. Direkt beobachtet sind drei Manipulationsfenster auf AOMEIs Update-Infrastruktur: 28. Mai 2026 (zehn Minuten, 05:40–05:50 UTC), 16. Juli (sechs Minuten) und 20. Juli (fünf Minuten), jeweils mit anschließender Wiederherstellung der echten Dateien. Google hält weitere, unbeobachtete Manipulationen für wahrscheinlich und datiert die Kampagne auf April bis Juli 2026.

Betroffen waren laut Google Organisationen in elf Ländern – darunter Schweiz, Spanien, Portugal, Indien und die USA – aus IT-Dienstleistung, Telekommunikation und dem Hochschulbereich. Die Opferauswahl war opportunistisch: Getroffen wurde, wer gerade pollte.

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Ich werte aus, ob du den Newsletter öffnest und Links anklickst, um ihn zu verbessern. Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Kein CVE, sondern eine unsignierte Konfigurationsdatei

AOMEI Backupper fragt im Hintergrund zwei Dateien ab. down_html.ini nennt das Paket und die erwartete Prüfsumme, Notifycfg.ini steuert das Hinweisfenster. Keine der beiden Dateien wird kryptografisch geprüft – und die Prüfsumme steht in derselben unsignierten Datei, die auch die Download-Adresse nennt. Wer die Adresse ändern kann, ändert den Hash mit. Jede Prüfung war grün, weil der Angreifer bestimmte, gegen was geprüft wurde. Es gab keinen CVE, keinen Speicherfehler und keine ungepatchte Komponente.

Auf getroffenen Rechnern entpackte der Dropper CROSSROAD ein Paket, legte die geplante Aufgabe RadminComponentRuntime im Drei-Stunden-Takt an und löschte sich anschließend selbst. Diese Aufgabe startet FamItrfc.exe, ein echtes, von Famatech signiertes Radmin-Binary. Über Search-Order-Hijacking lädt es eine angreifereigene DLL nach, die das eigentliche Implantat SHINYROAD als COM-Server registriert. Es läuft also kein eigenes, unsigniertes Programm – signierte Prozesse laden fremden Code nach. Der mitinstallierte Radmin-Server selbst blieb ohne Adresse, ohne Zugangsdaten und ohne Listener: bereitgestellt, aber nicht scharf.

Die Fernsteuerung läuft nach außen. Das von ManageEngine analysierte Implantat spricht genau einen Host auf einem hohen TCP-Port an, ohne Ausweichadresse und ohne Domain-Generierung; die Adresse steht nicht im Klartext in der Datei, sondern entsteht erst zur Laufzeit per ChaCha20-Entschlüsselung. Google beschreibt für eine neuere Variante denselben Host auf einem anderen Port – die Infrastruktur wechselte über die Kampagne hinweg.

Im Fenster am 20. Juli kam ein zweiter Weg hinzu, der gar keinen Programmstart brauchte: ein unsichtbares Ein-Pixel-Fenster auf einen WebDAV-Pfad, das die NetNTLMv2-Anmeldedaten des eingeloggten Nutzers nach außen schickte. Ein Rechner, auf dem die Backdoor scheiterte, kann also trotzdem Anmeldematerial verloren haben.

Was das für dich bedeutet

Aus CISO-Sicht sind hier zwei Dinge unangenehm. Erstens: Backup-Software ist ein Ziel erster Güte. Sie läuft als Dienst mit hohen Rechten, sie darf auf alles zugreifen, und sie aktualisiert sich selbst. Ich behandle solche Agenten seit Jahren wie Systeme in der Nähe eines Domain-Controllers – nicht wie „nur ein Tool“. Zweitens: Der übliche Reflex, nach einem Alarm kurz die Herstellerseite zu prüfen, geht hier ins Leere. Die manipulierte Datei war nach Minuten wieder sauber. Eine Momentaufnahme der Infrastruktur beantwortet eine andere Frage als die Telemetrie des Endgeräts. Wer Alarme mit „die Download-Seite ist in Ordnung“ schließt, schließt echte Funde.

Realistisch einordnen: Die Fenster waren sehr kurz, die Trefferwahrscheinlichkeit für einen einzelnen Rechner also klein. Panik ist unnötig, Nachsehen nicht – denn eine serverseitige Reparatur beim Hersteller räumt ein bereits infiziertes Gerät nicht auf. AOMEI hat heute Version 8.5.1 veröffentlicht; deren Changelog nennt die Schwachstelle erstmals indirekt („Enhanced file integrity checks“ und „Improved update checks to better safeguard software integrity“). Ob die Konfigurationsdateien damit kryptografisch signiert werden, lässt der Eintrag offen. Und die Fernwartungs-Software AnyViewer desselben Herstellers nutzt denselben Update-Weg.

Was du jetzt tun solltest

• Nachsehen statt abwarten: Suche auf Rechnern mit AOMEI Backupper oder AnyViewer nach der geplanten Aufgabe RadminComponentRuntime, nach einer unsignierten upgrade-now.exe mit AOMEI-Herstellerangaben und nach ausführbaren Dateien im html-Ordner der Installation. Relevant ist der ganze Zeitraum April bis Juli 2026.
• Der haltbarste Indikator ist ein Tippfehler: Die Produktangabe der Schaddatei lautet „AOMEI Update Compent“ – so steht es in keinem echten AOMEI-Build. Genau darüber wurde das Sample überhaupt gefunden, nachdem der Dropper sich selbst gelöscht hatte und seine Hashes bei VirusTotal nichts ergaben.
• Ausgehend blocken: SMB (TCP 445) und WebDAV zu externen Adressen sperren – das stoppt den Hash-Abfluss. Die in beiden Berichten genannten C2-Adressen gehören auf die Blockliste. Nützlich ist außerdem die Suche nach ausgehenden Verbindungen auf hohe Ports ohne vorherige DNS-Auflösung, weil das Implantat eine feste IP nutzt.
• Erkennung aus dem Beobachtungsmodus holen: In den betroffenen Umgebungen liefen die passenden Verhaltensregeln nur im Audit-Modus – protokolliert, nicht blockiert. Prüfe, welche deiner EDR-Regeln nur mitschreiben, und ob das eine Entscheidung war oder eine Voreinstellung.
• Backups offline halten: Ein Stand, den dieselbe kompromittierte Software verwaltet, ist kein zweiter Stand. Mindestens eine Kopie gehört auf ein Medium, das nicht dauerhaft am System hängt – dazu passen verschlüsselte USB-Sticks und externe SSDs.
• Weniger Agenten: Jedes Werkzeug mit eigenem Auto-Updater ist ein eigener Lieferweg. Wer Backup-Software konsolidiert, reduziert genau diese Fläche.

Dass Backup-Produkte im Visier stehen, ist kein Einzelfall – siehe den Angriff auf AhsayCBS-Backup-Server und die Rechteausweitung im Acronis-Backup-Plugin. Der Unterschied: Diesmal gibt es nichts zu patchen, nur etwas zu suchen.

Quellen

• Google Threat Intelligence Group / Mandiant: Investigating Ephemeral Supply Chain Tampering (15.10.2026)
• ManageEngine METAL: AOMEI Backupper supply-chain compromise (16.10.2026)
• The Hacker News: Attackers Tampered with AOMEI Backupper’s Update Servers (16.10.2026)
• AOMEI Backupper Changelog (Version 8.5.1, 20.10.2026)