OAuth-Forensik nach ShinyHunters: Wenn der Consent-Klick zum Einbruch wird
21.07.2026 oauthsaas-forensicssalesforcecloud-identity
Ein Jahr lang unsichtbar: Die ShinyHunters-Kampagne gegen Salesforce
Am 13. Juli 2026 veröffentlichte Microsoft eine Analyse, die vielen SaaS-Sicherheitsteams die Sprache verschlagen dürfte: Die Data-Extortion-Gruppe ShinyHunters hatte über ein ganzes Jahr hinweg Salesforce-Umgebungen kompromittiert, ohne dabei eine einzige Schwachstelle in der Plattform selbst auszunutzen. Der Weg hinein war das Vertrauen, das die Organisationen bereits gewährt hatten – meist über OAuth-Verbindungen, die Salesforce mit Apps und Drittanbietern verknüpfen. Für die DFIR-Praxis ist das ein Weckruf: Wenn der Angriff wie legitime Nutzung aussieht, versagen klassische Detektionsmechanismen – und die forensische Beweisführung beginnt bei null.
Microsoft identifizierte drei parallele Angriffspfade. Der erste Pfad, der die gesamte Kampagne ab Mitte 2025 auslöste, bestand aus Vishing-Anrufen, bei denen sich Angreifer als IT-Support ausgaben und Mitarbeitende durch den OAuth-Consent-Screen führten, um eine als Salesforce Data Loader getarnte, angreiferkontrollierte App zu autorisieren. Nach erteilter Zustimmung konnte die App API-Aufrufe im Namen des Nutzers durchführen und so Daten enumerieren, persistenten Zugriff halten und nach Credentials für andere SaaS-Plattformen suchen. Kein Malware-Einsatz, kein Passwort-Replay – nur ein Anruf und ein Klick.
Der zweite Pfad zielte auf die Lieferkette: Salesloft führte die Ursache auf einen Zugriff der Angreifer auf ihren GitHub-Account zurück, der bereits im März 2025 begann und genutzt wurde, um in Drifts AWS-Umgebung einzudringen und Tokens abzugreifen. Die Operatoren suchten gezielt nach Geheimnissen, führten SOQL-Queries aus, um Support-Fälle und andere Objekte nach AWS-Keys, Snowflake-Tokens und Passwörtern zu durchforsten, und löschten anschließend ihre Query-Jobs, um Ermittlungen zu verlangsamen. Genau diese Löschung von Job-Metadaten ist der Kern des forensischen Problems: Sie entzieht Incident-Respondern genau jene Artefakte, die eine Rekonstruktion der Exfiltration überhaupt ermöglichen würden.
Warum klassische Log-Analyse hier versagt
Das macht die Erkennung so schwierig: Wenn der Zugriff von einem echten Nutzer stammt, der eine Connected App genehmigt hat, oder von einer bereits vertrauten Integration kommt, liest sich der Traffic wie normale Nutzung – Sign-in- und Authentifizierungsmonitoring registriert kaum etwas. Ein Threat-Intel-Profil fasst die forensische Realität nüchtern zusammen: Forensische Artefakte beschränken sich auf OAuth-Token-Audit-Logs, Salesforce-Connected-App-Datensätze und API-Zugriffshistorien.
Das Ausmaß der Kaskade zeigt, warum das mehr als ein Salesforce-Problem ist: Google schätzte, dass der Drift-Token-Diebstahl potenziell mehr als 700 Organisationen betraf, darunter Cloudflare, Zscaler, Palo Alto Networks, Proofpoint, PagerDuty und Tanium; Google trackt den Cluster als UNC6395, Cloudflares Cloudforce One nennt ihn GRUB1. Eine weitere Welle traf im November 2025 die Gainsight-Integration: Salesforce zog Gainsight-Apps zurück, nachdem ungewöhnliche API-Aktivität aufgefallen war, und GTIG ordnete die Kampagne ShinyHunters-Affiliates über mehr als 200 betroffene Salesforce-Instanzen zu. Im Juni 2026 folgte der Fall Klue, bei dem Angreifer über ein längst ungenutztes, aber weiterhin aktives Legacy-Credential aus einer nie ausgerollten Testintegration eindrangen, ein Code-Update pushten, das OAuth-Tokens von Kunden abgriff, und diese nutzten, um auf Salesforce- und Gong-Daten von Klue-Kunden zuzugreifen – darunter Huntress und Recorded Future. Microsoft trackt den Klue-Akteur als Storm-3138.
Forensische Konsequenzen und Handlungsempfehlungen
Für IR-Teams bedeutet das einen Paradigmenwechsel: Statt Login-Anomalien zu jagen, muss der Fokus auf Connected-App-Inventar, Token-Scopes und API-Nutzungsmustern liegen. Microsoft und Salesforce reagierten mit erweiterter Telemetrie – außerdem wurde gemeinsam mit Salesforce neue Erkennungs- und Governance-Tooling ausgerollt, das Aktivitäten adressiert, die Authentifizierungs-Logs übersehen. Konkret empfohlen wird, robuste Identitätsverifikation für IT-Support-Interaktionen zu implementieren, zusätzliche Kontrollen wie OAuth-App-Whitelisting und Step-up-Authentifizierung für sensible Vorgänge einzuführen sowie Logs regelmäßig auf Kompromittierungsanzeichen zu prüfen.
Für die forensische Praxis heißt das konkret: Connected-App-Berechtigungen vor jedem Incident dokumentieren, API-Event-Logs über den gesetzlichen Mindestzeitraum hinaus archivieren und Token-Revocation als festen Bestandteil jedes Containment-Playbooks etablieren – denn wenn der Angreifer bereits im ersten Schritt die Beweise löscht, zählt jede Minute vor dem Incident.
← Zurück zur Übersicht