Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Publicznie dostępny, błędnie skonfigurowany serwer może stać się nieoczekiwanym źródłem danych o działaniach cyberprzestępców. W tym przypadku ujawnione zasoby pozwoliły przeanalizować zaplecze trzech operacji phishingowych ukierunkowanych na użytkowników Microsoft 365, w tym kampanii wykorzystujących Evilginx oraz nadużycie legalnego mechanizmu device code flow.
Sprawa pokazuje, że współczesny phishing nie ogranicza się już do kradzieży loginu i hasła. Atakujący coraz częściej przejmują sesje, tokeny uwierzytelniające i wykorzystują poprawne procesy logowania do uzyskania trwałego dostępu do środowisk ofiar.
W skrócie
- Badacze odkryli publicznie wystawiony serwer z włączonym listowaniem katalogów i śladami pracy operatorów.
- Ujawnione pliki zawierały konfiguracje, logi, kopie zapasowe i elementy infrastruktury phishingowej.
- Zidentyfikowano trzy odrębne kampanie wymierzone w Microsoft 365.
- Dwie operacje wykorzystywały Evilginx do przechwytywania sesji i tokenów.
- Trzecia kampania opierała się na phishingu z użyciem przepływu OAuth device code.
- Sama obecność MFA nie gwarantuje ochrony, jeśli organizacja nie kontroluje również device code flow.
Kontekst / historia
Punktem wyjścia był testowy serwer HTTP, który pozostał dostępny z internetu. Tego rodzaju błąd operacyjny może ujawnić znacznie więcej niż pojedyncze pliki — od struktury katalogów po historię poleceń, używane repozytoria i zależności między narzędziami wykorzystywanymi przez operatorów kampanii.
Analiza wskazuje, że atakujący nie budowali całego środowiska od podstaw. Wykorzystywali publicznie dostępne forki Evilginx, które następnie rozszerzali o własne modyfikacje poprawiające skuteczność ataków oraz utrudniające wykrycie infrastruktury. Jedna z kampanii miała działać przez dłuższy czas i koncentrować się głównie na przejmowaniu firmowych skrzynek pocztowych.
Znaczenie incydentu zwiększa fakt, że Microsoft już wcześniej ostrzegał przed phishingiem opartym na device code. Oznacza to, że zagrożenie nie ma charakteru teoretycznego, lecz wpisuje się w rosnący trend nadużywania legalnych procesów uwierzytelniania w środowiskach chmurowych.
Analiza techniczna
W pierwszym scenariuszu Evilginx działał jako serwer pośredniczący pomiędzy ofiarą a prawdziwym portalem logowania Microsoft 365. Taki model adversary-in-the-middle pozwala przechwycić nie tylko dane logowania, ale również ciasteczka sesyjne i tokeny uzyskane po poprawnym przejściu procesu MFA. W praktyce oznacza to, że napastnik może korzystać z ważnej sesji nawet bez dalszej znajomości hasła użytkownika.
Zmodyfikowane forki zawierały dodatkowe funkcje zwiększające skuteczność kampanii. Wśród nich znajdowały się mechanizmy przepisywania adresów URL, modyfikacje atrybutów HTML związanych z integralnością zasobów, automatyczne uzupełnianie adresu e-mail ofiary oraz komponenty ułatwiające wdrożenie całego zestawu bez samodzielnej kompilacji. Artefakty wskazywały też na możliwość wydłużania życia przechwyconych sesji i odnawiania skradzionych tokenów.
Drugi model ataku był bardziej subtelny i opierał się na legalnym przepływie OAuth device code. W takim scenariuszu użytkownik otrzymywał wiadomość lub stronę stylizowaną na komunikat Microsoftu i był nakłaniany do wpisania kodu na prawdziwej stronie logowania. Technicznie nie dochodzi tu do obejścia MFA, ponieważ ofiara sama przechodzi prawidłowe uwierzytelnienie. Problem polega na tym, że finalnie autoryzuje sesję wygenerowaną przez atakującego.
To rozróżnienie ma kluczowe znaczenie dla obrony. Rozwiązania phishing-resistant MFA, takie jak FIDO2 czy passkeys, bardzo skutecznie ograniczają klasyczne ataki reverse-proxy, ale nie eliminują ryzyka nadużycia device code flow, jeśli organizacja pozostawia ten mechanizm bez odpowiednich ograniczeń. Dodatkowo analiza wskazała na użycie automatyzacji do utrzymywania aktywności tokenów oraz narzędzi zdalnego zarządzania wykorzystywanych po przejęciu kont.
W ujawnionych materiałach pojawiły się również ślady użycia generatywnej AI do tworzenia kodu pomocniczego i modyfikacji elementów phishingowej infrastruktury. Nie oznacza to pełnej automatyzacji kampanii, ale potwierdza, że próg wejścia dla mniej zaawansowanych operatorów nadal spada.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem takich działań jest przejęcie aktywnej sesji Microsoft 365 z pominięciem tradycyjnych założeń bezpieczeństwa opartych wyłącznie na haśle i MFA. Po uzyskaniu ważnych tokenów napastnik może dostać się do poczty, plików, komunikacji wewnętrznej oraz innych usług zintegrowanych z Entra ID.
Szczególnie narażone są organizacje, które:
- pozostawiają włączony device code flow bez wyraźnej potrzeby biznesowej,
- nie stosują polityk Conditional Access ograniczających nietypowe logowania,
- nie monitorują logów Entra ID pod kątem anomalii sesyjnych i odświeżeń tokenów,
- traktują MFA jako jedyne zabezpieczenie tożsamości,
- nie wykrywają narzędzi RMM instalowanych po kompromitacji konta.
Dodatkowym problemem jest trwałość dostępu. Jeśli sesje lub tokeny mogą być odnawiane, przeciwnik może utrzymać obecność w środowisku nawet po zmianie hasła. To zwiększa ryzyko wycieku korespondencji, eskalacji działań wewnątrz organizacji, podszywania się pod pracowników i prowadzenia kolejnych kampanii z legalnych, skompromitowanych skrzynek.
Rekomendacje
Organizacje korzystające z Microsoft 365 powinny podejść do ochrony tożsamości warstwowo. Samo wdrożenie MFA nie jest dziś wystarczające, jeśli nie towarzyszą mu odpowiednie kontrole sesji, polityki dostępu i monitoring.
- Wdrażaj phishing-resistant MFA tam, gdzie jest to możliwe, aby ograniczyć skuteczność ataków reverse-proxy.
- Przeanalizuj wykorzystanie device code flow i wyłącz go tam, gdzie nie jest niezbędny operacyjnie.
- Jeśli device code flow musi pozostać aktywny, ogranicz go precyzyjnymi politykami Conditional Access oraz testuj zmiany w trybie raportowym.
- Monitoruj logi Entra ID pod kątem nietypowych użyć device code, odświeżeń tokenów z nietypowych lokalizacji oraz nowych rejestracji urządzeń.
- Wdrażaj mechanizmy skracające użyteczność skradzionych tokenów, w tym Continuous Access Evaluation oraz polityki ryzyka sesji.
- Rozszerz procedury SOC i IR o hunting artefaktów post-exploitation, takich jak narzędzia RMM, zadania harmonogramu i nietypowe procesy pomocnicze.
- Szkol użytkowników, że wpisanie kodu uwierzytelniającego otrzymanego z niezweryfikowanego źródła może autoryzować sesję napastnika, nawet jeśli strona logowania jest prawdziwa.
Podsumowanie
Incydent z błędnie skonfigurowanym serwerem pokazał pełny obraz nowoczesnych kampanii phishingowych wymierzonych w Microsoft 365. Ujawnione artefakty pozwoliły zrozumieć, jak operatorzy łączą klasyczne techniki Evilginx z nadużyciem legalnych przepływów uwierzytelniania, by zwiększać skuteczność i trwałość kompromitacji.
Dla obrońców najważniejszy wniosek jest jasny: ochrona kont nie może kończyć się na haśle i MFA. Skuteczna strategia musi obejmować również kontrolę sesji, ograniczanie device code flow, monitoring tokenów oraz szybkie wykrywanie działań po przejęciu tożsamości.