Sicherheitsvorfall bei Northflank: Was jetzt zu rotieren ist

Zuletzt aktualisiert: 5. November 2026. Die Vorfallsseite von Northflank wurde am 5. November erneut geprüft; das letzte dort veröffentlichte Update stammte weiterhin vom 2. November 2026.

Den Sicherheitsvorfall bei Northflank – so bezeichnet das Unternehmen den Einbruch selbst – hat die Plattform am 30. Oktober 2026 offengelegt. Dabei forderte sie ihre Kunden vorsorglich auf, davon auszugehen, dass jede Umgebungsvariable entschlüsselt wurde, also so entsperrt, dass Angreifer sie lesen konnten.

Umgebungsvariablen sind gespeicherte Einstellungen, die Anwendungen zur Laufzeit auslesen. Sie enthalten oft API-Schlüssel, also die geheimen Codes, mit denen Software einen Dienst nutzen kann. Benutzer meldeten zudem die unbefugte Nutzung ihrer KI-API-Schlüssel. Die Statusseite belegt nicht, dass jede gespeicherte Variable gestohlen wurde.

Im Folgenden: was Northflank, Railway und Huntress gemeldet haben und welche Prüfungen jetzt anstehen.

Northflank: forderte Kunden am 30. Oktober 2026 auf, davon auszugehen, dass alle Umgebungsvariablen entschlüsselt wurden, und jedes Secret zu rotieren (Northflank).
Black October: Wiz, ein Unternehmen für Cloud-Sicherheit, zählte mindestens neun KI-Entwicklerplattformen (Dienste zum Erstellen und Betreiben von KI-Anwendungen), die zwischen dem 6. und dem 30. Oktober Sicherheitsvorfälle offenlegten. Ihre öffentlichen Erklärungen unterschieden sich, mehrere waren vorläufig und bei einigen blieb die Ursache unbekannt (Wiz).
Railway: teilte am 21. Oktober 2026 mit, dass ein unbefugter Dritter möglicherweise auf verschlüsselte Umgebungsvariablen von Kunden zugegriffen und bei einigen davon die entschlüsselten Inhalte erlangt hat (Railway).
Token Spraying: Huntress verfolgte, wie gestohlene Session-Token für Microsoft 365 (M365), die einen Benutzer angemeldet halten, zwischen dem 14. Juli und dem 22. September 2026 bei 79 Organisationen wiederverwendet wurden (Huntress).

Sicherheitsvorfall bei Northflank: Alle Umgebungsvariablen gelten als entschlüsselt

Was passiert ist: Northflank ist eine Cloud-Plattform, auf der Teams Anwendungen und Datenbanken betreiben. Am 30. Oktober 2026 eröffnete das Unternehmen auf seiner Statusseite einen Sicherheitsvorfall. Die wichtigsten Zeitpunkte (UTC):

11:43: Von Wiz ging eine Bedrohungswarnung ein.
13:40: Northflank forderte Kunden auf, ihre Umgebungsvariablen sofort zu rotieren. Ein Secret zu rotieren bedeutet, es durch ein neues zu ersetzen und das alte ungültig zu machen.
13:58: Vorsorglich forderte Northflank Kunden auf, davon auszugehen, dass alle Umgebungsvariablen entschlüsselt wurden, und alle Schlüssel zu deaktivieren und zu rotieren.
Später am 30. Oktober: Northflank ergänzte, dass Benutzer die unbefugte Nutzung von KI-API-Schlüsseln gemeldet hatten, die auf der Plattform hinterlegt waren.
01:04 am 31. Oktober: Northflank aktivierte Audit-Logs für alle Kunden, auch für Benutzer des kostenlosen Tarifs. Audit-Logs protokollieren, wer in einem Konto was getan hat.
30. und 31. Oktober: Northflank schaltete schrittweise die Secret-Rotation für Datenbanken und andere Add-ons frei.

Die Seite nennt keine Zahl betroffener Kunden.

In einem Update vom 2. November erklärte Northflank:

Der Angriffsvektor sei nach eigener Einschätzung innerhalb einer Stunde nach der ersten Warnung eingedämmt worden
Zu diesem Zeitpunkt gebe es keine Anzeichen dafür, dass auf Workloads oder Workload-Daten zugegriffen wurde
Die Indizien deuteten darauf hin, dass sich der Angriff auf Secrets in der Control Plane konzentrierte, also dem Teil der Plattform, der die Projekte der Kunden verwaltet
Unabhängige forensische Prüfer untersuchten den Angriff noch
Kunden sollten weiterhin alle Secrets rotieren; eine Ursachenanalyse folge, sobald die Ergebnisse bestätigt seien

Eine Zahl betroffener Kunden nannte das Unternehmen weiterhin nicht.

Warum das wichtig ist: Wiz zählte mindestens neun KI-Entwicklerplattformen, die zwischen dem 6. und dem 30. Oktober Sicherheitsvorfälle offenlegten: Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode und Northflank. Am 2. und 3. November aktualisierte Wiz seinen Beitrag und ergänzte gemeldete Vorfälle bei Brev, Trigger.dev und Chainstack.

Laut Wiz deuteten die öffentlichen Berichte durchweg auf gezielte Versuche hin, an gespeicherte Umgebungsvariablen zu gelangen, insbesondere an Schlüssel für den Zugriff auf KI-Dienste. Eine einzelne Schwachstelle oder gemeinsame Abhängigkeit, die die Vorfälle verbindet, fand Wiz nicht. Dieses Muster beweist weder einen gemeinsamen Angreifer noch eine einzelne Kampagne.

Wiz fasste außerdem die ersten Erklärungen zusammen:

Zugriff auf Zugangsdaten bei Fireworks, Zeabur und Lightning
Mögliche Rechteausweitung in den Build-Systemen von Railway
Ein Problem bei einem Dienstleister von Warp
Zugriff über ein Altsystem bei OpenCode

Mehrere dieser Erklärungen waren vorläufig und einige Ursachen waren noch unbekannt.

Wiz beschrieb auch, was ein gestohlener Schlüssel wert sein kann. Bei zwei Unternehmensschlüsseln beobachtete Wiz die erste unbefugte Aktivität jeweils innerhalb von 30 Minuten nach dem gemeldeten Zugriff auf Zugangsdaten beim Anbieter. In einem Fall setzte der Angreifer über 30 Stunden rund 800.000 Aufrufe an Amazon Bedrock ab, den Amazon-Dienst zum Betreiben von KI-Modellen, und etwa 90 % davon waren erfolgreich.

Nach Schätzung von Wiz verursachten beide Fälle zusammen wahrscheinlich Nutzungskosten von mehr als 100.000 US-Dollar zu Listenpreisen, also gemäß der öffentlichen Preisliste. Das ist eine Schätzung, keine bestätigte Rechnung.

Konsequenz für die Abwehr: Die Empfehlungen von Northflank bestehen aus drei Teilen:

Widerrufen Sie bestehende Zugangsdaten beim ausstellenden Unternehmen, machen Sie sie also ungültig. Erstellen Sie Ersatz und aktualisieren Sie die betroffenen Secrets und Workloads in Northflank.
Prüfen Sie die Nutzungs- und Abrechnungsprotokolle Ihres KI-Anbieters auf Aktivitäten, die Sie nicht zuordnen können.
Deaktivieren Sie den öffentlichen Zugriff auf Add-ons, also Zusatzdienste wie Datenbanken, wo er aktiviert ist.

Unsere Empfehlung: Geben Sie jeder Plattform einen eigenen Schlüssel, sofern Ihr Anbieter das unterstützt, und beschränken Sie ihn auf die Berechtigungen, die diese Plattform benötigt. Richten Sie Nutzungswarnungen ein und, falls angeboten, ein festes Limit, also eine Obergrenze, die Anfragen ab einem bestimmten Ausgabenbetrag stoppt.

Getrennte Schlüssel erleichtern den Widerruf. Ausgabenkontrollen unterscheiden sich je nach Anbieter und stoppen möglicherweise nicht jede Überschreitung. Prüfen Sie daher, wie sich Ihr Anbieter verhält.

Quellen: Statusseite von Northflank; Wiz

Sicherheitsvorfall bei Railway: Jede Umgebungsvariable erneuern, inklusive Registry-Zugangsdaten

Was passiert ist: Railway ist eine weitere Plattform zum Betreiben von Anwendungen. Am 21. Oktober 2026 teilte das Unternehmen mit, ungewöhnliche Aktivitäten an den Systemen festgestellt zu haben, in denen die Umgebungsvariablen der Kunden gespeichert sind. Ein unbefugter Dritter habe möglicherweise auf die verschlüsselten Variablen zugegriffen und bei einigen davon die entschlüsselten Inhalte erlangt.

Zunächst erklärte Railway, die Auswirkungen beschränkten sich möglicherweise auf einen Teil der Benutzer. Der vorläufige Bericht vom 22. Oktober ergänzte:

Bei höchstens 1,85 % der Workspaces, rund 100.000, waren einige Umgebungsvariablen potenziell kompromittiert.
Railway konnte nicht feststellen, welche Variablen konkret entschlüsselt wurden.
Bestehende Bereitstellungen, also die bereits laufenden Anwendungsversionen, blieben online. Neue Builds und Bereitstellungen wurden pausiert.

Railway erklärte, der Vorfall sei nach eigener Einschätzung Teil „einer Reihe von Angriffen, die sich in letzter Zeit gegen Plattformunternehmen richteten“. Ziel sei es gewesen, KI-Inferenzanbieter zu kompromittieren, also Unternehmen, die KI-Modelle für Kunden betreiben. Railway habe diese vorgelagerten Anbieter informiert, damit sie Schlüssel vorsorglich widerrufen.

Warum das wichtig ist: Die Cloud Security Alliance, eine Forschungsgruppe der Branche, erklärte am 23. Oktober, dass kein Unternehmen die Vorfälle öffentlich einem einzelnen Angreifer zugeordnet habe. Die Einordnung als Kampagne stamme zudem allein von Railway. Nach dieser Einschätzung war eine einzelne Kampagne nicht belegt.

Wiz fand unabhängig davon keine gemeinsame Schwachstelle oder Abhängigkeit über die Vorfälle hinweg. Das Risiko ist in jedem Fall dasselbe: Ihre Secrets liegen auf einer Plattform, von der Sie abhängen, und möglicherweise hat jemand anderes sie gelesen.

Konsequenz für die Abwehr: Railway empfiehlt, alle Umgebungsvariablen zu erneuern, also jede einzelne zu ersetzen, einschließlich der in Railway gespeicherten API-Schlüssel und Zugangsdaten für private Registries. Gemeint sind die Zugangsdaten, mit denen eine Anwendung ihre Container-Images aus einem privaten Speicher abruft. Railway empfiehlt außerdem, die Protokolle dieser Dienste auf ungewöhnliche Aktivitäten zu prüfen.

Unsere Empfehlung: Führen Sie eine Liste, welche Anbieterschlüssel auf welcher Plattform liegen. So wird die Rotation zur Checkliste statt zur Suche.

Quellen: Offenlegung von Railway; Vorläufiger Bericht von Railway; Cloud Security Alliance

Token-Diebstahl bei Microsoft 365: Huntress verfolgte wiederverwendete Token bei 79 Organisationen

Was passiert ist: Huntress, ein Sicherheitsunternehmen, berichtete am 22. Oktober 2026 über eine Kampagne, die vom 14. Juli bis zum 22. September 2026 lief. Nach eigenen Angaben reagierte Huntress auf damit zusammenhängende Vorfälle bei 79 Organisationen. Das Unternehmen zählte 497 erfolgreiche Anmeldungen bei Microsoft 365 und mehr als 200.000 fehlgeschlagene Anmeldeversuche.

Drei Begriffe helfen beim Verständnis:

Session-Token: Daten, die nach der Anmeldung ausgestellt werden und mit denen Ihr Gerät angemeldet bleibt oder Zugriff erhält, ohne jeden Anmeldeschritt zu wiederholen. Wie lange ein Token gültig ist, hängt vom Token, der Anwendung, dem Ablauf, dem Widerruf und den Richtlinienkontrollen ab.
Token Spraying: So nennt Huntress die Wiederverwendung gestohlener Session-Token bei vielen Konten, analog zum Password Spraying, bei dem erratene Passwörter bei vielen Konten durchprobiert werden.
MFA: Abkürzung für Multi-Faktor-Authentifizierung, eine Anmeldung, die mindestens zwei verschiedene Arten von Nachweisen prüft, zum Beispiel ein Passwort plus einen Code oder eine Bestätigung in einer Authenticator-App.

Zwei Ergebnisse stechen hervor:

In 19 Organisationen wurden die bestehenden MFA-Methoden des Opfers gelöscht und innerhalb von drei Stunden nach der ersten Anmeldung von einer Kampagnenadresse eine neue Methode registriert
In einem detailliert beschriebenen Fall wurde laut den Zeitstempeln in der Zeitleiste von Huntress etwa 38 Minuten nach der Übernahme der Sitzung ein neuer Authenticator mit der Bezeichnung „iPhone 13“ aktiviert

Warum das wichtig ist: Laut Huntress stammten die Token aus drei Quellen:

Ein Adversary-in-the-Middle-Relay, also eine gefälschte Anmeldeseite, die die echte Anmeldung des Opfers an Microsoft durchreicht
Device-Code-Phishing, bei dem ein Benutzer dazu gebracht wird, eine vom Angreifer gestartete Anmeldung zu bestätigen
Social Engineering während einer echten Anmeldung

In den Relay-Fällen behielten die Angreifer ein Token, das ausgestellt wurde, nachdem das Opfer die MFA abgeschlossen hatte, und spielten es ohne erneute MFA-Abfrage wieder ein.

Mit einem wiederverwendeten Token lässt sich eine angemeldete Sitzung weiter nutzen. Wie lange der Zugriff anhält, hängt jedoch vom Token, der Anwendung, dem Ablauf oder Widerruf sowie von Richtlinien- und Risikokontrollen ab. Ein gestohlenes Token läuft schließlich ab oder wird widerrufen. Eine vom Angreifer hinzugefügte MFA-Methode bleibt dagegen im Konto, bis jemand sie entfernt.

Laut der Schlagzeile von Help Net Security wurden die Konten kompromittiert, ohne dass Passwörter nötig waren. Das beschreibt, wie der Angreifer die gestohlene Sitzung nutzte, nicht jeden Schritt, mit dem er sie erlangte.

Konsequenz für die Abwehr: Bei Verdacht auf eine Kompromittierung empfiehlt Huntress drei Schritte:

Widerrufen Sie die Sitzungen des Benutzers.
Setzen Sie das Passwort zurück.
Entfernen Sie alle Geräte und MFA-Methoden, die der Angreifer hinzugefügt hat. Ein Zurücksetzen des Passworts allein lässt diese bestehen.

Microsoft empfiehlt außerdem, das Konto nach Möglichkeit zu deaktivieren oder zu sperren und nach weiteren Wegen zu suchen, über die sich Angreifer im Konto halten: App-Passwörter, erteilte Einwilligungen (Consent Grants), Rollen und E-Mail-Weiterleitungsregeln. Der Widerruf von Sitzungen beendet möglicherweise nicht alle Anwendungssitzungen sofort, da bereits ausgestellte Zugriffstoken bis zu ihrem Ablauf weiter funktionieren können.

Zur Vorbeugung empfiehlt Huntress Richtlinien für den bedingten Zugriff (Conditional Access), also die Regeln von Microsoft dafür, wer sich unter welchen Bedingungen anmelden darf. Sie sollten für alle Benutzer, Cloud-Apps und Client-App-Typen MFA verlangen oder den Zugriff blockieren. Gehen Sie dabei mit Bedacht vor:

Nehmen Sie „Break-glass“-Notfallkonten, also die für Aussperrungen vorgehaltenen Admin-Konten, von Richtlinien aus, die die Anmeldung blockieren oder einschränken. Laut Microsoft sollten diese Konten separat geschützt und überwacht werden.
Synchronisierungskonten müssen möglicherweise ausdrücklich von der Benutzerrichtlinie ausgenommen werden. Dienstprinzipale (Service Principals), also Identitäten von Anwendungen und Automatisierungen, werden vom benutzerbezogenen bedingten Zugriff nicht erfasst. Steuern Sie sie daher mit separaten Kontrollen für Workload-Identitäten.
Blockieren Sie die Legacy-Authentifizierung, also ältere Anmeldeverfahren ohne MFA-Unterstützung, über die dafür vorgesehene Bedingung für Legacy-Clients.
Testen Sie die Auswirkungen im Modus „Nur Bericht“, bevor Sie die Richtlinien erzwingen.

Quellen: Huntress; Help Net Security; Infosecurity Magazine; Microsoft: Benutzerzugriff widerrufen; Microsoft: Kompromittiertes E-Mail-Konto; Microsoft: Notfallzugriffskonten; Microsoft: MFA für alle Benutzer; Microsoft: Legacy-Authentifizierung blockieren

Was nach dem Sicherheitsvorfall bei Northflank zu rotieren ist

Bei diesen Vorfällen können gestohlene Zugangsdaten und Token als gültig akzeptiert werden, sodass unbefugte Anfragen wie normale Aktivität angemeldeter Benutzer aussehen können. Unsichtbar sind sie dadurch nicht: Nutzungsprotokolle, Anmeldeprotokolle und Risikokontrollen können ungewöhnliche Aktivitäten zeigen.

Was jetzt zu prüfen ist:

Erfassen Sie die Secrets, die Ihre Plattformen speichern. Notieren Sie jeden API-Schlüssel, jedes Datenbankpasswort und jedes Token, das als Umgebungsvariable auf einer Hosting- oder CI-Plattform gespeichert ist, sowie das Unternehmen, das es jeweils ausgestellt hat. CI bezeichnet die automatisierten Werkzeuge, die Ihren Code bauen und bereitstellen.
Widerrufen Sie zuerst an der Quelle und aktualisieren Sie dann die Plattform. Halten Sie sich an die von Northflank genannte Reihenfolge: Widerrufen Sie die bestehenden Zugangsdaten beim ausstellenden Anbieter, erstellen Sie Ersatz und aktualisieren Sie dann das betroffene Secret und die Workloads in Northflank.
Begrenzen Sie, was ein gestohlener Schlüssel tun und ausgeben kann. Verwenden Sie, wo unterstützt, für jede Plattform einen eigenen Schlüssel oder ein eigenes Projekt, beschränkt auf die benötigten Berechtigungen, mit Nutzungswarnungen und einem festen Limit. Warnungen stoppen Anfragen möglicherweise nicht und die Durchsetzung kann verzögert greifen. Durchsuchen Sie die Nutzungsprotokolle nach Aufrufen, die Sie nicht erklären können.
Beenden Sie Sitzungen und prüfen Sie dann die Anmeldemethoden. Widerrufen Sie bei jedem verdächtigen Microsoft-365-Konto die Sitzungen und setzen Sie das Passwort zurück. Entfernen Sie anschließend Geräte und Authenticatoren, die Sie nicht kennen. Prüfen Sie außerdem App-Passwörter, erteilte Einwilligungen, Rollen und Weiterleitungsregeln.
Überprüfen Sie die Abdeckung durch bedingten Zugriff. Verlangen Sie MFA für normale Benutzeranmeldungen über alle Benutzer und Ressourcen hinweg. Blockieren Sie die Legacy-Authentifizierung nach einem Test im Modus „Nur Bericht“. Dokumentieren Sie Ausnahmen für Notfallkonten und gegebenenfalls für Synchronisierungskonten und schützen und überwachen Sie diese Konten. Nutzen Sie für Dienstprinzipale einen separaten bedingten Zugriff für Workload-Identitäten, statt eine Ausnahme als Abdeckung zu werten.
Aktivieren Sie die Protokolle, die Sie benötigen würden. Schalten Sie die Audit-Logs ein, die Ihre Plattformen anbieten, und klären Sie, was sie abdecken und wie lange sie Daten aufbewahren. Northflank hat Audit-Logs für alle Kunden, auch für Benutzer des kostenlosen Tarifs, erst am 31. Oktober nach dem Vorfall aktiviert.

Passwork dokumentiert die tresorbasierte Speicherung von API-Schlüsseln und Token mit rollenbasiertem Zugriff, sodass Benutzer nur sehen, was ihre Rolle erlaubt. Über die REST API und die CLI können Skripte und CI-Pipelines Secrets aus dem Tresor auslesen. Testen Sie Passwork kostenlos und prüfen Sie, wie es zu Ihrer Umgebung passt.