CyberPlay

Sitzungs- und Gerätecode-Phishing: Zugriffe sicher prüfen

Unterscheiden Sie Sitzungsdiebstahl, Gerätecode-Phishing und OAuth-Zustimmung. Üben Sie sichere Entscheidungen mit CyberPlay-Kursen und Find the Fake Login.

CyberPlay-Redaktionsteam · Veröffentlicht am · Aktualisiert am · 9 Min. Lesezeit

Leitfaden und Übungen auf Deutsch

Eine inszenierte Anmeldeseite und eine Eingabeaufforderung zur Authentifizierungsgenehmigung im Sitzungs-Phishing-Kurs von CyberPlay.

Bild vergrößern · Standbild aus dem Videokurs · englische Oberfläche

Tatsächliches Bild aus „Schließen Sie die Anmeldung nicht dort ab“ mit englischem Bildschirmtext. Diese fiktive Anmeldeszene stellt das Risiko vor, eine Sitzung über eine vom Angreifer kontrollierte Route zu autorisieren.

MFA bleibt wertvoll, aber der Abschluss einer zusätzlichen Anmeldeprüfung beweist nicht, dass die zugrunde liegende Anfrage sicher ist. Sitzungs-Phishing zielt auf eine authentifizierte Sitzung ab; Gerätecode-Phishing verleitet Sie dazu, eine andernorts gestartete Anmeldung zu autorisieren; Zustimmungs-Phishing fordert Sie auf, einer Anwendung Zugriff zu gewähren. Die Entscheidung des Mitarbeiters besteht darin, das Ziel zu überprüfen, wer die Anfrage gestartet hat und was die Genehmigung zulässt.

Dieser Leitfaden nutzt CyberPlay-Kurse, um diese drei Mechanismen zu trennen, und verknüpft sie dann mit Find the Fake Login. Es ist eine praktische Lektion für Personen, die Dokumentenlinks, Besprechungseinladungen und Support-Nachrichten erhalten. Die Kursvideos werden auf Englisch oder Rumänisch vertont; die Plattform und das ausgewählte Spiel unterstützen alle neun Website-Sprachen.

Das Wichtigste zum Mitnehmen

  • Eine echte Seite eines Identitätsanbieters kann eine unsichere Geräte- oder Anwendungsanfrage anzeigen.
  • Geben Sie einen Gerätecode nur für einen genehmigten Ablauf ein, den Sie initiiert haben und überprüfen können.
  • Lesen Sie die Anwendung, den Herausgeber und die angeforderten Berechtigungen, bevor Sie Ihre Zustimmung erteilen.
  • Melden Sie, was Sie genehmigt haben; eine bloße Passwortänderung kann andere Zugriffe bestehen lassen.

1. Lehren Sie die Genehmigung, nicht nur das Passwortfeld

Die EvilTokens-Forschung von Microsoft aus dem September 2026 beschreibt Gerätecode-Phishing, bei dem eine Person einen vom Angreifer bereitgestellten Code beim echten Anmeldedienst von Microsoft eingibt. Die legitime Seite ist Teil der Täuschung. Im September 2026 warnte das FBI auch vor OAuth-Zustimmungs-Phishing, das Zielpersonen auf einen echten Berechtigungsbildschirm des Anbieters umleitet. Dies sind dokumentierte Angriffsmuster, keine Gründe, auf MFA zu verzichten.

Bitten Sie den Lernenden zu Schulungszwecken, diesen Satz vor dem Klicken zu beenden: „Ich genehmige den Zugriff für…“. Eine Antwort wie „das Dokument hat mich dazu aufgefordert“ lässt die zentrale Frage ungelöst. Eine nützliche Lektion macht das Gerät, die Anwendung oder die Sitzung sichtbar genug, damit der Lernende die Entscheidung erklären kann.

Quellen dieses Abschnitts: EvilTokens demaskieren: Dem Gerätecode-Phishing auf den Grund gehen · Bösartige Cyber-Akteure erlangen durch Zustimmungs-Phishing Zugriff auf Opferkonten

2. Vergleichen Sie die drei Mechanismen

Die Begriffe beschreiben unterschiedliche Wege, um Zugriff zu erhalten. Lehren Sie diese nicht als drei Namen für eine gefälschte Passwortseite. Verwenden Sie zuerst diesen kompakten Vergleich und arbeiten Sie dann ein separates Beispiel für jeden durch. Die Tabelle ist ein Schulungshilfsmittel; die tatsächliche Eindämmung hängt vom Dienst und den Erkenntnissen des Reaktionsteams ab.

2. Vergleichen Sie die drei Mechanismen
MechanismusWas der Angreifer suchtFrage vor dem Fortfahren
Sitzungscookie-Phishing, oft durch einen Angreifer in der Mitte (Adversary-in-the-Middle)Die authentifizierte Sitzung, die während einer weitergeleiteten Anmeldung erstellt wurde.Habe ich den erwarteten Dienst über eine vertrauenswürdige Route erreicht?
Gerätecode-PhishingAutorisierung für eine Anmeldung, die der Angreifer initiiert hat.Habe ich diese Geräteverbindung gestartet, und kann ich ihren Code und Zweck überprüfen?
OAuth-Zustimmungs-PhishingBerechtigungen für eine vom Angreifer kontrollierte Anwendung.Habe ich diese genehmigte App ausgewählt, und passen diese Berechtigungen zu ihrer Aufgabe?

Quellen dieses Abschnitts: Wiederaufleben einer mehrstufigen AiTM-Phishing- und BEC-Kampagne, die SharePoint missbraucht · EvilTokens demaskieren: Dem Gerätecode-Phishing auf den Grund gehen · Schutz vor Zustimmungs-Phishing

3. Sitzungs-Phishing: Die zusätzliche Prüfung kann weitergeleitet werden

Bei einer Adversary-in-the-Middle-Anmeldung leitet ein bösartiger Vermittler die Interaktion mit dem echten Dienst weiter und erfasst das resultierende Sitzungsdaten. Eine Microsoft-Untersuchung vom Januar 2026 beschreibt eine AiTM-Kampagne, gefolgt von Postfachmanipulation und weiterem Phishing. Die Leitlinien zur Behebung gehen über das Zurücksetzen eines Passworts hinaus und umfassen den Widerruf von Sitzungen sowie Prüfungen auf Persistenz.

Üben Sie mit dem Mitarbeiter die vertrauenswürdige Navigation. Wenn ein unerwartetes Dokument oder eine Nachricht eine Anmeldung erfordert, halten Sie inne und öffnen Sie die genehmigte Anwendung oder das gespeicherte Portal unabhängig davon. Bestätigen Sie das Element dort oder fragen Sie über einen bekannten Kontakt nach. Führen Sie einen verdächtigen Ablauf nicht weiter aus, nur weil eine MFA-Eingabeaufforderung erschienen ist, und setzen Sie eine Nichtübereinstimmung bei Passkeys oder Passwort-Managern nicht außer Kraft, nur damit die Seite funktioniert.

Quellen dieses Abschnitts: Wiederaufleben einer mehrstufigen AiTM-Phishing- und BEC-Kampagne, die SharePoint missbraucht

4. Gerätecode-Phishing: Prüfen Sie, wer die Verbindung gestartet hat

Die Anmeldung per Gerätecode hat legitime Verwendungszwecke, einschließlich Geräten mit begrenzten Eingabemöglichkeiten. In dem von Microsoft beschriebenen missbräuchlichen Ablauf startet der Angreifer die Anfrage und gibt deren Code an die Zielperson weiter. Die Eingabe und Bestätigung dieses Codes kann die Sitzung des Angreifers autorisieren, ohne ihm das Passwort zu übergeben. Wenn man nur die Webadresse des Anbieters überprüft, übersieht man diesen Unterschied.

Verwenden Sie in einer Diskussion zwei fiktive Karten. Auf der einen hat ein Lernender gerade damit begonnen, ein genehmigtes Besprechungsraumgerät zu verbinden, und kann dessen Code sehen. Auf der anderen stellt ein Chat-Kontakt einen Code zur Verfügung, um „ein Dokument zu entsperren“. Fragen Sie, was jede Aktion initiiert hat und welches Gerät oder welche Anwendung Zugriff erhält. Ein unaufgefordert erhaltener Code ist kein Dokumentenpasswort. Brechen Sie ab und überprüfen Sie die Anfrage über den Support; geben Sie ihn nicht versuchsweise ein.

Eine inszenierte Geräte-Anmeldeseite fragt nach einem maskierten Code und erklärt den Kontozugriff, den sie gewährt.

Bild vergrößern · Standbild aus dem Videokurs · englische Oberfläche

  1. Eine echte Domain ist nur eine Prüfung

    Die echte Seite des Anbieters beweist nicht, dass Sie die Geräteautorisierung initiiert haben.

  2. Prüfen Sie, woher der Code stammt

    Fahren Sie nur mit einem Geräteablauf fort, den Sie für Ihre eigene bekannte App oder Ihr eigenes Gerät gestartet haben.

Tatsächliches Bild aus „Eine echte Seite kann dennoch die falsche Anfrage sein“ mit englischem Bildschirmtext. Der Code ist maskiert und die Szene ist ein Lehrbeispiel.

Quellen dieses Abschnitts: EvilTokens demaskieren: Dem Gerätecode-Phishing auf den Grund gehen

6. Erklären Sie, was eine stärkere Authentifizierung ändert

Passkeys und FIDO2-Sicherheitsschlüssel verwenden Anmeldeinformationen, die an den beabsichtigten Dienst gebunden sind, und bieten Widerstand gegen Phishing, das ein Passwort oder einen Code über eine ähnlich aussehende Website weiterleitet. Microsoft beschreibt dies als an die Web-Origin gebundene Authentifizierung mit öffentlichen Schlüsseln. Ermutigen Sie Mitarbeiter, die von ihrer Organisation genehmigte Methode zu verwenden und den Support zu kontaktieren, wenn eine unerwartete Seite sie auffordert, auf eine andere Methode herabzustufen.

Halten Sie die Grenzen der Lektion klar: Eine stärkere Authentifizierung entscheidet nicht darüber, ob eine angeforderte App-Berechtigung einem legitimen Geschäftszweck dient. Administratoren benötigen außerdem geeignete Kontrollen für Geräteabläufe, Anwendungszustimmungen und Sitzungen. Mitarbeiter sollten diese Richtlinien während einer Awareness-Übung nicht ändern. Ihre Aufgabe ist es, die ungeklärte Zugriffsanfrage zu erkennen, innezuhalten und der verantwortlichen Person nützliche Informationen bereitzustellen.

Vergleich von drei Genehmigungsfragen: Überprüfen Sie die Route für eine Sitzung, das initiierende Gerät für einen Gerätecode sowie die App und die Berechtigungen für die OAuth-Zustimmung.

Bild vergrößern

Originaler CyberPlay-Lehrvergleich. Technische Kontrollen und die Reaktion auf Vorfälle hängen vom Identitätsdienst der Organisation ab.

Quellen dieses Abschnitts: Authentifizierungsmethoden in Microsoft Entra ID: Passkeys (FIDO2) · Schutz vor Zustimmungs-Phishing

7. Verknüpfen Sie die Kurse mit Find the Fake Login

Verwenden Sie „Schließen Sie die Anmeldung nicht dort ab“ für Sitzungs-Phishing, „Eine echte Seite kann dennoch die falsche Anfrage sein“ für Gerätecodes und „Lassen Sie keine App zu, die Sie nicht ausgewählt haben“ für Zustimmungen. Jeder Kurs pausiert an fünf Antwort-Checkpoints vor der Erklärung. Überprüfen Sie den Grund für eine Antwort, insbesondere wenn ein Lernender „die Seite war echt“ als einzige Rechtfertigung verwendet. Videos sind auf Englisch und Rumänisch verfügbar, wobei der Zugriff durch das Konto und den Tarif geregelt wird.

Öffnen Sie dann Find the Fake Login. Zu den tatsächlichen Szenarien gehören ein Helpdesk-Chat, der einen Gerätecode bereitstellt, eine unerwartete Anwendung, die E-Mail- und Dateizugriff anfordert, und eine legitime interne Kalenderanwendung. Vergleichen Sie die bösartigen und legitimen Zustimmungsbeispiele, damit der Lernende eine wohlüberlegte Entscheidung übt. Dies sind fiktive, reine Browser-Szenarien; das Spiel inspiziert kein echtes Konto und testet nicht die Identitätskonfiguration Ihrer Organisation.

8. Erklären Sie die sichere Entscheidung in einem neuen Szenario

Verwenden Sie den unten stehenden Fall nach dem Kurs und dem Spiel. Halten Sie es als Tabletop-Diskussion mit fiktiven Diensten; es wird kein echter Gerätecode, keine Anwendungszustimmung und kein Konto benötigt. Bitten Sie jeden Lernenden, die fehlenden Beweise zu identifizieren, bevor Sie die Antwort lesen.

9. Melden Sie Ihre Aktion und lassen Sie das Reaktionsteam den Umfang prüfen

Melden Sie umgehend, wenn Sie eine verdächtige Anmeldung abgeschlossen, einen bereitgestellten Gerätecode eingegeben oder eine unerwartete App genehmigt haben. Geben Sie die Uhrzeit, das Konto, die Startnachricht und die von Ihnen ergriffene Maßnahme an. Fügen Sie bei einer App den angezeigten Namen und die Berechtigungen hinzu, falls diese bereits verfügbar sind. Bewahren Sie die Nachricht über den genehmigten Meldeweg auf; öffnen Sie die Anfrage nicht erneut, um weitere Beweise zu sammeln.

Teilen Sie dem zuständigen Reaktionsteam mit, ob Sie Anmeldeinformationen eingegeben, eine Geräteverbindung genehmigt oder Anwendungsberechtigungen erteilt haben. Diese Unterschiede wirken sich darauf aus, welche Sitzungen, Token, Apps und Kontoänderungen untersucht werden müssen. Gehen Sie nicht davon aus, dass das Schließen des Browsers oder das Ändern des Passworts die Wiederherstellung abschließt. Der Verantwortliche für die Reaktion sollte die entsprechende Eindämmung und Nachverfolgung gemäß den Verfahren des Dienstes bestätigen.

Ändern Sie für die nächste Übungssitzung den Köder, behalten Sie aber den Genehmigungsmechanismus bei. Vergleichen Sie die Erklärungen über die Versuche hinweg und notieren Sie ungelöste Fragen für das Coaching. Der Kursabschluss und die Spielentscheidungen zeigen die Teilnahme und Leistung in diesen Übungen; sie beweisen nicht, dass ein echtes Konto sicher ist oder dass zukünftiges Phishing fehlschlagen wird.

Quellen dieses Abschnitts: Wiederaufleben einer mehrstufigen AiTM-Phishing- und BEC-Kampagne, die SharePoint missbraucht · Bösartige Cyber-Akteure erlangen durch Zustimmungs-Phishing Zugriff auf Opferkonten

Freigaben für den Kontozugriff üben

Verwenden Sie Find the Fake Login, um eine Gerätecode-Anfrage zu untersuchen und legitime und bösartige App-Berechtigungen nach den Kursen zu vergleichen.

Spielen Sie Find the Fake Login

Quellen und weiterführende Informationen

  1. EvilTokens demaskieren: Dem Gerätecode-Phishing auf den Grund gehen — Microsoft Security. Abgerufen am 2026-10-03
  2. Wiederaufleben einer mehrstufigen AiTM-Phishing- und BEC-Kampagne, die SharePoint missbraucht — Microsoft Security. Abgerufen am 2026-10-03
  3. Authentifizierungsmethoden in Microsoft Entra ID: Passkeys (FIDO2) — Microsoft Learn. Abgerufen am 2026-10-03

Weitere Artikel entdecken

Alle Artikel

Kontakt · Über uns