Stell dir vor, du hast ein Haus mit einem sehr gut gesicherten Haupteingang. Dafür gibt es Kameras, einen Pförtner und mehrere Schlösser. Die meisten von uns haben in den letzten Jahren viel Energie in diesen Haupteingang gesteckt: Hauptgeschäftssysteme wie Salesforce werden mit Multi-Faktor-Authentifizierung, Conditional Access und strengen Sitzungsregeln geschützt. Aber was ist mit den vielen anderen Türen und Fenstern, die du selbst für vertrauenswürdige Helfer geöffnet hast? Der Briefträger hat einen Schlüssel, der Gärtner hat einen Code, und der Putzdienst kommt durch den Hauseingang, aber dann direkt in alle Räume. Genau diesen blinden Fleck haben Angreifer der Gruppe ShinyHunters ein Jahr lang systematisch ausgenutzt, ohne jemals eine Tür aufzubrechen. Der Microsoft-Bericht vom Juli 2026 zeigt eindrücklich, wie die Angreifer in Salesforce-Umgebungen eindrangen, indem sie das Vertrauen missbrauchten, das Unternehmen bereits in ihre eigenen Integrationen und Apps gesetzt hatten. Und das Schlimmste: Herkömmliche Überwachung hat dieses Verhalten kaum registriert.
Der Microsoft-Bericht dokumentiert drei fundamentale Angriffspfade, die alle auf demselben Prinzip beruhen: OAuth-Verbindungen, die Salesforce mit externen Tools und Drittanbieter-Diensten verknüpfen. Statt eine technische Sicherheitslücke in Salesforce selbst zu suchen, haben die Angreifer die menschliche und organisatorische Komponente ins Visier genommen. Die Forscher bei Microsoft haben diese Kampagnen von Mitte 2025 bis Mitte 2026 verfolgt und dabei ein klares Muster erkannt: Der Zugang erfolgte stets über bereits bestehende Vertrauensbeziehungen. Das ist auch der Grund, warum herkömmliche Authentifizierungsprotokolle keine Warnungen auslösten. Wenn sich ein echter Benutzer anmeldet, der zuvor eine bösartige App autorisiert hat, oder wenn eine Integration ausgeführt wird, die das Unternehmen bereits als vertrauenswürdig eingestuft hat, sehen die Logs aus wie alltäglicher Traffic. Die eigentliche Frage ist, was eine solche App oder ein Konto tut, sobald es sich im Salesforce-System befindet. Genau diese Überwachung hat in den meisten Implementierungen bisher einfach gefehlt. Microsoft hat daher gemeinsam mit Salesforce neue Erkennungs- und Governance-Tools entwickelt, um genau diese Lücke zu schließen.
Der Telefonanruf – Wo die Kette begann
Der erste und öffentlichkeitswirksamste Pfad begann nicht mit einem physischen Einbruch, sondern mit einem ganz einfachen Telefonanruf. Mitte 2025 riefen die Angreifer Mitarbeiter an, gaben sich als IT-Support aus und führten sie durch den OAuth-Zustimmungsbildschirm von Salesforce. Die Mitarbeiter autorisierten dabei eine angebliche Version des legitimen Salesforce-Tools „Data Loader“, die in Wahrheit aber von den Angreifern kontrolliert wurde. Sobald der Benutzer zugestimmt hatte, konnte die bösartige App über die Salesforce-API auf die Daten des Benutzers zugreifen. Keine Schadsoftware, kein Phishing-Link – nur ein Telefonat und ein Klick. Diese Vorgehensweise, auch Vishing genannt, wurde aufgedeckt, als Google selbst im Juni 2025 betroffen war. Die Angreifer erbeuteten überwiegend öffentliche Geschäftskontaktdaten, bevor Google den Zugriff unterband. Mandiant und andere Forscher dokumentierten die Kampagne als UNC6040 (Erstzugriff) und UNC6240 (Erpressung). Die Namen der betroffenen Unternehmen lesen sich wie ein Who’s who der globalen Wirtschaft: Chanel, Pandora, Adidas, Qantas, Allianz Life und mehrere Marken des LVMH-Konzerns. Der wichtigste Ratschlag von Mandiant an Verteidiger war einfach, aber schwer umsetzbar: Diese Anrufe nutzen den natürlichen Hilfsinstinkt von Support-Mitarbeitern aus. Man soll auflegen und selbst über eine bekannte, vertrauenswürdige Nummer zurückrufen.
Der Angriffspunkt ist hier nicht die Technik, sondern die menschliche Psychologie. Die Angreifer wussten, dass viele Sicherheitsprozesse auf die Identität des Menschen abzielen, aber die OAuth-Zustimmung schützt nicht vor einem Menschen, der selbstsicher die richtigen Fragen stellt. Genau hier liegt das Problem: Ein IT-Mitarbeiter, der gebeten wird, eine App zu installieren, folgt oft einer Routine und prüft nicht, ob der Anrufer tatsächlich von der internen IT ist. Die Unternehmenspolitik ist vielleicht vorhanden, aber die Umsetzung scheitert an der Hektik des Alltags. Microsoft betont in seinem Bericht, dass die Unternehmen genau diese Schwachstelle erkennen müssen: OAuth ist mächtig, aber die Zustimmungsprozesse sind oft nicht an die Bedrohungslage angepasst. Deshalb müssen nicht nur technische, sondern auch prozessuale Sicherheitsmaßnahmen wie verpflichtende Second-Level-Autorisierungen für jede App-Installation etabliert werden.
Gestohlene Tokens von vertrauenswürdigen Drittanbietern
Der zweite Pfad verzichtet vollständig auf den direkten Kontakt mit dem Mitarbeiter. Statt einen Benutzer zu überzeugen, haben die Angreifer Drittanbieter kompromittiert, die bereits OAuth-Zugriff auf die Salesforce-Umgebungen ihrer Kunden besaßen. Sie stahlen die Verbindungsgeheimnisse oder Tokens dieser Integrationen und nutzten sie, um parallel in vielen verschiedenen Unternehmen Daten abzurufen. Da der Datenverkehr von einer bereits genehmigten Integration kommt, wird er von den normalen Überwachungssystemen nicht als Angriff erkannt. Microsoft beschreibt drei konkrete Vorfälle, die diese Methode belegen. Der bekannteste ist die Kompromittierung von Salesloft Drift im August 2025. Die Angreifer erbeuteten OAuth- und Refresh-Tokens der Drift AI Chat-Integration und nutzten sie, um auf die Salesforce-Umgebungen von über 700 Organisationen zuzugreifen. Darunter waren bekannte Namen wie Cloudflare, Zscaler, Palo Alto Networks, Proofpoint und PagerDuty. Die Angreifer blieben unerkannt, weil der gesamte Traffic wie legitime geschäftliche Nutzung aussah. Salesforce selbst stellte später fest, dass die Angreifer offenbar schon ab März 2025 Zugriff auf das GitHub-Konto von Salesloft hatten und von dort aus in die AWS-Umgebung von Drift gelangten.
Diese Angriffskette zeigt, wie gefährlich Software-Lieferketten für Unternehmen sein können. Ein kleines, kaum beachtetes Feature eines Drittanbieters kann zur Eintrittspforte für das gesamte Kundenökosystem werden. Der zweite Vorfall ereignete sich im November 2025 bei Gainsight. Auch hier nutzten die Angreifer gestohlene OAuth-Token, um auf Salesforce-Instanzen zuzugreifen. Salesforce zog daraufhin veröffentlichte Gainsight-Apps zurück, nachdem ungewöhnliche API-Aktivitäten aufgefallen waren. Google schätzte, dass über 200 Salesforce-Instanzen betroffen waren. Die Gruppe, die sich selbst als ShinyHunters ausgibt, behauptete damals, die Attacken auf Salesloft und Gainsight hätten gemeinsam fast 1.000 Organisationen erreicht – eine Zahl, die unabhängig nicht bestätigt werden kann. Der dritte Vorfall im Juni 2026 traf Klue, eine Competitive-Intelligence-Plattform. Hier war der Einstiegspunkt ein veraltetes Legacy-Credential, das aus einer Testintegration stammte, die nie ausgerollt worden war. Die Angreifer nutzten es aus, um einen Code-Update zu pushen, der die OAuth-Token der Kunden erntete. Damit griffen sie auf Salesforce- und Gong-Daten von Klue-Kunden zu, darunter Huntress und Recorded Future.
Die Benennung der Angreifer ist in diesem Bereich notorisch ungenau. Microsoft verfolgt den Klue-Akteur als Storm-3138, während andere Forscher die Gruppe Icarus nennen. Ein Telegram-Kanal, der vorgab, ShinyHunters zu sein, reklamierte die Tat ebenfalls für sich. Diese Überschneidungen sind kein Zufall: Die Identitäten werden opportunistisch beansprucht, um den Druck auf die Opfer zu erhöhen. Das macht die Bedrohungsanalyse komplizierter, aber das grundlegende Problem bleibt dasselbe: Unternehmen vertrauen blind darauf, dass ihre Drittanbieter sicher sind, aber die Sicherheitspraxis der Anbieter ist oft nicht auf dem gleichen Niveau. Microsoft weist daher darauf hin, dass nicht nur die eigenen Systeme, sondern auch die Integrationspartner einer regelmäßigen Überprüfung bedürfen. Die Tokens müssen regelmäßig rotiert werden, und der Zugriff sollte auf das absolut Notwendige beschränkt sein.
Gastzugang, der niemals geschlossen wurde
Der dritte und vielleicht überraschendste Pfand benötigt überhaupt keine Anmeldeinformationen. Microsoft beobachtete einen Anstieg verdächtiger Gast-Benutzeraktivitäten gegen Salesforce-Aura-Endpunkte, dem Framework hinter Experience Cloud-Seiten. Wenn die Berechtigungen für den Gastzugang falsch konfiguriert waren, konnten die Angreifer auf Aura-Funktionen zugreifen, ohne sich zu authentifizieren. Sie verwendeten speziell die GraphQL-Aura-Steuerung, um mit cursor-basierter Paginierung Datensätze über die standardmäßige Grenze von 2.000 Datensätzen hinaus abzurufen. So entwendeten sie weit mehr Daten, als die Gastrolle eigentlich hätte preisgeben dürfen. Microsofts Erkennungslogik zielt dabei auf das Tool AuraInspector ab, das für solche Sondierungen verwendet wird. Wieder einmal: kein technischer Exploit. Die Organisation hatte die Gastrolle so konfiguriert, dass sie mehr sehen konnte als nötig, und die Angreifer nutzten diese Fehlkonfiguration einfach aus.
Dieser Pfad zeigt, wie selbst grundlegende Sicherheitseinstellungen wie Gastzugänge vernachlässigt werden können. Oft werden Experience Cloud-Seiten für temporäre Zwecke eingerichtet und dann nicht mehr angepasst. Die Gastrolle erhält standardmäßig Lesezugriff auf viele Objekte, und wenn niemand die Berechtigungen im Detail prüft, bleibt die Tür offen. Microsoft empfiehlt hier eine konsequente Überprüfung der Gastzugänge und den Einsatz von Least-Privilege-Prinzipien. Zudem sollten Unternehmen den Zugang zu Aura-Endpunkten auf ein Minimum beschränken und sensible Daten hinter zusätzlichen Authentifizierungsschichten schützen. Der Bericht ist hier besonders deutlich: Es gibt keinen Angriff, wenn die Konfiguration von Anfang an sicher ist.
Was Microsoft und Salesforce gemeinsam dagegen tun
Die Herausforderung besteht darin, die Signale zu finden, die ein Angriff hinterlässt, ohne den normalen Geschäftsbetrieb zu stören. Das Signal liegt in dem, was nach dem Zugriff passiert: Welche verbundene App hat einen API-Aufruf getätigt? Welche OAuth-Bereiche besitzt sie? Wie viele Daten hat sie abgefragt, und ist das im Kontext des Mandanten normal? Microsoft und Salesforce haben daraufhin gemeinsam eine Reihe von Verbesserungen in Microsoft Defender for Cloud Apps implementiert. Für Kunden, die Salesforce Shield Event Monitoring nutzen, wird der aktualisierte Salesforce-Connector das Real-Time Event Monitoring-Framework für nahezu Echtzeit-Erkennung integrieren. Zusätzlich wird jetzt die verbundene App direkt einer Aktivität zugeordnet: Man sieht, welche App einen Aufruf getätigt hat, welche OAuth-Bereiche ihr gewährt wurden und um welche Sitzung oder API-Kontext es sich handelt. Das ist ein massiver Fortschritt gegenüber den bisherigen Logs, die nur die Aktion, aber nicht die Quelle zeigten.
Neben der Erkennung hat Microsoft die Posture- und Governance-Funktionen für verbundene OAuth-Apps erweitert. Das umfasst eine Ansicht überprivilegierter Apps mit erhöhten Berechtigungen, die Möglichkeit, ungenutzte Apps zu identifizieren, die seit 90 Tagen oder länger inaktiv sind, aber weiterhin aktive Berechtigungen haben, und eine Risikobewertung von 0 bis 100 für jede App. Diese Risikobewertung kann direkt in Warnungen und Richtlinien eingebunden werden. Ziel ist es, die überprivilegierten und vergessenen Integrationen zu finden, bevor ein Angreifer sie findet. Das ist der Schlüssel, denn in den meisten Unternehmen gibt es Dutzende, manchmal Hunderte von OAuth-Integrationen, und niemand hat einen vollständigen Überblick. Microsofts Ansatz macht diese Transparenz erzwingbar und reduziert die Angriffsfläche.
Die Angriffsfläche verkleinern: Was Unternehmen jetzt tun können
Microsofts Handlungsempfehlungen sind pragmatisch und decken sich mit den Lektionen, die jede der betroffenen Unternehmen nach den Vorfällen gelernt hat. Erstens: Verbinde die Salesforce-Instanzen mit Defender for Cloud Apps, um die erweiterte Telemetrie zu erhalten. Zweitens: Aktiviere und überwache tatsächlich die Salesforce-Ereignisprotokolle – viele Kunden schalten sie ein, schauen aber nie hinein. Drittens: Schränke den Gastzugang zu Experience Cloud-Seiten auf das absolute Minimum ein. Darüber hinaus gelten die immer gleichen, aber dennoch wichtigen Schritte: Führe ein vollständiges Inventar aller verbundenen Apps, entferne diejenigen, die niemand mehr nutzt, schränke die verbleibenden auf die geringstmöglichen Berechtigungen ein, und sei bereit, Tokens sofort zu widerrufen und zu rotieren, sobald eine Integration ein ungewöhnliches Verhalten zeigt.
Diese Liste mag trivial erscheinen, aber nur, weil sie so häufig wiederholt wird. Die Realität ist eine andere: In den meisten Unternehmen gibt es keine automatisierte Erkennung für OAuth-Missbrauch. Die Identitätskontrollen der letzten zehn Jahre waren auf menschliche Anmeldungen ausgelegt: MFA, Conditional Access, Sitzungsrichtlinien. Die OAuth-Apps, Integrationskonten und Service-Anmeldeinformationen, die die eigentliche Arbeit in einer modernen Salesforce-Umgebung erledigen, stehen meist außerhalb dieses Schutzes. Sie sind unbeaufsichtigt, überprivilegiert und vergessen. Die Angreifer von ShinyHunters haben genau diese Lücke erkannt und über ein Jahr systematisch genutzt. Mehr als einmal war der Zugang nicht mehr als eine Berechtigung, die jemand abzuschalten vergessen hatte. Es ist nicht die spektakuläre Sicherheitslücke, die Schlagzeilen macht, sondern die alltägliche Nachlässigkeit, die uns verwundbar macht. Der Microsoft-Bericht ist ein Weckruf, der zeigt, dass Sicherheit nicht aufhört, wenn der Benutzer authentifiziert ist. Sie muss das gesamte Ökosystem aus Vertrauen umfassen, das wir um unsere Systeme herum aufbauen. Und genau dieses Vertrauen müssen wir kontrollieren, sonst tut es jemand anderes für uns.
Quelle: thehackernews.com
