22 Proxmox-Nodes gehackt: Was bei der Wiederherstellung übersehen wurde

Ein Proxmox-Cluster mit 22 Nodes wurde Berichten zufolge kompromittiert, nachdem eine veraltete Proxmox VE 7.4-Umgebung über Port 8006 aus dem Internet erreichbar blieb. Der Sicherheitsvorfall an sich war schon gravierend genug, doch was sich im Anschluss ereignete, liefert noch wichtigere Lehren: Beim Neuaufsetzen der Hosts blieben Hintertüren unbemerkt bestehen, sodass die Angreifer nach Wiederaufnahme des Betriebs sofort zurückkehrten.

Die naheliegende Schlussfolgerung lautet natürlich: Zeitnah patchen und niemals Hypervisor-Managementoberflächen ins öffentliche Internet stellen. Der weniger offensichtliche Aspekt betrifft die Wiederherstellung: Ein geclustertes System nach einer vollständigen Root-Kompromittierung zu bereinigen, erfordert weit mehr als das bloße Zurückspielen von Dateien aus einem Backup. Ein kompromittierter Kernel kann Ihre Wiederherstellungswerkzeuge gezielt belügen, und ein gemeinsam genutzter Cluster-Status hält Angreifer-Zugangsdaten über Node-Neuinstallationen hinweg am Leben. Zudem verwandeln Gast-Agenten den Root-Zugriff auf dem Hypervisor in Root-Rechte innerhalb der virtuellen Maschinen, während Backups zwar die Plattform retten, die Control Plane jedoch verseucht bleiben kann. In diesem Vorfall traten all diese Fehlannahmen gleichzeitig zutage.

Was geschah mit dem Proxmox-Cluster mit 22 Nodes?

Laut dem veröffentlichten Incident Report von Netfront erlangten zwischen dem 1. September und dem 2. September 2026 mindestens 33 externe IP-Adressen Root-Zugriff auf den gesamten Proxmox VE-Cluster mit 22 Nodes.

Der betroffene Bereich lief zu diesem Zeitpunkt noch auf Proxmox VE 7.4, einer Version, die bereits im Juli 2024 ihr End of Life erreicht hatte. Port 8006 war direkt über das Internet erreichbar, weil Kunden über die Proxmox-Oberfläche ihre virtuellen Maschinen selbst verwalten sollten.

Das Einfallstor bildete CVE-2023-54391. Diese Schwachstelle betrifft libpve-access-control in den Versionen von 7.0-7 bis einschließlich Versionen vor 8.0.4. Ein Angreifer mit Zugriff auf die Login-API konnte den Zwei-Faktor-Challenge-Ablauf manipulieren, um ein gültiges Ticket für ein beliebiges aktives Konto zu erhalten, für das kein zweiter Faktor eingerichtet war.

Im neueren Proxmox-Paketstand war der verwundbare Codepfad bereits im Juli 2023 entfernt worden. Die Sicherheitsrelevanz dieses Fixes wurde damals jedoch weder erkannt noch bis September 2026 öffentlich dokumentiert.

Netfront berichtet, dass die erste auffällige Anfrage etwa 25 Minuten nach der Veröffentlichung des Proxmox-Sicherheitshinweises registriert wurde. Die erste bestätigte Root-Shell erschien noch am selben Abend. Von da an beschleunigten sich die Angriffe massiv: Die Logs zeigten mehrere voneinander unabhängige Akteure, die simultan die gesamte Serverflotte durchsuchten. Eine IP-Adresse öffnete innerhalb von gut einer Minute exakt eine Root-Shell auf jedem einzelnen der 22 Nodes, während eine andere Quelle im Verlauf eines Tages fast 2,000 Shell-Sitzungen im gesamten Cluster aufbaute.

Der Bericht hält unmissverständlich fest, dass dies nicht nach einer einzelnen koordinierten Gruppe aussah: Sobald eine leicht ausnutzbare Authentifizierungsumgehung öffentlich bekannt wird, stürzen sich etliche voneinander unabhängige Angreifer zeitgleich auf die exponierte Verwaltungsebene.

Warum gefährdete die Kompromittierung eines Nodes alle 22?

Ein Proxmox-Cluster teilt sensible Zustände der Control Plane konstruktionsbedingt zwischen allen Nodes.

Proxmox nutzt pmxcfs, ein verteiltes Cluster-Dateisystem, das unter /etc/pve gemountet ist. Es repliziert die Cluster-Konfiguration fortlaufend, sodass jeder Host dieselben Benutzerkonten, VM-Definitionen, Firewall-Regeln, Zertifikate, HA-Einstellungen und weitere clusterweite Daten sieht. Eine der geschützten Dateien ist /etc/pve/priv/authorized_keys, die Proxmox für die gegenseitige SSH-Authentifizierung der Cluster-Mitglieder verwendet.

Netfront betont, dass dies die Ausbreitung im gesamten Verbund dramatisch erleichterte, sobald die Angreifer auf einem einzigen Host Root-Rechte erlangt hatten. Cluster-Knoten benötigen vertrauenswürdige Kommunikationswege und gemeinsame Konfigurationsdaten. Das ist für sich genommen kein Konstruktionsfehler, erfordert im Ernstfall jedoch eine völlig andere Reaktionsweise. Root auf einem geclusterten Hypervisor unterscheidet sich grundlegend von Root auf einem isolierten Linux-Server, weil jede Vertrauensstellung zu allen anderen Cluster-Mitgliedern kompromittiert ist.

Wenn Sie einen Cluster entwerfen oder auditieren, erläutert der Mr.PlanB Proxmox-Hub, wie Netzwerk, Storage, HA und Cluster-Status zusammenspielen. Das ist wesentlich aufschlussreicher, als jeden Host nur für sich allein zu betrachten.

Warum wirkten die Hosts wie defekte Hardware?

Laut dem Incident Report sorgte ein eBPF-Rootkit dafür, dass sich die befallenen Systeme so fehlerhaft verhielten, dass das Team anfangs von einem Hardwaredefekt ausging. Zu den Symptomen zählten Load-Averages zwischen 30 und 160 auf ansonsten völlig untätigen Maschinen, unvermittelt abbrechende Befehle und Abstürze grundlegender Werkzeuge wie top.

Paketprüfungen deckten die Ursache nicht unmittelbar auf, da die regulären System-Binärdateien gar nicht verändert worden waren. Der Eingriff fand direkt im Kernel statt. Das Rootkit klinkte sich in Systemaufrufe ein, um Prozesse und Dateien zu verbergen, Prüfungen zu blockieren, eigene Prozesse vor Beendigung zu schützen und die Ausgaben von User-Space-Tools zu fälschen. Netfront führte Teile des Codes auf öffentlich zugängliche eBPF-Proof-of-Concept-Repositories zurück; es handelte sich also keineswegs um ein exklusives, hochkomplexes Spionagewerkzeug.

Dieser Umstand stimmt besonders nachdenklich: Angreifer müssen ausgefeilte Tarnmechanismen heute nicht mehr selbst entwickeln, da öffentlich verfügbare Forschungsprojekte ihnen einsatzbereite Vorlagen liefern, die sich aus dem laufenden System heraus kaum analysieren lassen. Sie müssen deshalb nicht jeden ausgelasteten Server pauschal verdächtigen, aber Sie dürfen den Ausgaben eines Systems nicht mehr vertrauen, sobald eine Kernel-Kompromittierung plausibel erscheint.

Wie gelangten die Angreifer in die Kunden-VMs?

Netfront berichtet, dass die Angreifer von den kompromittierten Proxmox-Hosts aus den QEMU Guest Agent nutzten. Diesen Punkt sollten Administratoren besonders aufmerksam verinnerlichen.

Der Guest Agent steuert die Kommunikation zwischen Host und Gastsystem. Proxmox verwendet ihn für geordnetes Herunterfahren, das Einfrieren des Dateisystems für Snapshots, IP-Reporting und Befehlsausführungen. Nach einer Host-Kompromittierung liefert dieser Komfort dem Angreifer mächtige Steuerungsfunktionen frei Haus.

Den API-Logs zufolge wurden Befehle innerhalb der Gast-VMs über agent/exec ausgeführt und deren Resultate über agent/exec-status abgefragt. Ein VM-Passwort war dafür nicht erforderlich, da der Hypervisor bereits autorisiert war, Aktionen über den Agenten anzufordern. Gastsysteme mit aktivem QEMU Guest Agent waren direkt betroffen; VMs ohne den Agenten blieben vor diesem Angriffsvektor verschont.

Das bedeutet nicht, dass Sie den Guest Agent nun pauschal überall deaktivieren sollten, schließlich erfüllt er unverzichtbare Aufgaben im laufenden Betrieb. Dennoch agiert Hypervisor-Root in einer privilegierten Position über jedem Gast, und starke Passwörter im Gastsystem bieten keinerlei Schutz gegen einen vollständig übernommenen Hypervisor. Schützen Sie die Verwaltungsebene stets mit diesem Wissen im Hinterkopf.

Warum schlug die erste Wiederherstellung fehl?

Das Team versuchte, das Dateisystem wiederherzustellen, während der infizierte Kernel noch aktiv lief. Der erste Wiederherstellungsversuch von Netfront basierte auf dem Befehl:

rsync -aHAX --delete

um saubere Daten über das infizierte System zu spielen. Der Befehl lief zwar ohne Fehler durch, das Rootkit überlebte diesen Vorgang jedoch unbeschadet.

Der Untersuchungsbericht liefert die Erklärung: Das Rootkit manipulierte die Verzeichnisauflistung. Der Parameter rsync --delete muss jedoch das Zielverzeichnis vollständig einlesen, um überflüssige Dateien zu identifizieren und zu löschen. Wenn der manipulierte Kernel bösartige Dateien vor dieser Auflistung versteckt, erfährt rsync gar nicht von deren Existenz und löscht sie folglich nicht. Selbst ein makelloses Backup führt so zu einem fehlgeschlagenen Restore, weil das kompromittierte Betriebssystem dem Recovery-Tool falsche Tatsachen vorspiegelt.

Netfront passte die Vorgehensweise an: Rootkit entfernen, Neustart, Daten wiederherstellen, erneuter Neustart und abschließende Validierung. Hosts, die nicht mehr zuverlässig booteten, wurden vollständig über externe Medien neu installiert, auf denen kein manipulierter Kernel lief. Nach einer tiefgreifenden Host-Kompromittierung ist der Weg über externe Bootmedien stets die sicherere Wahl. Haben Sie Grund zu der Annahme, dass der Kernel unterwandert wurde, sollten Sie jedem Restore misstrauen, der aus diesem laufenden System heraus erfolgt.

Warum verschafften sich Angreifer nach dem Neuaufbau erneut Zugang?

Obwohl die Hosts neu installiert worden waren, enthielt die gemeinsam genutzte Cluster-Control-Plane weiterhin Zugangsdaten, die von den Angreifern zuvor angelegt worden waren. Das ist der lehrreichste Aspekt des gesamten Vorfalls.

Netfront erneuerte Passwörter, SSH-Schlüssel und Teile der Inhalte unter /etc/pve/priv/. Zu Beginn wurden jedoch weder alle API-Tokens vollständig erfasst noch sämtliche Benutzerkonten mit einer autoritativen Liste legitimer Identitäten abgeglichen. Dieses Versäumnis rächte sich bitter, denn /etc/pve ist das lebendige, replizierte Proxmox-Cluster-Dateisystem: Das Neuaufsetzen eines einzelnen Hosts ändert nichts an bösartigen Daten, die der Cluster postwendend wieder auf den neuen Node spiegelt.

Eine spätere Sicherheitsprüfung brachte Berichten zufolge 42 API-Token ans Licht, die root@pam zugeordnet waren, sowie zehn manipulierte Benutzerkonten, die legitimen Systemkonten täuschend ähnlich sahen. Am 7. September, nachdem die Plattform wieder in den regulären Betrieb übergeben worden war, wurden Zugangsdaten verwendet, die die Neuinstallation unbemerkt überstanden hatten.

Ein sauber aufgesetzter Node kann sich problemlos mit einer kompromittierten Control Plane verbinden. Nach einem Sicherheitsvorfall auf einer geclusterten Plattform erfordert das Recovery daher ein eigenständiges Audit aller gemeinsamen Konfigurationsdateien, Zugangsdaten, Tokens, ACLs, Automatisierungskonten, Zertifikate, SSH-Trusts und aller weiteren Daten, die außerhalb des eigentlichen Host-Dateisystems repliziert werden.

Ein Proxmox Health Check deckt gewöhnliche Konfigurationsmängel auf, doch nach einem Einbruch ist ein weitaus aggressiveres Identitäts- und Rechteaudit zwingend erforderlich.

Was machte das Backup-Konzept richtig?

Von allen architektonischen Komponenten bewährte sich die strikte Trennung zwischen Produktions- und Backup-Infrastruktur am eindrucksvollsten.

Laut Netfront zogen die Backup-Systeme die Daten eigenständig von den Produktions-Hosts ab (Pull-Prinzip). Die Produktionsumgebung konnte somit weder Schreib- noch Verwaltungszugriffe auf die Backup-Ziele ausüben. Die betroffene Zone besaß keine Zugangsdaten, mit denen entfernte Wiederherstellungskopien hätten gelöscht werden können. Zudem hielt das Unternehmen standortübergreifende Kopien in separaten Rechenzentren vor.

Dieser Aufbau entspricht exakt den Best Practices für Proxmox Backup Server. Proxmox empfiehlt räumlich getrennte Offsite-Kopien, restriktive Backup-Berechtigungen, warnt ausdrücklich vor Löschrechten für Backup-Clients und rät zu regelmäßigen Wiederherstellungstests, statt sich blind auf den erfolgreichen Status von Backup-Jobs zu verlassen.

Replikation allein ist kein Backup. Kann sich ein kompromittiertes Produktionssystem an der Kopie authentifizieren, Daten ändern oder löschen, kann ein Angreifer Produktivdaten und Recovery-Stände in einem Arbeitsgang vernichten. Ein verlässliches Backup befindet sich hinter einer Sicherheitsgrenze, die die Produktion nicht überwinden kann. So bleibt die Wiederherstellung zwar aufwendig, baut aber auf einem vertrauenswürdigen Fundament auf.

War der eigentliche Fehler der Betrieb von Proxmox VE 7.4?

Es war einer von mehreren schwerwiegenden Fehlern. Die Reaktionen der Fachwelt konzentrierten sich übereinstimmend auf zwei Kernpunkte: Der Betrieb einer Hypervisor-Version nach deren End of Life und eine öffentlich exponierte Management-Schnittstelle. Jeder dieser Punkte für sich erhöht das Risiko drastisch; in Kombination multiplizieren sie die Angriffsfläche.

Teilnehmer der Diskussion brachten jedoch auch Verständnis dafür auf, warum Produktivteams vor großen Hypervisor-Upgrades oft zurückschrecken. Eine Infrastruktur, die stabil und verstanden ist und zahlende Kunden bedient, aktualisiert man nicht leichtfertig. Ein überstürztes Upgrade ohne gründliche Tests birgt enorme Betriebsrisiken. Daher ist ein strukturierter Patch-Prozess essenziell, der größere Upgrades testet, bevor die Altversion zu einem nicht mehr unterstützten Sicherheitsnotfall wird.

Ein Testlabor, dokumentierte Rollback-Pfade, geplante Wartungsfenster, Hardware-Kompatibilitätsprüfungen, Tests mit Gastsystemen und gestaffelte Node-Upgrades kosten zweifellos Zeit. Das Neuaufsetzen von 22 gehackten Hypervisoren kostet jedoch ungleich mehr Zeit und Nerven. Wer den Aufwand für regelmäßige Upgrades einspart, zahlt die Zeche später, und zwar unter Bedingungen, die das Unternehmen nicht mehr selbst bestimmt.

Sollte Proxmox-Port 8006 jemals direkt aus dem Internet erreichbar sein?

Vermeiden Sie die direkte Freigabe ins Internet, es sei denn, Sie haben zwingende Gründe und verfügen über eine belastbare kompensierende Sicherheitsarchitektur.

Die Proxmox-Weboberfläche ist die zentrale Verwaltungsebene für den gesamten Hypervisor, und kein Bestandteil davon arbeitet mit niedrigen Rechten. Genau deshalb richtete sich die schärfste Kritik in der Community gegen das ungeschützte Exponieren von Port 8006 an nicht vertrauenswürdige Netze, und nicht gegen Proxmox selbst. Wesentlich sicherere Ansätze sind ein Management-VLAN, VPNs, dedizierte Jump-Hosts, Identity-Aware-Proxys, strikt reglementierte Firewall-Regeln und verpflichtende MFA.

Kunden-Self-Service erschwert diese Trennung, da externe Anwender berechtigten Bedarf an Verwaltungsfunktionen haben. Sie benötigen jedoch keineswegs direkten Netzwerkzugriff auf die vollständige Hypervisor-Control-Plane. Ein separates Kundenportal mit eng zugeschnittenen Proxmox-API-Berechtigungen ist eine praxistaugliche Lösung, ein Reverse-Proxy mit harter Identitätsprüfung eine andere.

Für welches Modell Sie sich auch entscheiden: Gehen Sie stets davon aus, dass Authentifizierungscode Fehler enthalten kann, und planen Sie die Architektur so, dass eine einzelne Umgehung nicht sofort Root-Zugriff auf sämtliche Hypervisoren eröffnet.

Was sollte eine Proxmox-Recovery-Checkliste nach Root-Kompromittierung enthalten?

Der Vorfall legt eine Checkliste nahe, die weit über das einfache Wiederherstellen von Backups hinausgeht:

• Bei Verdacht auf Kernel-Kompromittierung ausschließlich von sauberen, externen Medien neu installieren.
• Jeden einzelnen Node innerhalb der Vertrauensdomäne als potenziell kompromittiert behandeln.
• /etc/pve als eigenständige, gemeinsam genutzte Control Plane auditieren.
• Sämtliche Benutzerkonten und API-Token lückenlos erfassen und abgleichen.
• Zugriffsrechte (ACLs) gegen eine verifizierte Soll-Konfiguration prüfen.
• Passwörter, SSH-Schlüssel, Zertifikate und Dienst-Anmeldedaten ausnahmslos rotieren.
• Aktivitäten des Guest Agent auswerten und Gastsysteme untersuchen, falls der Hypervisor Befehle darin ausführen konnte.
• Backups aus einer Umgebung heraus validieren, die von kompromittierten Hosts nicht manipuliert werden konnte.
• Logs zentral und extern speichern, damit Angreifer die Historie nicht löschen können.
• Das Management-Interface von externen Netzen aus prüfen und sicherstellen, dass kein ungeschützter Zugriff möglich ist.

Beschränken Sie Ihre Suche niemals nur auf die Persistenzmechanismen, die Sie bereits entdeckt haben. Netfronts Bericht beschreibt Dutzende hinterlegte Token und Konten, von denen viele gar nicht aktiv genutzt wurden. Eine schlafende Hintertür bleibt dennoch eine permanente Bedrohung.

Ein eindrucksvoller Neuaufbau, der vermeidbar gewesen wäre

Die geleistete Wiederherstellungsarbeit verdient fachliche Anerkennung. Das Team führte das auffällige Systemverhalten präzise auf ein eBPF-Rootkit zurück und identifizierte das Versagen von In-Place-Wiederherstellungen mit rsync. Zudem gelang es, nicht mehr bootfähige Hosts wiederzubeleben, dank der standortübergreifenden Backup-Architektur konsistente Datenbestände zu sichern und die Aktivitäten der Angreifer anhand von Logs detailliert zu rekonstruieren.

Dennoch ist heroisches Recovery eine denkbar schlechte Sicherheitsstrategie. 22 Hypervisoren nach ihrem End of Life mit einer frei zugänglichen Verwaltungsebene machten aus einer einzelnen Authentifizierungslücke einen clusterweiten Großschadensfall. Und das Wiederherstellen der Hosts ohne vollständiges Audit der geteilten Cluster-Zugangsdaten öffnete den Angreifern die Tür ein zweites Mal.

Die weit überlegene Strategie wirkt unspektakulär: Unterstützte Softwarestände, abgeschotteter Managementzugang, MFA, unabhängige Backups, zentrales Logging außerhalb des Clusters, erprobte Upgrade-Abläufe, ein vollständiges Identitätsinventar und Recovery-Pläne, die einkalkulieren, dass ein kompromittierter Host falsche Daten liefert. Daraus entstehen zwar keine dramatischen Erfahrungsberichte, aber ein stabiler und sicherer Betrieb.