ShinyHunters machte die OAuth-Zustimmung zum Generalschlüssel: Die Salesforce-Angriffswelle 2026

Im Juli 2026 beschrieb Microsoft detailliert, wie die Erpresserbande ShinyHunters ein Jahr lang unbemerkt Salesforce-Tenants in Einzelhandel, Gesundheitswesen, Luftfahrt und Technologie leerräumte – und das, ohne ein einziges Passwort zu knacken. Die ShinyHunters Salesforce OAuth-Kampagne missbrauchte genau das, was die Multi-Faktor-Authentifizierung nie verhindern sollte: einen Nutzer, der freiwillig auf „Zulassen“ klickt. Wo ältere Angriffe Zugangsdaten stahlen, stahl dieser das Vertrauen – er brachte Mitarbeiter dazu, eine bösartige Connected App zu autorisieren, die anschließend zeitlich unbegrenzt über ein gültiges API-Token verfügte.

Diese Unterscheidung ist für jeden relevant, der einen SaaS-Stack betreibt. Die Angreifer berührten den Anmeldebildschirm kaum, sodass MFA-Abfragen, Impossible-Travel-Regeln und Anmeldewarnungen weitgehend stumm blieben. Wenn Ihr Sicherheitsmodell davon ausgeht „Wir haben MFA, also sind wir abgesichert“, dann ist diese Kampagne die Fallstudie, die das Gegenteil beweist.

Was tatsächlich geschah

Zwischen Mitte 2025 und Mitte 2026 führte ShinyHunters (von Googles Mandiant für die Vishing-Aktivität als UNC6040 und für den Token-Diebstahl als UNC6395 geführt) eine Operation in industriellem Maßstab gegen Salesforce-Kunden. Die Zusammenfassung von The Hacker News zu Microsofts Threat Intelligence beziffert die Angaben der Affiliates auf knapp 1,000 betroffene Organisationen, wobei viele davon unbestätigt bleiben. Die Beute waren CRM-Daten – Kundendatensätze, Support-Tickets, Kontaktlisten –, die die Gruppe anschließend zur Erpressung nutzte und mit deren Veröffentlichung sie drohte, sofern die Opfer nicht zahlten.

Der raffinierte Teil war die Persistenz. Ein gestohlenes OAuth-Token verfällt nicht, wenn ein Passwort zurückgesetzt wird oder wenn der gephishte Mitarbeiter sein MFA-Gerät wechselt. Wie Microsoft anmerkte, war der Großteil der Salesforce-Protokollierung „nicht dafür gebaut zu zeigen“, was nach der Autorisierung geschieht, sodass sich die bösartigen API-Aufrufe wochenlang in den normalen Automatisierungsverkehr einfügten.

Die drei Einfallstore

Microsoft und das Threat-Intelligence-Team von Google Cloud beschreiben drei unterschiedliche Einstiegswege, die alle am selben Punkt enden: einer vom Angreifer kontrollierten OAuth-Berechtigung.

Angriffsweg	Funktionsweise	Entscheidendes Detail
Voice-Phishing (Vishing)	Anrufer gaben sich als IT-Support aus und führten Mitarbeiter durch den OAuth-Zustimmungsbildschirm von Salesforce	Opfer autorisierten eine bösartige App, die sich als Salesforces Data Loader ausgab, teils umbenannt in „My Ticket Portal“
Supply-Chain-Token-Diebstahl	Angreifer kompromittierten vertrauenswürdige Integrationen und verwendeten deren OAuth-Tokens gegen nachgelagerte Tenants wieder	Salesloft/Drift (Aug 2025), Gainsight (Nov 2025) und Klue (Juni 2026); Berichten zufolge lag die nachgelagerte Betroffenheit bei 700+ bzw. 200+ Organisationen
Fehlkonfigurierter Gastzugriff	Zu weit gefasste Gastrollen in der Experience Cloud erlaubten nicht authentifizierten Nutzern das Lesen von Daten	Die Akteure nutzten GraphQL-Paginierung, um das Abfragelimit von 2,000 Datensätzen zu umgehen

Der Vishing-Weg ist die Schlagzeile, weil er überhaupt keine Software-Schwachstelle benötigt – nur einen überzeugenden Telefonanruf und einen abgelenkten Administrator. Der Supply-Chain-Weg ist wohl noch schlimmer: Eine einzige Kompromittierung bei einem Anbieter wie Salesloft übergab den Angreifern einen ganzen Schlüsselbund zu Hunderten von Kundenorganisationen, die selbst nie einen Fehler gemacht hatten.

Warum OAuth-Missbrauch direkt an MFA vorbeigeht

Das ist das Detail, das die meiste Berichterstattung übergeht, und es ist der Grund, warum die Kampagne so lange funktionierte. OAuth-Zustimmung ist dafür gedacht, Zugriff zu delegieren. Wenn ein Mitarbeiter eine Connected App genehmigt, stellt Salesforce ein langlebiges Token aus, mit dem diese App die API im Namen des Nutzers aufrufen kann – ohne erneute Anmeldung, ohne frische MFA-Abfrage. Genau das ist der Sinn von OAuth, und deshalb ist „einfach MFA aktivieren“ hier keine Verteidigung.

Sobald das Token existiert, agiert der Angreifer als vertrauenswürdige Anwendung, nicht als verdächtige Anmeldung. Es gibt keine anomale Geolokalisierung, die auffallen könnte, weil die API-Aufrufe von der eigenen Infrastruktur der App ausgehen. Richtlinien für Anmelderisiken greifen nie, weil es keine Anmeldung gibt. Die Passwortrotation bewirkt nichts, weil kein Passwort im Spiel ist. Das Token zu widerrufen ist der einzige echte Notausschalter – und widerrufen kann man nur, was man sieht, was genau das ist, was Salesforces Standardprotokollierung erschwerte. Das ist dieselbe Lektion „Identität ist der neue Perimeter“, die hinter Zero-Trust-Migrationen steht: Der Netzwerkrand ist irrelevant, wenn der Angreifer mit einem gültigen Zugangsnachweis in der Hand ankommt.

Wen es traf

Die Opferliste liest sich wie ein Who's who der Konzernwelt. Öffentliche Berichterstattung und Postings auf Leak-Seiten bringen die breitere ShinyHunters-Salesforce-Aktivität unter anderem mit Google, Cloudflare, Zscaler, Palo Alto Networks, Proofpoint, Qantas, Allianz Life, Adidas, Chanel, Pandora und mehreren LVMH-Marken in Verbindung. Auch Sicherheitsanbieter blieben nicht verschont – Tanium, Huntress und Recorded Future tauchen ebenfalls in den Berichten auf, eine deutliche Erinnerung daran, dass das Risiko der OAuth-Zustimmung universell ist und kein Problem kleiner Unternehmen.

Das Gesundheitswesen erhielt besondere Aufmerksamkeit. Health-ISAC veröffentlichte Handlungsempfehlungen zur Schadensbegrenzung, nachdem die Aktivitäten der Gruppe in den Sektor übergriffen, und die Finanzaufsicht FINRA veröffentlichte ihre eigene Warnung zur Salesforce Experience Cloud, die den Weg über die Gastzugriff-Fehlkonfiguration abdeckt.

So sichern Sie die OAuth-Zustimmung in Ihrer eigenen Organisation ab

Die Lösung ist Governance, kein Patch – und sie gilt für jede SaaS-Plattform, die die Autorisierung von Drittanbieter-Apps unterstützt (Google Workspace und Microsoft 365 haben dieselbe Angriffsfläche). Eine praxistaugliche Checkliste:

• Beschränken Sie, wer zustimmen darf. Deaktivieren Sie die OAuth-Zustimmung durch Endnutzer und leiten Sie alle neuen Genehmigungen von Connected Apps über eine Admin-Prüfschlange. Sperren Sie in Salesforce die Einstellungen „Connected Apps OAuth Usage“; nutzen Sie in Microsoft 365 App-Zustimmungsrichtlinien und Conditional Access.
• Inventarisieren und bereinigen Sie bestehende Berechtigungen. Überprüfen Sie jede autorisierte Connected App und widerrufen Sie alles Ungenutzte, Unbekannte oder Inaktive. Ein Token einer App, an deren Installation sich niemand erinnert, ist Ihr höchstes Risiko.
• Beobachten Sie die richtigen Protokolle. Anmeldeprotokolle erfassen das nicht. Überwachen Sie stattdessen OAuth-Autorisierungsereignisse, das API-Aufrufvolumen von Connected Apps und Muster beim Massenexport von Daten. Plötzliche Massenlesezugriffe durch eine selten genutzte App sind das verräterische Zeichen.
• Schulen Sie Mitarbeiter zu Vishing am Zustimmungsbildschirm. Der letzte Klick ist menschlich. Stellen Sie sicher, dass Mitarbeiter wissen, dass die IT sie niemals anrufen und durch eine OAuth-„Zulassen“-Abfrage führen wird.
• Prüfen Sie Ihre Integrationsanbieter. Die Kompromittierungen von Salesloft und Gainsight zeigen, dass Ihre Salesforce-Sicherheit nur so stark ist wie die Dritten, denen Sie Tokens erteilt haben – dieselbe Supply-Chain-Lektion wie aus der npm-Shai-Hulud-Krise.

Häufig gestellte Fragen

Hat ShinyHunters eine Salesforce-Schwachstelle ausgenutzt?

Nein. Es gab keinen Fehler in Salesforce selbst. Die Angreifer missbrauchten die legitime OAuth-Zustimmung und fehlkonfigurierten Gastzugriff – ein Fall von Funktionen, die wie vorgesehen arbeiten und gegen die Nutzer gewendet wurden.

Hätte MFA das verhindert?

Nicht allein. MFA schützt die Anmeldung, aber der Missbrauch von OAuth-Tokens geschieht, nachdem ein Nutzer eine App bereits autorisiert hat. Die Verteidigung ist Zustimmungs-Governance und Token-Überwachung, nicht stärkere Anmeldefaktoren.

Was ist in diesem Zusammenhang eine „Connected App“?

Es ist eine Drittanbieter-Anwendung, der über OAuth API-Zugriff auf eine Salesforce-Organisation gewährt wird. Legitime (Data Loader, Analyse-Tools) sind weit verbreitet, was genau der Grund ist, warum ein bösartiger Klon durchrutscht.

Woran erkenne ich, ob ich betroffen war?

Prüfen Sie Ihre autorisierten Connected Apps und OAuth-Berechtigungen, widerrufen Sie alles Unbekannte und überprüfen Sie die API-Aufrufprotokolle auf ungewöhnliche Massenexporte. Wenn Sie Salesloft, Gainsight oder Klue nutzen, nehmen Sie deren offengelegte Vorfälle zum Anlass, Tokens zu rotieren.

Ist das nur ein Salesforce-Problem?

Nein. Jede SaaS-Plattform mit Drittanbieter-OAuth – Google Workspace, Microsoft 365, Slack, GitHub – trägt dasselbe Consent-Phishing-Risiko. Das obige Vorgehen ist plattformunabhängig.

Sources

• Microsoft Security — Verteidigung SaaS-basierter Anwendungen gegen ShinyHunters-OAuth-Missbrauch (13. Juli 2026) — primäre Threat-Intel-Offenlegung und Verteidigungsempfehlungen.
• The Hacker News — Microsoft kartiert die einjährige ShinyHunters-Aktivität — Zusammenfassung der Angriffswege, des Ausmaßes und der Opferberichterstattung.
• Google Cloud Threat Intelligence — Proaktive Verteidigung gegen ShinyHunters-SaaS-Erpressung — UNC6040/UNC6395-Tracking und Erkennungshinweise.
• Varonis — Salesforce-Vishing-Bedrohung (UNC6040) — Mechanik der Data-Loader-Imitation.
• Mitiga — ShinyHunters und UNC6395: die Salesforce- und Salesloft-Kompromittierungen — Details zum Supply-Chain-Token-Diebstahl.
• Health-ISAC — Auswirkungen von ShinyHunters auf den Gesundheitssektor — Handlungsempfehlungen für den Sektor.
• FINRA — Sicherheitswarnung zur Salesforce Experience Cloud — Weg über die Gastzugriff-Fehlkonfiguration.