Letzten Monat nutzten Angreifer gestohlene Zugangsdaten, um den SaaS-Anbieter Klue für Wettbewerbsanalysen zu hacken. Die Anfänge dieses Angriffs reichen jedoch offenbar vier Jahre zurück.
Klue-Führungskräfte sagte dass das in Vancouver ansässige Unternehmen im Jahr 2022 einem nicht genannten Dritten eine Akkreditierung für ein begrenztes Pilotprojekt ausgestellt hat. Untersuchung Crowdstrike enthüllte später, dass es sich bei den Zugangsdaten um ein GitHub Personal Access Token (PAT) handelt, das Entwicklern den Zugriff auf Softwareentwicklungs-Repositories ermöglicht.
Nach dem Ende des Pilotprojekts blieb der Token aktiv, da ihn niemand widerrufen hatte. Er lag irgendwo verborgen, unsichtbar für die Kunden, die Klue Zugang zu ihren intimsten Geheimnissen gewährt hatten. Er war eine tickende Zeitbombe.
Die Untersuchung konnte nicht klären, wie Icarus (eine neue Gruppe, die erst seit April 2026 aktiv ist) an das PAT gelangte, aber am 11. Juni nutzte sie das Token, um neuen Code in die Integrationsdienstschicht von Klue einzuspielen.
Auf dieser Ebene bezieht Klue Daten aus den Systemen seiner Kunden, die auf Diensten wie Salesforce und Gong gehostet werden. Mithilfe dieser Daten führt Klue Wettbewerbsanalysen für seine Kunden durch und ermöglicht deren Vertriebsmitarbeitern so eine bessere Vorbereitung auf Verhandlungen.
Durch das Code-Update wurden die OAuth-Tokens (persistente Sitzungstokens für wiederholten passwortlosen Zugriff) ausgelesen, die Klue für den Zugriff auf Kundendaten in diesen Systemen verwendete. Die Angreifer nutzten diese Tokens anschließend, um Daten aus den Salesforce- und Gong-Instanzen dieser Kunden zu stehlen.
OAuth-Tokens als Legitimitätswäsche
Der Angriff war schwer zu erkennen, da die Verwendung gestohlener OAuth-Token erst dann als unbefugter Zugriff erkennbar wird, wenn diese Token widerrufen werden. Icarus führte direkte REST-Aufrufe an Salesforce- und Gong-Instanzen durch, genau wie jeder legitime Kunde.
Es war Salesforce, das Klue über den Vorfall am 12. Juni informierte, woraufhin das Unternehmen für Wettbewerbsanalysen seine OAuth-Tokens rotierte.
Die Liste der bestätigten Opfer umfasste HackerOne, Huntress, Jamf, Recorded Future, Snyk und LastPass. Sie liest sich wie ein Verzeichnis von Unternehmen, deren Kerngeschäft darin besteht, anderen Unternehmen zu erklären, wie sie genau dieses Risiko managen sollen.
Die Auswirkungen auf die Betroffenen sind im Internet allgegenwärtig, da sie regelmäßig Berichte darüber veröffentlichen mussten, wie sich das Problem mit Klue auf sie auswirkte. Salesforce bestätigte, dass der Vorfall „auf die App-Verbindung von Klue beschränkt war und nicht auf einer Sicherheitslücke in der Salesforce-Plattform beruht“ – und legte die Verantwortung für die Überwachung damit eindeutig dem Kunden zu, der die Integration autorisiert hatte. sagte „Organisationen können sich bis auf Weiteres nicht über diese App mit Salesforce verbinden.“ Gong sagte das gleicheUnd Tanium auch Klue blockiert.
Lastpass offengelegt Es wurde festgestellt, dass Kundennamen, E-Mail-Adressen, Telefonnummern, Anschriften sowie Supportfalldetails und Vertriebsdaten offengelegt worden waren. Das Unternehmen hat daraufhin allen Mitarbeitern den Zugriff auf Klue gesperrt.
Jägerin detaillierte AktualisierungenDarin wurde erklärt, dass Icarus einen Datensatz auf seiner Darknet-Seite veröffentlicht und mit der Veröffentlichung weiterer Daten gedroht habe, wobei über 200 betroffene Unternehmen genannt wurden. Die Webseite, auf der die Daten veröffentlicht wurden, wurde als in Russland gehostet identifiziert.
Keines der nachgelagerten Opfer hatte eine realistische Möglichkeit, die Vorgänge in der Infrastruktur von Klue einzusehen; ihre Lieferantenrisikomanagementprogramme hatten die Integration vermutlich genehmigt und die Angelegenheit damit abgeschlossen. Für viele Sicherheitsteams scheinen Audits von SaaS-Unternehmen eine einmalige Angelegenheit zu sein. Sobald der Anbieter den Fragebogen ausgefüllt und die Genehmigung erhalten hat, gilt die Prüfung als beendet.
Warum dies ISO 27001 wertvoller macht
Die Lieferanten- und Zugriffsmanagementkontrollen der ISO 27001 sind darauf ausgelegt, vor den von Icarus ausgenutzten Fehlern zu schützen.
Mit Control A.5.16 müssen Organisationen den gesamten Lebenszyklus jeder Identität von der Bereitstellung bis zur Deaktivierung verwalten, während A.5.18 die gleiche Disziplin auf Authentifizierungsdaten ausdehnt und dokumentierte Rotationspläne für API-Schlüssel und Token vorschreibt.
Konsequent angewendet, hätte jede dieser Methoden einen vier Jahre alten PAT lange vor Ikarus aufgedeckt. Klues aktuelle Probleme sind ein Paradebeispiel dafür, welche Folgen die Nichtbeachtung dieser Prinzipien später haben kann.
Das hätte Klue aber intern regeln können, nicht aufgrund der Kontrolle der Kunden. Was kann ein Unternehmen tun, um sich vor Fehlern eines Lieferanten zu schützen?
Die Kontrollpunkte A.5.19 bis A.5.23 regeln die Lieferantenbeziehung selbst. A.5.22 verpflichtet Organisationen, die Leistungen ihrer Lieferanten regelmäßig zu überwachen, zu überprüfen und zu auditieren.
A.5.21 geht noch einen Schritt weiter und verlangt, dass die Sicherheitsanforderungen auch an Unterauftragnehmer weitergegeben werden und dass die Nutzung von Unterauftragnehmern in den Lieferantenverträgen festgehalten wird.
Ein Informationssicherheitsmanagementsystem setzt diese Klauseln in die Praxis um und wandelt einen jährlichen Fragebogen in ein dynamisches Register von Integrationen, Zugangsdaten und Token-Vergabe um. Es erzwingt die Deaktivierung von Zugriffen nach Abschluss eines Pilotprojekts. Zudem bietet es Compliance-Managern einen Prüfpfad, der belegt, dass sowohl die beauftragten Dienstleister als auch deren Unterauftragnehmer die gleiche kontinuierliche Überwachung erfahren wie die direkt beauftragten Dienstleister.
Klue hat lobenswerterweise mehrere Maßnahmen ergriffen, um ein erneutes Auftreten dieses Problems zu verhindern. Dazu gehören das Verbot von PATs und die Umstellung auf andere Authentifizierungsmechanismen. Das Unternehmen hat seine Audit-Protokollierung verbessert und die Kontrolle über seine Softwareentwicklungsprozesse verschärft. Besser spät als nie.
Ein ISMS ist das Mittel, mit dem Compliance-Manager sicherstellen, dass sie nicht selbst zur nächsten Schlagzeile werden – weder als direktes Ziel eines Datenlecks noch als Kunde eines kompromittierten Opfers.
Erweitern Sie Ihr Wissen
Blog: Wie Ransomware zu einem Problem für die Geschäftskontinuität wurde
Blog: Die Lücke im Blick behalten: Der Salesforce-Vorfall und die sich wandelnde Natur des Cloud-Risikos
