Phishing Microsoft 365. Krótki przewodnik po kampanii z użyciem Railway

Phishing Microsoft 365. Krótki przewodnik po kampanii z użyciem Railway

2026-03-31

TL;DR

Phishing związany z Microsoft 365 coraz częściej nie polega już na prostym wyłudzeniu hasła. W opisywanej kampanii użytkownik trafia do prawdziwego procesu logowania Microsoft, ale w praktyce zatwierdza sesję przygotowaną przez napastnika. To kolejny dowód, że phishing jest codziennością i firmy muszą ćwiczyć nie tylko rozpoznanie wiadomości, ale też zgłaszanie oraz szybką reakcję.

Na czym polega ten scenariusz oparty o Microsoft 365 i platformę Railway

To nie jest atak na kolej ani branżę transportową. Railway to nazwa platformy chmurowej, którą napastnicy wykorzystali jako zaplecze kampanii wymierzonej w konta Microsoft 365. W tym modelu ofiara nie zawsze widzi oczywistą fałszywą stronę. Często przechodzi przez legalny mechanizm logowania Microsoft i właśnie dlatego atak może wydawać się bezpieczny.

Jeżeli chcesz uporządkować podstawy tego typu oszustw, zobacz też co to jest phishing. W praktyce sednem ataku nadal jest socjotechnika, tylko podana w bardziej wiarygodnej i nowocześniejszej formie.

Jak wyglądała kampania wykorzystująca platformę Railway

Badacze opisali kampanię, w której pojawiały się różne przynęty, między innymi tematy dokumentów, ofert, powiadomień głosowych czy podszycia pod DocuSign. Użytkownik trafiał na stronę z instrukcją, a potem był kierowany do prawdziwego logowania Microsoft, gdzie wpisywał kod lub zatwierdzał proces uruchomiony przez napastnika. Szczegóły kampanii opisał Huntress.

To pokazuje, że phishing nie musi wyglądać jak mail z błędami językowymi. Może korzystać z legalnych usług chmurowych, wiarygodnych ekranów logowania i znanych marek. Microsoft już wcześniej opisywał podobne działania w kampaniach typu device code phishing.

Dlaczego prawdziwa strona logowania nie zawsze oznacza bezpieczeństwo

W tym scenariuszu użytkownik może myśleć, że wszystko jest w porządku, bo widzi prawdziwy ekran Microsoft. Problem polega na tym, że zatwierdza sesję wygenerowaną wcześniej przez przestępcę. Efektem może być przejęcie tokenów sesji, a więc dostępu, który nie znika automatycznie tylko dlatego, że ktoś później zmieni hasło.

To właśnie dlatego samo MFA nie zamyka tematu. Podobny mechanizm szerzej opisano też we wpisie o phishingu omijającym MFA typu AiTM.

Jak rozpoznać, zgłosić i ograniczyć ryzyko

Najważniejsze sygnały ostrzegawcze: presja czasu, nieoczekiwana prośba o wykonanie logowania, konieczność wpisania kodu poza zwykłym rytmem pracy albo komunikat, który nie pasuje do tego, co właśnie robisz. Jeżeli coś takiego pojawia się nagle, nie działaj automatycznie.

Warto ćwiczyć nawyki. Po pierwsze rozpoznanie, czyli umiejętność zatrzymania się przed kliknięciem albo zatwierdzeniem dostępu. Po drugie zgłoszenie, czyli szybkie przekazanie incydentu do IT lub Security razem z kontekstem wiadomości, linku albo ekranu. Po trzecie reakcję, czyli odcięcie sesji, sprawdzenie logów, wylogowanie aktywnych połączeń i ocenę, czy nie doszło już do przejęcia konta.

Jeżeli chcesz sprawdzić, czy Twoi ludzie rozpoznają podobne sygnały ostrzegawcze w praktyce, zobacz też nasz krótki quiz phishingowy. Właśnie takie codzienne ćwiczenia budują odporność organizacji dużo skuteczniej niż jednorazowe przypomnienie zasad.

Najczęstsze pytania

Czy prawdziwa strona logowania Microsoft oznacza bezpieczeństwo?

Nie zawsze. W tym scenariuszu użytkownik może przejść przez prawdziwy ekran Microsoft i mimo to potwierdzić dostęp przygotowany przez napastnika.

Czy MFA wystarczy, żeby zatrzymać taki atak?

Nie w każdym przypadku. Jeżeli użytkownik sam zatwierdzi cudzą sesję, napastnik może uzyskać ważne tokeny dostępu mimo dodatkowego kroku logowania.

Co powinien zrobić pracownik po podejrzanym logowaniu?

Przerwać działanie, niczego dalej nie zatwierdzać, zgłosić incydent do IT lub Security i przekazać, z jakiej wiadomości albo strony wszystko się zaczęło.

Co firma powinna robić poza samym wdrożeniem MFA?

Regularnie szkolić pracowników, ćwiczyć zgłaszanie incydentów, analizować logi logowania i ograniczać ryzykowne mechanizmy uwierzytelniania tam, gdzie nie są potrzebne.

Źródła

  1. Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack InfrastructureGłówne źródło opisu kampanii, infrastruktury Railway i przejęcia tokenów
  2. Storm-2372 conducts device code phishing campaignKontekst techniki device code phishing i potwierdzenie schematu przez Microsoft
  3. Block authentication flows with Conditional Access policyPraktyczne zalecenia dla IT i Security dotyczące blokowania device code flow