Neue Phishing-Welle missbraucht Googles Application Integration Service

So funktioniert der Angriff

Die Angreifer verwenden Googles Application Integration Infrastruktur, um E-Mails über `noreply-application-integration@google.com` zu versenden. Da diese Nachrichten direkt von Googles Servern stammen, bestehen sie SPF-, DKIM- und DMARC-Prüfungen — und wirken dadurch sowohl für E-Mail-Gateways als auch für Empfänger vollkommen legitim.

Für zusätzliche Glaubwürdigkeit kombinieren die Angreifer diese authentifizierten E-Mails mit Links zu Google-Domains wie `storage.cloud.google.com`, `sites.google.com` und `share.google`. Ausserdem verwenden sie Googles bekannte E-Mail-Vorlagen. Das Ergebnis: Eine E-Mail von Google, mit Links zu Google, die sämtliche Authentifizierungschecks besteht.

Einrichtung des E-Mail-Workflows in Googles Application Integration Service

Wahrscheinliche Angriffsziele

Um der Erkennung zu entgehen, nutzen die Angreifer mehrstufige Weiterleitungsketten über mehrere legitime Dienste. Eine typische Kette sieht so aus:

Google-Domain (z.B. share.google, sites.google.com)
→ Microsoft OAuth (login.microsoftonline.com)
→ Angreifer-kontrollierte Seite (z.B. AWS S3 Bucket)

Jeder Schritt nutzt vertrauenswürdige Infrastruktur — Google, Microsoft, AWS — was die Erkennung oder Blockierung an jedem einzelnen Punkt erschwert. Unabhängig vom Einstiegspunkt landen die Opfer schliesslich auf der Microsoft-365-Anmeldeseite, was das primäre Ziel der Angreifer offenbart: M365-Zugangsdaten.

Je nach Rolle des Opfers dient der Angriff einem von zwei Zwecken:

Credential Harvesting

Für die meisten Opfer handelt es sich um klassischen Zugangsdaten-Diebstahl. Der OAuth-Flow fordert den Scope https://management.core.windows.net//.default an, aber die meisten Empfänger haben keine Azure-Management-Berechtigungen. Stattdessen vermuten wir, dass der OAuth-Prompt als Mechanismus dient, um Zugangsdaten über Microsofts legitimen Login-Flow zu erfassen und zu validieren — selbst wenn das Opfer keine Azure-Berechtigungen hat, bestätigt der Angreifer, dass das Passwort gültig ist.

OAuth Consent Phishing

Für Opfer mit Cloud-Berechtigungen wird dies zu einem OAuth-Consent-Angriff (auch bekannt als "Illicit Consent Grant"). Die Angreifer bringen Opfer dazu, einer bösartigen Azure-AD-Anwendung Zugriff auf ihre Cloud-Ressourcen zu gewähren — und erhalten so Zugang zu Azure-Abonnements, VMs, Speicher und Datenbanken über delegierte Berechtigungen, die durch Access- und Refresh-Tokens bestehen bleiben.

Warum dieser Angriff traditionelle Schutzmechanismen umgeht

• Legitime Anmeldeseite: Zugangsdaten werden auf Microsofts echter Seite eingegeben, nicht auf einer Fälschung
• MFA hilft nicht: Das Opfer durchläuft die MFA-Authentifizierung selbst
• Tokens bleiben bestehen: Access-Tokens gelten Stunden oder Tage; Refresh-Tokens verlängern den Zugriff weiter
• Multi-Cloud-Verschleierung: Google-, Microsoft- und AWS-Infrastruktur in einer einzigen Angriffskette.

Warum dieser Angriff so effektiv ist

Dieser Angriff funktioniert dort, wo klassisches Phishing scheitert.

• Echte Absender-Domain E-Mails kommen von @google.com, nicht von einer Fälschung
• Besteht Authentifizierung SPF, DKIM und DMARC validieren erfolgreich
• Vertrauenswürdige Links: URLs zeigen auf legitime Google-Domains
• Bekanntes Format: Benachrichtigungen sehen aus wie echte Google-Sharing-Alerts.

Für viele Sicherheitstools und Nutzer signalisieren diese Merkmale eine vertrauenswürdige Nachricht.

Empfehlungen

Security-Teams sollten folgende Massnahmen in Betracht ziehen:

1. Quarantäne oder Kennzeichnung von E-Mails von `noreply-application-integration@google.com` zur manuellen Überprüfung
2. Alerting auf verdächtige Muster mit `sites.google.com`- oder `storage.cloud.google.com`-Links, besonders in Kombination mit dringlichen Finanz- oder Sicherheitsthemen
3. Awareness-Training aktualisieren — Nutzer sollten wissen, dass auch @google.com-Absender bösartig sein können
4. Monitoring auf Indikatoren wie unerwartete Application-Integration-Benachrichtigungen in Umgebungen, die diesen Dienst nicht nutzen.

Beispiele und verwendete Quellen

Beispiel-Screenshots

Gefälschte File Sharing Benachrichtigung

Gefälschte Voicemail Benachrichtung

Quellen

• [1] LinkedIn: "You're Dead" Legal Call - Google Signed Email Phone Prompt
• [2] X: Report by @blaize_w
• [3] Reddit: Got an email from noreply-application-integration and How can scammers send Google security prompts