Die Auswirkungen des Salesloft-Drift-Verstoßes auf Cloudflare und unsere Kunden

Letzte Woche wurde Cloudflare darüber informiert, dass wir (und unsere Kunden) von der Salesloft Drift-Datenpanne betroffen sind. Aufgrund dieses Verstoßes hat jemand außerhalb von Cloudflare Zugriff auf unsere Salesforce-Instanz erhalten, die wir für den Kundensupport und die interne Kundenfallverwaltung nutzen, sowie auf einige der darin enthaltenen Daten. Die meisten dieser Informationen sind Kundenkontaktdaten und grundlegende Support-Falldaten, aber einige Interaktionen mit dem Kundensupport können Informationen über die Konfiguration eines Kunden offenbaren und sensible Informationen wie Zugriffstoken enthalten. Da die Salesforce-Support-Falldaten den Inhalt von Support-Tickets mit Cloudflare enthalten, sollten alle Informationen, die ein Kunde in unserem Support-System an Cloudflare weitergegeben hat – einschließlich Protokolle, Token oder Passwörter – als kompromittiert betrachtet werden, und wir empfehlen Ihnen dringend, alle Anmeldedaten zu ändern, die Sie uns möglicherweise über diesen Kanal mitgeteilt haben.

Als Teil unserer Reaktion auf diesen Vorfall haben wir die kompromittierten Daten nach Token oder Passwörtern durchsucht und dabei 104 Cloudflare-API-Token gefunden. Wir haben keine verdächtigen Aktivitäten im Zusammenhang mit diesen Token festgestellt, aber alle wurden aus Vorsicht rotiert. Alle Kunden, deren Daten bei diesem Vorfall kompromittiert wurden, sind direkt von Cloudflare benachrichtigt worden.

Keine Cloudflare-Services oder -Infrastruktur wurden in der Folge dieses Verstoßes kompromittiert.

Wir sind für die Wahl der Werkzeuge verantwortlich, die wir zur Unterstützung unseres Geschäfts verwenden. Dieser Verstoß hat unsere Kunden im Stich gelassen. Dafür möchten wir uns vielmals bei Ihnen entschuldigen. Der Rest dieses Blogbeitrags bietet eine detaillierte Zeitleiste und ausführliche Informationen darüber, wie wir diesen Verstoß untersucht haben.

Letzte Woche wurde Cloudflare auf verdächtige Aktivitäten innerhalb unseres Salesforce-Mandanten aufmerksam und erfuhr, dass wir, wie auch Hunderte anderer Unternehmen, Ziel eines Angreifers geworden sind, der die Textfelder von Support-Fällen aus unserer Salesforce-Instanz erfolgreich exfiltrieren konnte. Unser Sicherheitsteam hat daraufhin sofort eine Untersuchung eingeleitet und den Zugriff des Angreifers gesperrt sowie eine Reihe von Maßnahmen (siehe unten) ergriffen, um unsere Umgebung zu sichern. Wir schreiben diesen Blog, um zu erläutern, was passiert ist, wie wir reagiert haben und um unseren Kunden und anderen zu helfen, zu verstehen, wie sie sich vor diesem Vorfall schützen können.

Cloudflare verwendet Salesforce, um nachzuverfolgen, wer unsere Kunden sind und wie sie unsere Dienste nutzen. Wir verwenden es als Support-Tool, um mit unseren Kunden zu interagieren. Ein wichtiges Detail zu diesem Vorfall ist, dass der Bedrohungsakteur nur auf Daten in Salesforce-„Fällen“ zugegriffen hat. Diese „Fälle“ können entstehen, wenn Mitglieder des Cloudflare-Vertriebs- und Supportteams intern miteinander kommunizieren müssen, um unsere Kunden zu unterstützen; sie werden auch erstellt, wenn Kunden mit dem Cloudflare-Support interagieren. Salesforce hatte eine Integration mit dem Salesloft-Drift-Chatbot, den Cloudflare nutzte, um Website-Besuchern eine Kontaktmöglichkeit zu bieten.

Wie Salesloft bekanntgegeben hat, ist ein Angreifer in die Systeme des Unternehmens eingedrungen. Im Rahmen des Sicherheitsvorfalls gelang es dem Angreifer, OAuth-Zugangsdaten der Salesforce-Integration des Salesloft-Drift-Chat-Agents zu erlangen, um Daten aus den Salesforce-Instanzen von Salesloft-Kunden zu exfiltrieren. Unsere Nachforschungen ergaben, dass dies Teil eines ausgeklügelten Supply-Chain-Angriffs war, der auf Business-to-Business-Integrationen von Drittanbietern abzielte und Hunderte von Organisationen weltweit betraf, die Kunden von Salesloft waren. Cloudforce One– das Cloudflare-Team für Bedrohungsanalysen und Forschung – hat den fortgeschrittenen Bedrohungsakteur als GRUB1 klassifiziert. Zusätzliche Offenlegungen der Threat Intelligence Group von Google stimmen mit den von uns in unserer Umgebung beobachteten Aktivitäten überein.

Unsere Untersuchung ergab, dass der Bedrohungsakteur zwischen dem 12. und 17. August 2025 Daten aus unserem Salesforce-Mandanten kompromittierte und exfiltrierte, nachdem am 9. August 2025 eine erste Erkundung beobachtet wurde. Eine detaillierte Analyse bestätigte, dass die Offenlegung auf Salesforce-Fallobjekte beschränkt war, die hauptsächlich aus Kunden-Support-Tickets und den damit verbundenen Daten innerhalb unseres Salesforce-Mandanten bestehen. Diese Fallobjekte enthalten Kundenkontaktinformationen, die sich auf den Support-Fall beziehen, die Betreffzeilen des Falls und den Text der Fallkorrespondenz – jedoch keine Anhänge zu den Fällen. Cloudflare fordert oder verlangt von Kunden in Support-Fällen nicht, Secrets, Anmeldeinformationen oder API-Schlüssel zu teilen. In einigen Szenarien zur Fehlerbehebung können Kunden jedoch Schlüssel, Protokolle oder andere sensible Informationen in die Textfelder des Falls einfügen. Alles, was über diesen Kanal geteilt wird, sollte jetzt als kompromittiert angesehen werden.

Wir glauben, dass dieser Vorfall kein Einzelfall war, sondern dass der Bedrohungsakteur beabsichtigte, Anmeldedaten und Kundeninformationen für zukünftige Angriffe zu sammeln. Angesichts der Tatsache, dass Hunderte von Organisationen von dieser Drift-Kompromittierung betroffen waren, vermuten wir, dass der Bedrohungsakteur diese Informationen nutzen wird, um gezielte Angriffe gegen Kunden in den betroffenen Organisationen zu starten. 

Dieser Beitrag bietet eine Zeitleiste des Angriffs, beschreibt unsere Reaktion und bietet Sicherheitsempfehlungen, um anderen Organisationen zu helfen, ähnliche Bedrohungen zu mindern.

In diesem Blog-Post beziehen sich alle Datums- und Zeitangaben auf UTC.

Als Salesforce und Salesloft uns am 23. August 2025 darüber informierten, dass die Drift-Integration in mehreren Organisationen, darunter auch bei Cloudflare, missbraucht worden war, haben wir umgehend eine unternehmensweite Sicherheitsvorfallreaktion (Security Incident Response) eingeleitet. Wir haben funktionsübergreifende Teams aktiviert und Experten aus den Bereichen Sicherheit, IT, Produkt, Recht, Kommunikation und aus der Geschäftsführung unter einer einzigen, einheitlichen Vorfall-Kommandostruktur zusammengeführt.

Wir haben vier klare vorrangige Arbeitsströme eingerichtet, um unsere Kunden und Cloudflare zu schützen:

1. Sofortige Bedrohungseindämmung: Wir haben den Zugriff aller Bedrohungsakteure gesperrt, indem wir die kompromittierte Drift-Integration deaktiviert haben, eine forensische Analyse durchgeführt, um das Ausmaß der Kompromittierung zu verstehen, und die aktive Bedrohung aus unserer Umgebung entfernt.

2. Sicherung unseres Drittanbieter-Ökosystems: Wir haben sofort alle Drittanbieter-Integrationen von Salesforce getrennt. Wir haben neue Secrets für alle Dienste erstellt und einen neuen Prozess eingeführt, um diese wöchentlich zu rotieren.

3. Schutz der Integrität unserer umfassenderen Systeme: Wir haben die Rotation der Anmeldedaten auf alle unsere Internetdienste und Konten von Drittanbietern als Vorsichtsmaßnahme ausgeweitet, um zu verhindern, dass Angreifer mithilfe kompromittierter Daten auf andere Cloudflare-Systeme zugreifen.

4. Analyse der Auswirkungen auf Kunden: Wir haben die Daten unserer Salesforce-Fallobjekte analysiert, um festzustellen, ob Kunden gefährdet sein könnten, und um sicherzustellen, dass sie rechtzeitig und korrekt über potenzielle Gefährdungen informiert werden.

Unsere forensische Untersuchung rekonstruierte die Aktivitäten des Bedrohungsakteurs gegen Cloudflare, die zwischen dem 9. und dem 17. August 2025 stattfanden. Im Folgenden wird ein chronologischer Überblick über die Aktionen des Bedrohungsakteurs gegeben, einschließlich der anfänglichen Aufklärung vor der Erstkompromittierung.

Um 11:51 Uhr versuchte GRUB1, ein von Cloudflare ausgestelltes API-Token für die Salesforce-API zu validieren. Der Akteur verwendete Trufflehog (einen beliebten Open-Source-Secret-Scanner) als User-Agent und sendete eine Verifizierungsanfrage an client/v4/user/Tokens/verify. Die Anfrage schlug mit einer 404 Not Found fehl, wodurch bestätigt wurde, dass das Token ungültig ist. Die Quelle dieses API-Tokens ist unklar – es könnte aus verschiedenen Quellen stammen, einschließlich anderer Drift-Kunden, die GRUB1 möglicherweise vor Cloudflare kompromittiert hat. 

Um 22:14 Uhr verschaffte sich GRUB1 Zugriff auf den Salesforce-Mandanten von Cloudflare, indem er einen gestohlenen Anmeldedatensatz nutzte, das von der Salesloft-Integration verwendet wurde. Mit diesen Anmeldedaten meldete sich GRUB1 von der IP-Adresse 44[.]215[.]108[.]109 aus an und stellte eine GET-Anfrage an den API-Endpunkt /services/data/v58.0/sobjects/ . Diese Aktion schien alle Objekte in unserer Salesforce-Umgebung aufzulisten und verschaffte dem Angreifer einen umfassenden Überblick über die dort gespeicherten Daten.

Einen Tag nach dem ersten Verstoß startete der Bedrohungsakteur GRUB1 einen weiteren Angriff von derselben IP-Adresse, 44[.]215[.]108[.]109. Ab 19:33 stahlen die Angreifer Kundendaten aus den Salesforce-Fallobjekten. Zuerst führten sie eine Objektaufzählung erneut aus, um die Datenstruktur zu bestätigen, dann riefen sie sofort das Schema der Fallobjekte über den Endpunkt /sobjects/Case/describe/ ab. Darauf folgte eine umfassende Salesforce-Abfrage, die Felder aus dem Salesforce-Fallobjekt auflistete.

Der Bedrohungsakteur GRUB1 investierte Stunden, um umfassende Erkundungen des Salesforce-Mandanten von Cloudflare von der IP-Adresse 44[.]215[.]108[.]109 durchzuführen. Es scheint, dass sein Ziel darin bestand, ein Verständnis für unsere Umgebung zu entwickeln. Mehrere Stunden lang führte er eine Reihe gezielter Abfragen aus:

• 00:17 Uhr – Er hat die Größe des Mandanten durch die Zählung von Accounts, Kontakten und Nutzern gemessen; 

• 04:34 Uhr – Analyse der Fall-Workflows durch Abfrage von CaseTeamMemberHistory; und 

• 12:09 Uhr – Durch Fingerprinting des Organization-Objekts wurde bestätigt, dass er sich in einer Produktionsumgebung befindet. 

Der Bedrohungsakteur schloss seine Aufklärungsarbeit mit zusätzlichen Abfragen ab, um zu verstehen, wie unser Kundensupport-System funktioniert – einschließlich der Art und Weise, wie Teammitglieder verschiedene Arten von Fällen bearbeiten, wie Fälle zugewiesen und eskaliert werden und wie unsere Supportprozesse ablaufen. Anschließend fragte er den /limits/-Endpunkt ab, um die operativen Schwellenwerte der API zu erfahren. Die von GRUB1 durchgeführten Abfragen gaben ihm Einblicke in ihre Zugriffsebene, die Größe der Fallobjekte und die genauen API-Grenzwerte, die er einhalten musste, um nicht in unserer Salesforce-Umgebung entdeckt zu werden.

Nach der Erkundung am 14. August 2025 haben wir fast 48 Stunden lang keinen Datenverkehr und keine erfolgreichen Anmeldungen des Bedrohungsakteurs GRUB1 beobachtet.  

Sie kehrten am 16. August 2025 zurück. Um 19:26 Uhr meldete sich GRUB1 von der IP-Adresse 44[.]215[.]108[.]109 aus wieder beim Salesforce-Mandanten von Cloudflare an und führte um 19:28 Uhr eine einzige, letzte Abfrage aus: SELECT COUNT() FROM Case. Diese Aktion diente als letzter „Probelauf“, um die genaue Größe des Datensatzes zu überprüfen, den sie stehlen wollten, was das endgültige Ende der Aufklärungsphase markierte und die Bühne für den Hauptangriff bereitete. 

GRUB1 leitete die Phase der Datenexfiltration durch den Wechsel zur neuen Infrastruktur ein und meldete sich um 11:11:23 von der IP-Adresse 208[.]68[.]36[.]90 aus an. Nach einer letzten Überprüfung der Größe des Fallobjekts startete ein Salesforce Bulk API 2.0-Auftrag um 11:11:56. In etwas mehr als drei Minuten exfiltrierte er erfolgreich einen Datensatz, der den Text von Support-Fällen, jedoch keine Anhänge oder Dateien, in unserer Salesforce-Instanz enthielt. Um 11:15:42 Uhr versuchte GRUB1, seine Spuren zu verwischen, indem er den API-Auftrag löschte. Obwohl diese Maßnahme die primären Beweise verschleierte, konnte unser Team den Angriff anhand der verbleibenden Protokolle rekonstruieren. 

Wir haben nach dem 17. August 2025 keine weiteren Aktivitäten dieses Bedrohungsakteurs beobachtet.

Salesloft setzte sämtliche Drift-Salesforce-Verknüpfungen bei seinen Kunden außer Kraft und veröffentlichte hierzu eine Mitteilung auf der eigenen Website. Zu diesem Zeitpunkt war Cloudflare noch nicht benachrichtigt worden, und wir hatten keinen Hinweis darauf, dass diese Maßnahme des Anbieters unsere Umgebung betreffen könnte.

Unsere Reaktion auf diesen Vorfall begann, als Salesforce und Salesloft uns über ungewöhnliche Drift-bezogene Aktivitäten informierten.  Wir haben die von den Anbietern empfohlenen Eindämmungsmaßnahmen umgehend umgesetzt und sie beauftragt, Informationen zu sammeln. 

Bis zum 25. August hatten wir zusätzliche Informationen über den Vorfall erhalten und unsere Reaktion über die anfänglich vom Anbieter empfohlenen Eindämmungsmaßnahmen hinaus verstärkt. Wir haben unsere eigene umfassende Untersuchung und Abhilfemaßnahmen eingeleitet.

Unsere oberste Priorität war es, den Zugriff von GRUB1 direkt an der Quelle zu unterbinden. Wir haben das Drift-Benutzerkonto deaktiviert, die Client-ID und die zugehörigen Geheimnisse widerrufen und alle Salesloft-Software und Browsererweiterungen vollständig aus den Cloudflare-Systemen entfernt. Diese umfassende Entfernung minderte das Risiko, dass Bedrohungsakteure kompromittierte Token wiederverwenden, sich über veraltete Sitzungen erneut Zugang verschaffen oder Software-Erweiterungen zur Aufrechterhaltung der Persistenz nutzen. Separat haben wir unsere Sicherheitsüberprüfung erweitert, um alle mit unserer Salesforce-Umgebung verbundenen Drittanbieterdienste einzubeziehen, und die Zugangsdaten als Vorsichtsmaßnahme rotiert, um jede potenzielle laterale Bewegung des Angreifers zu verhindern. 

Da wir Salesforce als unser primäres Werkzeug zur Verwaltung der Kundensupport-Daten verwenden, bestand das Risiko, dass Kunden in ihren Serviceanfragen Secrets, Passwörter oder andere sensible Daten übermittelt haben. Wir mussten verstehen, welches sensible Material der Angreifer jetzt hatte. 

Wir haben uns sofort darauf konzentriert, ob diese Daten zur Kompromittierung der Konten, Systeme oder Infrastruktur unserer Kunden hätten verwendet werden können. Wir haben die von den Bedrohungsakteuren erlangten Daten untersucht, um festzustellen, ob sie offengelegte Anmeldedaten enthalten, da die Fälle Freitextfelder umfassen, in denen Kunden Cloudflare-API-Token, Schlüssel oder Protokolle an unser Support-Team übermitteln können. Unsere Teams haben benutzerdefinierte Scan-Tools entwickelt, die Regex-, Entropie- und Musterabgleichstechniken verwenden, um wahrscheinliche Cloudflare-Secrets in großem Maßstab zu erkennen. 

Unsere Untersuchung bestätigte, dass die Offenlegung strikt auf den Freiformtext in den Salesforce-Fallobjekten beschränkt war – nicht jedoch auf Anhänge oder Dateien. Fälle werden von Vertriebs- und Supportteams genutzt, um intern über Kundenanfragen zu kommunizieren und direkt mit Kunden zu interagieren. Infolgedessen enthielten diese Fallobjekte ausschließlich Textdaten, bestehend aus:

• Der Betreffzeile des Salesforce-Falls

• Dem Hauptteil (Body) des Falls (Freiformtext, der jegliche Korrespondenz einschließlich Schlüssel, Secrets usw. umfassen kann, wenn er vom Kunden an Cloudflare bereitgestellt wird)

• Kundenkontaktinformationen (z. B. Firmenname, E-Mail-Adresse und Telefonnummer des Anfragenden, Domainname des Unternehmens und Unternehmensland)

Diese Schlussfolgerung wurde durch umfangreiche Überprüfungen von Integrationen, Authentifizierungsaktivitäten, Endpunkt-Telemetrie und Netzwerkprotokollen validiert.

Obwohl die primären Zugangsdaten für Salesforce und Salesloft bereits zurückgesetzt worden waren, bestand unser nächster Schritt darin, die Integrationen von Drittanbietern zu beenden und sicher wiederherzustellen. Wir begannen methodisch mit dem erneuten Onboarding der beendeten Dienste, um sicherzustellen, dass jeder mit neuen Zugangsdaten versehen wurde und strengeren Sicherheitskontrollen unterliegt.

In der Zwischenzeit analysierten unsere Teams weiterhin die exfiltrierten Daten. Basierend auf der Analyse haben wir potenzielle Gefährdungen vorausgewählt (triagiert) und validiert, wobei wir nach dem Grundsatz arbeiteten, dass alle Daten, die hätten offengelegt werden können, untersucht wurden. Dies ermöglichte es uns, direkt nach der Entdeckung Maßnahmen zu ergreifen, indem wir die von der Cloudflare-Plattform ausgegebenen Token sofort rotierten – insgesamt wurden 104 API-Token rotiert. Es wurde keine verdächtige Aktivität im Zusammenhang mit diesen Tokens identifiziert. 

Basierend auf der detaillierten Analyse von Cloudflare wurden alle betroffenen Kunden formell per E-Mail und mit Bannerhinweisen in unserem Dashboard über den Vorfall informiert und über empfohlene nächste Schritte unterrichtet. 

Dieser Vorfall unterstreicht die dringende Notwendigkeit erhöhter Wachsamkeit bei der Sicherung von SaaS-Anwendungen und anderen Drittanbieter-Integrationen. Die Daten, die von Hunderten von Unternehmen kompromittiert wurden, die von diesem Angriff betroffen waren, könnten für weitere Angriffe genutzt werden. Wir drängen alle Organisationen nachdrücklich, die folgenden Sicherheitsmaßnahmen zu übernehmen:

• Trennen Sie Salesloft und alle zugehörigen Anwendungen: Trennen Sie umgehend alle Salesloft-Verbindungen aus Ihrer Salesforce-Umgebung und deinstallieren Sie alle zugehörigen Softwarekomponenten oder Browser-Erweiterungen.

• Anmeldedaten zurücksetzen: Setzen Sie die Anmeldedaten für alle Drittanbieteranwendungen und -integrationen zurück, die mit Ihrer Salesforce-Instanz verbunden sind. Ändern Sie alle Anmeldedaten, die möglicherweise zuvor in einem Support-Fall an Cloudflare weitergegeben wurden. Basierend auf dem Umfang und der Absicht dieses Angriffs empfehlen wir auch, alle Drittanbieter-Anmeldeinformationen in Ihrer Umgebung sowie alle Anmeldeinformationen, die in einem Support-Fall mit einem anderen Anbieter enthalten sein könnten, zu ändern. 

• Häufige Rotation der Anmeldedaten implementieren: Legen Sie einen regelmäßigen Rotationsplan für alle API-Schlüssel und andere Geheimnisse fest, die in Ihren Integrationen verwendet werden, um das Risiko der Offenlegung zu minimieren.

• Support-Falldaten überprüfen: Überprüfen Sie alle Daten der Kundensupport-Fälle mit Ihren Drittanbietern, um festzustellen, welche sensiblen Informationen möglicherweise offengelegt wurden. Suchen Sie nach Fällen, die Anmeldeinformationen, API-Schlüssel, Konfigurationsdetails oder andere sensible Daten enthalten, die Kunden möglicherweise geteilt haben. Speziell für Cloudflare-Kunden: Sie können den Verlauf Ihrer Support-Fälle über das Cloudflare-Dashboard unter Support > Technischer Support > Meine Aktivitäten einsehen, wo Sie Fälle filtern oder die Funktion „Fälle herunterladen“ verwenden können, um eine umfassende Überprüfung durchzuführen.

• Forensik durchführen:  Überprüfen Sie die Zugriffsprotokolle und Berechtigungen für alle Drittanbieter-Integrationen und überprüfen Sie die öffentlichen Materialien, die mit dem Drift-Vorfall in Verbindung stehen, und führen Sie eine Sicherheitsüberprüfung Ihrer Umgebung durch, falls erforderlich.

• Prinzip der Vergabe geringster Zugriffsberechtigungen durchsetzen: Überprüfen Sie alle Drittanbieteranwendungen, um sicherzustellen, dass sie mit den minimal erforderlichen Zugriffsberechtigungen arbeiten und dass keine Administratorkonten für Anbieter verwendet werden. Setzen Sie außerdem strenge Kontrollen wie IP-Adressbeschränkungen und Sitzungsbindungen für alle Verbindungen mit Drittanbietern und Business-to-Business (B2B) durch.

• Überwachung und Kontrollen verbessern: Setzen Sie erweiterte Überwachungsmaßnahmen ein, um Anomalien wie große Datenexporte oder Anmeldungen von unbekannten Orten zu erkennen. Die Erfassung von Drittanbieter-Protokollen kann zwar schwierig sein, diese Protokolle müssen jedoch unbedingt Teil Ihrer Sicherheitsteams sein.

Nachfolgend sind die Hinweise auf Kompromittierung (Indications of Compromise, IOC) aufgeführt, die wir bei GRUB1 festgestellt haben. Wir veröffentlichen sie, damit andere Unternehmen – insbesondere solche, die möglicherweise vom Salesloft-Verstoß betroffen sind – ihre Protokolle überprüfen und sich vergewissern können, dass derselbe Angreifer keinen Zugriff auf ihre Systeme oder Dritte hatte.

Wir sind für die von uns ausgewählten Werkzeuge verantwortlich, und wenn diese Werkzeuge von ausgeklügelten Bedrohungsakteuren kompromittiert werden, tragen wir die Konsequenzen. Unser Team reagierte auf die Mitteilung, und unsere Untersuchung bestätigte, dass die Auswirkungen strikt auf Daten in Salesforce-Fallobjekten beschränkt waren, ohne dass andere Cloudflare-Systeme oder -Infrastrukturen kompromittiert wurden.

Dennoch halten wir die Kompromittierung von jeglichen Daten für inakzeptabel. Unsere Kunden vertrauen Cloudflare ihre Daten, ihre Infrastruktur und ihre Sicherheit an. Im Gegenzug vertrauen wir manchmal auf Tools von Drittanbietern, die überwacht und deren Zugriffsmöglichkeiten sorgfältig festgelegt werden müssen. Wir sind dafür verantwortlich. Wir haben unsere Kunden im Stich gelassen. Dafür möchten wir uns vielmals bei Ihnen entschuldigen.

Da Drittanbieter-Tools zunehmend branchenweit mit internen Unternehmensdaten integriert werden, müssen wir jedes neue Tool mit sorgfältiger Prüfung angehen. Dieser Vorfall betraf Hunderte von Organisationen über einen einzigen Integrationspunkt und hob die miteinander verknüpften Risiken in der heutigen Technologielandschaft hervor. Wir sind entschlossen, neue Funktionen zu entwickeln, die uns und unseren Kunden helfen, sich gegen solche Angriffe in der Zukunft zu verteidigen—bleiben Sie dran für Ankündigungen während der Cloudflare Birthday Week später in diesem Monat.

Wir sind auch verpflichtet, Bedrohungsdaten und Forschungsergebnisse mit der breiteren Sicherheitsgemeinschaft zu teilen. In den kommenden Wochen wird unser Cloudforce One-Team einen ausführlichen Blogbeitrag veröffentlichen, der die Taktiken von GRUB1 analysiert, um die breitere Community bei der Abwehr ähnlicher Kampagnen zu unterstützen.

Die folgende Tabelle bietet eine detaillierte, chronologische Übersicht über die spezifischen Aktionen von GRUB1 während des Vorfalls.