Threat Spotlight: Phishing-Seiten, die nur im Browser des Opfers existieren

Wie Angreifer Microsoft-OAuth-Weiterleitungen, Teams-Domains, Blob-URLs und Service Worker missbrauchen, um Phishing-Seiten ohne eine herkömmliche Phishing-Website bereitzustellen.

Die wichtigsten Erkenntnisse

• Forscher von Barracuda haben eine Angriffskampagne analysiert, die die herkömmliche Phishing-Website durch eine Phishing-Seite ersetzt, die mithilfe von Blob-URLs im Browser des Opfers generiert wird.
• Opfer werden über legitime Microsoft-Dienste weitergeleitet, wodurch der Angriff vertrauenswürdig erscheint und typische Warnsignale reduziert werden.
• Service Worker, Sandboxed-iFrames und Remote-Infrastruktur ermöglichen es Angreifern, das Phishing-Erlebnis dynamisch zu steuern und herkömmliche Erkennungsmethoden zu umgehen.

Die meisten Phishing-Kampagnen laufen über eine gehostete Webseite, die Sicherheitstools abrufen, analysieren, kategorisieren und letztendlich blockieren können. Eine aktuelle Kampagne, die von Barracuda-Forschern analysiert wurde, schweift von diesem Modell ab.

Anstatt eine Phishing-Seite von einem Webserver auszuliefern, wird der bösartige Inhalt mithilfe einer Blob-URL im Browser des Opfers zusammengesetzt. Dabei handelt es sich um eine temporäre, vom Browser generierte URL, die auf lokal im Speicher anstatt auf einer Website gespeicherte Inhalte verweist.

Bis die Phishing-Seite erscheint, wurde das Opfer bereits über legitime Microsoft-Dienste weitergeleitet, darunter Microsoft OAuth und Microsoft Teams, mit kaum sichtbaren Hinweisen darauf, dass etwas Bösartiges geschieht.

Was unterscheidet diesen Angriff?

Im Gegensatz zu herkömmlichen Phishing-Kampagnen, die sich auf eine gehostete nahezu identisch aussehende Website verlassen, nutzt dieser Angriff eine im Browser untergebrachte Architektur, die seine Sichtbarkeit sowohl für Nutzer als auch für Security-Tools verringern soll.

• Keine Phishing-Seite zum Blockieren. Der Phishing-Inhalt wird nie als herkömmliche Webseite bereitgestellt. Stattdessen wird er aus einer Blob-URL gerendert, die im Browser des Opfers generiert wird. Da die Seite nur innerhalb dieser Browsersitzung existiert, gibt es keine persistente Phishing-URL, die Security-Tools im Voraus abrufen, analysieren oder auf eine Blockliste setzen können.
• Vertrauenswürdige Microsoft-Dienste in der gesamten Angriffskette. Anstatt Opfer auf eine offensichtlich verdächtige Website zu leiten, leitet der Angriff sie über eine legitime Microsoft-Infrastruktur, einschließlich login.microsoftonline.com und Microsoft Teams. Da die sichtbare Navigation innerhalb vertrauenswürdiger Microsoft-Dienste verbleibt, ist es für Nutzer und automatisierte Scanner weniger wahrscheinlich, die Aktivität als bösartig zu identifizieren.
• Browserbasierte Phishing-Ausführung. Sobald die Blob-basierte Phishing-Seite geladen ist, registriert sie einen Service Worker und führt einen Teil des Workflows innerhalb eines Sandbox-Iframes aus. Zusammen helfen diese Komponenten dabei, Anfragen zu verwalten, die Navigation zu steuern und das Phishing-Erlebnis direkt aus der Browsersitzung heraus zu koordinieren.
• Dynamische Kontrolle durch den Angreifer. Die Phishing-Seite empfängt Anweisungen von der Backend-Infrastruktur über Browser-Messaging-Mechanismen. Da der Workflow dynamisch und nicht über fest codierte Weiterleitungen gesteuert wird, können Betreiber Ziele und Verhalten in Echtzeit anpassen.
• Zusätzliche Legitimität. Die E-Mail enthält eine Kalendereinladungsdatei als harmlosen Anhang. Obwohl dies nicht Teil der bösartigen Nutzlast ist, trägt es dazu bei, dass die Nachricht wie eine routinemäßige geschäftliche Kommunikation wirkt, und kann das Vertrauen der Empfänger stärken.

Angriffsablauf

1. Das Opfer erhält eine E-Mail im DocuSign-Design.

2. Im Anhang der E-Mail befindet sich eine Datei mit einer Kalendereinladung. Die E-Mail wirkt nicht bösartig, da sie auf einen legitimen Microsoft OAuth-Endpunkt verweist. Der Anhang ist vorhanden, damit die E-Mail wie eine normale geschäftliche Besprechung oder Kalendereinladung aussieht. 

3. Ein manipulierter Weiterleitungsparameter leitet den Nutzer zu Microsoft Teams weiter.

4. Microsoft Teams lädt eine externe Ressource, die auf cdn.bloom[.]io gehostet wird.

5. Der Browser konvertiert diesen Inhalt in eine Blob-URL.

6. Die Blob-URL rendert die Phishing-Seite lokal im Browser.

7. Service-Worker, Iframes und Backend-Steuerelemente verwalten den Phishing-Workflow und die Nutzernavigation.

8. Die versteckte Konfiguration für Command-and-Control zeigt, dass dies keine eigenständige Seite ist, sondern Teil einer verwalteten Phishing-Plattform, die zentral für viele Opfer gleichzeitig betrieben, aktualisiert und gesteuert werden kann.

Zusammen bieten diese Mechanismen dem Angreifer die Echtzeitkontrolle über den Phishing-Workflow innerhalb der Browsersitzung des Opfers. Dies ermöglicht ein Maß an Flexibilität und Verschleierung, das bei statischen Phishing-Seiten für gewöhnlich nicht zu beobachten ist.

Erkennung und Abwehr

Diese Kampagne zeigt, wie sich Phishing über gefälschte Websites und verdächtige Domains hinaus entwickelt und viele der Indikatoren verringert, auf die sich Security-Teams traditionell bei der Erkennung verlassen haben.

Unternehmen sollten sich auf die Identifizierung bösartigen Verhaltens und auf Identitätskontrollen konzentrieren, anstatt lediglich bekannte Phishing-URLs zu blockieren. Zu den wichtigsten Abwehrmaßnahmen gehören:

• Überwachung von OAuth-Autorisierungsabläufen und Weiterleitungsketten auf ungewöhnliche oder unerwartete Ziele.
• Überprüfung von Browseraktivitäten im Zusammenhang mit Blob-URLs, insbesondere wenn diese zum Rendern von Anmeldeseiten oder Authentifizierungs-Workflows verwendet werden.
• Erkennung verdächtiger Service-Worker-Registrierungen im Zusammenhang mit extern bezogenen Inhalten.
• Anwendung von phishingresistenten Methoden zur Multi-Faktor-Authentifizierung wie FIDO2-Sicherheitsschlüsseln und Passkeys.
• Verwendung von Kontrollen zur E-Mail-Sicherheit, die den gesamten Klickpfad analysieren, anstatt sich ausschließlich auf die ursprüngliche URL zu verlassen.
• Schulung von Nutzern, bei unerwarteten Anfragen zur Unterzeichnung von Dokumenten vorsichtig zu sein, auch wenn Links offenbar vertrauenswürdige Microsoft-Infrastruktur nutzen.

Da Angreifer Phishing-Workflows zunehmend direkt in den Browser verlagern, müssen Verteidiger verstärkt auf Identitätsschutz, Browser-Sicherheit und Verhaltenserkennung setzen. Die Herausforderung besteht nicht mehr nur darin, eine bösartige Website zu erkennen. Bei solchen Kampagnen existiert die Phishing-Seite möglicherweise nirgendwo außer im Browser des Opfers.