Die Cyberkriminellen von heute wissen, wie E-Mail-Gateways funktionieren. Sie wissen, dass diese Systeme Nachrichten-Header, den Nachrichtentext sowie Anlagen analysieren und verdächtig erscheinende Anhänge und URLs in einer Sandbox isolieren, um deren Verhalten zu beobachten.
Und weil die Angreifer all das wissen, haben sie ihre Angriffstaktiken angepasst. Während sie in der Vergangenheit schädliche Anhänge bevorzugt haben, verwenden sie jetzt zunehmend schädliche URLs. Laut dem neuesten Proofpoint-Bericht zum Faktor Mensch: Vol. 2: Phishing und URL-basierte Bedrohungen, werden URLs heute viermal häufiger in schädlichen E-Mails als in Anhängen verwendet.
Um der Erkennung durch Sicherheitskontrollen zu entgehen, verstecken Bedrohungsakteure die schädlichen Komponenten einer URL häufig hinter Authentifizierungsabfragen oder bedingter Logik. Eine Sandbox kann echtes Anwenderverhalten nicht wirklich emulieren – und ohne authentische Anwenderinteraktionen gelangt die Sandbox möglicherweise niemals bis zum schädlichen Teil des Angriffs. Gleichzeitig nutzen Bedrohungsakteure nicht nur manipulierte URLs, sondern finden auch Möglichkeiten, die E-Mail-Sicherheitsinfrastruktur vollständig zu umgehen, indem sie vertrauenswürdige Beziehungen in Collaboration-Plattformen ausnutzen.
Nachfolgend finden Sie drei von uns beobachtete reale Anwendungsfälle, bei denen Bedrohungsakteure ihre Angriffe gezielt so gestaltet haben, dass sie die bestehenden Schutzfunktionen umgehen konnten. Bei jedem Beispiel gingen sie anders vor.
Anwendungsfall 1: Ausnutzung von Verifizierungs-Links (Verbergen hinter der Authentifizierung)
In diesem ersten Anwendungsfall verwendet ein Bedrohungsakteur in seiner E-Mail einen scheinbar legitimen Link, z. B. zu einem freigegebenen Dokument auf OneDrive, zu einer Datei in Dropbox oder zu einer DocuSign-Anfrage.
Funktionsweise
Wenn die Sandbox des E-Mail-Gateways die URL analysiert, wird nur eine Authentifizierungsseite angezeigt, die Anwender zur Bestätigung ihrer Identität auffordert. Dazu sollen Anwender eine E-Mail-Adresse und/oder ein Kennwort eingeben, eine CAPTCHA-Abfrage beantworten oder auf eine andere Weise bestätigen, dass sie „ein Mensch sind“.
Die kritische Umgehungstaktik: Die ursprüngliche URL enthält keinerlei schädlichen Code.
Für das Sicherheitssystem sieht diese Seite wie eine normale Bestätigungsseite für einen legitimen File-Sharing-Dienst aus. Die Sandbox stuft die URL als sicher ein, und die E-Mail wird in den Posteingang des Empfängers zugestellt.
Erst nachdem der Anwender auf den Link geklickt und sich authentifiziert hat, gewährt der Webserver Zugriff auf die schädliche Seite. Dabei kann es sich um ein Formular zur Erfassung von Anmeldedaten, einen Malware-Download oder eine raffinierte Phishing-Website handeln. Der eigentliche Angriff erfolgt erst nach der Authentifizierungsanforderung und ist daher unsichtbar für automatische Scans, die die E-Mail bereits als sicher eingestuft haben.
Abb. 1: Beispiel für eine Ausnutzung von Verifizierungs-Links.
Die Konsequenz
Selbst wenn das Gateway die bekannte schädliche URL hinter der Authentifizierungsseite erkennen kann, wird es die Seite niemals analysieren können. Da die ursprüngliche URL tatsächlich unschädlich ist, wird das Gateway die URL für zukünftige Analysen nicht verändern und die Nachricht zustellen. Die Bedrohung zeigt sich erst, nachdem die Sicherheitsanalyse abgeschlossen ist und der Anwender überzeugt wurde, sich zu authentifizieren. Diese Technik macht legitime Sicherheitsfunktionen (Authentifizierungsseiten) zu einem effektiven Umgehungsmechanismus.
Anwendungsfall 2: Die Sandbox-Täuschung (Erkennung des Detektors)
Bei diesem raffinierten Angriff ist die Webinfrastruktur des Cyberkriminellen in der Lage zu erkennen, ob es sich bei dem Besucher einer Webseite um einen Menschen oder ein automatisiertes Sicherheitssystem handelt.
Funktionsweise
Wenn am Gateway eine E-Mail eingeht, die eine schädliche URL enthält, öffnet das Sicherheitssystem sie noch vor der Zustellung in einer Sandbox-Umgebung, um eine Verhaltensanalyse durchzuführen.
Der Webserver des Angreifers analysiert jedoch eingehende HTTP-Anfragen, um zwischen Sandboxes und echten Anwendern zu unterscheiden. Dabei können Webserver Folgendes untersuchen:
- Zeichenfolgen des Benutzeragenten: Sandboxes verwenden häufig Benutzeragenten, die sie als automatisierte Sicherheitstools identifizierbar machen.
- IP-Adressen: Dadurch erfahren die Webserver, ob eine Anfrage von bekannten IP-Adressbereichen eines Sicherheitsanbieters oder von einem Rechenzentrum stammt.
- HTTP-Header: Muster in Headern wie Referer, Accept-Language sowie in anderen Attributen ermöglichen die Unterscheidung zwischen automatisierten Tools und echten Browsern.
- JavaScript-Ausführung: Dadurch erfahren Webserver, ob der Client JavaScript vollständig ausführt. Dies ist relevant, weil einige Sandbox-Seiten ohne vollständige Skriptausführung laden können.
- Zugriffsmuster: Webserver suchen danach, ob es sich um einen direkten URL-Zugriff oder um natürliche Navigationsmuster von Such- oder E-Mail-Clients handelt.
Abb. 2: Ablauf einer Webseitenanfrage.
Wenn die Analyse auf eine Anfrage von einer Sandbox hinweist, übermittelt der Server des Angreifers eine völlig harmlose Webseite oder leitet auf sie um.
Wenn das Sicherheitssystem die URL anschließend analysiert und den Inhalt als sicher einstuft, wird die E-Mail zugestellt. Klickt jedoch ein Anwender an einem Unternehmensgerät mit üblichen Browsereigenschaften auf diesen Link, leitet der Server des Angreifers zu den eigentlichen schädlichen Inhalten um bzw. lädt eine entsprechende Webseite.
Die Konsequenz
Wenn Bedrohungsakteure serverseitige Logik verwenden, um zwischen Sicherheitsscannern und menschlichen Zielen zu unterscheiden, reicht eine statische oder einmalige URL-Analyse nicht aus. Bereits die Durchführung automatisierter Analysen kann erkannt werden – und diese Tatsache wird genutzt und führt zu einem Katz-und-Maus-Spiel, das die Verteidiger derzeit verlieren.
Anwendungsfall 3: Die Google Kalender-Backdoor (Ausnutzung vertrauenswürdiger Ökosysteme)
Dieser Angriffsvektor ist besonders heimtückisch, weil dazu noch nicht einmal eine E-Mail versendet werden muss, sodass E-Mail-Sicherheitsgateways vollständig umgangen werden.
Funktionsweise
Angreifer gehen bei dieser Taktik wie folgt vor:
- Aufklärung: Der Bedrohungsakteur stellt fest, dass das Unternehmen XYZ Google Workspace verwendet.
- Kontoerstellung: Der Angreifer erstellt ein kostenloses Gmail-Konto, z. B. badguy@gmail.com.
- Identifizierung des Ziels: Der Angreifer erhält eine Liste der E-Mail-Adressen für Mitarbeiter des Unternehmens XYZ.
- Erstellung von Terminen im Kalender: In seinem @gmail.com-Konto erstellt der Angreifer eine Kalendereinladung, die Folgendes beinhaltet:
- Die E-Mail-Adressen der Zielpersonen
- Eine in die Termindetails eingebettete Phishing-URL
- Ein schädlicher PDF-Anhang (getarnt als Unterlagen zum geplanten Termin)
5. Der entscheidende Schritt: Anstatt auf „Einladung senden“ zu klicken, speichert der Angreifer das Kalenderereignis einfach als Entwurf.
Innerhalb von Sekunden erscheint die Kalendereinladung in den Kalendern aller Zielpersonen im Unternehmen XYZ, einschließlich Phishing-URL und schädlichem Anhang. Da keine E-Mail gesendet wurde, kann das E-Mail-Sicherheitsgateway die Bedrohung gar nicht sehen und erhält keine Gelegenheit, die URL zu scannen oder den Anhang zu analysieren.
Abb. 3: Beispiel für einen Google-Kalender-Exploit.
Dieser Angriff nutzt das inhärente Vertrauensverhältnis innerhalb von Google Workspace aus. Wenn Kalendereinladungen innerhalb des Google-Ökosystems erstellt werden, werden sie direkt zwischen Konten synchronisiert, ohne dass herkömmliche E-Mail-Zustellmechanismen ausgelöst werden.
Die Sicherheitskontrollen zur Überprüfung des E-Mail-Verkehrs werden vollständig umgangen, da die Bedrohung auf der Anwendungsebene und nicht auf der E-Mail-Transportebene übertragen wird.
Anwender sehen dabei lediglich eine legitime Kalendereinladung (z. B. zu einem vierteljährlichen Geschäftsentwicklungsbericht oder zu einem Termin mit einem Auftragnehmer) mit professioneller Formatierung und angehängten Dokumenten. Da die Einladung über eine vertrauenswürdige Anwendung eingegangen ist, besteht für sie kein Grund zu der Annahme, dass eine Sicherheitsüberprüfung umgangen wurde.
Die Konsequenz
Dieser Anwendungsfall zeigt eine kritische Lücke: Wenn sich Unternehmen ausschließlich auf den Schutz durch E-Mail-Gateway verlassen, sind sie blind für Bedrohungen, die über Collaboration-Tools verbreitet werden.
Da Mitarbeiter zunehmend kollaborativ und Cloud-basiert zusammenarbeiten, passen Angreifer ihre Techniken an, um Vertrauensbeziehungen zwischen integrierten Anwendungen auszunutzen.
So können Sie sich schützen
Zum Schutz vor diesen Umgehungstaktiken müssen Sie Ihren Sicherheitsansatz grundlegend ändern. Statt Untersuchungen auf einen einzigen Punkt zu konzentrieren, benötigen Sie umfassenden und tiefgreifenden Schutz. Achten Sie dabei auf Folgendes:
1: Erweiterter E-Mail-Schutz mit kontinuierlichen Analysen
Sie benötigen ein Sicherheitssystem, das nicht nur die ursprünglichen Seiten untersucht und die kontinuierliche Überwachung sowie Analysen nach der Zustellung ermöglicht. Dazu sollten diese Funktionen gehören:
- Kontinuierliche Neubewertung von URLs auch nach der E-Mail-Zustellung
- Verhaltensanalysen, die Anomalien in Anwenderinteraktionsmustern erkennen
- Schutz zum Klickzeitpunkt, der URLs in dem Moment analysiert, in dem Anwender auf sie zugreifen, sodass URLs nicht nur beim Eintreffen der E-Mail überprüft werden
2: Nativer browserbasierter Collaboration-Schutz
Bedrohungen werden zunehmend über Collaboration-Plattformen statt per E-Mail übertragen. Daher benötigen Sie Sicherheitskontrollen, die dort ansetzen, wo Anwender mit Inhalten interagieren: im Browser. Nativer Browserschutz kann diese Funktionen umfassen:
- Echtzeit-Analysen von Weiterleitungen und mehrfach verschachtelten URLs – unabhängig davon, über welchen Kanal sie übertragen werden
- Untersuchung von Bedrohungen auf jeder Seite, die Anwender aufrufen – nicht nur auf der ersten Landing Page
- Erkennung von böswilligem Verhalten in Kalendereinladungen, freigegebenen Dokumenten und Messaging-Plattformen
3: Personenzentrierter Schutz
Keine noch so fortschrittliche Technologie kann Sensibilisierung für Sicherheit ersetzen. Daher müssen Sie Ihre Anwender zu diesen Themen schulen:
- Warum sie bei URLs misstrauisch sein sollten, wenn diese zur sofortigen Authentifizierung auffordern, v. a. wenn Anmeldedaten involviert sind
- Wie sie ungewöhnliche Kalendereinladungen von externen Parteien erkennen und melden können
- Dass Sicherheitskontrollen nicht unfehlbar sind und ihr Urteilsvermögen nach wie vor den zuverlässigsten Schutz bietet
Fazit
Die in diesem Blog-Beitrag genannten Anwendungsfälle sind nicht nur theoretisch – wir haben diese Angriffsmuster tatsächlich bereits in Unternehmensumgebungen beobachtet. Wenn Sie davon ausgehen, dass Ihr E-Mail-Gateway umfassenden Schutz bietet, riskieren Sie einen gefährlichen blinden Fleck.
Erfahren Sie, wie Proofpoint Prime Threat Protection umfassenden, mehrschichtigen Schutz vor diesen gezielten Umgehungstaktiken bietet.
