Tenant Härtung gegen Session Hijacking

Phishingangriffe sind seit vielen Jahren ein gern gewählter Angriffsweg, um in Organisationen und Unternehmen einzudringen. Lange Zeit galt das Einführen einer Multi-Faktor-Authentifizierung (MFA) als sinnvolle Schutzmaßnahme.

Zwar ist die Verwendung mehrerer Faktoren immer noch sinnvoll, jedoch haben sich die Tools und Phishingangriffe in den letzten Jahren gewandelt. Inzwischen sind viele Phishingangriffe so aufgebaut, dass sie MFA umgehen bzw. diese von den Opfern mit abgreifen. Diesen Trend hat bspw. auch proofpoint wahrgenommen. In ihrer Analyse haben sie eine Steigerung erfolgreicher Angriffe von über 100% innerhalb von sechs Monaten mit diesen neuen Techniken verzeichnet.

Was diese neuen Angriffe gemeinsam haben ist, dass sich Angreifende in die Mitte der Kommunikation zwischen Opfer und einem vom Opfer genutzten Service setzen. Dabei bilden die Angreifer:innen die Seite des Service, z.B. Office 365, nach und leiten jede Anfrage des Opfers inklusive der Logindaten an den Service weiter. Jede Antwort des Service leiten sie wiederum an das Opfer weiter. Auf diesem Wege lassen sich dann Session Cookies abgreifen und Sessions des Opfers übernehmen. Dieses Übernehmen einer Session ist auch als Session Hijacking bekannt.

Wir sehen uns in diesem Artikel an, wie diese Angriffe funktionieren und vorallem, wie sich gut gegen diese schützen lässt.

Phishing

Damit wir verstehen, wovor wir uns schützen möchten und wie welche Maßnahmen Wirkung entfalten können, wollen wir kurz über unser Setup für die Angriffe sprechen und einen beispielhaften Angriff darstellen.

Evilginx & GoPhish

Nicht nur in Security-Awareness-Schulungen, sondern auch in Redteam-Pentests mit Phishinganteilen verwenden wir gerne Evilginx für das Nachahmen von Loginseiten und GoPhish zum Managen der Phishing-Kampagnen.

Für diesen Artikel ist Evilginx der entscheidendere Part. Es handelt sich dabei um einen besonderen Reverse Proxy. Er ermöglicht also die Interaktion mit einer Webseite über eine von uns kontrollierte Domain.

Die Konfiguration erfolgt dabei über spezielle Konfigurationsdateien sogenannten Phishlets. Hier existieren für die gängigsten Dienste bereits entsprechende Phishlets und sind online verfügbar. Neben den originalen Domains sind darin unter anderem auch die Namen von Sessioncookies und Authentifizierungsabläufe hinterlegt, sodass Evilginx die Cookies und Zugangsdaten identifizieren und abspeichern kann, wenn ein Opfer sich anmeldet.

Auch wenn wir in diesem Artikel nicht im Detail auf GoPhish eingehen, sei angemerkt, dass seit Evilginx Version 3.3 gemeinsame Nutzung von GoPhish und Evilginx deutlich leichter ist. Zum Aufsetzen der beiden zusammen empfiehlt sich dieser Blogeintrag.

Exemplarischer Angriff

Wie so ein Angriff praktisch aussieht ist im Folgenden dargestellt. Sensitive Informationen in den Screenshots haben wir dabei geschwärzt.

In unserem Setup haben wir die Domain o364.de verwendet, um unseren Server damit zu tarnen. Ungründliches Hinsehen vermittelt dabei den Eindruck, es könne sich um eine gültige Microsoft Domain handeln.

Wir beginnen damit eine Phishing-E-Mail an das Opfer zu versenden. Darin enthalten ist ein Link auf den von uns kontrollierten Server.

Screenshot unserer Phishing E-Mail. Die E-Mail scheint eine Einladung zu einem Sommerfest mit zugehöriger Planungsvorbereitung zu sein. Enthalten ist ein Link zu einer vermeintlichen Abstimmung.

Klickt das Opfer auf den Link, wird es zu einer nachgestellten Login-Seite auf unserem Server geleitet.

Screenshot einer Seite, die der Microsoft-Loginseite nachempfunden ist, aber unter der Domain login.o364.de liegt. Eingetragen in der Loginmaske ist bereits eine E-Mail-Adresse.

Logt sich das Opfer hier ein, erhalten wir die Zugangsdaten in Form von E-Mail-Adresse und Passwort. Auch zu beachten ist, dass die Seite sich genauso verhält wie das Original. So ist auch der Hintergrund in der für die Organisation üblichen Farbgebung gehalten.

Screenshot der nachgebildeten Loginseite mit einem Passwortfeld, in das ein Passwort eingetragen ist.

Da unser Server im Hintergrund die Daten an Microsoft weiterleitet und probiert eine vollständige Session aufzubauen, fragt er auch nach einer Multifaktor-Authentifizierung (MFA), wenn diese benötigt wird.

Screenshot der Loginseite, die nach einem Einmalpasswort fragt. In das entsprechende Feld ist ein Code eingetragen worden.

Im Hintergrund hat unser Server eine gültige Session mit dem Microsoft Tenant aufgebaut und stellt die Inhalte auf unserer Seite dar. Hier könnten nun noch weitere Aktionen folgen. Beispielsweise könnten wir die Umfrage, welche im Text der Phishing-E-Mail erwähnt wurde, anzeigen. Somit können wir den Angriff noch weiter verschleiern.

Screenshot einer gespiegelten Inhaltsübersicht für den eingeloggten Microsoftaccount unter der Domain www.o364.de .

Auf unserem Server haben wir nun sowohl die Zugangsdaten, als auch die Session-Cookies aufzeichnet. Mit diesen Informationen können wir nun beliebige Aktionen als Nutzer auf dem Tenant durchführen.

Screenshot unserer Evilginx Übersicht. Zu sehen sind die Loginversuche mit Timestamp, E-Mail-Adresse, Passwort und weiteren Daten. Auch sind die einzelnen Sessioncookies ausgegeben worden.

Ein Beispiel für einen tatsächlich erfolgten Angriff schadhafter Akteure ist hier beschrieben.

Härtungsmaßnahmen

Es gibt verschiedene Maßnahmen, um einen Tenant gegen diese Angriffe zu härten.

FIDO2

Der technisch effektivste Weg ist die ausschließliche Verwendung von FIDO2 zur Authentifizierung. Dieses Verfahren ist nicht anfällig für die beschriebenen Angriffe, da es die Domain im Authentifizierungsprozess berücksichtigt. Im Beispiel oben würde anstatt der von uns kontrollierten Domain o364.de also die tatsächliche Domain login.microsoftonline.com benötigt werden.

Jedoch kommt FIDO2 auch mit möglichen Einschränkungen daher. FIDO2 verwendet zur Authentifizierung eine Smartcard. Somit wird für alle Nutzer:innen eine entsprechende Hardware benötigt, was initial erhöhte Kosten verursachen kann.

Insofern kann es Sinn ergeben nur besonders kritische Accounts auf FIDO2 umzustellen. Dies können z.B. Adminaccounts sein. Bei allen Accounts, die FIDO2 nutzen, sollte darauf geachtet werden, dass auch nur ausschließlich FIDO2 genutzt werden kann, da ansonsten Downgrade-Angriffe möglich sind und die FIDO2-Authentifizierung umgangen werden kann. Als Orientierung in der Konfiguration, wie sich FIDO2 forcieren lässt, empfiehlt sich dieser Microsoft Artikel. Auf den darin verwendeten Conditional Access werden wir im nächsten Abschnitt noch genauer eingehen.

Durch die Verlagerung von wissensbasierter hin zu besitzbasierter Authentifizierung in FIDO2 ist ein anderes physisches Angriffsszenario möglich. Angreifer:innen können sich durch physischen Diebstahl bei schlecht konfigurierten Smartcards einfach Zugang zum Tenant verschaffen. Um dieses Szenario zu vermeiden, sollte die Smartcard abgesichert werden, bestenfalls mit einer PIN.

Conditional Access

Wir haben bereits im letzten Abschnitt Conditional Access kurz angesprochen. Conditional Access macht im Grunde genau das, was der Name schon sagt: Der Zugriff auf Resourcen oder ein Login wird nur unter bestimmten Konditionen tatsächlich gewährt oder verweigert.

Geschieht bspw. ein Login von einem ungewohnten Ort aus bzw. ist ein rascher Ortswechsel erkennbar, kann der Loginversuch blockiert oder nur eingeschränkter Zugriff auf Resourcen erlaubt werden. Es können aber auch andere sogenannte Signale als die Geolokation der Nutzer:in verwendet werden. Zu diesen Signalen zählen u.a. auch Risikoeinschätzungen durch Heuristiken von Microsoft Defender und anderen Anwendungen, der Zustand des Endgerätes von dem aus der Login-Versuch unternommen wird oder die Anwendung auf die probiert wird zuzugreifen.

Ein Blockieren bestimmter Geolokationen bzw. von raschen Ortswechseln verhindert nicht unbedingt einen Session Hijacking-Angriff, aber kann den daraus entstehenden Schaden potentiell eingrenzen und dafür sorgen, dass der Angriff frühzeitig auffällt.

Ein spezielles Feature, das Conditional Access aktuell in der Preview-Phase anbietet, ist Token protection. Wird die Nutzung von Token protection forciert, werden die ausgestellten Tokens an das Gerät der Nutzer:in gebunden. Somit können sie in einem Session-Hijacking-Angriff nicht mehr von Angreifer:innen verwendet werden.

Seperate Accounts

Eine andere Art den möglichen Schaden durch Session Hijacking zu reduzieren ist das Absichern privilegierter Accounts, wie Admin-Accounts. Das lässt sich insbesondere durch seperate Accounts ermöglichen. Diese werden ausschließlich für privilegierte Aktionen genutzt und für alltägliche, nicht privilegierte Aktionen, wie das Lesen und Versenden von E-Mails, kommt ein anderer Account zum Einsatz.

Sofern die Nutzung der oben dargestellten Maßnahmen für alle Accounts des Tenants unpraktikabel erscheint, könnten die Maßnahmen dann womöglich für die privilegierten Accounts umgesetzt werden.

Dieser Artikel empfiehlt auch noch andere Härtungsmaßnahmen, wie den Einsatz einer Privileged Access Workstation (PAW) für die administrative Nutzung. Dies kann auch die Folgen von Session Hijacking Angriffen eindämmen. Ein solcher Angriff kann auch über die Kompromittierung von Endgeräten passieren. Haben Angreifer:innen Zugriff auf ein Endgerät, können sie auch die auf dem Gerät befindlichen Session-Cookies auslesen. Findet die Administration aber über andere Geräte statt, erhalten sie nicht direkt einen privilegierten Zugang zum Tenant.

Schulungen

Ein wenig technischer, aber gleichzeitig effektiver Ansatz ist die Schulung der Anwender:innen. Erkennen diese den Angriff, bevor sie sich auf der nachgeahmten Seite einloggen, kommt es gar nicht erst zum Session Hijacking.

Auch wenn es zu einem Angriff kommt, helfen geschulte Anwender:innnen in der Regel deutlich besser bei der Aufklärung. Dabei fällt diesen nicht nur selber schnell auf, wenn sie einen schadhaften Link angeklickt oder eine Schaddatei ausgeführt haben. Sie haben auch ein besseres Verständnis davon welche Informationen zur Aufklärung eines Vorfalles sinnvoll sein können. Generell ist es aus unserer Perspektive hilfreich die Menschen, die auf einen Angriff hereinfallen, positiv darin zu bestärken, den Angriff zu melden. Weniger hilfreich erscheint es, die Menschen abzustrafen, da die Aufklärungsrate somit deutlich sinkt und die Reaktionszeit steigt. In diesem Rahmen sei diese auch diese Podcastfolge erwähnt.

Hierfür bieten wir Security-Awarness-Schulungen an, bei denen wir u.a. zeigen, wie konkrete Angriffe gestaltet sind und erarbeiten gemeinsam mit dem Publikum, wie sich diese Angriffe erkennen und verhindern lassen, bzw. besprechen, wie bei einem erfolgreichen Angriff vorzugehen ist. Dabei nehmen wir die Perspektive der Endnutzer:innen besonders in den Fokus.

Eine technischere Perspektive nehmen wir bei den von uns angebotenen Pentests ein. Hier zeigen wir zwar primär technische Schwachstellen auf, beleuchten diese aber auch aus der Sichtweise der Anwender:innen. Auf Wunsch führen wir hier auch Social-Engineering Angriffe durch, um einen vollständigen Angriffsweg abzubilden. Dabei legen wir besonderen Wert darauf, im Nachgang des Tests transparent aufzuzeigen, wie wir vorgegangen sind, um auch hier einen Fortbildungsaspekt aufzugreifen. Bestenfalls wird ein solcher Pentest mit Social-Engineering-Elementen in eine Awareness-Kampagne integriert.

Incident Response

Neben der Schulung der Endnutzer:innen gibt es noch andere Maßnahmen, die eine Reaktion bei einem erfolgreichen Angriff begünstigen und damit den potentiellen Schaden abmindern können.

Hierzu zählt auch das Aufsetzen eines Loggings bspw. in Form eines Security Information and Event Management System (SIEM). Auf Basis dessen kann nach auffälligem Verhalten gesucht werden, um Angriffe aufzudecken, bzw. bei einem bestätigten Angriff den Schaden nachzuvollziehen und Resourcen abzuschirmen.

Ein detailliertes Vorgehen, angefangen vom Durchsuchen des SIEMs nach Anzeichen eines Angriffs bis hin zum Deaktivieren der entsprechenden Tokens, ist in diesem Microsoft-Artikel "Token theft playbook" aufgeführt.

Auch das Advanced Hunting Feature des Microsoft Defender XDR lässt sich für die Analyse in einem solchen Vorfall nutzen. Hier findet sich bspw. eine Query um Anolmalien in der Geolokation während eines Logins zu entdecken. Im verlinkten Repository finden sich auch noch einige weitere hilfreiche Abfragen.

Zum schnellen Deaktivieren kompromittierter Tokens kann es weiterhin hilfreich sein Continous access evaluation in Conditional Access zu nutzen.

Im von uns dargestellten Angriff, wurde eine Phishing-E-Mail verwendet. Dies ist kein unübliches Szenario. Einen Anhaltspunkt zum Aufarbeiten eines erfolgreichen Phishingangriffs liefert diese Checkliste. Auch hier lohnt es sich bereits im Vorfeld anzusehen, welche Daten hilfreich zur Aufklärung eines Angriffs sein können, um diese im konkreten Fall schnell zur Hand haben zu können.

Feedback

Wir hoffen, wir könnten mit diesem Eintrag einen Überblick über Härtungsmaßnahmen gegen Session Hijacking Angriffe geben. Sollten wichtige Inhalte fehlen, freuen wir uns über eine E-Mail, um diese ergänzen zu können. Ebenso verhält es sich mit Erfahrungsberichten!

Bei Interesse an einer Security-Awareness-Schulung oder einem Pentest, freuen wir uns ebenfalls über eine E-Mail. Aber auch ansonsten stehen wir als Security-Dienstleister immer gerne unterstützend zur Seite!

Blog