Eine Grafik mit rotem Hintergrund, die eine digitale IT-Struktur in einem abstrakten Design darstellt. Geeignet für technische Themen.
Teams-Phishing ohne Fake-Login: Consent-Phishing
- von Technischer Support
Phishing lebte jahrelang von der Fälschung: nachgebaute Login-Seiten, Domains mit einem vertauschten Buchstaben, schlecht kopierte Logos. Genau darauf sind die meisten Schutzmechanismen trainiert.
Nun haben Angreifer unlängst Medienberichten zufolge mehr als 200 Phishing-E-Mails an Mitarbeiter von rund 120 Unternehmen weltweit verschickt.
Genutzt wurde eine Methode, die ohne Fälschung auskommt: Consent-Phishing.
Die Opfer landen auf der echten Microsoft-Anmeldeseite. Erbeutet wird in diesem Fall nicht das Passwort, sondern eine Berechtigung.
Das Wichtigste zu Consent-Phishing im Überblick
- Der Köder imitiert eine Teams-/Planner-Benachrichtigung mit HR-Bezug und künstlichem Zeitdruck.
- Der Link führt auf eine echte login.microsoftonline.com-OAuth-URL – keine Look-alike-Domain.
- Nach der regulären Anmeldung soll einer angreiferkontrollierten App zugestimmt werden.
- Bei Zustimmung sind E-Mails, Dateien, SharePoint, OneDrive, Teams-Chats und Kalender offen.
Ablauf Consent-Phishing Angriff
Der Ablauf ist bewusst unauffällig, weil jeder einzelne Schritt für sich betrachtet legitim wirkt: eine erwartbare Benachrichtigung, eine bekannte Absenderadresse, eine echte Anmeldeseite.
Genau diese Kette aus unverdächtigen Einzelschritten macht die Kampagne wirksam – der entscheidende Moment ist erst der Berechtigungsdialog am Ende.
1
Der Köder
Eine E-Mail imitiert eine Microsoft-Teams- bzw. Planner-Benachrichtigung: „Es gibt neue Aktivität in Ihrem Team.“ Inhaltlich geht es um neue Aufgaben oder Nachrichten aus der Personalabteilung – häufig mit Bezug auf Gehalt, Vergütung und Zusatzleistungen. Ein Hinweis auf „mehrere überfällige Mitarbeiteraufgaben“ erzeugt Zeitdruck.
2
Die vertraute Absenderadresse
Die sichtbare Absenderadresse gehört zur Organisation des Ziels. Für den Empfänger sieht die Nachricht damit aus wie interne Kommunikation – ein Prüfkriterium, auf das viele Anwender geschult sind, fällt damit aus.
3
Die echte Microsoft-Anmeldeseite
Der Link öffnet eine legitime OAuth-Autorisierungs-URL auf login.microsoftonline.com. Zertifikat, Domain und Optik stimmen, weil es sich tatsächlich um Microsoft handelt. Die Anmeldung inklusive MFA läuft völlig regulär ab.
4
Die Zustimmungsabfrage
Anschließend erscheint ein echter Microsoft-Berechtigungsdialog. Er fordert Zugriff für eine Anwendung an, die von den Angreifern kontrolliert wird – teilweise mit der Aufforderung, im Namen der gesamten Organisation zuzustimmen.
5
Der Zugriff
Nach der Zustimmung leitet Microsoft auf einen von den Angreifern betriebenen Endpunkt weiter – in der beobachteten Kampagne ein AWS-API-Gateway. Die Anwendung besitzt nun ein gültiges Token und verhält sich gegenüber Microsoft 365 wie ein berechtigter Client.
Entscheidend beim Consent-Phishing ist nicht ein einzelnes Passwort, sondern der Umfang der erteilten Berechtigungen.
| Bereich | Möglicher Zugriff | Risiko für das Unternehmen |
|---|---|---|
| Exchange Online | E-Mails lesen und versenden | Business E-Mail Compromise von einer internen Adresse aus |
| SharePoint | Dokumente und Bibliotheken lesen | Abfluss von Verträgen, Angeboten, Personalunterlagen |
| OneDrive | Dateien lesen und verwalten | Unbemerkter Datenabzug aus persönlichen Ablagen |
| Microsoft Teams | Chats und Kanalinhalte einsehen | Mitlesen interner Abstimmungen, Social Engineering mit Insiderwissen |
| Kalender | Termine und Teilnehmer einsehen | Zielgenaue Folgeangriffe auf Führungskräfte und Projekte |
Besonders kritisch
Der Postfachzugriff erlaubt Folgeangriffe und Business-E-Mail-Compromise-Versuche von einer Adresse aus, der die Empfänger vertrauen.
Aus Sicht der Empfänger gibt es dann kein technisches Warnsignal mehr.
Warum die Erkennung bei Consent-Phishing versagt
Die etablierten Kontrollen prüfen im Kern zwei Dinge:
Ist die Domain gefälscht? Sieht die Login-Seite nachgebaut aus? Beides trifft hier nicht zu.
Klassisches Phishing
- Gefälschte Login-Seite auf fremder Domain
- Ziel: Zugangsdaten abgreifen
- Erkennbar an Domain, Zertifikat und Layout
- Passwortwechsel beendet den Zugriff
Consent-Phishing
- Echte Microsoft-Seite, echte Anmeldung
- Ziel: dauerhafte App-Berechtigung
- Domain- und Zertifikatsprüfung greifen nicht
- Zugriff bleibt auch nach Passwortwechsel bestehen
Auch MFA hilft hier nur bedingt:
Die Mehr-Faktor-Authentifizierung wird korrekt durchlaufen. Der Zugriff entsteht erst danach – durch die bewusst erteilte Zustimmung.
Microsoft-365-Tenant prüfen
Vor jeder Maßnahme – auch bei Prävention für Consent-Phishing – steht die Bestandsaufnahme. Diese Wege werden IT-Admins empfohlen:
- Entra Admin Center → Unternehmensanwendungen: Apps nach Erstellungsdatum sortieren und unbekannte Einträge prüfen.
- Überwachungsprotokolle: nach der Aktivität „Consent to application“ filtern.
- Berechtigungen bewerten: Wer darf Mail.Read, Mail.Send, Files.Read.All oder offline_access?
- Postfachregeln kontrollieren – automatische Weiterleitungen sind ein typisches Folgeartefakt.
- Defender for Cloud Apps / App Governance: OAuth-Apps mit hohem Berechtigungsumfang bewerten.
PowerShell · Microsoft Graph
# Verbindung zu Microsoft Graph herstellen Connect-MgGraph -Scopes "Directory.Read.All","Application.Read.All","AuditLog.Read.All" # Erteilte delegierte Berechtigungen auflisten Get-MgOauth2PermissionGrant -All | Select-Object ClientId, ConsentType, PrincipalId, Scope | Sort-Object ClientId
Wird eine verdächtige Anwendung gefunden, reicht das Deaktivieren nicht aus. Die Zustimmung muss entzogen und die bestehende Sitzung beendet werden.
PowerShell · Bereinigung
# Zustimmung entziehen Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId "<Grant-ID>" # Aktive Token des betroffenen Kontos entwerten Revoke-MgUserSignInSession -UserId "benutzer@ihre-domain.de"
Schutzmaßnahmen für Unternehmen
Technisch
Benutzerzustimmung in Entra ID einschränken – idealerweise nur für verifizierte Herausgeber und Berechtigungen mit geringer Auswirkung. Admin-Consent-Workflow aktivieren, damit Anfragen kontrolliert im Team landen. Conditional Access und Anmelderisiko-Richtlinien ergänzen die Kontrolle. MDR sorgt zudem dafür, dass im Falle fehlgeschlagener Richtlinien und Antivirus-Erkennungen rechtzeitig reagiert werden kann.
Organisatorisch
Einen festen Freigabeprozess für neue Anwendungen etablieren. App-Berechtigungen turnusmäßig überprüfen und nicht mehr genutzte Zustimmungen entziehen. Audit-Logs auf Consent-Ereignisse überwachen und als Alarm hinterlegen.
Menschlich
Anwender darauf schulen, Berechtigungsdialoge tatsächlich zu lesen. Dienste im Zweifel direkt über die installierte App öffnen statt über den Link in der Mail. Ungewöhnlich dringliche HR-Themen und mehrere Buttons auf dieselbe URL gehören gemeldet.
Typische Fehler vermeiden
- Sich allein auf Domain- und Zertifikatsprüfung verlassen – hier ist beides echt.
- „Im Namen Ihrer Organisation zustimmen“ anklicken, ohne die Anwendung zu kennen.
- Nach einem Vorfall nur das Passwort zurücksetzen: bestehende Token bleiben gültig.
- Eine verdächtige App nur deaktivieren, ohne die Zustimmung zu entziehen.
- Benutzerzustimmung uneingeschränkt lassen, weil „das noch nie ein Problem war“.
Nicht zu empfehlen
Verdächtige Anwendungen nicht stillschweigend löschen, bevor die Protokolle gesichert sind – sonst fehlt die Grundlage für die Aufarbeitung.
Zudem Benutzerzustimmung nicht pauschal wieder freigeben, weil einzelne Tools sonst „nicht funktionieren“.
Empfehlungen für IT-Admins
Sinnvoll ist ein gestaffeltes Vorgehen statt einer einmaligen Aktion:
- Inventur: alle erteilten App-Berechtigungen im Tenant erfassen und bewerten.
- Benutzerzustimmung einschränken und den Admin-Consent-Workflow aktivieren.
- Monitoring auf Consent-Ereignisse einrichten und als Alarm hinterlegen.
- Awareness-Einheit zum Thema Berechtigungsdialoge in die nächste Schulung aufnehmen.
- Incident-Playbook um den Schritt „Zustimmung entziehen und Token widerrufen“ ergänzen.
FAQ zu Consent-Phishing
Nur bedingt. Die Mehr-Faktor-Authentifizierung wird regulär und erfolgreich durchlaufen. Der Zugriff entsteht erst durch die anschließend erteilte App-Zustimmung.
Nein. Zustimmung entziehen, Anwendung entfernen, Sitzungen und Token widerrufen, danach Postfach und Weiterleitungsregeln prüfen.
Ja. In Entra ID lässt sich die Benutzerzustimmung einschränken oder ganz deaktivieren. In Kombination mit dem Admin-Consent-Workflow bleibt der Betrieb arbeitsfähig.
Fazit
Nicht jeder Angriff braucht eine Fälschung. Wenn die legitime Infrastruktur selbst zum Werkzeug wird – wie hier beim Consent-Phishing -verschiebt sich die Verteidigung von der Domain-Prüfung hin zur konsequenten Verwaltung von App-Berechtigungen.
Fanden Sie den Blogbeitrag hilfreich und interessant?
Vielen Dank für Ihre Rückmeldung!