Wenn ein Schlüssel alle Türen öffnet: Der KnowledgeDeliver-LMS-Zwischenfall
In der Welt der Cybersicherheit gibt es Fehler, die man beheben kann, und dann gibt es architektonische Sünden, die wie offene Türen für Angreifer wirken. Der aktuelle Vorfall rund um das Learning Management System (LMS) KnowledgeDeliver des japanischen Anbieters Digital Knowledge gehört eindeutig in die zweite Kategorie. Eine mittlerweile gepatchte Sicherheitslücke (CVE-2026-5426) wurde als Zero-Day missbraucht, um das System mit der Godzilla-Web-Shell zu infizieren und letztlich Cobalt Strike Beacon auf den Geräten ahnungsloser Nutzer zu installieren. Doch die wahre Geschichte hier ist nicht nur der Angriff selbst, sondern die erschreckende Leichtfertigkeit, die ihn überhaupt erst möglich machte.
Die Anatomie des Desasters: Hartkodierte Machine Keys
Der Kern des Problems ist so banal wie fatal: Die KnowledgeDeliver-Installationen verließen sich auf eine standardisierte web.config-Datei, die vom Hersteller bereitgestellt wurde. In dieser Datei waren sogenannte Machine Keys – also kryptografische Schlüssel, die das ASP.NET-Framework zur Verschlüsselung und Signierung von Daten nutzt – fest einkodiert (hard-coded). Das ist der absolute Antipattern in der IT-Sicherheit.
Microsoft hatte den Missbrauch öffentlich bekannter ASP.NET Machine Keys bereits im Februar 2025 dokumentiert. Doch offensichtlich war diese Warnung bei Digital Knowledge nicht angekommen oder wurde ignoriert. Die Folge: Wer den Schlüssel aus einer einzigen Installation extrahieren konnte, besaß den Masterschlüssel für alle internetzugänglichen KnowledgeDeliver-Instanzen. Ein einziger geleakter Schlüssel kompromittierte somit ein ganzes Ökosystem.
Von ViewState zu Cobalt Strike: Die Angriffskette
Technisch funktionierte der Angriff über eine sogenannte ViewState-Deserialisierung. ASP.NET nutzt ViewState, um den Zustand von Webseiten über Postbacks hinweg zu speichern. Wenn der Machine Key bekannt ist, können Angreifer bösartige ViewState-Payloads erstellen und diese über den __VIEWSTATE-Parameter in HTTP-Requests an den Server senden. Der Server deserialisiert diese Daten – und führt damit den Code des Angreifers aus. Das Ergebnis: unauthentifiziertes Remote Code Execution (RCE).
Die Angreifer nutzten diesen Zugriff, um die Godzilla-Web-Shell (auch bekannt als BLUEBEAM) einzuschleusen. Diese mächtige Web-Shell bot ihnen die Möglichkeit, beliebige Befehle auszuführen oder weitere Schadsoftware zu installieren. Doch damit nicht genug: Die Angreifer zeigten ein hohes Maß an Raffinesse bei der weiteren Vorgehensweise.
Vom Server zum Nutzer: Die Infektionskette
Nachdem die Angreifer die Kontrolle über den Webserver erlangt hatten, eskalierten sie ihre Berechtigungen auf dem Dateisystem, indem sie der Gruppe "Everyone" Vollzugriff auf das Webapplikationsverzeichnis gewährten. Dann manipulierten sie eine JavaScript-Datei der Anwendung, um eine gefälschte Sicherheitswarnung anzuzeigen. Diese warnte die Nutzer vor einer angeblichen Bedrohung und forderte sie auf, ein "Security Authentication Plugin" zu installieren.
Parallel lud diese Manipulation unsichtbar ein bösartiges Skript von einer Domain der Angreifer. Dieses Skript überredete die Nutzer, einen gefälschten Installer herunterzuladen, der letztendlich Cobalt Strike Beacon auf ihren Systemen installierte. Besonders interessant: Das finale Payload wurde mit einem Schlüssel verschlüsselt, der den Namen der kompromittierten Organisation enthielt. Ein klares Indiz dafür, dass dieser Angriff spezifisch auf das jeweilige Ziel vorbereitet wurde – kein Massenangriff, sondern ein gezielter Schlag.
Ein systemisches Problem
Dieser Vorfall ist leider kein Einzelfall. Ähnliche Schwachstellen mit hartkodierten Machine Keys wurden bereits in Sitecore Experience Manager (XM) sowie Gladinet CentreStack und TrioFox ausgenutzt. Das Muster ist immer dasselbe: Hersteller liefern Standardkonfigurationen mit festen kryptografischen Schlüsseln aus, um die Einrichtung für den Kunden zu vereinfachen. Bequemlichkeit wird hier auf Kosten der Sicherheit erkauft.
Wie Google Mandiant und das Google Threat Intelligence Group (GTIG) zutreffend anmerken, zeigt die Ausnutzung von KnowledgeDeliver die schwerwiegenden Risiken der Verwendung gemeinsamer Geheimnisse in Deployment-Templates. Ein einziger geleakter Schlüssel kann ein ganzes Ökosystem von Installationen kompromittieren.
Konsequenzen und Handlungsbedarf
Für Organisationen, die ASP.NET-Anwendungen betreiben, lautet die wichtigste Lehre: Jede Installation muss einzigartige kryptografische Schlüssel verwenden. Es gibt keine Ausreden für hartkodierte Machine Keys in Produktionsumgebungen. Darüber hinaus ist ein robustes Endpoint-Monitoring unerlässlich, um Deserialisierungsangriffe frühzeitig zu erkennen.
Für Softwarehersteller gilt: Sicherheit darf kein nachträgliches Add-on sein. Standard-Templates müssen von Haus aus sichere, zufällig generierte Schlüssel erzwingen. Die Bequemlichkeit einer einfachen Installation darf nicht zu einer existenziellen Bedrohung für die Kunden werden.
Der KnowledgeDeliver-Vorfall ist ein weiteres Lehrstück darüber, wie vermeintlich kleine Konfigurationsfehler massive Auswirkungen haben können. Es ist an der Zeit, dass die Industrie aus diesen Fehlern lernt – nicht erst, wenn der nächste Angriff passiert ist.
