CodeStorm i phishing z przejętych kont M365

TL;DR

CodeStorm pokazuje, że phishing w Microsoft 365 nie musi zaczynać się od fałszywej domeny i anonimowego nadawcy. Według analizy Hexastrike atakujący używają przejętych kont i tenantów Microsoft 365 do skalowania kampanii, wysyłania wiadomości z zaufanych tożsamości oraz dalszego przejmowania kont.

To ważny temat dla firm, bo zaufanie do nadawcy przestaje być prostym kryterium bezpieczeństwa. Wiadomość może pochodzić z realnej skrzynki kontrahenta, pracownika albo partnera, przejść część kontroli SPF, DKIM i DMARC, a mimo to prowadzić do strony przechwytującej logowanie, MFA i sesję.

Jak działa CodeStorm

Hexastrike opisuje CodeStorm jako wcześniej nieudokumentowany kit phishingowy typu adversary-in-the-middle, czyli AiTM. W takim ataku użytkownik trafia na stronę pośredniczącą między nim a prawdziwym logowaniem. Celem jest nie tylko hasło, ale też przechwycenie MFA, tokenów i materiału sesyjnego.

Według raportu CodeStorm korzysta z dużej infrastruktury: setek domen, tysięcy subdomen, mechanizmów antyanalizy, bramek Cloudflare Turnstile, hostowania elementów w usługach chmurowych oraz dostosowania przynęt do konkretnych marek i organizacji. Najważniejszy element dla programu awareness jest jednak prostszy: kampania może być wspierana przez przejęte konta Microsoft 365.

Jeżeli atakujący ma dostęp do prawdziwej skrzynki, może wysyłać wiadomości z nadawcy, którego odbiorca zna. Może też wykorzystać historię komunikacji, podpis, styl korespondencji, nazwę firmy i realne relacje. Wtedy użytkownik nie widzi obcego phishingu. Widzi kontynuację znanego procesu.

Dlaczego to omija intuicję użytkownika

Wielu pracowników uczy się, że trzeba sprawdzić nadawcę. To nadal dobra praktyka, ale niewystarczająca. W przypadku przejętego konta nadawca może być prawdziwy. Problem nie leży w samej nazwie skrzynki, tylko w tym, że ktoś inny przejął kontrolę nad kanałem.

To dlatego artykuł o tym, czym jest phishing, powinien być uzupełniany o scenariusze przejętych kont i sesji. Użytkownik musi wiedzieć, że zaufany nadawca zmniejsza ryzyko, ale go nie zeruje.

Praktyczny moment decyzji pojawia się później: czy wiadomość prosi o nietypowe logowanie, otwarcie załącznika, zeskanowanie kodu QR, przejście do SharePoint, pobranie pliku, podanie kodu MFA albo wykonanie pilnej czynności poza normalnym procesem.

Polski i firmowy kontekst

W polskiej firmie taki scenariusz może zacząć się od przejętej skrzynki dostawcy, kancelarii, biura rachunkowego, operatora logistycznego, klienta albo pracownika działu finansów. Wiadomość może dotyczyć faktury, potwierdzenia płatności, aneksu do umowy, dokumentu HR, awarii skrzynki albo nowego linku do pliku w Microsoft 365.

Atak może też przejść przez usługi, które pracownicy uznają za codzienne: Outlook, Teams, SharePoint, OneDrive, Entra ID i firmowy portal logowania. To łączy CodeStorm z innymi scenariuszami opisywanymi na PHISHLY, takimi jak phishing kodem urządzenia w Microsoft 365 czy phishing OAuth w Microsoft Entra ID.

Najważniejszy wniosek: jeśli organizacja korzysta z Microsoft 365, przejęcie jednej skrzynki nie jest problemem tylko tej jednej osoby. To może być infrastruktura do kolejnego ataku na kontrahentów, klientów i pracowników.

Co powinien zrobić użytkownik

Użytkownik powinien traktować nietypową prośbę od znanego nadawcy tak samo poważnie jak wiadomość od obcej osoby. Jeżeli znany kontakt nagle wysyła link do logowania, nowy dokument, pilne polecenie, kod QR albo prośbę o zmianę procesu, trzeba potwierdzić sprawę innym kanałem.

Nie należy odpowiadać wyłącznie w tym samym wątku, bo przejęta skrzynka może nadal być kontrolowana przez atakującego. Lepszy jest telefon na znany numer, komunikat przez wcześniej ustalony kanał albo kontakt z osobą odpowiedzialną za relację z danym kontrahentem.

Jeżeli wiadomość wymaga logowania do Microsoft 365, użytkownik powinien wejść do usługi znanym adresem albo przez firmowy portal aplikacji. Link z wiadomości nie powinien być pierwszym miejscem, w którym podaje się hasło, kod MFA lub zatwierdza sesję.

Co powinny zrobić IT, Security i SOC

Zespół bezpieczeństwa powinien zakładać, że przejęte konto może wysyłać kolejne phishingi. Microsoft opisuje reakcję na przejęte konto pocztowe jako proces obejmujący m.in. blokadę konta, reset hasła, odwołanie sesji, przegląd MFA, zgód aplikacji, ról administracyjnych oraz reguł przekierowania poczty.

W praktyce SOC powinien sprawdzać nowe reguły inbox, forwardery, nietypowe logowania, logowania z nowych lokalizacji, aktywność w SharePoint i OneDrive, masową wysyłkę, wiadomości wysłane do kontaktów zewnętrznych oraz nowe zgody OAuth. Sam reset hasła może nie wystarczyć, jeśli atakujący ma aktywną sesję albo dodał trwały mechanizm dostępu.

Warto też prowadzić ćwiczenia po kliknięciu. Testy phishingowe dla firm powinny mierzyć nie tylko kliknięcie, ale też zgłoszenie wiadomości od znanego nadawcy, reakcję po wpisaniu danych i gotowość organizacji do szybkiego unieważnienia sesji.

Co zrobić, jeśli to już się stało

Jeżeli użytkownik kliknął link i podał dane Microsoft 365, trzeba natychmiast zgłosić incydent. Organizacja powinna zmienić hasło, unieważnić sesje, sprawdzić metody MFA, przejrzeć zgody aplikacji, nowe urządzenia, forwardery, reguły skrzynki i nietypową aktywność w poczcie oraz plikach.

Jeżeli konto wysyłało dalej phishing, trzeba ustalić listę odbiorców, wysłać ostrzeżenie, zablokować linki i sprawdzić, czy inni użytkownicy nie wykonali kolejnych działań. W przypadku wiadomości do kontrahentów należy powiadomić ich właściwym kanałem, a nie tym samym wątkiem, który mógł zostać przejęty.

Jeżeli użytkownik zatwierdził MFA albo sesję, trzeba założyć ryzyko przejęcia tokenu. Wtedy priorytetem jest odwołanie sesji i analiza logowań, nie tylko zmiana hasła.

Jak ćwiczyć ten scenariusz w awareness

Scenariusz CodeStorm można przełożyć na kontrolowany test, w którym wiadomość wygląda jak kontynuacja realnego procesu: dokument od dostawcy, alert poczty głosowej, udostępniony plik, faktura albo prośba o potwierdzenie konta. Celem nie jest tylko sprawdzenie, czy użytkownik kliknie. Celem jest sprawdzenie, czy zatrzyma się przy logowaniu i czy zgłosi nietypową prośbę od znanego nadawcy.

Takie ćwiczenie powinno być połączone z omówieniem: prawdziwy nadawca nie gwarantuje prawdziwej intencji. Przejęte konto jest jednym z najtrudniejszych scenariuszy, bo atakujący korzysta z zaufania, które organizacja sama zbudowała.

Konkretna zasada na koniec

W Microsoft 365 zaufany nadawca nie wystarcza. Jeżeli znany kontakt prowadzi do nietypowego logowania, MFA, QR, pliku lub zmiany procesu, decyzję trzeba potwierdzić poza tym samym kanałem. Właśnie ten moment decyduje, czy przejęte konto stanie się kolejnym etapem phishingu.