Phishing-Abwehr: Warum Awareness-Training nicht ausreicht (und was stattdessen hilft)

Security Awareness Training ist wertvoll. Verdächtige E-Mails erkennen, unerwartete Login-Anfragen hinterfragen, wissen wie Phishing aussieht: all das macht Angriffe schwieriger.

Aber hier ist die ehrliche Wahrheit: Mit genug Aufwand kann jeder gephisht werden. Ich führe regelmäßig simulierte Phishing-Kampagnen für Kunden durch, im Rahmen von Simulationen von Cyberangriffen, und habe dabei noch nie weniger als einige wenige Nutzer erwischt, egal wie gut das Training war.

Awareness reduziert die Angriffsfläche. Sie eliminiert sie nicht. Wenn deine gesamte Phishing-Verteidigungsstrategie darauf basiert, dass Mitarbeitende immer die richtige Entscheidung treffen, hast du eine Strategie, die auf Optimismus statt auf Sicherheit aufbaut.

Dieser Beitrag behandelt, wie moderne Phishing-Angriffe aussehen, warum die gängigste technische Maßnahme (MFA) nicht so funktioniert, wie die meisten denken, und welche Maßnahmen Angreifer wirklich stoppen, auch dann, wenn ein Benutzer einen Fehler macht.

Modernes Phishing ist nicht das, worauf Awareness-Training vorbereitet

Klassisches Phishing-Awareness bringt Menschen bei, auf Folgendes zu achten:

• Verdächtige Absenderadressen
• Dringende Sprache und Drucktaktiken
• Links zu ungewöhnlichen Domains
• Aufforderungen zur Eingabe von Zugangsdaten

Das ist nützlich. Eine CEO-Fraud-E-Mail von einer Gmail-Adresse ist leicht zu erkennen, wenn man weiß, worauf man achten muss. Aber Angreifer passen sich an, und die ausgefeilten Angriffe, die heute gegen Unternehmen eingesetzt werden, sehen ganz anders aus als die Trainingsbeispiele.

Der Proxy-Angriff: Sessions stehlen, nicht Passwörter

Die effektivste Phishing-Technik heute stiehlt nicht dein Passwort. Sie stiehlt deine authentifizierte Session.

So funktioniert es: Der Angreifer richtet eine Proxy-Website ein, die zwischen dem Opfer und der echten Login-Seite sitzt. Das Opfer kommuniziert tatsächlich mit dem echten Dienst (Microsoft 365, einem Corporate-VPN, einer Cloud-Plattform), aber jede Anfrage läuft durch den Proxy des Angreifers. Nachdem das Opfer die Authentifizierung abgeschlossen hat, erfasst der Proxy das Session-Token.

Der Angreifer hat jetzt eine gültige Session. Kein Diebstahl von Zugangsdaten, kein Brute Force. Das Session-Token funktioniert genauso wie ein vollständiger Login.

Das umgeht Passwörter und die meisten MFA-Formen vollständig. Das Opfer hat sein korrektes Passwort und seinen korrekten Einmalcode eingegeben. Der echte Server hat alles akzeptiert. Der Angreifer hat nur den Traffic mitgelesen.

Device Code Phishing: Eine legitime URL ist kein Sicherheitsmerkmal mehr

Device Code Phishing missbraucht einen legitimen Authentifizierungsfluss, der ursprünglich für Geräte entwickelt wurde, die keinen einfachen Browser-Login unterstützen (Smart-TVs, CLI-Tools und ähnliche Szenarien).

Das Opfer erhält eine Nachricht: „Bitte geh zu microsoft.com/devicelogin und gib diesen Code ein." Die URL ist echt. Die Website gehört tatsächlich Microsoft. Der Benutzer gibt den Code ein und schließt einen normalen Login ab. Was er nicht weiß: Der Angreifer hat die Device-Authentifizierungsanfrage initiiert und wartet auf der anderen Seite darauf, die Session zu erhalten.

Weil die Domain legitim ist und die Interaktion normal aussieht, umgeht dieser Angriff sowohl die User-Awareness als auch viele automatisierte E-Mail-Filter. Conditional-Access-Richtlinien, die darauf angewiesen sind, dass der Login verdächtig aussieht, versagen hier ebenfalls: der Login selbst ist legitim, er wurde nur von einem Angreifer initiiert.

Social Engineering in großem Maßstab: Der lange Betrug

Manche Angriffe investieren wochenlang in den Aufbau von Vertrauen, bevor sie irgendetwas versuchen. Pig-Butchering-Scams (ursprünglich auf persönliche Finanzen ausgerichtet) funktionieren, indem über Social Media echte Beziehungen aufgebaut werden, oft mit geklonten Accounts von echten Personen mit legitim aussehenden Follower-Zahlen und Post-Historien.

Der Angreifer überwacht, wem ein Zielaccount folgt, und erstellt ein nahezu identisches Profil. Nach tagelangem oder wochenlangem Aufbau von Vertrauen kommt der Angriff: ein Link, eine Login-Anfrage, ein Code, den man irgendwo eingeben soll. Zu diesem Zeitpunkt hat das Opfer keinen Grund misstrauisch zu sein.

Diese Sophistication macht Awareness-Training nahezu irrelevant. Der Benutzer macht alles richtig: Er kommuniziert mit jemandem, von dem er glaubt, ihn zu kennen, auf einer Plattform, der er vertraut.

Der MFA-Mythos, den du aufhören musst zu wiederholen

„MFA aktivieren, um sich gegen Phishing zu schützen."

Diese Aussage wird ständig wiederholt, auch von Leuten, die es besser wissen sollten. Für die meisten MFA-Implementierungen ist sie nicht korrekt.

MFA (Zwei-Faktor-Authentifizierung, TOTP-Codes, SMS-Codes, Push-Benachrichtigungen) schützt gegen Credential Stuffing: einen Angreifer, der dein Passwort durch ein Datenleck oder Raten erhalten hat und versucht, sich ohne persönliche Anwesenheit einzuloggen.

Es schützt nicht gegen den oben beschriebenen Proxy-Angriff. In diesem Szenario gibt das Opfer sein Passwort und seinen MFA-Code über den Proxy des Angreifers beim legitimen Dienst ein. Beide Faktoren werden korrekt angegeben. Das Session-Token, das der Server ausgibt, ist das, was gestohlen wird, und dieses Token ist bereits authentifiziert.

Was Phishing wirklich stoppt: Phishing-resistente MFA

Es gibt eine Kategorie von Authentifizierungsmethoden, die gegen diesen Angriff wirklich resistent sind: FIDO2-Hardware-Token und Passkeys.

Der Mechanismus, der sie resistent macht: Diese Methoden binden die Authentifizierung kryptografisch an die genaue Herkunftsdomain. Das FIDO2-Token oder der Passkey antwortet nur auf Authentifizierungsanfragen von der legitimen Domain. Es spielt keine Rolle, dass das Opfer den Unterschied zwischen login.microsoft.com und login.micros0ft-secure.com nicht erkennt. Die Hardware erkennt ihn und verweigert.

Der Proxy-Angriff scheitert, weil die Proxy-Site des Angreifers nicht die legitime Domain ist, und der Authentifikator die Challenge nicht abschließt.

Wenn du deinen Benutzern sagen willst, dass MFA sie gegen Phishing schützt: Stell sicher, dass es FIDO2 oder Passkeys sind. SMS-Codes, Authenticator-App-TOTP und Push-Benachrichtigungen bieten diesen Schutz nicht.

Technische Maßnahmen, die wirken, wenn Benutzer es nicht tun

Da wir festgestellt haben, dass Benutzerentscheidungen nicht die letzte Verteidigungslinie sein können, hier die technischen Maßnahmen, die Angriffe stoppen, auch nachdem Zugangsdaten oder Session-Token kompromittiert wurden.

Conditional Access: Managed Devices voraussetzen

Microsoft Entra ID (früher Azure AD) enthält Conditional Access, eine Richtlinien-Engine, die steuert, wer sich einloggen kann, von wo und unter welchen Bedingungen. Ein EntraID-Audit zeigt, ob deine Conditional-Access-Richtlinien tatsächlich diesen Schutz bieten, oder nur so aussehen, als würden sie es tun.

Die effektivste Konfiguration zum Stoppen von Credential-basierten Angriffen: Login nur von verwalteten (unternehmensregistrierten) Geräten erlauben.

Hier ist, warum das so wirkungsvoll ist: Selbst wenn ein Angreifer gültige Zugangsdaten, einen korrekten MFA-Code und ein gültiges Session-Token gestohlen hat, loggt er sich von seinem eigenen Gerät ein. Dieses Gerät ist nicht als vertrauenswürdiges Gerät in deinem Tenant registriert. Conditional Access blockiert den Login.

Damit das funktioniert:

1. Conditional Access so konfigurieren, dass für alle Authentifizierungen ein compliant oder Entra-joined Gerät erforderlich ist.
2. Die Neuregistrierung von Geräten auf internen Netzwerkzugang beschränken.

Der zweite Schritt ist entscheidend. Er bedeutet, dass ein Angreifer sein eigenes Gerät nicht einfach remote registrieren kann. Dazu müsste er bereits im internen Netzwerk sein, und wenn das der Fall ist, hat man größere Probleme, als Conditional Access lösen kann.

Weitere sinnvolle Conditional-Access-Richtlinien:

• Geografische Einschränkungen (Logins aus Ländern blockieren, in denen man nicht tätig ist)
• Risikobasierte Anmelderichtlinien (Logins mit ungewöhnlichen Mustern markieren)
• Session-Frequenzanforderungen (Re-Authentifizierung nach einem definierten Zeitraum erzwingen)

Outlooks eingebauter Report-Button

Wenn du Microsoft 365 verwendest, hast du bereits ein Phishing-Melde-Tool installiert. Die meisten Unternehmen haben es nur nicht nützlich konfiguriert.

Der „Melden"-Button in Outlook leitet verdächtige E-Mails standardmäßig zur Analyse an Microsoft weiter. Das hilft Microsoft, seine Filter zu verbessern. Es hilft deinem Security-Team nicht.

Was die meisten Admins nicht wissen: Das Ziel ist konfigurierbar. Setze die gemeldeten Nachrichten so, dass sie an ein internes Security-Postfach weitergeleitet werden, und plötzlich hat dein Blue Team Echtzeit-Einblick in das, was in Postfächern ankommt. Echte Angriffs-E-Mails, von Benutzern gemeldet, die in einer zentralen Warteschlange eintreffen.

Eine einfache Konfigurationsänderung. Die Auswirkungen können bei guter Umsetzung dramatisch sein: Unternehmen, die einen klar beschrifteten Phishing-Melde-Button mit korrekter interner Weiterleitung eingeführt haben, haben eine Verzehnfachung der Phishing-Meldungen beobachtet. Meldereibung ist der Grund, warum die meisten verdächtigen E-Mails ungemeldet bleiben. Reduziere die Reibung, und du bekommst die Daten.

Zusammengefasst: Eine mehrschichtige Verteidigung

Keine einzelne Maßnahme hier ist ein Allheilmittel. Der Wert liegt in ihrer Kombination:

Das Ziel ist, dass jede Schicht die Schwächen der anderen kompensiert. Wenn ein Benutzer auf einen Link klickt und seine Zugangsdaten auf einer Proxy-Site eingibt, sollte Conditional Access den Login vom unverwalteten Gerät des Angreifers verhindern. Wenn eine Phishing-Kampagne kursiert, sollte der Report-Button sie in die Warteschlange des Security-Teams bringen, bevor die gesamte Organisation sie gesehen hat.

Awareness-Training bleibt der richtige Ausgangspunkt. Dass Benutzer etwas Verdächtiges bemerken und nicht klicken, ist immer das beste Ergebnis. Aber Sicherheitsrichtlinien auf der Annahme aufzubauen, dass sie immer die richtige Entscheidung treffen, ist keine Strategie. Es ist ein Wunsch.

Quick-Start-Checkliste

Wenn du nicht sicher bist, wo du anfangen sollst, sind das die Maßnahmen mit dem höchsten Wert:

• MFA-Methoden prüfen: sind darunter phishing-resistente (FIDO2/Passkeys)?
• Conditional-Access-Richtlinien überprüfen: wird Device Compliance für M365-Zugriff erzwungen?
• Den Outlook-Report-Button so konfigurieren, dass er an ein internes Security-Postfach weiterleitet
• Geografische und risikobasierte Conditional-Access-Regeln hinzufügen, wenn noch nicht vorhanden
• Geräteregistrierungsrichtlinien überprüfen: können externe Geräte ohne Netzwerkzugang registriert werden?

Jede dieser Maßnahmen kann ohne neue Tools umgesetzt werden, wenn du bereits Microsoft 365 verwendest. Die Infrastruktur ist vorhanden. Sie muss nur eingeschaltet und richtig konfiguriert werden.

Wissen, wie dein Unternehmen einer echten Phishing-Kampagne standhält? Meld dich gerne.