VMmanager 6 Sicherheitsvorfall: Was ist passiert und was ist zu tun?

Im Oktober 2026 attackierten Angreifer mehrere russische Hosting-Anbieter gleichzeitig über eine kritische Sicherheitslücke in VMmanager 6, einem Virtualisierungsmanagement-Panel von ISPsystem (Teil der Astra Group). Dieses Panel wird für uns und viele andere Anbieter zum Betrieb von VPS eingesetzt. Auch wir waren betroffen.

Ihre Server laufen weiterhin. Im Folgenden finden Sie eine Beschreibung des Vorfalls, die Gründe dafür, unsere bisherigen Maßnahmen und Ihre weiteren Schritte.

Die Ursache: eine Schwachstelle im Produkt des Anbieters.

Der Angriff wurde durch eine kritische Sicherheitslücke in der VMmanager 6-Software ermöglicht. Es handelte sich nicht um eine Fehlkonfiguration bei einem einzelnen Anbieter: Dieselbe Sicherheitslücke wurde gleichzeitig gegen zahlreiche Hosting-Unternehmen ausgenutzt.

FirstVDS, ForestsNet Cloud, MHost, HSH Network und YaColo haben öffentlich Sicherheitslücken in Verbindung mit VMmanager 6 gemeldet. Der Hersteller hat den Vorfall bestätigt: Laut einem Vertreter der Astra Group befand sich die Schwachstelle in einer der VMmanager-Versionen.

Was der Anbieter noch immer nicht offengelegt hat

Zum Zeitpunkt der Veröffentlichung hat ISPsystem den Hosting-Anbietern nicht genügend Informationen zur Verfügung gestellt, um die Sicherheitslücke sicher zu beheben und ihre Infrastruktur zu überprüfen. Folgendes wurde noch nicht veröffentlicht:

• eine Beschreibung der Sicherheitslücke und der Methode des ersten Zugriffs;
• eine CVE-Kennung und die Liste der betroffenen Versionen;
• Indikatoren für eine Kompromittierung (IoCs): Adressen von Angreiferservern, Datei- und Prozessnamen, Anzeichen für Persistenz;
• Bestätigung, dass die veröffentlichten Korrekturen die Sicherheitslücke vollständig schließen.

Der erste Fix wurde in der Nacht des 18. Oktober veröffentlicht, gefolgt von mehreren weiteren. Laut anderen betroffenen Anbietern riet der Hersteller selbst davon ab, den Zugriff auf das Panel wieder zu öffnen, bis weitere Patches verfügbar sind. Ohne technische Details muss jeder Anbieter den Angriff anhand seiner eigenen Protokolle und durch den Austausch der Erkenntnisse mit Kollegen selbst rekonstruieren.

Wir haben den Anbieter um vollständige technische Informationen gebeten und werden diese veröffentlichen, sobald wir sie erhalten. Wir sind der Ansicht, dass die Verantwortung für die Sicherheitslücke und die rechtzeitige Offenlegung der Informationen darüber beim Produktentwickler liegt.

Was könnte durchgesickert sein?

Die Angreifer erlangten Zugriff auf die Panel-Datenbank, die Folgendes enthielt:

• die Liste der Server und ihrer IP-Adressen;
• E-Mail-Adressen der Panel-Konten;
• Root-Passwörter, die über das Bedienfeld bei der Bestellung, Neuinstallation oder Änderung des Passworts festgelegt werden;
• Passwörter für die VNC-Konsole.

Bei einigen Anbietern gelangten die Angreifer auch bis zu den Virtualisierungsknoten. Dort führten sie ein Programm aus, das die Festplatten der Client-Server im Nur-Lese-Modus einband und sie nach Geheimnissen durchsuchte:

• SSH-Schlüssel, authorized_keys, Passwort-Hashes, Passwort-Manager, GnuPG-Schlüssel;
• Cloud- und DevOps-Zugangsdaten: AWS, Google Cloud, Azure, Kubernetes, Docker, Terraform, GitHub, GitLab und npm-Tokens;
• .env und docker-compose.yml Dateien, Anwendungs- und Datenbankkonfigurationen;
• Krypto-Wallets, Seed-Phrasen, API-Schlüssel für Kryptobörsen;
• Browserpasswörter und Cookies, Shell-Verlauf;
• API-Schlüssel für KI-Dienste, restic- und Borg-Backup-Passwörter.

Das Programm lief auf Infrastrukturebene und wurde nie innerhalb der Server ausgeführt. Daher hinterlässt es keine Spuren auf dem Server selbst, selbst wenn Daten kopiert wurden.

Wir haben auf unseren Knoten keine Spuren dieses Programms gefunden, aber angesichts der mangelnden Informationen seitens des Herstellers können wir nicht völlig ausschließen, dass es ausgeführt wurde.

Was wir gemacht haben

Ohne auf die vollständigen Informationen des Anbieters zu warten, führten wir unsere eigene Untersuchung durch und schlossen die uns bekannten Zugriffswege:

1. Unmittelbar nach Feststellung des Angriffs wurde der öffentliche Zugang zum Kontrollpanel gesperrt.
2. Wir haben in beiden Systemen unbefugte Administratorkonten gefunden und gesperrt, die von den Angreifern zur Aufrechterhaltung des Zugriffs erstellt worden waren. Die Daten wurden für die Untersuchung gesichert und dem Anbieter mitgeteilt.
3. Alle von ISPsystem veröffentlichten Korrekturen wurden installiert.
4. Alle auf dem Panel-Server gespeicherten Daten wurden rotiert: Knotenzugriffsschlüssel, Servicepasswörter für Abrechnungs- und Supportintegrationen, DNS- und Backup-Schlüssel.
5. Die Knoten, auf denen die Client-Server gehostet werden, wurden überprüft: Dateien, Dienste, Prozesse und Protokolle.

Was nicht betroffen war

Nach unseren Ermittlungen hatte der Vorfall keine Auswirkungen auf:

• Backup-Server;
• personenbezogene Daten bei der Abrechnung;
• Zahlungsdetails;
• alle anderen Dienste als die betroffene Virtualisierungsmanagementplattform.

Die Trennung dieser Systeme machte den Unterschied: Der Zugriff auf einen Teil der Virtualisierungsmanagementumgebung gewährte keinen Zugriff auf Abrechnungsdaten, Kundenkonten oder die Backup-Infrastruktur.

Was musst du machen

Das Hauptrisiko besteht darin, dass die Angreifer gestohlene Passwörter und Schlüssel verwenden. Führen Sie die folgenden Schritte so schnell wie möglich durch, auch wenn auf Ihrem Server alles normal aussieht.

1. Zuerst die Krypto-Wallets. Falls auf dem Server Wallets oder Seed-Phrasen gespeichert waren, übertragen Sie die Gelder auf neue Wallets, die auf einem anderen, sauberen Gerät erstellt wurden.
2. Ändern Sie Ihr Root-Passwort. Wenn Sie die Einstellung über das Bedienfeld vorgenommen und seitdem nicht mehr geändert haben.
3. Wechseln Sie zur SSH-Schlüsselanmeldung. und die Passwortanmeldung deaktivieren.
4. Alle auf dem Server gespeicherten Geheimnisse rotieren: Benutzer- und Datenbankpasswörter, SSH-Schlüssel, API-Schlüssel und -Tokens, Zugriff auf Cloud-Dienste, CI/CD, E-Mail, Zahlungssysteme und KI-Dienste.
5. Alte Schlüssel widerrufen anstatt einfach neue zu erstellen: in Cloud-Konsolen, GitHub, GitLab und bei Zahlungsanbietern.
6. Überprüfen Sie den Server: unbekannte Benutzer, Schlüssel in ~/.ssh/authorized_keys, Cronjobs, ungewohnte Prozesse und Systemd-Dienste.
7. Anmeldeprotokolle prüfen auf dem Server und in den Diensten, deren Schlüssel darauf gespeichert waren: Suchen Sie nach Anmeldungen von unbekannten Adressen nach dem 11. Oktober.

Falls Sie Server bei anderen Anbietern haben, auf denen VMmanager 6 läuft, führen Sie dort die gleichen Schritte durch.

Brauchen Sie Hilfe?

Haben Sie etwas Verdächtiges auf Ihrem Server entdeckt oder sind Sie sich unsicher? Kontaktieren Sie unser Support-Team – wir helfen Ihnen gerne weiter und installieren den Server bei Bedarf neu.

Wir entschuldigen uns für die Unannehmlichkeiten, insbesondere für die Zeit, in der das Bedienfeld nicht erreichbar war. Wir werden diesen Artikel aktualisieren, sobald neue Informationen des Anbieters vorliegen, und nach Abschluss der Untersuchung einen ausführlichen Bericht veröffentlichen.