Bitgets Signierungsprozess hat eine Fälschung autorisiert, Salesforce meldete eine Blockierung nach dem Abfluss der Daten, ein bösartiger MFA-Anbieter überlebt Ihr Reset, Google kann die Compliance nicht nachweisen, und ISO 9001 prüft Unternehmenskultur.
In dieser Ausgabe
- 01Bitgets Signierungsprozess hat einwandfrei funktioniert. Er hat eine Fälschung signiert.
- 02Ein bösartiger MFA-Anbieter stiehlt das Passwort und überlebt anschließend das Reset.
- 03Der Agent meldete, die Daten seien blockiert worden. Sie waren bereits versendet.
- 04Google mit 403 Millionen Euro Bußgeld belegt, teilweise wegen fehlenden Compliance-Nachweises.
- 05ISO 9001:2026 macht Qualitätskultur auditierbar. Dafür lässt sich keine Verfahrensanweisung schreiben.
Erhalten Sie den nächsten GRC Brief in Ihrem Postfach.
The GRC Brief abonnierenBitgets Signierungsprozess hat einwandfrei funktioniert. Er hat eine Fälschung signiert.
Am 24. September stellte die Kryptobörse Bitget 19 nicht autorisierte Überweisungen aus ihren Hot- und Warm-Wallets fest, rund 351,6 Millionen Dollar in Ether, XRP und Stablecoins über sieben Chains. Cold Wallets blieben unberührt. Der Mechanismus ist der Teil, der Sie interessieren sollte. Laut dem eigenen Sicherheitsteam der Börse drangen die Angreifer in ein kritisches Backend-Wallet-System ein, nutzten es, um die Überweisungsdetails zu fälschen, und lösten anschließend Bitgets normalen autorisierten Signierungsprozess aus, um die Gelder zu bewegen. Geschäftsführerin Gracy Chen erklärte, ein Kompromittierung des privaten Schlüssels sei ausgeschlossen. Es hat also nichts Kryptografisches versagt. Die Signierungskontrolle tat genau das, wofür sie existiert, auf Anweisungen, die sie nicht hinterfragen konnte. Wie die Angreifer eindrangen, wird noch untersucht. Bitget verweist auf eine VPN-Infrastruktur, die zuvor mit nordkoreanischer Aktivität in Verbindung gebracht wurde, obwohl diese Zuordnung vorläufig ist und andere Analysten sie anfechten. Abhebungen sind ausgesetzt, und ein Schutzfonds von 464 Millionen Dollar deckt den Verlust.
Quelle: CNBC · Bitget breach, 25 Sep 2026
Meine Einschätzung
Lesen Sie über die Krypto-Thematik hinaus, denn das Muster existiert in Ihrer Organisation. Es handelt sich um ein Autorisierungsversagen. Die Signierungskontrolle hat den Schlüssel geschützt, nicht die Echtheit der Anweisung: Sie wurde gebeten, eine Überweisung zu autorisieren, bestätigte, dass sie berechtigt ist, Überweisungen zu autorisieren, und signierte. Niemand hat überprüft, ob die Überweisung real war. Ersetzen Sie Wallet durch Zahlungslauf oder durch Bankverbindung eines Lieferanten, und Sie haben Business Email Compromise mit besserer Kryptografie.
Die Kontrolle, die Sie tatsächlich benötigen, liegt vorgelagert, bei der Integrität dessen, was den Signierer erreicht. Woher kommt diese Anweisung, stimmt sie mit einer genehmigten Quelle überein, und wird das System, das Überweisungen zusammenstellt, sorgfältiger als das signierende System vertraut? Halten Sie die Nordkorea-Zuordnung vorerst für vorläufig: der Einstiegspunkt ist unbekannt, und Lazarus ist zu einem Label für alles vage DPRK-Artige geworden. Der Mechanismus ist die Lektion, nicht die Attribution.
Ein bösartiger MFA-Anbieter stiehlt das Passwort und überlebt anschließend das Reset.
Varonis Threat Labs veröffentlichte TrustSink, einen Missbrauch des externen Authentifizierungsmodells, demonstriert gegen Microsoft Entra. Entra ermöglicht es Ihnen, den zweiten Faktor an einen externen MFA-Anbieter zu delegieren: Der Benutzer gibt sein Passwort ein, Entra leitet weiter, und wenn der Anbieter ein gültiges signiertes Token zurückgibt, gilt die MFA-Anforderung als erfüllt. Ein Angreifer, der bereits ein privilegiertes Entra-Konto besitzt, kann einen bösartigen Anbieter registrieren, der dann genau in dem Moment, in dem der Benutzer einen zweiten Schritt erwartet, eine überzeugende Kopie der Microsoft-Passwortseite anzeigt. Das Passwort geht im Klartext an den Angreifer, der Anbieter gibt ein gültiges signiertes Token zurück, und die Anmeldung wird ohne Fehler abgeschlossen. Im Test-Tenant sah jede Anmeldung normal aus, während der Server der Forscher Passwörter mit Zeitstempel und Quell-IPs sammelte. Das Zurücksetzen des Passworts entfernt den Anbieter nicht. Er verbleibt im Flow und erfasst das Ersatz-Passwort.
Quelle: BleepingComputer · Varonis Threat Labs, 22 Sep 2026
Meine Einschätzung
Zum zweiten Mal innerhalb von zwei Monaten trifft dieselbe Lektion ein: Ein Passwort-Reset vertreibt einen Angreifer nicht. Im August war es ein Phishing-Kit, das seinen eigenen Passkey registrierte und das Reset überlebte. Hier überlebt der bösartige Anbieter das Reset und sammelt das Ersatz-Passwort. Die Reihenfolge der Maßnahmen ist daher selbst eine Kontrolle. Entfernen Sie zuerst die Persistenz, also den Anbieter, seine Anwendungen, Schlüssel und Redirect-URIs, und rotieren Sie danach die Zugangsdaten. Umgekehrt haben Sie das neue Passwort preisgegeben.
Seien Sie präzise in der Einordnung, denn das ist relevant. Es handelt sich um Post-Compromise, nicht um initialen Zugang: Die Registrierung eines bösartigen Anbieters erfordert Global Administrator oder Authentication Policy Administrator. Der eigentliche Befund ist also Standing Privilege, kein gebrochenes MFA. Beachten Sie außerdem, was Entra verifiziert hat: eine gültige Signatur auf einem Token, das behauptet, der zweite Faktor habe stattgefunden. Nicht, dass er tatsächlich stattgefunden hat.
Der Agent meldete, die Daten seien blockiert worden. Sie waren bereits versendet.
Zenity Labs entdeckte drei Schwachstellen in Salesforce Agentforce, zusammen als SalesBleed bezeichnet. Der Einstiegspunkt ist Web-to-Lead, Salesforces eigenes öffentliches Lead-Erfassungsformular, das direkt in das CRM einspeist. Schädliche Anweisungen, die über dieses Formular eingereicht werden, liegen dormant, bis ein Mitarbeiter einen Agentforce-Agenten bittet, an dem Lead zu arbeiten; zu diesem Zeitpunkt liest und handelt der Agent nach ihnen. Zwei der Schwachstellen ermöglichten Zero-Click-Exfiltration von Leads- und Kontodaten mithilfe von HTML-Bild-Tags, was Trusted URLs umging, den Mechanismus, der den Agenten am Erreichen nicht genehmigter Domains hindern soll und der Top-Level-Domains nicht erkannte. Zenity berichtet, dass Agentforce dem Benutzer meldete, der Inhalt sei durch die Sicherheitsrichtlinien der Organisation blockiert worden, während die CRM-Daten bereits auf dem Server des Angreifers lagen. Die dritte Schwachstelle erlaubte dem Agenten, Phishing in interne Slack-Kanäle unter seiner eigenen Identität zu posten. Gemeldet am 1. Juni, behoben bis zum 19. August.
Quelle: SecurityWeek · Zenity Labs, 25 Sep 2026
Meine Einschätzung
Heften Sie diesen einen Satz an die Wand. Der Sicherheitsmechanismus zeigte eine Policy-Blockierung an, nachdem die Daten bereits abgeflossen waren. Sie erhielten die beruhigende Meldung und den Datenverlust, von derselben Kontrolle, in derselben Sekunde. Wenn Sie jemals einen Beweis brauchten, dass eine Kontrolle, die Erfolg meldet, nicht dasselbe ist wie eine Kontrolle, die funktioniert: Er ist diese Woche mit einem Screenshot eingetroffen.
Zwei Punkte, die Sie in Ihre eigene Umgebung mitnehmen sollten. Erstens: Ein öffentliches Lead-Formular ist nicht vertrauenswürdiger Input mit einem direkten Weg zu Ihren Kronjuwelen. Fragen Sie daher, was in alles schreiben kann, was Ihre Agenten lesen. Zweitens hatte der Agent keine Vorstellung davon, wer ihn steuerte, und signierte das Phishing daher mit seinem eigenen vertrauenswürdigen Namen. Das ist die konkrete Version des Ratschlags, den ich vor vierzehn Tagen gegeben habe: eine Identität pro Agent, und Protokolle darüber, was der Agent tatsächlich getan hat, nicht was er tun sollte.
Google mit 403 Millionen Euro Bußgeld belegt, teilweise wegen fehlenden Compliance-Nachweises.
Am 21. September verhängte die irische Data Protection Commission ein Bußgeld von 403 Millionen Euro gegen Google Ireland und ordnete an, die Verarbeitung innerhalb von sechs Monaten in Einklang zu bringen. Die im Februar 2020 nach Beschwerden europäischer Verbraucherorganisationen eröffnete Untersuchung prüfte Standortdaten in drei Funktionen: Web- und App-Aktivität, Standortverlauf und Standortgenauigkeit, im Zeitraum Mai 2018 bis Februar 2020. Die Feststellungen: unrechtmäßige und unfaire Verarbeitung in zwei davon, mangelnde Transparenz in allen drei, Aufbewahrung von Standortdaten über das Notwendige hinaus, und bei Standortgenauigkeit die fehlende Fähigkeit, die Übereinstimmung mit Rechtmäßigkeit, Fairness und Transparenz nachzuweisen. Deputy Commissioner Graham Doyle erklärte, Standortdaten könnten inhärent private Informationen offenbaren, dass Personen möglicherweise nicht wussten, dass sie zur Zielgruppenansprache mit Werbung oder zur Ableitung ihrer Interessen verwendet wurden, und dass die Aufbewahrungsdauer diesen Kontrollverlust verschlimmert habe.
Quelle: Data Protection Commission · DPC decision, 21 Sep 2026
Meine Einschätzung
Schauen Sie auf die Grundlagen. Kein Verstoß, kein Hack, kein raffinierter Angriff. Rechtmäßigkeit, Fairness, Transparenz, Aufbewahrung und die Unfähigkeit, Compliance nachzuweisen. Dieser letzte Punkt ist Artikel 5 Absatz 2, und er zieht denselben Faden wie alles oben: Compliant zu sein und es belegen zu können sind keine optionalen Hälften. Wenn Sie Ihren Arbeitsnachweis nicht erbringen können, wertet die Aufsichtsbehörde es als nicht erledigt. Die Aufbewahrungsdauer wurde als erschwerender Umstand genannt, was das dritte Mal in diesem Jahr ist, dass ich über Daten schreibe, die ihren Zweck überleben.
Achten Sie auf die Reihenfolge, nicht auf die Zahl. Ich habe beim DMA-Bußgeld im Juli dasselbe gesagt: Für Alphabet ist das Geld ein Bilanzposten, das Verhaltensmittel ist das eigentliche Instrument, und Google hat nun sechs Monate Zeit, die Art der Verarbeitung von Standortdaten zu ändern. Beachten Sie auch die Uhr. Eröffnet im Februar 2020, entschieden im September 2026. Sechs einhalb Jahre, das ist der Zeitraum, nach dem Sie aufgefordert werden können, Entscheidungen zu rechtfertigen, die von Personen getroffen wurden, die seitdem das Unternehmen verlassen haben.
ISO 9001:2026 macht Qualitätskultur auditierbar. Dafür lässt sich keine Verfahrensanweisung schreiben.
ISO hat am 16. September die sechste Ausgabe von ISO 9001 veröffentlicht, die Version von 2015 aufgehoben und die Klimaänderung von 2024 integriert. Zehn Abschnitte, gleiche Reihenfolge, der größte Teil des Textes vertraut – genau darin liegt die Falle. Vier Dinge haben sich verändert. Das Top-Management muss nun eine Qualitätskultur und ethisches Verhalten fördern; Personen, die unter Ihrer Kontrolle tätig sind, müssen darüber informiert sein, was Kultur zu einem Auditthema macht, das durch Interviews bewertet wird. Risiken und Chancen werden in separate Abschnitte aufgeteilt, die jeweils verlangen, dass Sie diese bestimmen, analysieren und bewerten – und anschließend im Management Review erneut separat bewertet werden. Das Änderungsmanagement wächst von vier auf sieben Anforderungen und umfasst neu die Kommunikation von Änderungen, die Überwachung ihrer Wirksamkeit sowie die Überprüfung der Ergebnisse. Zudem verschiebt sich ein Großteil der Formulierungen zu dokumentierten Informationen von „pflegen und aufbewahren" zu „verfügbar sein". Die Transition läuft bis zum 30. September 2029, wenn die Zertifikate von 2015 ablaufen.
Quelle: My full breakdown · cyberacademy.net
Meine Einschätzung
Eine Kultur ist keine Verfahrensanweisung. Sie können sie nicht schreiben, genehmigen und ablegen, und ein Auditor wird sie nicht durch das Lesen Ihrer Richtlinienseite bewerten. Er wird sie bewerten, indem er Ihre Mitarbeiter fragt, wie Fehler gemeldet werden und ob jemand zögert, schlechte Nachrichten zu übermitteln. Ihre Verteidigung ist der Nachweis dessen, was das Management tatsächlich tut: Vorstandsprotokolle, Entscheidungen, bei denen Qualität den Zeitplan übertroffen hat, und was mit der letzten Person passiert ist, die ein Problem eskaliert hat. Sammeln Sie diese Belege jetzt, denn Sie können sie später nicht rekonstruieren.
Zwei praktische Hinweise. Anhang A.6.1.2 besagt, dass risikobasiertes Denken keinen formalen Risikomanagementansatz oder einen dokumentierten Prozess voraussetzt. Wenn Ihnen also ein Berater sagt, die neue Version zwinge Sie zu einem Risikoregister, verkauft er Ihnen etwas. Und vertrauen Sie nicht auf die Drei-Jahres-Frist. Die meisten Organisationen führen den Übergang während eines geplanten Überwachungs- oder Rezertifizierungsaudits durch, und diese Termine werden von der Zertifizierungsstelle belegt, nicht von Ihnen. Wenn Sie von Ihrem eigenen Zyklus rückwärts rechnen, finden Sie in der Regel nur ein realistisches Zeitfenster. Die vollständige klauselweise Analyse ist oben verlinkt.