CyberPlay

Phishing sesji i kodów urządzeń: dlaczego prawdziwa strona logowania to za mało

Phishing sesji, kodów urządzenia i zgód OAuth: poznaj różnice i reakcje. Połącz kursy CyberPlay, grę Find the Fake Login i ćwiczenia ochrony kont.

Zespół redakcyjny CyberPlay · Opublikowano · Zaktualizowano · 8 min czytania

Poradnik i ćwiczenia po polsku

Symulowana strona logowania i monit o zatwierdzenie uwierzytelniania w kursie CyberPlay dotyczącym phishingu sesji.

Powiększ obraz · Kadr z kursu wideo · interfejs w języku angielskim

Rzeczywisty kadr z kursu Nie dokańczaj logowania na tej stronie, z angielskim tekstem na ekranie. Ta fikcyjna scena logowania wprowadza ryzyko autoryzacji sesji przez trasę kontrolowaną przez atakującego.

Uwierzytelnianie wieloskładnikowe (MFA) pozostaje wartościowe, ale wykonanie dodatkowej weryfikacji logowania nie dowodzi, że całe żądanie jest bezpieczne. Phishing sesji jest wymierzony w uwierzytelnioną sesję; phishing kodów urządzeń podstępem nakłania do autoryzacji logowania rozpoczętego w innym miejscu; phishing zgód prosi o przyznanie dostępu aplikacji. Decyzja pracownika polega na zweryfikowaniu miejsca docelowego, tego, kto zainicjował żądanie, oraz tego, na co pozwoli zatwierdzenie.

Ten przewodnik wykorzystuje kursy CyberPlay, aby rozróżnić te trzy mechanizmy, a następnie łączy je z grą Find the Fake Login. To praktyczna lekcja dla osób otrzymujących linki do dokumentów, zaproszenia na spotkania i wiadomości od pomocy technicznej. Filmy wideo w kursach zawierają narrację w języku angielskim lub rumuńskim; platforma i wybrana gra obsługują wszystkie dziewięć języków witryny.

Najważniejsze wnioski

  • Prawdziwa strona dostawcy tożsamości może wyświetlać niebezpieczne żądanie urządzenia lub aplikacji.
  • Wprowadzaj kod urządzenia tylko w przypadku zatwierdzonego procesu, który został przez Ciebie zainicjowany i który możesz zweryfikować.
  • Przed wyrażeniem zgody zapoznaj się z aplikacją, wydawcą i żądanymi uprawnieniami.
  • Zgłoś, co zostało przez Ciebie zatwierdzone; sama zmiana hasła może pozostawić inne formy dostępu.

1. Ucz o zatwierdzaniu, a nie tylko o polu na hasło

Badanie firmy Microsoft z września 2026 r. dotyczące EvilTokens opisuje phishing kodów urządzeń, w którym osoba wprowadza dostarczony przez atakującego kod w prawdziwej usłudze logowania Microsoft. Legalna strona jest częścią oszustwa. We wrześniu 2026 r. FBI ostrzegało również przed phishingiem zgód OAuth, który przekierowuje cele na prawdziwy ekran uprawnień dostawcy. Są to udokumentowane wzorce ataków, a nie powody do rezygnacji z MFA.

W celach szkoleniowych poproś uczestnika o dokończenie tego zdania przed kliknięciem: „Zatwierdzam dostęp dla…”. Odpowiedź typu „dokument kazał mi to zrobić” pozostawia główne pytanie bez odpowiedzi. Przydatna lekcja sprawia, że urządzenie, aplikacja lub sesja są na tyle widoczne, by uczestnik mógł uzasadnić swoją decyzję.

Źródła tej sekcji: Demaskowanie EvilTokens: Docieranie do źródła phishingu kodów urządzeń · Złośliwi cyberprzestępcy uzyskują dostęp do kont ofiar poprzez phishing zgód

2. Porównaj trzy mechanizmy

Terminy te opisują różne sposoby uzyskiwania dostępu. Nie należy uczyć o nich jako o trzech nazwach fałszywej strony z hasłem. Najpierw użyj tego zwięzłego porównania, a następnie przeanalizuj osobny przykład dla każdego z nich. Tabela jest pomocą szkoleniową; rzeczywiste powstrzymanie zagrożenia zależy od usługi i ustaleń zespołu reagowania.

2. Porównaj trzy mechanizmy
MechanizmCzego szuka atakującyPytanie przed kontynuacją
Phishing plików cookie sesji, często poprzez atak typu adversary-in-the-middleUwierzytelniona sesja utworzona podczas przekazywanego logowania.Czy dotarłem do oczekiwanej usługi zaufaną drogą?
Phishing kodów urządzeńAutoryzacja logowania zainicjowanego przez atakującego.Czy to ja rozpocząłem to połączenie urządzenia i czy mogę zweryfikować jego kod i cel?
Phishing zgód OAuthUprawnienia dla aplikacji kontrolowanej przez atakującego.Czy wybrałem tę zatwierdzoną aplikację i czy te uprawnienia pasują do jej zadania?

Źródła tej sekcji: Odrodzenie wieloetapowej kampanii phishingowej AiTM i BEC nadużywającej SharePoint · Demaskowanie EvilTokens: Docieranie do źródła phishingu kodów urządzeń · Ochrona przed phishingiem zgód

3. Phishing sesji: dodatkowa weryfikacja może zostać przekazana dalej

W logowaniu typu adversary-in-the-middle złośliwy pośrednik przekazuje interakcję z prawdziwą usługą i przechwytuje wynikowy materiał sesji. Dochodzenie firmy Microsoft ze stycznia 2026 r. opisuje kampanię AiTM, po której nastąpiła manipulacja skrzynką pocztową i dalszy phishing. Wytyczne dotyczące naprawy wykraczają poza resetowanie hasła i obejmują unieważnienie sesji oraz kontrole pod kątem utrzymywania dostępu.

W przypadku pracownika należy przećwiczyć zaufaną nawigację. Jeśli nieoczekiwany dokument lub wiadomość wymaga logowania, zatrzymaj się i niezależnie otwórz zatwierdzoną aplikację lub zapisany portal. Potwierdź tam dany element lub zapytaj za pośrednictwem znanego kontaktu. Nie kontynuuj podejrzanego procesu tylko dlatego, że pojawił się monit MFA, i nie ignoruj niezgodności klucza dostępu lub menedżera haseł tylko po to, aby strona zadziałała.

Źródła tej sekcji: Odrodzenie wieloetapowej kampanii phishingowej AiTM i BEC nadużywającej SharePoint

4. Phishing kodów urządzeń: sprawdź, kto rozpoczął połączenie

Logowanie za pomocą kodu urządzenia ma uzasadnione zastosowania, w tym w urządzeniach z ograniczonymi możliwościami wprowadzania danych. W nadużyciu opisanym przez firmę Microsoft atakujący inicjuje żądanie i przekazuje jego kod użytkownikowi. Wprowadzenie i potwierdzenie tego kodu może autoryzować sesję atakującego bez przekazywania mu hasła. Sprawdzanie wyłącznie adresu internetowego dostawcy pomija tę różnicę.

Użyj dwóch fikcyjnych kart w dyskusji. Na jednej z nich uczestnik właśnie rozpoczął podłączanie zatwierdzonego urządzenia w sali konferencyjnej i widzi jego kod. Na drugiej kontakt na czacie podaje kod, aby „odblokować dokument”. Zapytaj, co zainicjowało każde z tych działań i które urządzenie lub aplikacja otrzyma dostęp. Niezamówiony kod nie jest hasłem do dokumentu. Anuluj i zweryfikuj żądanie za pośrednictwem pomocy technicznej; nie wprowadzaj go eksperymentalnie.

Symulowana strona logowania urządzenia prosi o zamaskowany kod i wyjaśnia, jaki dostęp do konta on przyznaje.

Powiększ obraz · Kadr z kursu wideo · interfejs w języku angielskim

  1. Prawdziwa domena to tylko jedna z weryfikacji

    Autentyczna strona dostawcy nie dowodzi, że to Ty zainicjowałeś autoryzację urządzenia.

  2. Sprawdź, skąd pochodzi kod

    Kontynuuj proces dla urządzenia tylko wtedy, gdy został on rozpoczęty przez Ciebie dla Twojej własnej, znanej aplikacji lub urządzenia.

Rzeczywisty kadr z kursu Autentyczna strona może służyć fałszywemu żądaniu, z angielskim tekstem na ekranie. Kod jest zamaskowany, a scena jest przykładem szkoleniowym.

Źródła tej sekcji: Demaskowanie EvilTokens: Docieranie do źródła phishingu kodów urządzeń

6. Wyjaśnij, co zmienia silniejsze uwierzytelnianie

Klucze dostępu i klucze zabezpieczeń FIDO2 wykorzystują poświadczenia powiązane z docelową usługą, zapewniając odporność na phishing, który przekazuje hasło lub kod przez łudząco podobną stronę. Firma Microsoft opisuje to jako uwierzytelnianie kluczem publicznym powiązanym z adresem usługi. Zachęcaj pracowników do korzystania z metody zatwierdzonej przez ich organizację i do kontaktowania się z pomocą techniczną, jeśli nieoczekiwana strona poprosi ich o obniżenie poziomu zabezpieczeń do innej metody.

Utrzymuj jasne granice lekcji: silniejsze uwierzytelnianie nie decyduje o tym, czy żądane uprawnienia aplikacji służą uzasadnionemu celowi biznesowemu. Administratorzy potrzebują również odpowiednich mechanizmów kontroli przepływu urządzeń, zgód aplikacji i sesji. Pracownicy nie powinni zmieniać tych zasad podczas ćwiczeń uświadamiających. Ich zadaniem jest rozpoznanie nierozstrzygniętego zatwierdzenia, zatrzymanie się i przekazanie przydatnych informacji osobie odpowiedzialnej.

Porównanie trzech pytań dotyczących zatwierdzania: zweryfikuj trasę dla sesji, urządzenie inicjujące dla kodu urządzenia oraz aplikację i uprawnienia dla zgody OAuth.

Powiększ obraz

Oryginalne porównanie szkoleniowe CyberPlay. Kontrole techniczne i reagowanie na incydenty zależą od usługi tożsamości w organizacji.

Źródła tej sekcji: Metody uwierzytelniania w Microsoft Entra ID: klucze dostępu (FIDO2) · Ochrona przed phishingiem zgód

7. Połącz kursy z grą Find the Fake Login

Użyj kursu Nie dokańczaj logowania na tej stronie dla phishingu sesji, Autentyczna strona może służyć fałszywemu żądaniu dla kodów urządzeń oraz Nie udzielaj dostępu aplikacji, której nie wybrałeś dla zgód. Każdy kurs zatrzymuje się na pięciu punktach kontrolnych z odpowiedziami przed wyjaśnieniem. Przeanalizuj powód stojący za odpowiedzią, zwłaszcza gdy uczestnik używa argumentu „strona była prawdziwa” jako jedynego uzasadnienia. Filmy wideo są dostępne w języku angielskim i rumuńskim, a dostęp do nich zależy od konta i planu.

Następnie otwórz grę Find the Fake Login. Jej rzeczywiste scenariusze obejmują czat z działem pomocy technicznej dostarczający kod urządzenia, nieoczekiwaną aplikację żądającą dostępu do poczty i plików oraz legalną wewnętrzną aplikację kalendarza. Porównaj przykłady złośliwych i legalnych zgód, aby uczestnik mógł przećwiczyć podejmowanie przemyślanych decyzji. Są to fikcyjne scenariusze działające wyłącznie w przeglądarce; gra nie sprawdza prawdziwego konta ani nie testuje konfiguracji tożsamości Twojej organizacji.

8. Wyjaśnij bezpieczną decyzję w nowym scenariuszu

Użyj poniższego przypadku po kursie i grze. Przeprowadź je jako ćwiczenie dyskusyjne z fikcyjnymi usługami; nie jest potrzebny żaden prawdziwy kod urządzenia, zgoda aplikacji ani konto. Poproś każdego uczestnika o zidentyfikowanie brakujących dowodów przed przeczytaniem odpowiedzi.

9. Zgłoś podjęte działanie, a następnie pozwól zespołowi reagowania ocenić jego zakres

Niezwłocznie zgłoś, jeśli ukończyłeś podejrzane logowanie, wprowadziłeś dostarczony kod urządzenia lub zatwierdziłeś nieoczekiwaną aplikację. Podaj czas, konto, wiadomość początkową i podjęte działanie. W przypadku aplikacji podaj jej wyświetlaną nazwę i uprawnienia, jeśli są już dostępne. Zachowaj wiadomość, korzystając z zatwierdzonej ścieżki raportowania; nie otwieraj ponownie żądania w celu zebrania większej liczby dowodów.

Poinformuj zespół reagowania, czy wprowadziłeś poświadczenia, zatwierdziłeś połączenie urządzenia, czy przyznałeś uprawnienia aplikacji. Te różnice wpływają na to, które sesje, tokeny, aplikacje i zmiany na koncie wymagają zbadania. Nie zakładaj, że zamknięcie przeglądarki lub zmiana hasła kończy proces przywracania. Osoba odpowiedzialna za reagowanie powinna potwierdzić odpowiednie powstrzymanie zagrożenia i dalsze działania zgodnie z procedurami usługi.

Na następną sesję ćwiczeniową zmień przynętę, ale zachowaj mechanizm zatwierdzania. Porównaj wyjaśnienia z różnych prób i zapisz nierozwiązane pytania do celów szkoleniowych. Ukończenie kursu i decyzje w grze pokazują udział i wyniki w tych ćwiczeniach; nie dowodzą one, że prawdziwe konto jest bezpieczne ani że przyszły phishing się nie powiedzie.

Źródła tej sekcji: Odrodzenie wieloetapowej kampanii phishingowej AiTM i BEC nadużywającej SharePoint · Złośliwi cyberprzestępcy uzyskują dostęp do kont ofiar poprzez phishing zgód

Przećwicz zatwierdzanie dostępu do kont

Użyj gry Find the Fake Login, aby zbadać żądanie kodu urządzenia i porównać uprawnienia legalnych i złośliwych aplikacji po ukończeniu kursów.

Zagraj w Find the Fake Login

Źródła i dalsza lektura

  1. Demaskowanie EvilTokens: Docieranie do źródła phishingu kodów urządzeń — Microsoft Security. Dostęp 2026-10-03
  2. Odrodzenie wieloetapowej kampanii phishingowej AiTM i BEC nadużywającej SharePoint — Microsoft Security. Dostęp 2026-10-03
  3. Metody uwierzytelniania w Microsoft Entra ID: klucze dostępu (FIDO2) — Microsoft Learn. Dostęp 2026-10-03

Czytaj dalej

Wszystkie artykuły

Kontakt · O nas