OAuth-Token-Diebstahl bei Klue: Was deutsche Unternehmen jetzt wissen müssen

Neue Erpressergruppe „Icarus" stiehlt Zugangsdaten zu Salesforce-Umgebungen – NIS2-Pflichten und konkrete Schutzmaßnahmen im Überblick

Einleitung: Ein Angriff mit globaler Reichweite

Die Marktintelligenz-Plattform Klue hat öffentlich bestätigt, dass Angreifer in einem kürzlichen Sicherheitsvorfall OAuth-Token gestohlen haben – Zugangsdaten, die Klues System mit den Salesforce-Umgebungen seiner Kunden verbinden. Verantwortlich zeigt sich die bislang wenig bekannte Erpressergruppe „Icarus", die den Angriff öffentlich reklamiert und damit offenbar einen wachsenden Kreis betroffener Unternehmen unter Druck setzen will.

Für deutsche IT-Verantwortliche und Geschäftsführer mag dieser Vorfall auf den ersten Blick wie eine weitere Meldung aus dem internationalen Cyberraum wirken. Doch der Fall ist aus mehreren Gründen höchst relevant: Erstens nutzen zahlreiche deutsche Unternehmen sowohl Salesforce als auch Drittanbieter-Integrationen, die über OAuth arbeiten. Zweitens zeigt der Vorfall exemplarisch, wie Angreifer nicht mehr direkte Opfer attackieren, sondern die Lieferkette als Einfallstor nutzen – ein Szenario, das NIS2 ausdrücklich adressiert. Und drittens wächst die Liste betroffener Unternehmen noch, was bedeutet: Die Schadensbewertung ist noch nicht abgeschlossen.

Technischer Hintergrund: Was sind OAuth-Token – und warum sind sie so gefährlich?

OAuth einfach erklärt

OAuth ist ein weit verbreitetes Authentifizierungsprotokoll, das es Anwendungen ermöglicht, im Namen eines Nutzers auf Ressourcen zuzugreifen, ohne dessen Passwort zu kennen. Wenn Sie sich etwa mit „Weiter mit Google" oder „Mit Salesforce verbinden" bei einem Drittanbieter anmelden, stellt OAuth im Hintergrund ein sogenanntes Access Token aus – eine Art temporären digitalen Schlüssel.

Das klingt sicherer als die direkte Passwortweitergabe – und ist es unter normalen Umständen auch. Das Problem: Wird ein solches Token gestohlen, hat der Angreifer dieselben Zugriffsrechte wie die legitime Anwendung – und das oft ohne jede weitere Authentifizierung, ohne MFA-Abfrage, ohne Login-Alarm.

Was bei Klue passiert ist

Im vorliegenden Fall gelang es der Gruppe „Icarus", OAuth-Token abzugreifen, die Klues Plattform dazu berechtigen, auf die Salesforce-Instanzen von Kunden zuzugreifen. Das bedeutet im Klartext:

• Die Angreifer mussten nicht in die Salesforce-Umgebung der Opfer einbrechen
• Sie mussten keine Passwörter knacken
• Sie nutzten stattdessen das Vertrauensverhältnis zwischen Klue und Salesforce aus

Dieses Muster – ein Drittanbieter wird kompromittiert, um über ihn auf Kundensysteme zuzugreifen – wird in der Fachsprache als Supply-Chain-Angriff bezeichnet. Die Gruppe Icarus ist nach aktuellem Stand eine neu aufgetretene Erpresserorganisation, die nach dem Prinzip „Doppelter Erpressung" vorgeht: Daten werden gestohlen und mit Veröffentlichung gedroht, um Lösegeld zu erpressen.

NIS2-Relevanz: Was bedeutet das für deutsche Unternehmen?

Betroffene Sektoren und Pflichten

Die NIS2-Richtlinie, die in Deutschland durch das IT-Sicherheitsgesetz 3.0 (BSIG-Novelle) umgesetzt wird, stellt erhöhte Anforderungen an Unternehmen in kritischen und wichtigen Sektoren – darunter Industrie, Gesundheit, digitale Infrastruktur, Finanzwesen und viele mehr. Wer zu den erfassten Unternehmen zählt, muss unter anderem:

Der Klue-Fall als Muster für Ihre Risikoanalyse

Der Vorfall bei Klue ist ein Paradebeispiel für das, was NIS2 in Artikel 21, Absatz 2d explizit adressiert: die Sicherheit der Lieferkette. Wenn ein SaaS-Anbieter, den Ihr Unternehmen nutzt, kompromittiert wird und dadurch Zugang zu Ihren Kernsystemen entsteht, sind Sie als betreibendes Unternehmen in der Pflicht – sowohl gegenüber dem BSI als auch gegenüber Ihren eigenen Kunden (ggf. auch nach DSGVO, Art. 33).

Das BSI empfiehlt in seinem IT-Grundschutz-Kompendium explizit, Drittanbieter-Integrationen regelmäßig zu auditieren und den Umfang gewährter Zugriffsrechte zu minimieren (Prinzip der minimalen Rechtevergabe / Least Privilege).

Meldepflicht beachten

Sollten Sie feststellen, dass Ihre Salesforce-Umgebung über einen Drittanbieter wie Klue kompromittiert wurde, greifen unter Umständen zwei parallele Meldepflichten:

1. BSI (nach BSIG / NIS2): Wenn Ihr Unternehmen unter NIS2 fällt und der Vorfall erhebliche Auswirkungen auf Ihre Dienste hat
2. Datenschutzbehörde (nach DSGVO Art. 33): Wenn personenbezogene Daten betroffen sind – Meldung binnen 72 Stunden an die zuständige Landesbehörde

Praktische Schutzmaßnahmen: Was Sie jetzt tun sollten

1. OAuth-Token-Inventur sofort durchführen

Erstellen Sie eine vollständige Liste aller OAuth-Verbindungen Ihrer Systeme – insbesondere für kritische Plattformen wie Salesforce, Microsoft 365, HubSpot oder SAP-Integrationen. Fragen Sie sich bei jeder Verbindung: Welche Rechte hat diese App? Ist sie noch aktiv genutzt? Wann wurde der Token zuletzt rotiert?

Tool-Tipp: Salesforce bietet unter Setup → Verbundene Apps → OAuth-Nutzung eine native Übersicht aller aktiven Token.

2. Least Privilege konsequent umsetzen

OAuth-Tokens sollten nur die minimal notwendigen Berechtigungen enthalten. Eine Marktintelligenz-Plattform, die lediglich Kontaktdaten liest, benötigt keinen Schreibzugriff auf Ihre gesamte CRM-Datenbank. Überprüfen Sie OAuth-Scopes und reduzieren Sie diese auf das tatsächlich Notwendige.

3. Token-Rotation und automatischen Ablauf erzwingen

Viele Systeme erlauben es, OAuth-Tokens mit einem Ablaufdatum (Expiry) zu versehen oder regelmäßige Rotation zu erzwingen. Langlebige, nie ablaufende Tokens sind ein erhebliches Risiko. Konfigurieren Sie kurze Gültigkeitsdauern und automatische Erneuerungsprozesse mit erneutem Consent.

4. Drittanbieter-Risikomanagement formalisieren

Führen Sie für alle SaaS-Integrationen ein Vendor Risk Assessment durch – mindestens jährlich, besonders aber vor der Einführung neuer Tools. Stellen Sie Ihren Anbietern gezielte Fragen:

• Wie werden OAuth-Tokens bei Ihnen gespeichert und geschützt?
• Haben Sie SOC 2 Typ II oder ISO 27001-Zertifizierung?
• Wie würden Sie uns im Falle eines Sicherheitsvorfalls informieren?

NIS2 verlangt genau diese Art von vertraglicher und prozessualer Absicherung gegenüber Drittanbietern.

5. Monitoring und Anomalieerkennung aktivieren

Salesforce sowie die meisten Enterprise-CRM-Systeme bieten Event-Monitoring-Funktionen. Konfigurieren Sie Alerts für ungewöhnliche API-Zugriffe – etwa unbekannte IP-Adressen, ungewöhnliche Zugriffszeiten oder massenhafte Datenabfragen über OAuth-APIs. Im Falle von Klue hätte ein solches Monitoring betroffene Kunden potenziell frühzeitig warnen können.

6. Incident-Response-Plan aktualisieren

Stellen Sie sicher, dass Ihr Incident-Response-Plan explizit den Fall eines kompromittierten Drittanbieters abdeckt. Wer wird intern informiert? Wann und wie wird das BSI kontaktiert? Wer übernimmt die forensische Analyse? Diese Prozesse sollten vorab definiert und regelmäßig geübt werden – NIS2 fordert in Artikel 21 explizit Maßnahmen zur Bewältigung von Sicherheitsvorfällen.

Fazit: Vertrauen ist gut, Kontrolle ist besser – besonders bei OAuth

Der Angriff auf Klue durch die Icarus-Gruppe illustriert ein fundamentales Problem moderner SaaS-Ökosysteme: Je stärker Unternehmen auf Integrationen und Drittanbieter setzen, desto größer wird die potenzielle Angriffsfläche. OAuth ist dabei kein Risiko an sich – aber ein schlecht verwaltetes OAuth-Ökosystem ist eine offene Flanke.

Für deutsche Unternehmen kommt hinzu: NIS2 macht die Lieferkettensicherheit zur Pflichtdisziplin, keine Kür. Wer seine Drittanbieter nicht kennt, ihre Zugriffsrechte nicht kontrolliert und im Ernstfall keine klare Meldestrecke hat, riskiert nicht nur Datenverlust, sondern auch empfindliche Bußgelder und Reputationsschäden.

Call-to-Action: NIS2-Compliance strukturiert angehen

Die manuelle Verwaltung von Drittanbieterrisiken, Meldepflichten und Sicherheitsnachweisen ist komplex und fehleranfällig. Spezialisierte NIS2-Compliance-Software kann dabei helfen, Lieferkettenrisiken systematisch zu erfassen, Meldeprozesse zu automatisieren und die geforderte Dokumentation revisionssicher vorzuhalten. Wenn Sie noch kein strukturiertes Tool für Ihr NIS2-Management einsetzen, ist jetzt ein guter Zeitpunkt, entsprechende Lösungen zu evaluieren – bevor der nächste Vorfall Ihrem Unternehmen die Entscheidung abnimmt.