Mitte August 2025 wurde der Salesloft Drift-Datenleck gemeldet, das Giganten wie Palo Alto Networks, Salesforce, Cloudflare und deren Kunden betraf. Angreifer stahlen und missbrauchten Hunderte von OAuth-Token, um auf Salesforce-Umgebungen zuzugreifen und sensible Daten zu extrahieren. Dies hatte sowohl nachgewiesene als auch potenziell weitreichende Folgen.
Beim Lesen der Berichte konnte ich mich nicht dazu durchringen, es als einen weiteren „Supply-Chain-Angriff“ einzustufen. Dieser Angriff war anders.
Es war verbunden mit Diebstahl nicht-menschlicher Identitäten und ein Vertrauensbruch mit einer Lateral Movement TTP auf Steroiden, auch bekannt als Cross-Vendor Lateral Movement. Es handelte sich um einen Business-to-Business-to-Business-Angriff. Oder, wissenschaftlicher ausgedrückt, um einen (B2)ⁿ AngriffDiese Kette gebrochenen Vertrauens macht es den Opfern des Angriffs sehr schwer, sich zu schützen.
Denk darüber nach: Angreifer → Drift → Salesloft → Salesforce → Durch den → Kunde des Kunden.
Jeder Sprung vergrößerte die Angriffsfläche, und einmal OAuth-Token wurden gestohlen, Angreifer hatten einen vertrauenswürdigen Weg durch jeden Anbieter. Die nachgewiesenen Auswirkungen umfassen bereits Hunderte von betroffenen Organisationen, gestohlene Fallakten und mehr als 100 offengelegte API-Token. Es besteht das Potenzial für weitaus umfassendere Kompromittierungen, da Angreifer diese Daten nach Cloud-Schlüsseln und anderen Anmeldeinformationen durchsuchen.
Große Unternehmen pflegen Tausende von Partnerschaften und Integrationen, ohne ein wirklich sicheres Integrationsmodell zu haben. Diese Integrationskette führt zu einer Beziehung, die mehr als 1:1 ist. Wie können wir also solche Angriffe verhindern, erkennen oder schneller darauf reagieren und uns vor Dominoeffekten schützen?
Dies wirft natürlich auch eine größere Frage auf: Müssen wir auf eine Gemeinsames Sicherheitsmodell für SaaS-Anbieter, nicht nur für Cloud-Infrastrukturgiganten wie AWS, Microsoft und Google Cloud, die im Jahr 2020 ähnliche Forderungen stellten? In diesem Artikel werde ich erklären, wo das eigentliche Problem liegt und wie sowohl Anbieter als auch CISOs einen Rahmen für gemeinsame Verantwortung schaffen können, der alle Abhängigkeiten berücksichtigt und letztendlich reduziert Risiko einer lateralen Bewegung.
Klingt das interessant? Lesen Sie weiter. Wenn es hilfreich ist, würde ich mich über Ihre Meinung freuen.
Weitere Einzelheiten zum Verstoß
Verschiedenen Quellen zufolge (siehe unten) stahlen Angreifer mit dem Namen UNC2025 im August 6395 OAuth-Aktualisierungstoken aus der Drift-Integration von Salesloft mit Salesforce. Diese Token ermöglichten es Drift, Salesforce-Instanzen im Namen von über 700 Kunden abzufragen. Im Zugriff exportierten die Angreifer Kontaktdaten, Fallakten und sogar in Tickets oder Anhängen eingebettete API-Schlüssel.
Zu den betroffenen Unternehmen gehörten namhafte Firmen wie Cloudflare, Proofpoint und Palo Alto Networks. Cloudflare gab bekannt, dass 104 API-Token und sensible Falldaten kompromittiert wurden. Salesforce und Salesloft reagierten, indem sie Drift-Token widerriefen und die App aus AppExchange entfernten. Auch Endkunden deaktivierten diese Integration als Gegenmaßnahme. Für einige war es zu spät, da ihre Daten, einschließlich der Zugangsgeheimnisse, bereits durchgesickert waren.
Weitere Analysen ergaben, dass die Angreifer Zugriff auf die GitHub-Repositories von Salesloft hatten, was eine umfassendere Aufklärung ermöglichte und möglicherweise Token-Diebstahl begünstigte. Google berichtete zudem über einen begrenzten Missbrauch von Drift Email OAuth-Token in Google Workspace-Umgebungen. Schlimmer noch: Angreifer durchsuchten die gestohlenen Daten nach AWS-Schlüsseln, Snowflake-Token und anderen Anmeldeinformationen, was die potenziellen Auswirkungen vervielfachte.
Während viele der in den letzten Wochen veröffentlichten Beiträge und Artikel den Standpunkt vertreten, dass es sich bei diesem Cyberangriff um einen „traditionellen“ Datenverstoß, eine SaaS-Ausnutzung oder sogar einen KI-Agenten-Kompromittierung handelte, ist dieser Vorfall anders. Er ist ein reines Beispiel für IAM Komplexität, oder, vereinfacht gesagt, ein totales IAM-Chaos (kein Mesh), mit dem wir alle im Zeitalter von SaaS, KI und der explosionsartigen Zunahme nicht-menschlicher Identitäten (NHIs) konfrontiert sind. Der Drift-Chatbot ist eine Softwareanwendung zur Automatisierung von Konversationen und agiert daher nicht autonom oder trifft unabhängige Entscheidungen. Stattdessen arbeitet er innerhalb vordefinierter Workflows und Integrationen. Und das für die Integration verwendete OAuth ist ein NHI (nichtmenschliche Identität).
Was wir lernen können
Wir als Kunden sind nicht bereit, uns gegen (B2)ⁿ zu schützen. NHI-Angriffe
Es ist nicht einfach, die grundlegende Frage zu beantworten: „Welche unserer Lieferanten waren betroffen?“ und „Welche Daten und Zugriffsrechte hatten sie in Salesforce über uns?“ Diese Art von lateraler Bewegung ausnutzen Angriffe, die die Vernetzung unserer digitalen Systeme aufdecken, machen deutlich, dass es schwieriger ist, Hacker aufzuhalten, als wir denken, weil wir uns der Auswirkungen entlang der Nahrungskette oft als Letzte bewusst sind.
B2B2B-Risiken sind real und wir brauchen ein Modell der geteilten Verantwortung
Es ging nicht nur um Drift → Salesforce → Kunden. Es ging um Drift → Salesforce → SaaS-Daten der Kunden → Cloud-Dienste. Jeder Sprung vergrößerte den Explosionsradius. Anbieter müssen für die Anbieter ihrer Anbieter Rechenschaft ablegen.
Token sind Identitäten – und sollten als solche verwaltet werden, unabhängig von der B2B-Distanz
OAuth-Token sind nicht nur „technischer Klebstoff“. Es handelt sich um nicht-menschliche Identitäten, die mit der gleichen Sorgfalt behandelt werden sollten wie menschliche Konten: kurzlebig, begrenzt, rotiert und überwacht. Es sind Identitäten, die jeder (auch Angreifer) annehmen kann, wenn sie nicht ausreichend geschützt sind.
Ihre Geheimnisse und Anmeldeinformationen sind ebenfalls in den Daten enthalten – nicht nur Ihre, sondern auch die Ihrer Partner.
Fallnotizen und Anhänge enthalten oft vertrauliche Schlüssel oder Konfigurationen. Sobald sie gehackt sind, werden CRM- und Supportsysteme zu wahren Goldgruben für Anmeldeinformationen. Das Scannen und Schwärzen von Geheimnissen in SaaS-Daten muss zur Standardpraxis werden.
Zentralisierte Kill-Switches sind wichtig
Die Möglichkeit von Salesforce, Drift-Token global zu widerrufen, trug zur Eindämmung der Verbreitung bei. Alle Plattformen sollten in der Lage sein, einen Notfallwiderruf in großem Umfang zu ermöglichen.
Über die Lieferkette hinaus: Verständnis (B2)ⁿ
Es ist verlockend, dies einfach als Angriff auf die Lieferkette oder als Risiko Dritter zu kategorisieren. Doch dieser Rahmen ist zu weit gefasst und verbirgt die einzigartigen Mechanismen.
Was wir hier gesehen haben, ähnelt eher einem (B2)ⁿ-Crossing-Angriff, einer Form der anbieterübergreifenden Lateralbewegung.
Im Kern sieht es so aus:
- Ein Kunde, beispielsweise Palo Alto Networks, verwendet eine SaaS-Plattform wie Salesforce.
- Um den Wert zu steigern, verbindet Palo Alto Networks 3rd Party-App – Salesloft zu Salesforce.
- Salesloft erwirbt Drift, das OAuth-Token besaß, die im Namen von Palo Alto Networks den Zugriff von Saleloft auf Salesforce gewährten.
- Wenn die Salesforce-Daten von Palo Alto Networks eingebettete Geheimnisse (wie API-Schlüssel) enthalten, können Angreifer, die in Drift eindringen, die Salesforce-Daten ausnutzen, um tiefer in die Umgebung eines anderen Anbieters einzudringen.
Dies führt dazu, dass föderiertes Vertrauen – und implizites Vertrauen – zu einem föderierten Risiko wird. Jede Integration wirkt isoliert betrachtet harmlos, doch in Kombination eröffnen sie Angreifern einen Weg über mehrere Organisationen hinweg. Daher die Idee von (B2)ⁿ: Die Business-to-Business-Verbindungen vervielfachen sich und erhöhen die Gefährdung.
Aufbau eines Modells der geteilten Verantwortung für (B2)ⁿ SaaS-Integrationen
In der folgenden Tabelle sehen Sie, wo jeder Teil der Kette die Verantwortung für die Verhinderung von anbieterübergreifenden Lateral-Movement-Angriffen übernimmt:
Der Weg nach vorn durch gemeinsame Verantwortung
Bis eine gemeinsame Einigung über ein neues Sicherheitsmodell erzielt wird, sollten CISOs und IAM-Verantwortliche von ihren Anbietern für jede Integration oder jedes Token/Schlüssel/Zertifikat/jede Identität, die für Dritte oder Vierte erstellt wird, Transparenz über den Token-Lebenszyklus, das Nutzungsvolumen, eine grundlegende Überwachung auf Anomalien bei der Nutzung und mehr verlangen. Zumindest sollten sie mit den Anbietern zusammenarbeiten, um die Verfügbarkeit eines „Kill Switch“ oder einer Aktualisierungstaste zu bestätigen.
Und was die Anbieter selbst betrifft, sollten wir sicherstellen, dass wir unseren Integrationspartnern und Endkunden diese Transparenz ermöglichen, und zwar als Teil der Paywall, als Teil der Basispakete.
Referenzen
Google Threat Analysis Group: UNC6395-Updates –
https://cloud.google.com/blog/topics/threat-intelligence/unc6395-drift-attack
Salesforce-Hinweis zur Entfernung der Drift-App
https://help.salesforce.com/s/articleView?id=005134951&language=en_US&type=1
Analyse von Palo Alto Networks Unit 42
https://unit42.paloaltonetworks.com/threat-brief-compromised-salesforce-instances/
Cloudflare-Offenlegung zu kompromittierten Token
https://blog.cloudflare.com/response-to-salesloft-drift-incident/
Mandiant-Untersuchung des Salesloft-GitHub-Kompromisses –
https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift