AiTM-Angriff und Diebstahl von MFA-Token

Der Angreifer muss keine gefälschte Seite bauen: Er richtet einen Webserver ein, der HTTP-Pakete zwischen dem Opfer und dem anvisierten Dienst in beide Richtungen weiterreicht¹. Die Seite enthält zwei getrennte TLS-Sitzungen, eine mit dem Opfer, eine mit der echten Website, sodass er aus den Anfragen Passwörter und, wichtiger noch, Sitzungscookies auslesen kann¹.

Diese Arbeit lässt sich mit Open-Source-Kits automatisieren. Microsoft nennt Evilginx2, Modlishka und Muraena¹. MITRE führt aus, dass Evilginx2 als AiTM-Relay zwischen einer legitimen Website und einer angephishten Person dienen kann, um Zugangsdaten, Authentifizierungstoken und Sitzungscookies abzugreifen⁵. Hat der Angreifer das Cookie, fügt er es in seinen eigenen Browser ein, um die Authentifizierung zu überspringen, auch wenn die MFA des Ziels aktiviert ist¹.

Am Anfang steht eine Nachricht. MITRE beschreibt die E-Mail mit präpariertem Link, die unter anderem dazu dient, Schutzmaßnahmen zu umgehen, die Anhänge prüfen⁶. In der von Microsoft untersuchten Kampagne enthielt die E-Mail einen HTML-Anhang und kündigte eine Sprachnachricht an¹. Die Seite zeigte eine Download-Leiste für die Nachricht, doch die Leiste war fest in die Datei geschrieben: Es wurde keine Audiodatei heruntergeladen¹. Anschließend wurde das Opfer auf eine Seite weitergeleitet, die seine E-Mail-Adresse vorausfüllte, was die Glaubwürdigkeit der Falle erhöhte¹.

Dann folgt die Anmeldeseite, eine Kopie des Microsoft-Portals. Nachdem die Zugangsdaten eingegeben und die Authentifizierung erfolgreich war, landete das Opfer auf der echten Seite office.com¹. Nichts deutet auf das Abfangen hin: Im Hintergrund hatte der Angreifer die Zugangsdaten bereits abgefangen und seinerseits eine Sitzung geöffnet¹.

Hier eine neutralisierte Illustration der Form einer solchen Adresse, die zeigt, dass nur die Adresse die Falle verrät:

Illustration (neutralisierte Adresse, für das Beispiel erfunden):
hxxps://login[.]exemple-portail[.]invalid/[Kennung des Opfers]
Angezeigte Seite: [Kopie des Microsoft-Anmeldeformulars]
Erwartete Adresse: [die offizielle Adresse des Dienstes, von Ihnen eingetippt oder gespeichert]

Ein Webdienst eröffnet nach der Authentifizierung eine Sitzung, um nicht auf jeder Seite erneut nach der Identität zu fragen. Diese Sitzung beruht auf einem Cookie, das der Authentifizierungsdienst ausstellt und das dem Server belegt, dass der Nutzer angemeldet ist¹. MITRE hält fest, dass solche Cookies oft lange gültig bleiben, auch wenn die Anwendung nicht aktiv genutzt wird⁷. Ein Angreifer, der eines besitzt, kann es in einen Browser importieren, den er kontrolliert, und sich bei der Anwendung anmelden².

In der Kampagne von 2022 trugen die Cookies eine MFA-Angabe: Der Angreifer nutzte sie daher, um trotz der MFA-Richtlinie der Organisation auf das Konto zuzugreifen¹. MITRE nennt außerdem einen Fall, in dem APT29 gestohlene Cookies für den Zugriff auf Cloud-Ressourcen nutzte, sowie ein gefälschtes duo-sid-Cookie, mit dem bei der Kompromittierung von SolarWinds die MFA eines E-Mail-Kontos umgangen wurde².

Auf der Abwehrseite ordnet die CISA die MFA-Formen von der stärksten zur schwächsten. Einmalcodes aus einer App sind anfällig für Phishing, ebenso SMS und Sprachanrufe³. Push-Benachrichtigungen mit Zahleneingabe widerstehen dem „Push Bombing“, aber nicht dem Phishing³. Nur FIDO/WebAuthn ist laut CISA die weithin verfügbare phishing-resistente Authentifizierung³. Das britische NCSC widmet den stärksten MFA-Methoden einen Leitfaden⁸. Microsoft empfiehlt zudem Richtlinien für bedingten Zugriff, die bei jedem Versuch, ein gestohlenes Cookie zu verwenden, ausgewertet werden (konformes Gerät, vertrauenswürdige IP-Adresse)¹.

Juli 2022: eine Kampagne gegen mehr als 10.000 Organisationen

Am 12. Juli 2022 veröffentlicht Microsoft die Analyse einer groß angelegten AiTM-Phishing-Kampagne. Sie stahl Passwörter, übernahm Sitzungen und umging die Authentifizierung auch bei aktivierter MFA. Nach Angaben von Microsoft versuchte sie seit September 2021, mehr als 10.000 Organisationen ins Visier zu nehmen¹. Die Angreifer ahmten die Online-Anmeldeseite von Office nach, mit dem Kit Evilginx2¹.

Nach dem Diebstahl: Betrug mit Überweisungen

Die Angreifer nutzten die gestohlenen Zugangsdaten und Cookies anschließend, um auf Postfächer zuzugreifen und Überweisungsbetrug (BEC) gegen andere Ziele zu starten¹. Microsoft stellte fest, dass zwischen Diebstahl und Beginn des Betrugs fünf Minuten genügen konnten¹. In den folgenden Tagen sah der Angreifer alle paar Stunden die finanzbezogenen E-Mails und Anhänge durch, suchte nach laufenden Gesprächen und löschte dann die ursprüngliche Phishing-Mail¹.

Danach legte er eine Posteingangsregel an, die Nachrichten aus der Domäne des Betrugsziels als gelesen markiert in den Ordner „Archiv“ verschob, damit der Kontoinhaber nichts bemerkte¹. Schließlich antwortete er auf Gesprächsverläufe zu Zahlungen und Rechnungen und löschte seine Antworten aus den gesendeten Elementen¹. Einmal führte er mehrere Versuche parallel aus demselben Postfach durch¹.