KnowledgeDeliver Zero-Day legt 100% gemeinsamen machineKey-Fußabdruck offen

Einhundert Prozent aller KnowledgeDeliver-Installationen, die vor dem 24. Februar 2026 ausgeliefert wurden, sind derselben Zero-Day-Schwachstelle ausgesetzt – weil jede von ihnen denselben hardcodierten ASP.NET machineKey in einer standardisierten web.config enthielt. Das ist keine Schwachstelle im herkömmlichen Sinne, sondern eine Shared-Secret-Architektur, die sich als eine solche tarnt. CVE-2026-5426 hat einen CVSS-Wert von 7,5, der den operativen Schweregrad unterschätzt, sobald man bedenkt, dass die Voraussetzung für eine Ausnutzung (Kenntnis des Schlüssels) für jeden Kunden bereits am ersten Tag der Bereitstellung erfüllt war.

Die Zahlen

Zunächst zum Ausmaß: KnowledgeDeliver ist ein Learning-Management-System, das von Digital Knowledge entwickelt wurde und hauptsächlich in japanischen Unternehmens- und Bildungsumgebungen eingesetzt wird. Wie SecurityWeek berichtete, schreibt das Google-Tochterunternehmen Mandiant die Ausnutzung Bedrohungsakteuren zu, die ViewState-Deserialisierungsangriffe auf Basis der hardcodierten Schlüssel einsetzten und dabei Godzilla-Web-Shells sowie eine Cobalt-Strike-Backdoor auf der Infrastruktur der Opfer platzierten.

Der CVSS-Wert von 7,5 verdient genauere Betrachtung. Auf dem Papier liest sich 7,5 als „hoch, aber nicht kritisch." In der Praxis war die Voraussetzung für die Ausnutzung – die Kenntnis des machineKey – für jede Installation effektiv vorab erfüllt. Im Vergleich dazu erforderten CVE-2017-9248 in Telerik UI oder die lange Sitecore-ViewState-Kette entweder kryptografische Schwächen oder spezifische Konfigurationsfehler je Deployment. Hier war der Fehler ein vom Hersteller ausgelieferter Standard, der sich auf die gesamte Kundenbasis ausbreitete. Die tatsächlich angreifbare Population ist eher „jeder, der das Produkt heruntergeladen hat" als „jeder, der es falsch konfiguriert hat." Wer CVE-2026-5426 nachschlägt, wird feststellen, dass der Score diesen Unterschied nicht abbildet.

Die Angriffskette lohnt eine detaillierte Betrachtung, da jede Stufe den Aufwand für Verteidiger erhöht. Stufe eins: ViewState-Deserialisierung, serverseitige Codeausführung. Stufe zwei: In-Memory-Godzilla-Web-Shell (auch als Bluebeam bekannt), die den Datenträger nicht berührt und signaturbasierte Dateiprüfungen umgeht. Stufe drei: Änderung der Verzeichnis-ACLs im Web-App-Stammverzeichnis. Stufe vier: eine manipulierte JavaScript-Datei im LMS, die dem Benutzer eine gefälschte Sicherheitswarnung anzeigt und ihn auffordert, ein gefälschtes Plugin zu installieren. Stufe fünf: Cobalt Strike, verschlüsselt mit einem Schlüssel, der den Namen der Opferorganisation enthält.

Dieses letzte Detail ist bedeutsamer als es scheint. Mandiant bewertet, dass der Cobalt-Strike-Payload speziell für die angegriffene Organisation vorbereitet wurde, was auf Aufklärung und zielgerichtetes Tooling pro Opfer hinweist – kein Gießkannenprinzip. Die Quelle gibt nicht preis, wie viele Organisationen betroffen waren; das ist relevant, da es bestimmt, ob es sich um eine präzise Kampagne gegen eine Handvoll hochwertiger japanischer Ziele oder um den Beginn einer breiteren Offensive handelte. Wer KnowledgeDeliver betreibt, sollte von „mindestens einem bestätigten Opfer, Obergrenze unbekannt" ausgehen und entsprechend handeln. Sollte die Ausnutzung zunehmen, ist zu erwarten, dass Mandiant oder JPCERT/CC innerhalb von 60 Tagen Telemetriedaten veröffentlichen, die die Opferzahl nach oben korrigieren.

Was wirklich neu ist

ViewState-Deserialisierung ist keine neuartige Angriffskategorie. Sie tauchte bei Sitecore-Angriffen, bei CentreStack-Deployments und als wiederkehrender Vektor in Godzilla-Framework-Kampagnen auf. Die Technik selbst ist also recycelt. Was wirklich neu ist, ist die Supply-Chain-Natur der Voraussetzung.

Bei Sitecore und CentreStack mussten Angreifer den machineKey typischerweise pro Ziel extrahieren oder erraten. Diese Ökonomie begünstigte Verteidiger: Jedes neue Opfer erforderte neue Aufklärung. KnowledgeDeliver reduziert dieses wirtschaftliche Gefälle auf null. Sobald eine einzige Installation untersucht oder die standardisierte web.config aus einer beliebigen Quelle beschafft wird (ein geleaktes Install-Image, eine falsch konfigurierte öffentliche Instanz, ein ehemaliger Kunde), hält der Angreifer den Universalschlüssel für jedes Deployment vor dem 24. Februar. Das ähnelt eher den Vorfällen mit hardcodierten Herstellerzugangsdaten aus dem Jahr 2024 als einem klassischen Deserialisierungsfehler.

Das zweite wirklich neue Element ist der Social-Engineering-Pivot. Die meisten ViewState-zu-Web-Shell-Ketten enden bei der Server-Kompromittierung. Hier gingen die Angreifer einen Schritt weiter und manipulierten eine JavaScript-Datei der Anwendung, um Benutzern eine gefälschte Sicherheitswarnung anzuzeigen, die zur Installation eines gefälschten Plugins auffordert. Das verbindet serverseitige Kompromittierung mit clientseitigem Erstzugriff und weitet den Wirkungsradius vom LMS-Host auf jeden authentifizierten Lernenden aus, der sich einloggt. Bei einem in Unternehmen eingesetzten LMS umfasst diese Nutzerpopulation Mitarbeiter mit Unternehmensendpunkten und SSO-verknüpften Identitäten. Wer das LMS kompromittiert, hat ein Watering Hole für die gesamte Kundenbasis.

Drittens: der opferspezifische Cobalt-Strike-Schlüssel. Die Verschlüsselung des Payloads mit einem von der Opferorganisation abgeleiteten String ist ein kleines operatives Detail, das zeigt, dass die Angreifer gezielt und nicht opportunistisch vorgehen. Die Quelle gibt nicht preis, ob derselbe Operatorcluster für alle beobachteten Einbrüche verantwortlich ist – was relevant wäre, um eine einzelne APT-Kampagne von einem Freie-Schlüssel-für-alle zu unterscheiden. Die Zuordnung beobachteter TTPs zur MITRE ATT&CK-Matrix (T1190 Initial Access, T1505.003 Web Shell, T1059 Execution) ist unkompliziert, aber die Attribution ist es nicht.

Was Security-Teams bereits einpreisen sollten

Mehrere Aspekte dieses Vorfalls sollten niemanden überraschen, der seit mehr als einem Jahr Schwachstellenmanagement betreibt. ASP.NET-ViewState-Angriffe sind seit mindestens 2014 als Klasse bekannt. Hardcodierte Geheimnisse in herstellergelieferten Konfigurationen sind in der OWASP Top Ten zu kryptografischen Fehlern und Sicherheitsfehlkonfigurationen dokumentiert. Godzilla und Cobalt Strike sind handelsübliche Post-Exploitation-Tools, die jedes ausgereifte SOC bereits über Memory-Scans und Beacon-Traffic-Analyse erkennen sollte. Keine der technischen Grundkomponenten ist hier neu.

Was noch nicht eingepreist ist: die Bereitschaft regionaler Unternehmens-Softwareanbieter, im Jahr 2026 Produkte mit gemeinsam genutztem kryptografischen Material über alle Kunden hinweg auszuliefern. Ein Jahrzehnt Advisory-Output, NIST-Leitfäden und OWASP-Empfehlungen hätte dieses Muster eigentlich beenden müssen. Es ist nicht passiert. Meiner Ansicht nach ist das ein wiederkehrender blinder Fleck für Security-Teams, die standardmäßig die Anwendung im Bedrohungsmodell erfassen, aber nicht das vom Hersteller gelieferte Deployment-Artefakt. Die web.config-Datei ist kein Anwendungscode, sondern Konfiguration – und Konfigurationsaudits gleichen kryptografisches Material selten mit Datenbanken bekannter Standardwerte ab.

Ebenfalls unterschätzt: das LMS als hochkarätiges Angriffsziel. Security-Teams neigen dazu, LMS-Plattformen als Systeme geringer Kritikalität zu modellieren, die Kursinhalte beherbergen. Das sind sie nicht. Sie verarbeiten SSO-Assertions, Nutzer-PII, mitunter Zahlungsdaten für kostenpflichtige Trainings und bieten in diesem Fall einen JavaScript-Ausführungskontext für jeden authentifizierten Mitarbeiter jedes Kunden. Eine LMS-Kompromittierung ist ein Angriffspfad für Zugangsdaten und Endpunkte im gesamten Kundenunternehmen. Es ist zu erwarten, dass diese Kategorie bis 2026 mehr gezielte Aufmerksamkeit auf sich zieht – und wenn dem so ist, sollten bis Jahresende mindestens zwei weitere LMS-Anbieter-Advisories mit einem CVSS über 7,0 erscheinen.

Die Gegenmeinung

Die mehrheitliche Einschätzung wird lauten: „Patchen, Schlüssel rotieren, Zugriff einschränken, weitermachen." Mandiants eigene Empfehlungen sind genau das: Einbruch überwachen, Machine Keys rotieren, LMS-Zugriff einschränken. Vernünftiger Rat. Wahrscheinlich unzureichend.

Die Gegenmeinung: Die Rotation des machineKey bei einer Deployment, die für einen unbekannten Zeitraum exponiert war, macht bereits Geschehenes nicht ungeschehen. Wenn Godzilla im Arbeitsspeicher lief, wenn Verzeichnis-ACLs geändert wurden, wenn eine JavaScript-Datei manipuliert wurde, um authentifizierten Nutzern gefälschte Plugins unterzujubeln, dann wurden bereits Zugangsdaten exfiltriert und möglicherweise Persistenz auf Nutzerendpunkten etabliert. Die Schlüsselrotation schließt die Vordertür, nachdem die Einbrecher durch die Hintertür verschwunden sind.

Die schwierigere, weniger populäre Empfehlung lautet: vollständige Incident-Response-Haltung für jede KnowledgeDeliver-Instanz, die vor dem 24. Februar 2026 betrieben wurde. Kompromittierung annehmen, LMS von sauberem Medium neu aufbauen, Zugangsdaten für jeden Nutzer rotieren, der sich im Expositionszeitraum am LMS authentifiziert hat, und Endpunkte dieser Nutzer auf den Fake-Plugin-Payload prüfen. Das ist teuer. Die meisten Organisationen werden es nicht tun. Sie werden Schlüssel rotieren, einen Scan durchführen, nichts finden und sich für sicher erklären. In sechs bis zwölf Monaten, wenn zugehörige Cobalt-Strike-Beacons in japanischen Unternehmensnetzwerken auftauchen, wird die Spur genau hierher zurückführen.

Die wichtigsten Erkenntnisse

• CVE-2026-5426 hat einen CVSS-Wert von 7,5, aber die effektiv angreifbare Population umfasst jede KnowledgeDeliver-Installation vor dem 24. Februar 2026, da die machineKey-Voraussetzung durch den Herstellerstandard erfüllt war.
• Die Angriffskette endet in einem opferspezifisch verschlüsselten Cobalt-Strike-Backdoor, was auf gezielte Operationen statt opportunistischer Massenausnutzung hindeutet. Die Opferzahl ist nicht offengelegt.
• Die JavaScript-Manipulationsstufe verwandelt die LMS-Server-Kompromittierung in ein Watering Hole für jeden authentifizierten Nutzer und weitet den Wirkungsradius über den LMS-Host hinaus aus.
• Mandiants empfohlene Abhilfemaßnahmen (Schlüssel rotieren, Zugriff einschränken, überwachen) bilden eine Mindestanforderung, keine Obergrenze. Instanzen vor dem 24. Februar sollten als mutmaßlich kompromittiert behandelt werden, bis Endpunkt-Beweise das Gegenteil belegen.
• Testbare Prognose: War diese Kampagne auf einen Operatorkreis beschränkt, bleibt die Ausnutzungstelemetrie bis Q3 2026 flach. Wenn der Schlüssel breit geleakt wurde, ist damit zu rechnen, dass Commodity-Scanner innerhalb von 90 Tagen beginnen, KnowledgeDeliver-Instanzen zu sondieren, gefolgt von einer CISA- oder JPCERT-Advisory-Eskalation.