Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Kali365 to platforma phishing-as-a-service, która wykorzystuje technikę device code phishing do przejmowania sesji i tokenów OAuth bez konieczności poznania hasła ofiary. To szczególnie groźny model ataku, ponieważ użytkownik loguje się na prawdziwej stronie dostawcy usługi i samodzielnie zatwierdza uwierzytelnienie wieloskładnikowe, nieświadomie autoryzując dostęp napastnikowi.
W praktyce oznacza to odejście od klasycznego scenariusza wyłudzania danych logowania na fałszywej stronie. Zamiast kraść hasło, atakujący przejmuje legalnie wydane tokeny dostępu, które pozwalają mu działać w imieniu użytkownika.
W skrócie
Kali365 początkowo był kojarzony głównie z kampaniami wymierzonymi w konta Microsoft 365, jednak najnowsze analizy wskazują na wyraźne rozszerzenie katalogu celów. Zestaw phishingowy jest obecnie wykorzystywany także do podszywania się pod usługi związane z AWS, Okta, Xerox DocuShare oraz wybrane platformy rosyjskojęzyczne.
Najważniejszą cechą tej operacji pozostaje fakt, że nie opiera się ona na tradycyjnej kradzieży poświadczeń. Kluczowym elementem jest przejęcie tokenów dostępowych w ramach legalnego przepływu autoryzacji urządzeń, co znacząco utrudnia wykrycie i podważa skuteczność części standardowych mechanizmów ochronnych.
Kontekst / historia
Kali365 zwrócił uwagę branży bezpieczeństwa po ostrzeżeniu wydanym przez FBI w maju 2026 roku. Według dostępnych ustaleń platforma była aktywna co najmniej od kwietnia 2026 roku i funkcjonowała w modelu usługowym, oferując gotowe narzędzia operatorom o różnym poziomie zaawansowania.
Taki model abonamentowy obniża próg wejścia dla cyberprzestępców. Zamiast samodzielnie budować infrastrukturę, przygotowywać przynęty i rozwijać mechanizmy automatyzacji, mogą oni korzystać z gotowego panelu, szablonów kampanii oraz funkcji śledzenia aktywności ofiar.
Z czasem Kali365 przestał być narzędziem wyspecjalizowanym wyłącznie w ekosystemie Microsoft 365. Rozszerzenie zasięgu na kolejne usługi chmurowe, platformy SSO i serwisy wykorzystywane w różnych środowiskach sugeruje, że operatorzy rozwijają platformę w kierunku uniwersalnego narzędzia do przejmowania tożsamości cyfrowych.
Analiza techniczna
Rdzeniem kampanii jest nadużycie mechanizmu OAuth 2.0 Device Authorization Grant, znanego także jako device code flow. Ten proces został zaprojektowany dla urządzeń o ograniczonych możliwościach interakcji, takich jak telewizory smart, drukarki czy terminale bez pełnej przeglądarki.
W typowym scenariuszu użytkownik otrzymuje kod i wpisuje go na legalnej stronie logowania z wykorzystaniem innego urządzenia. W kampanii Kali365 właśnie ten legalny proces staje się narzędziem ataku. Ofiara otrzymuje wiadomość phishingową, która podszywa się pod zaufaną usługę i nakłania do wpisania kodu oraz dokończenia procesu logowania.
Po zatwierdzeniu uwierzytelnienia, w tym MFA, system wydaje tokeny dostępu i odświeżania dla sesji kontrolowanej przez atakującego. Oznacza to, że napastnik nie musi znać hasła ofiary ani przełamywać mechanizmu drugiego składnika. Wystarczy, że skłoni użytkownika do dokończenia autoryzacji w nieświadomy sposób.
Z perspektywy obronnej to zasadnicza zmiana względem tradycyjnego phishingu. Nie ma tu fałszywego panelu logowania, który łatwo wskazać w szkoleniach lub zablokować przez filtry. Użytkownik korzysta z prawdziwej strony, a cały przepływ wygląda wiarygodnie, co zwiększa skuteczność kampanii.
Analitycy opisali także rozbudowaną infrastrukturę wspierającą tę działalność. W jednym z klastrów wykryto 126 aktywnych hostów działających w maju 2026 roku i obsługujących podobny schemat operacyjny. Szeroki zestaw domen i przynęt pokazuje, że platforma jest skalowalna i może być szybko dostosowywana do nowych marek, sektorów oraz regionów.
Konsekwencje / ryzyko
Najistotniejsze ryzyko polega na tym, że MFA nie zatrzymuje tego typu ataku, jeśli użytkownik sam finalizuje proces autoryzacji w imieniu napastnika. Organizacje, które traktują uwierzytelnianie wieloskładnikowe jako główną i wystarczającą ochronę kont chmurowych, mogą przez to mieć fałszywe poczucie bezpieczeństwa.
Skutki przejęcia tokenów mogą być bardzo poważne. Atakujący może uzyskać dostęp do poczty, plików, narzędzi współpracy, zasobów chmurowych oraz procesów biznesowych opartych na tożsamości. Jeśli w grę wchodzą tokeny odświeżania, możliwe jest także utrzymanie dostępu przez dłuższy czas.
Dla środowisk korporacyjnych oznacza to ryzyko:
- kradzieży danych i dokumentów,
- eskalacji uprawnień,
- przejęcia komunikacji wewnętrznej,
- wykorzystania skrzynek pocztowych do dalszych kampanii socjotechnicznych,
- nadużycia zaufanych kont do poruszania się po środowisku.
Rozszerzenie listy imitowanych usług zwiększa również zagrożenie dla zespołów administracyjnych, deweloperskich i uprzywilejowanych użytkowników. To właśnie te grupy częściej pracują z usługami IAM, integracjami OAuth oraz procesami autoryzacji urządzeń, co może czynić je bardziej podatnymi na wiarygodnie przygotowane przynęty.
Rekomendacje
Organizacje powinny w pierwszej kolejności ustalić, czy device code flow jest rzeczywiście potrzebny we wszystkich częściach środowiska. Tam, gdzie nie jest wymagany biznesowo, warto go ograniczyć lub zablokować za pomocą polityk dostępu warunkowego i wyjątków tylko dla uzasadnionych scenariuszy.
Niezbędne jest również monitorowanie logów uwierzytelniania pod kątem nietypowych żądań device code, nowych sesji OAuth, anomalii geolokalizacyjnych oraz nieoczekiwanych autoryzacji aplikacji. Szczególną uwagę należy zwrócić na przypadki, w których po poprawnym MFA pojawia się nietypowa aktywność tokenów.
W warstwie operacyjnej warto wdrożyć następujące działania:
- przegląd i ograniczenie użycia device code flow,
- monitorowanie nowych oraz rzadko używanych aplikacji OAuth,
- skracanie czasu życia tokenów tam, gdzie platforma na to pozwala,
- procedury natychmiastowego unieważniania aktywnych sesji i tokenów,
- szkolenia użytkowników obejmujące scenariusze z legalnymi stronami logowania,
- dodatkowe zabezpieczenia dla kont uprzywilejowanych i administracyjnych.
Programy awareness powinny zostać rozszerzone o ważny komunikat: wpisanie kodu na prawdziwej stronie nie zawsze oznacza bezpieczne działanie. Użytkownik musi umieć rozpoznać, czy to on sam zainicjował proces logowania, czy też został do niego nakłoniony przez wiadomość, alert lub prośbę od potencjalnego napastnika.
Podsumowanie
Kali365 pokazuje, że phishing ewoluuje w stronę ataków opartych na przejęciu autoryzacji, a nie wyłącznie poświadczeń. Rozszerzenie kampanii poza Microsoft 365 potwierdza, że device code phishing staje się uniwersalną techniką przejmowania tożsamości cyfrowych w wielu ekosystemach.
Dla organizacji to wyraźny sygnał, że samo MFA nie wystarcza jako jedyna linia obrony. Skuteczna ochrona wymaga połączenia ograniczeń technicznych, monitorowania tokenów i sesji, lepszej widoczności procesów OAuth oraz nowocześniejszych szkoleń użytkowników.