SaaS-to-SaaS OAuth-Würmer: Das "Zustimmungs"-Virus

Zusammenfassung

Im Jahr 2026 hat sich die Ära “Identity is the New Perimeter” zu “Interconnectivity is the New Vulnerability” entwickelt. Die neueste Bedrohung in der Cybersicherheit ist kein Brute-Force-Passwortangriff oder Zero-Day-Exploit. Es ist der SaaS-to-SaaS OAuth-Wurm — ein sich selbst verbreitender “Zustimmungs-Virus”, der die legitimen API-Verbindungen zwischen Cloud-Anwendungen ausnutzt.

Dieser Artikel analysiert die Anatomie dieser Angriffe, verbindet sie mit realen Kampagnen aus dem Jahr 2025 und bietet umsetzbare Verteidigungsstrategien für Microsoft 365- und Google Workspace-Administratoren.

---

Die Neue Angriffsfläche: “Helper Apps”  AI-Integrationen

Bis 2026 verbindet der durchschnittliche Unternehmenskunde über 50 Drittanbieter-Apps mit seiner Unternehmensidentität. Dabei handelt es sich nicht nur um Shadow IT — sondern um “Produktivitäts-Boosters” wie AI-Planer, Grammatikprüfer und Meeting-Assistenten.

Sicherheitsteams haben ein Jahrzehnt damit verbracht, die Haustür (MFA, SSO, biometrische Verfahren) zu sichern. Der OAuth-Wurm schleicht durch die Hintertür. Er bricht nicht ein; er bittet um Einlass. Nach der Autorisierung benötigt er nicht Ihr Passwort — er besitzt Ihren OAuth Access Token, einen digitalen Schlüssel, der auch nach einer Änderung der Anmeldeinformationen funktioniert.

---

Das Szenario “AI-Meeting-Summarizer”

Das prominenteste Beispiel dieses Bedrohungsmusters ist der “AI-Meeting-Summarizer”-Wurm. Hier ist der Infektionszyklus:

1. Patient Zero — Ein Nutzer erhält eine hilfreiche E-Mail von einem Kollegen (der bereits infiziert ist), der ihn einlädt, “bei der Zusammenfassung dieses Meetings zu kollaborieren” mit einem neuen AI-Tool.

2. Der Köder — Die E-Mail ist kein herkömmlicher Phishing-Link. Sie stammt von einer legitimen internen Domain (z.B. user@unternehmen.de), weil das Konto des Absenders die Einladung via API automatisiert versendet.

3. Der Haken — Der Nutzer klickt auf den Link und sieht einen standardmäßigen OAuth-Zustimmungsbildschirm von Microsoft 365 oder Google Workspace. Er wirkt 100% authentisch — weil er es ist.

4. Der Payload (Das “Zustimmung”) — Die App fordert Berechtigungen an wie:

   • Contacts.Read — um neue Opfer zu identifizieren
   • Mail.Send — um den Wurm zu verbreiten
   • Files.ReadWrite.All — um Daten zu exfiltrieren
   • Offline_Access — um dauerhaften Zugriff zu gewährleisten

5. Die Verbreitung — Sobald der Nutzer “Akzeptieren” klickt, nutzt der Wurm das erteilte API-Token, um die häufigsten Kontakte des Nutzers zu scannen und 50 personalisierte Einladungen von der eigenen E-Mail-Adresse des Opfers zu versenden.

Zeit, um eine ganze Abteilung zu infizieren: < 15 Minuten.

---

Reale Vorfälle (2025–2026)

Diese Szenarien sind keine Theorie. Das Angriffsmuster wurde 2025 in großem Stil durchgeführt und nimmt 2026 weiter zu.

Die Salesloft-Drift Lieferkettenpanne (März 2025)

Einer der bedeutendsten OAuth-Vorfälle 2025 zeigt die SaaS-to-SaaS-Explosion perfekt. Angreifer griffen auf das GitHub-Repository von Salesloft zu und nutzten die Drift-Integration OAuth-Tokens, um Salesforce-Instanzen in mehr als 700 Organisationen zu erreichen. Forscher von Obsidian Security stellten fest, dass der Schaden das Zehnfache der direkten Angriffe auf Salesforce betrug — weil eine kompromittierte Integration sich in Hunderte von downstream-Umgebungen ausbreitete.

Die Lektion: Ein einzelner OAuth-Link in Ihrer SaaS-Lieferkette kann der Einstieg in Ihr gesamtes Geschäftsumfeld sein.

Die Chrome Extension Consent-Welle (Ende 2024–2025)

Eine Phishing-Kampagne gegen Chrome-Extension-Anbieter betraf schätzungsweise 2,6 Millionen Endnutzer bei mindestens 35 gängigen Erweiterungen, inklusive der Cybersicherheitsfirma Cyberhaven. Ein kompromittiertes Mitarbeiterkonto ermöglichte Angreifern den Zugriff auf den Chrome Web Store, um bösartige Versionen von Erweiterungen zu veröffentlichen, die OAuth-Anmeldeinformationen in großem Stil sammelten.

Die “ShadyPanda” Browser-Kampagne (Dezember 2025)

Die “ShadyPanda”-Kampagne sammelte etwa 4,3 Millionen Installationen bei Chrome- und Edge-Erweiterungen und exfiltrierte Daten durch Cookie- und Sitzungstoken-Diebstahl — vollständig außerhalb der Sichtbarkeit von Endpoint-Detection-Tools.

Microsoft 365 OAuth-App-Impersonation (2025, laufend)

Proofpoint identifizierte eine anhaltende Kampagne mit gefälschten Microsoft 365 OAuth-Anwendungen, die vertrauenswürdige Marken wie Adobe, DocuSign, RingCentral und SharePoint imitierten. Diese Kampagnen zielten auf fast 3.000 Nutzerkonten in mehr als 900 Microsoft 365-Umgebungen ab, mit einer bestätigten Erfolgsquote bei Kontenkompromittierungen von über 50%. Die bösartigen Apps fungierten als Lockmittel, die Opfer zu Man-in-the-Middle (AiTM)-Phishing-Kits wie Tycoon umleiteten, um Sitzungscookies und MFA-Tokens gleichzeitig zu stehlen.

Staatlich ausgerichteter OAuth-Missbrauch (September 2025)

Proofpoint beobachtete eine mutmaßliche russisch ausgerichtete Bedrohungsakteurgruppe namens UNK_AcademicFlare, die OAuth-Gerätecode-Authentifizierung für gezielten Kontenübernahme missbrauchte. Die Akteure nutzten kompromittierte Regierungs- und Militär-E-Mail-Konten, um Vertrauen aufzubauen, bevor sie gefälschte OneDrive-Links verschickten, die Opfer in Gerätecode-Phishing-Flows lockten. Hauptziele waren Regierungs-, akademische, Think-Tank- und Transportsektoren in den USA und Europa.

---

Die Entwicklung: “ConsentFix” — Die nächste Mutation (Dezember 2025)

Gerade als Verteidiger begannen, Drittanbieter-OAuth-Zustimmungsflüsse zu sperren, dokumentierten Push-Security-Forscher im Dezember 2025 eine bedeutende Mutation: ConsentFix.

ConsentFix ist ein browser-natives Angriffsmuster, das sogar die strengeren OAuth-Zustimmungs-Konfigurationen umgeht, die Microsoft 2025 eingeführt hat. Hier ist warum es gefährlicher ist:

Der Mechanismus: Anstatt einen Nutzer dazu zu verleiten, “Zulassen” auf einem Zustimmungsdialog zu klicken, sozial-engineert ConsentFix das Opfer, eine legitime OAuth-Autorisierungscode-URL in die Phishing-Seite des Angreifers zu kopieren und einzufügen. Das Opfer übergibt dem Angreifer so eine gültige Sitzung — vollständig im Browser, ohne Software zu installieren oder eine MFA-Herausforderung auszulösen.

Das First-Party-Loophole: ConsentFix zielt speziell auf Azure CLI — eine First-Party-Anwendung von Microsoft, die in jedem Entra ID-Mandant implizit vertrauenswürdig ist. Da Azure CLI eine Microsoft-native App ist, kann sie von Administratoren nicht blockiert oder gelöscht werden. Sie kann erhöhte Berechtigungen anfordern, ohne Admin-Workflows auszulösen, und Richtlinien zur Drittanbieter-App-Beschränkung gelten nicht für sie.

Der phishing-resistente Umgehung: Wenn das Opfer bereits eine aktive Browser-Sitzung mit seinem Microsoft-Konto hat, ist keine Anmeldung erforderlich. Damit umgeht ConsentFix phishing-resistente Authentifizierungsmethoden, inklusive Passkeys.

Dies stellt eine fundamentale Veränderung dar: Angreifer nutzen nicht mehr nur die Drittanbieter-App-Zustimmungs-Lücke aus — sie nutzen das implizite Vertrauen, das Cloud-Plattformen ihren eigenen Tools entgegenbringen.

---

Anatomie eines OAuth-Wurms: Warum er Legacy-Sicherheitsmaßnahmen umgeht

Er umgeht MFA

MFA schützt den Authentifizierungszeitpunkt — die Anmeldung. OAuth-Würmer nutzen Autorisierung — die Berechtigungsgewährung. Da der Nutzer bereits mit einer gültigen Sitzung eingeloggt ist, löst das Klicken auf “Zulassen” auf einem Zustimmungsdialog in den meisten Standardkonfigurationen keine MFA-Herausforderung aus. Da Angreifer nicht-menschliche Identitäten über OAuth 2.0 API-Zugriffe verwenden, sind MFA-Schutzmaßnahmen gegen nachfolgende Token-Missbräuche wirkungslos.

Leben im Cloud (LotC)

Der Angriff installiert keine Malware auf dem Endgerät. Es gibt keine .exe, die CrowdStrike oder Windows Defender erkennen könnten. Die bösartige Logik lebt vollständig in der Cloud-Infrastruktur des Angreifers (AWS/Azure/GCP), die direkt mit den APIs Ihres Mandanten kommuniziert — Microsoft Graph API oder Google Workspace APIs.

Vertrauenswürdige Einladungen

Spam-Filter verlassen sich auf Reputationssignale. Wenn der Wurm E-Mails von interner-mitarbeiter@unternehmen.de an anderer-mitarbeiter@unternehmen.de sendet, sind diese mit gültigen DKIM- und SPF-Einträgen signiert. Sie passieren “Sichere Absender”-Listen, weil sie von einem vertrauenswürdigen internen Konto stammen.

Persistenz via Refresh Tokens

Selbst wenn das Opfer sein Passwort ändert, besteht die Infektionsgefahr weiter. OAuth-Apps verwenden Refresh Tokens, um neue Access Tokens ohne Nutzerinteraktion zu generieren. Solange die App-Berechtigung nicht explizit widerrufen wird, behält der Angreifer Zugriff für bis zu 90 Tage oder mehr — auch nach Passwort-Reset, MFA-Neuanmeldung und Kontosperrung.

Das Token ist der Schlüssel

Bearer-Tokens bieten keine Sender-Validierung. Ein gestohlenes OAuth-Token funktioniert von jedem Ort, Gerät oder Netzwerk ohne erneute Authentifizierung. Sobald ein Angreifer ein gültiges OAuth-Token erlangt — durch Zustimmungs-Phishing, Token-Diebstahl oder Drittanbieter-Kompromittierung — umgeht er die Authentifizierung vollständig. Wer das Token besitzt, hat die Schlüssel.

---

Die “Agentic”-Bedrohung: KI-gesteuertes Kontextverständnis

2024 demonstrierten Forscher Morris II — den ersten generativen KI-Wurm. Bis 2026 hat sich dieses Konzept zu operativen Angriffen weiterentwickelt.

Moderne OAuth-Würmer nutzen LLMs, um die letzten E-Mails und Kalenderdaten des Opfers zu lesen und kontextbezogene Einladungen zu generieren, die kaum von legitimen Kollegen-Kommunikationen zu unterscheiden sind:

Altes Phishing	2026 KI-gestützter OAuth-Wurm
“Bitte schauen Sie sich die angehängte Rechnung an.”	“Hey Sarah, ich habe dieses KI-Tool benutzt, um unser Budget-Meeting vom Dienstag zusammenzufassen. Es hat die Diskussion zur Q3-Prognose gut erfasst — schau es dir an.”

Dieses hochkontextbezogene Social Engineering macht Skepsis für den durchschnittlichen Mitarbeiter nahezu unmöglich. Die Nachricht ist personalisiert, bezieht sich auf echte Gespräche und kommt von einer vertrauenswürdigen E-Mail-Adresse eines Kollegen.

Bemerkenswert ist, dass ClickFix — eine Technik, die eng mit ConsentFix verwandt ist — im Jahr 2025 der häufigste initiale Angriffsvektor war, den Microsoft erfasste, und in 47% der Angriffe beteiligt war.

---

Plattform-Reaktionen: Was hat sich 2025 geändert

Microsofts Policy-Änderung im Juli 2025

In einem bedeutenden Verteidigungsschritt kündigte Microsoft an, dass ab Juli 2025 Nutzer standardmäßig keine Zustimmung mehr zu Drittanbieter-Apps für den Zugriff auf Dateien und Sites geben können. Stattdessen müssen Nutzer die Genehmigung des Administrators über den Admin-Zustimmungs-Workflow anfordern. Das risikobasierte Step-up-Zustimmungsverfahren in Entra ID eskaliert automatisch Zustimmungsgesuche für Multi-Tenant-Apps ohne verifizierten Publisher — um zu verhindern, dass Endnutzer verdächtige Apps direkt zustimmen, die sie über Phishing-URLs erreichen.

Dies ist eine große Verbesserung, aber es adressiert nicht vollständig die ConsentFix- und First-Party-Bypass-Vektoren.

Google Workspace Kontrollen

Google Workspace-Administratoren können API-Beschränkungen konfigurieren, um den Zugriff Drittanbieter-Apps einzuschränken. Die empfohlene Strategie ist, nur domäneneigene Apps und explizit erlaubte Drittanbieter-Apps zuzulassen und alle anderen standardmäßig zu blockieren. Das reduziert die Angriffsfläche für Zustimmung-Phishing erheblich.

---

Verteidigungsstrategien: Ihre Organisation schützen

Der Schutz vor dem Consent-Virus erfordert einen Wandel von “Identity Security” zu “App Governance”.

1. Der “Kill Switch”: Nutzer-Zustimmung einschränken

Microsoft 365: - Navigieren Sie zu Entra ID  Enterprise Applications  Consent and Permissions - Wählen Sie “Allow user consent for apps from verified publishers only” (empfohlen) oder deaktivieren Sie die Nutzer-Zustimmung vollständig - Aktivieren Sie den Admin Consent Workflow, damit Nutzer Apps anfordern können, ohne sie selbst zu genehmigen - Stellen Sie sicher, dass Ihr Mandant die im Juli 2025 eingeführte verwaltete Zustimmungsrichtlinie nutzt

Google Workspace: - Navigieren Sie zu Security  API Controls  App Access Control - Vertrauen Sie nur internen, domänen-eigenen Apps; pflegen Sie eine explizite Allow-List für genehmigte Drittanbieter-Apps - Blockieren Sie alle anderen Apps standardmäßig

2. Überprüfung und Bereinigung (“App-Hygiene”-Protokoll)

Ihre Umgebung enthält wahrscheinlich ruhende, überprivilegierte Apps, die vor Monaten oder Jahren genehmigt wurden. Nutzen Sie Ihren CASB oder Microsoft Defender for Cloud Apps, um nach:

• Apps mit Mail.Send oder Contacts.Read Berechtigungen zu filtern
• Apps mit “Low Community Trust” oder “Unverified Publisher”-Status
• Apps, die von mehr als 10 Nutzern in weniger als 24 Stunden genehmigt wurden — ein starker Indikator für eine aktive Verbreitung
• Jede App, die offline_access mit Files.ReadWrite.All oder Mail.ReadWrite kombiniert — eine Hochrisiko-Scopes-Kombination für langfristige Exfiltration

3. Anomalieerkennung bei API-Nutzung

Standard-EDR ist blind für cloud-native OAuth-Angriffe. Sie benötigen ITDR (Identity Threat Detection and Response) mit spezifischen Alarmregeln:

• “Neue OAuth-App mit Hochrisiko-Berechtigungen” — bei Erstauftreten alarmieren
• “Anomalies bei ausgehenden E-Mails vom internen Konto” — insbesondere identische Betreffzeilen an interne Verteiler
• “Neue Multi-Tenant-App mit offline_access + Files.ReadWrite.All” — innerhalb von 60 Minuten untersuchen
• “Erstmalige externe Tenant-DM + Postfachregel-Erstellung + neue OAuth-Genehmigung” innerhalb von 24–48 Stunden — dieses Trifecta ist ein hoher Worm-Indikator
• “Änderung des Publisher-Domains bei einer bestehenden App” — ein mögliches Zeichen für Lieferketten-Kompromittierung

4. Neue Prüfung für First-Party-Apps

ConsentFix zeigte, dass Microsoft-native Apps wie Azure CLI in einer Weise genutzt werden können, die Drittanbieter-Beschränkungen vollständig umgeht. Überprüfen Sie Conditional Access-Richtlinien, um Gerätecode-Authentifizierungsflüsse abzudecken, und erwägen Sie, Anmeldeursprungsbedingungen zu implementieren, um Authentifizierungen aus unerwarteten Standorten oder Geräten zu kennzeichnen.

5. “Consent Phishing”-Simulation

Führen Sie OAuth-Zustimmungs-Simulationen neben klassischen Phishing-Tests durch:

• Senden Sie eine gefälschte “Aktualisieren Sie Ihre Kalender-App”-E-Mail an Ihre Nutzer
• Leiten Sie Nutzer zu einem simulierten Zustimmungsbildschirm
• Verfolgen Sie, wie viele “Zulassen” klicken, ohne den Publisher zu prüfen

Ziel ist es, Nutzer zu schulen, auf den “Verifizierter Publisher”-Blaucheck zu achten, bevor sie Zustimmungsbildschirme genehmigen — und unerwartete OAuth-Aufforderungen an die IT-Sicherheit zu melden, anstatt sie zu ignorieren oder zu akzeptieren.

---

Wiederherstellung: Was tun bei Infektion

Wenn Sie einen OAuth-Wurm in Ihrer Mandantenumgebung erkennen, gehen Sie diese Schritte in Reihenfolge durch:

Schritt 1: App global widerrufen

Microsoft 365: In Entra ID, finden Sie die Enterprise Application, gehen Sie zu “Properties” und setzen Sie “Enabled for users to sign-in?” auf No. Löschen Sie die App-Zuweisung und die Service Principal.

Google Workspace: In API Controls, blockieren Sie die spezifische Client-ID der bösartigen App.

Schritt 2: Refresh Tokens widerrufen

Passwörter zu ändern reicht nicht — Sie müssen OAuth-Tokens explizit widerrufen.

PowerShell (M365):

Revoke-MgUserSignInSession -UserId <UserObjectID>

Führen Sie dies für alle betroffenen Nutzer durch, nicht nur für die zuerst gemeldeten Fälle.

Google Workspace: Setzen Sie die Anmelde-Cookies zurück und widerrufen Sie verbundene Apps in den Sicherheitseinstellungen jedes Nutzers.

Schritt 3: Interne E-Mails durchsuchen

Verwenden Sie Microsoft Content Search oder eDiscovery, um die Einladungs-E-Mails des Wurms in allen Postfächern zu finden und dauerhaft zu löschen — inklusive der gesendeten Elemente kompromittierter Konten. Nicht gelöschte Einladungen generieren weiterhin neue Opfer.

Schritt 4: Exfiltrationsumfang prüfen

Wenn die App Files.ReadWrite.All oder Mail.Read Berechtigungen hatte und ein aktives Offline_Access-Token besitzt, behandeln Sie Datenexfiltration als wahrscheinlich. Prüfen Sie, auf welche SharePoint-Sites, OneDrive-Ordner oder Postfächer während der Token-Dauer zugegriffen wurde, und starten Sie entsprechende Sicherheitsüberprüfungen.

---

Das Bedrohungsmodell verändert sich: Was 2026 verlangt

Das Bedrohungsmodell für Phishing im Jahr 2026 muss anerkennen, dass Angreifer Kontenübernahmen durch Authentifizierungsflüsse, OAuth-Zustimmung, Gerätecode-Authentifizierung und browser-native Token-Diebstahl erreichen — nicht nur durch Passwortdiebstahl. Es reicht nicht mehr aus, E-Mail als primäre Anti-Phishing-Abwehr zu schützen.

Der Unterschied ist operativ entscheidend. Ihr SEG kann einen schädlichen Link blockieren. Es kann keinen Zustimmungsdialog blockieren, der über eine legitime interne E-Mail von einem kompromittierten Kollegen kommt. Es kann keine Copy-Paste-Aktion im Browser erkennen.

Der Consent-Virus zeigt, dass in einer cloud-nativen Welt eine bösartige App viel gefährlicher ist als eine bösartige Datei. Durch die Umsetzung strenger Zustimmungsrichtlinien, den Einsatz von ITDR-Tools neben EDR und die gleiche Prüfung jeder OAuth-Integrationsanfrage wie bei einer ausführbaren Datei können Organisationen die Infektionskette durchbrechen, bevor sie ihre Cloud-Umgebung überflutet.

---

Zentrale Erkenntnisse

• OAuth-Zustimmungsangriffe umgehen MFA vollständig, weil sie Autorisierung ausnutzen, nicht Authentifizierung
• Der Salesloft-Drift-Vorfall (März 2025) zeigte, dass eine kompromittierte Integration auf 700+ Organisationen ausstrahlt — ein 10-facher Radius im Vergleich zu direkten Angriffen
• “ConsentFix” (Dezember 2025) ist eine browser-native Mutation, die sogar Admin-Zustimmungsbeschränkungen umgeht, indem sie vertrauenswürdige First-Party-Apps wie Azure CLI angreift
• Microsoft machte restriktive Zustimmung im Juli 2025 zur Standardeinstellung — prüfen Sie, ob Ihr Mandant konform ist und testen Sie es
• Widerrufen Sie Tokens, nicht nur Passwörter — ein kompromittiertes OAuth-Refresh-Token überlebt einen vollständigen Credential-Reset
• ITDR ist keine Option: Standard-Endpunkt-Erkennung erkennt cloud-native OAuth-Exploits nicht
• ClickFix / ConsentFix-Varianten machten fast die Hälfte aller initialen Angriffsvektoren aus, die Microsoft 2025 beobachtete

---

Die OAuth-Bedrohungslandschaft entwickelt sich schneller als die meisten Auditzyklen. Überprüfen Sie Ihre App-Zustimmungsrichtlinien, führen Sie eine App-Hygiene-Überprüfung durch und stellen Sie sicher, dass Ihr ITDR-Alarmierungssystem auch nicht-interaktive API-Token-Missbräuche erkennt — bevor Ihre nächste Einladung im Kalender Patient Zero wird.