Du nutzt die Zwei-Faktor-Authentifizierung (MFA) und bist überzeugt, dass Deine Identitäten sicher sind. Dennoch kann es vorkommen, dass ein Nutzer angibt, seine Anmeldedaten zur Authentifizierung seien durch Phishing gestohlen worden. Das wirft die Fragen auf, wie solche Vorfälle trotz MFA auftreten können und wie sich ein Microsoft MFA-Bypass verhindern lässt.
In diesem Beitrag werden wir gemeinsam zwei Richtlinien untersuchen, die im Conditional Access zur Authentifizierung konfiguriert werden können, um zu verhindern, dass externe Angreifer MFA-Bypässe durchführen können.
So beugen wir Schwachstellen vor und Deine Benutzerkonten sind effektiver geschützt. Die Implementierung dieser Richtlinien kann unterschiedlich aufwendig sein, aber sie bietet einen wesentlichen Beitrag zur Erhöhung der Sicherheit gegen Angriffe Deiner Microsoft Entra ID-Umgebung.
Richtlinie 1: Zugriff nur von verwalteten Geräten
Um das Risiko von Multi-Faktor-Authentifizierung-Angriffen zu minimieren, beginnen wir mit der Konfiguration einer Richtlinie, die den Zugriff auf Deine Anwendungen/Apps auf verwaltete Geräte beschränkt. Diese Richtlinie stellt sicher, dass nur Geräte, die von Deinem Unternehmen kontrolliert werden und den Sicherheitsstandards entsprechen, auf sensible Ressourcen zugreifen können.
Erstellung Deiner neuen Conditional-Access-Richtlinie
Wir beginnen mit der Erstellung Deiner neuen Richtlinie zur Authentifizierung im Conditional Access.
Zur Namensgebung geb ich dir später ein paar Tipps. Zunächst konfigurieren wir die Benutzerzuweisung. Wähle -> All users
und schließen Deinen Breaking-Glass-Account aus:
Schritt 1
Schritt 2
Du hast nun die Option, unter -> Resources auf einzelne Ressourcen zu setzen. In diesem Fall wählst Du aber -> All cloud apps, um die Richtlinie auf alle Anwendungen/Apps anzuwenden.
Implementierung granularen Zugriffs durch Gerätefilterung
Microsoft 365 gibt uns auch die Option, mit einer Any-Any-Konfiguration zu arbeiten. Im nächsten Schritt definieren wir deswegen Deine Zugriffsbedingungen unter -> Conditions.
Hier findest Du verschiedene Optionen wie User risk, Sign-in risk, Device platforms Locations usw. Wir konzentrieren uns auf -> Filter for devices. Klicke auf -> Not Configurerd, wähle -> Yes und anschließend -> Exclude.
Unter Properties definieren wir zwei Filterkriterien: -> Trust type equals und -> Is compliant.
Für Trust type wählen wir -> Hybrid Azure AD joined und für Is compliant wählen wir -> True.
Um die Relevanz dieser Konfiguration zur Authentifizierung zu verdeutlichen, betrachten wir die zugrunde liegende Logik. Die Richtlinie zielt darauf ab, den Zugriff für alle Konten mit Ausnahme des dedizierten Breaking-Glass-Kontos zu steuern, die auf beliebige Anwendungen/Apps zugreifen möchten. Innerhalb der definierten Bedingungen werden sämtliche Konten und ihre zugehörigen Geräte berücksichtigt, mit einer entscheidenden Ausnahme: Geräte, die nicht über einen Trust Type auf Basis von Microsoft Entra Hybrid Join verfügen.
Da ein Hybrid Join ausschließlich für verwaltete Unternehmensgeräte realisierbar ist, wird somit der Versuch eines externen Angreifers, einen MFA-Bypass über ein nicht verwaltetes Gerät durchzuführen, effektiv unterbunden und eine mögliche Schwachstelle gar nicht erst eingebaut.
Die Konfiguration erlaubt zudem die Berücksichtigung des Konformitätsstatus von Geräten. Hierbei besteht die Option, eine UND- oder ODER-Verknüpfung zu etablieren. Die Konformität eines Geräts wird dabei durch die Integration in Microsoft Intune, dem Mobile Device Management, sichergestellt, was wiederum die Verwaltung und Bereitstellung durch das Unternehmen impliziert.
Durch die Kombination dieser beiden Kriterien – Hybrid Join und Konformität – wird eine granulare Filterung ermöglicht, die sämtliche nicht unternehmenseigenen Geräte (BYOD) ausschließt und somit Anmeldungen von nicht verwalteten Geräten effektiv blockiert.
Konfiguration Deiner Zugriffssteuerung
Nachdem die Filterbedingungen definiert sind, konfigurieren wir Deine Zugriffssteuerung.
Klicke dazu -> Grant, und wähle -> Block Access.
Wähle -> On
und natürlich -> Create , um die Richtlinie zu aktivieren.
Vor der Aktivierung empfehle ich Dir, die Auswirkungen der Richtlinie im Report-only-Modus zu validieren. Gib der Richtlinie einen aussagekräftigen Namen, z.B. Non-company devices, und speichere die Konfiguration.
Diese Richtlinie blockiert den Zugriff von Geräten, die nicht von Deinem Unternehmen verwaltet werden oder nicht konform sind. Dies dient dazu, das Risiko von MFA-Bypässen zu reduzieren, indem der Zugriff auf vertrauenswürdige Geräte beschränkt wird.
Richtlinie 2: Implementierung eines robusten zweiten Faktors zur Absicherung gegen MFA-Bypass
Die Implementierung eines zweiten Faktors zur Authentifizierung ist ein essenzieller Schritt, um die Sicherheit Deiner Systeme signifikant zu erhöhen. Jedoch ist nicht jede Methode des zweiten Faktors gleichwertig. Daher ist es von entscheidender Bedeutung, dass Du eine Lösung wählst, die gegenüber gängigen Angriffsmethoden, insbesondere Phishing, stark ist.
Lass uns gemeinsam einen Blick darauf werfen, wie wir einen derart robusten zweiten Faktor als Tool implementieren können.
Die Notwendigkeit einer fortschrittlichen 2FA
Eine zweite Richtlinie, die möglicherweise einen abweichenden Implementierungsaufwand im Vergleich zur ersten mit sich bringt, rückt die Überlegung in den Vordergrund, welchen zweiten Faktor Du verwendest.
Es geht darum, eine Methode zu wählen, die bei der Authentifizierung nicht einfach zu umgehen ist. Auch hier gehen wir gemeinsam Schritt für Schritt vor, um einen möglichen Angriff abzuwehren.
Hier wiederholst du zunächst die Schritte, die wir in der ertsen Richtlinie genommen haben:
- Wählen alle Deine Konten aus.
- Exludiere Deinen Breaking Glass Account
- Definiere die relevanten Ressourcen.
Ab dem Punkt -> Grant unterscheidet sich jedoch die Richtlinie 1 von der Richtlinie 2.
Der entscheidende Punkt ist die Wahl der Authentifizierungsstärke, um einen bestmöglichen Schutz zu gewährleisten.
Anstatt uns auf herkömmliche Multifaktor-Authentifizierung-Stärken zu verlassen, setzen wir bei -> Require Authentication Strengths nicht auf Require Multifactor Authentication STRs, sondern auf die -> Fishing-Resistant MFA.
Wir sagen also, dass de facto alle Deine Konten einen Phishing-resistenten zweiten Faktor nutzen müssen, wenn sie auf Ressourcen zugreifen wollen - mit Ausnahme Deines Breaking Glass Accounts, der in einer sauberen Administration ohnehin aus den Conditional-Access-Richtlinien herausgenommen werden sollte, um im Notfall Zugriff zu gewährleisten.
Ein Beispiel hierfür ist ein FIDO2 Security Key.
Strategische Implementierung und Anpassung Deiner neuen Richtlinie
Aktuell sind diese Richtlinie für alle Konten angewendet; ich empfehle Dir aber, die Implementierung Schritt für Schritt durchzugehen. Der zweite Faktor ist bekanntlich ein kontrovers diskutiertes Thema. Tatsächlich könnten wir auch schwächere Authentifizierungsmethoden wie SMS in Betracht ziehen, die dennoch zum Schutz geeignet sind.
Sicher stimmst Du jedoch mit mir überein, dass nicht jeder zweite Faktor gleichermaßen effektiv vor einem MFA-Bypass schützt. Wie können wir trotz 2FA also mögliche Schwachstellen verhindern? Die Fishing-Resistant MFA bietet hier einen entscheidenden Vorteil. Du solltest diese Richtlinie in Erwägung ziehen, um die Anmeldesicherheit Deiner Benutzer zu gewährleisten und mögliche Angriffe vorzubeugen.
Um eine kontrollierte Einführung ohne Probleme zu ermöglichen, bezeichne ich diese Richtlinie vorläufig als "Require FIDO MFA", auch wenn dies nicht der optimalen Namenskonvention entspricht. Wir werden die zweite Richtlinie zunächst im -> Report-Only-Modus ausführen und anschließend -> Create auswählen, um sie zu finalisieren.
Zur Erinnerung: Die erste Richtlinie im Microsoft Conditional Access, die sich auf Compliance oder Hybrid Join Devices bzw. Join Devices bezieht, und diese zweite Richtlinie, die sich auf phishing-resistente 2FA konzentriert, sind beide darauf ausgerichtet, die Anmeldesicherheit zu optimieren.
Validierung und Optimierung Deiner Sicherheitsrichtlinien
Um sicherzustellen, dass Deine Sicherheitsrichtlinien nicht nur in der Theorie, sondern auch in der Praxis gegen eine MFA-Umgehung durch Angreifer wirksam sind, ist eine gründliche Validierung unerlässlich. Hier kommen die What-If-Szenarien ins Spiel, mit denen wir verschiedene Anmeldesituationen und deren Umsetzung simulieren und analysieren können.
So stellen wir sicher, dass Deine Microsoft Umgebung optimal geschützt ist und keine unerwarteten Sicherheitslücken entstehen, um Angriffe zu veranlassen.
Einsatz von What-If-Szenarien zur Überprüfung Deiner Richtlinien
Wir haben die Richtlinien jetzt sowohl im Report-Only- als auch im On-Modus getestet. Den jeweiligen Status kannst Du hier einsehen.
Ich empfehle Dir grundsätzlich, jede neue Logik, die Du im Conditional Access aufbaust, zunächst gründlich zu prüfen. Dazu hast Du zwei Möglichkeiten: Entweder Du testest die Richtlinien mit einem kleinen Benutzerkreis, wie Deinen Testbenutzern oder Deinem eigenen Konto, oder Du nutzt die What-If-Funktion.
Schauen wir uns die What-If-Funktion genauer an.
Wir simulieren nun verschiedene Anmeldesituationen: Von welchem Land meldet sich der User an und wogegen soll er sich authentifizieren?
Weiter können wir jetzt definieren: Auf welche Anwendung/App möchte er zugreifen oder von welcher Plattform aus meldet sich der User an?
In diesem Fall habe ich ein Windows-Gerät simuliert. Der -> Device State ist hier nun als veraltet markiert. Das ist aber kein Problem, denn es gibt noch weitere Optionen, die wir auswählen können. Wir können beispielsweise einen Filter verwenden, um zu prüfen, ob der Zugang/Anmeldung in einen unserer Filter fällt. Nutzen wir hier also den Filter -> Is Compliant und setzen ihn auf -> True.
Was passiert dann?
Mit diesen Bedingungen würden in diesem What-If-Szenario unter anderem die folgenden Richtlinien in Deinem Tenant angewendet werden:
- Require FIDO MFA
- Multifactor Authentication for Partners in Windows
- Policies that will not apply
Entsprechend würden-> Require Compliant Devices und -> Block Non-Company Devices nicht angewendet werden. Wir können hier auch direkt sehen, warum eine Regel als Eingabe greifen würde oder nicht.
Analyse und Anpassung Deiner Richtlinien
Wenn ich den Filter -> Is Compliant auf -> False setze und die What-If-Funktion erneut ausführe, sehen wir, dass die Richtlinie -> Block Non-Company Devices greift, weil das Gerät nicht konform ist. Der Grund dafür ist, dass es nicht verwaltet wird.
Dies ist nur ein kurzer Überblick zum besseren Schutz im Microsoft Tenant.
Wie Du siehst, kannst Du mit Conditional Access und zwei Richtlinien plus dem What-If-Funktionen verschiedene Szenarien durchspielen und die Auswirkungen Deiner Richtlinien analysieren. So schaffst Du eine sichere Microsoft Umgebung und kannst mögliche Multi-Faktor-Authentifizierungsbypässe verhindern. Wenn Du Hilfe brauchst, schick mir gerne eine E-Mail. Ich stehe Dir gerne in Sachen Einstellung und Hinweise zur Seite und helfe Dir, Schwachstellen auszubügeln.
Entra ID: Microsoft MFA-Bypass verhindern & Identitäten absichern!: Fazit und Blog
Schau Dir doch auch die anderen Tutorials und Tipps an, die ich bereits auf meinem Blog geteilt habe. Dort findest Du auch andere Beiträge zu Microsoft Security-Relevanen Themen, u.a. zum Defender for Identity, Microsoft Intune, der Enterprise & Mobility-Suite oder dem Microsoft 365 Defender.
Ich bin stets bemüht, die aktuellsten Themen und Fragestellungen meiner Kunden zu beantworten, um Dich bei der Arbeit mit der Microsoft Cloud Security und anderen Microsoft 365 Produkten zu unterstützen.
Wenn Du Fragen hast, melde Dich sehr gerne bei mir!
