Adversary-in-the-middle (AitM) attack

Schutz vor dem “Adversary-in-the-middle (AitM) phishing attack”

Was genau ist der “AitM phishing attack“?

Phishing bildet eines der am häufigsten genutzten Methoden, mit denen AngreiferInnen initialen Zugang zu einem Unternehmen bekommen. Durch eine simpel gestaltete E-Mail an den/die BenutzerIn wird dieser/e beispielsweise dazu gebracht eine schadhafte Seite zu besuchen.

Beim AitM Phishing setzt der/die AngreiferIn einen Proxy Server zwischen seinem/r ZielbenutzerIn und der Internetseite auf, die der/die BenutzerIn besuchen möchte (z.B. die Anmeldeseite von Microsoft). Diese Art der Vorgehensweise ermöglicht es dem/der AngreiferIn, sowohl die Authentifizierungsinformationen als auch den Session Cookie abzufangen.

Quelle: Adversary-in-the-middle (AitM) attack flowchart [Microsoft https://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/]

Moderne Webseiten und Dienste starten bei der initialen Anmeldung eine „Session“. Für die Gültigkeitsdauer des daraus generierten „Session Cookie“ braucht der/die NutzerIn sich bei darauffolgenden Anmeldungen nicht mehr erneut zu authentifizieren. Beim AiTM wird genau dieses „Session Cookie“ gekapert und der/die AngreiferIn ist damit in der Lage den Authentifizierungsprozess auszuhebeln.

Das folgende Bild verdeutlicht den Diebstahl des Session Cookies, durch den Einsatz von AitM Phishing:Quelle: Adversary-in-the-middle (AitM) phishing mit EvilProxy [Microsoft https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/]

Hilft Multi-Faktor-Authentifizierung (MFA) gegen AitM phishing?

Wir wissen, dass wir durch den Einsatz von MFA, via Conditional Access (CA), eine zweite Schutz-Ebene gegen Identitätsdiebstahl haben können. Der/die NutzerIn wird bei korrekter Konfiguration beim Zugriff auf eine Applikation oder Ressource aufgefordert, sich via einen zweiten Identitätsnachweis, z.B. durch Eingabe eines neu erstellten Codes, zu authentifizieren.

Dabei hat das Unternehmen administrativ die Möglichkeit, den Zugriff entsprechend der eingehenden Signale (wie z.B. Standort, Geräte-Zustand, Gruppen-Zugehörigkeit etc.) zu kontrollieren. Das Microsoft Azure AD unterstützt dabei mehrere Methoden der Multi-Faktor-Authentifizierung, z. B. per SMS, Telefonanruf, Biometrie oder Einmalkennung. So können Sie individuelle Sicherheitsanforderungen des Unternehmens erfüllen und den Schutz Ihrer EndnutzerInnen bestmöglich sicherstellen.

Quelle: Conditional Access Overview [https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/overview]

Beim AitM wird der Session Cookie für die Anmeldung genutzt und je nachdem wie MFA eingerichtet ist, wird auch dieser durch die Verwendung von dem gestohlenen Session Cookie umgangen. Bei korrekter Konfiguration (non-phishable MFA) ist der/die BenutzerIn aber auch hier durch MFA und Conditional Access vor dem AitM phishing geschützt. Jedoch hat ein Großteil der Unternehmen den grundlegenden Schutz durch MFA noch nicht eingeführt und jene die es getan haben, nicht auf einer Stufe, die non-phishable ist.

Wie schütze ich mich nun vor AitM?

Es gibt diverse Methoden sich vor AitM mit Hilfe von Microsoft Lösungen zu schützen. Dabei ist der bestmögliche Schutz gewährleistet durch die Kombination aus Conditional Access, Compliant Devices, Microsoft Defender for Office und User Awareness. Wenn wir diesen Schutz durch die Advanced Hunting Methoden von Microsoft Defender ergänzen, um somit auch bei einem Post-Breach Szenario möglichst schnell zu reagieren, ist das Unternehmen gegen AitM Phishing optimal gewappnet.

Conditional Access, MFA & Compliant Devices:

Bei der CA – Access Control Einstellung „Require device to be marked as compliant“ prüfen wir, ob sich die Identität über ein gemanagtes und als compliant befundenes Gerät authentifiziert. Da der/die AngreiferIn sich beim AitM Phishing über eine virtuelle Proxy Session am Dienst von Microsoft anmeldet, kann dieser den compliance Status nicht abbilden. Die Conditional Access Richtlinie blockt somit die unerlaubte Anmeldung.  Kombinieren wir nun diese Funktion mit einer Multi-Faktor Aufforderung, erreichen wir die bestmögliche Sicherheit für unsere Identitäten.

Des Weiteren ist es möglich diese Conditional Access Richtlinien mit weiteren non-phishable MFA-Methoden zu vereinen. Darunter fallen beispielsweise die Verwendung von FIDO2 Security Keys und Zertifikat basiertes MFA. Beide Methoden erfordern bei der Anmeldung, ähnlich wie bei Compliant Device Geräte Status, eine zusätzliche Information/Status, welcher aktuell noch nicht durch den/die AngreiferIn nachgebildet werden kann.

Microsoft Defender for Office (MDO) & User Awareness:

Neben dem „Schutz“ vor der Anmeldung über ein gestohlenen Session Cookie sollte man sich natürlich den eigentlichen Auslöser näher ansehen. Das initiale Einfallstor beim AitM bildet der Zugriff durch einen schadhaften Link, welcher über eine Phishing-E-Mail, Teams Phishing Nachricht o.ä. zugesandt wurde. Das Ziel besteht also darin, den Erstkontakt mit dem/der AngreiferIn möglichst zu vermeiden.

Dieses Risiko können wir z.B. durch die Verwendung von MDO verringern. Die Safe-Links Funktion von MDO ermöglicht es versendete Links (in E-Mails, MS-Dokumenten, Teams) auf Gefahren zu prüfen. Kombiniert mit dem intelligenten Anti-Phishing Schutz von MDO können wir somit den Initialen Zugriff weiter absichern.

Wie wir jedoch im Laufe der vergangenen Jahre feststellen mussten, gibt es keine Security Lösung die zu 100% alle Angriffe abfängt. Aus diesem Grund empfiehlt es sich, auf die Awareness der Mitarbeitenden des Unternehmens zu setzen. Wir können mit Microsoft Attack Simulation Trainings der Mitarbeitenden auf potenzielle Formen des Phishings vorbereiten. Es reicht, wenn bereits ein/e einzige/r BenutzerIn auf eine Phishing Kampagne korrekt reagiert und das Security Team des Unternehmens über einen möglichen Breach informiert. Auf diese Weise kann bei einem Vorfall dieser früh gestoppt und der Schaden möglichst geringgehalten werden.

Fazit

Wir erkennen, dass bereits die korrekte Einführung von non-phishable MFA einen sehr guten Schutz gegen AitM bietet. Jedoch sollte man hier nicht stoppen und stattdessen sich alle Aspekte eines Angriffes ansehen. Angefangen mit dem Phishing selber, hin zur kompromittierten Identität und abgeschlossen mit einem möglichen Post-Breach Szenario. Denn nur wenn wir alle Aspekte eines Angriffes betrachten, können wir den bestmöglichen Schutz für das Unternehmen garantieren.

Tufan Avcu
Office 365 IT-Consultant

Wenn Sie Hilfe bei der Implementierung der oben vorgestellten Lösungen benötigen oder gerne ein Review der existierenden Security Einstellungen wünschen, dann können Sie sich natürlich jederzeit bei uns melden.