BlueKit pokazuje, dokąd zmierza Phishing-as-a-Service

TL;DR

BlueKit był wcześniej opisany przez Varonis jako rozwijany phishing kit z panelem operatorskim, szablonami marek, konfiguracją domen, logami ofiar, powiadomieniami przez Telegram, elementami anti-analysis i AI Assistantem. Nowa analiza Netcraft zmienia wagę tematu: BlueKit został zaobserwowany w aktywnych wdrożeniach i rozwija technikę Browser-in-the-Middle.

W tym wariancie użytkownik nie trafia tylko na prosty klon formularza. Może widzieć interaktywny ekran logowania renderowany przez zdalną przeglądarkę kontrolowaną przez atakującego. BlueKit wykorzystuje rrweb do streamowania DOM przez WebSocket, a działania użytkownika są przekazywane do sesji po stronie napastnika.

Dla firm oznacza to zmianę akcentu: samo MFA nadal jest potrzebne, ale nie każde MFA wystarczy, jeżeli użytkownik przechodzi proces logowania w środowisku kontrolowanym przez pośrednika. Obrona musi łączyć phishing-resistant MFA, kontrolę sesji, wykrywanie nietypowych logowań, procedurę unieważniania tokenów i ćwiczenie decyzji użytkownika.

O co chodzi w BlueKit

Według Varonis Threat Labs, BlueKit reklamuje się jako szeroki zestaw do phishingu, który obsługuje ponad 40 szablonów podszywających się pod popularne marki i usługi. Wśród wymienianych celów pojawiają się między innymi iCloud, Apple ID, Gmail, Outlook, Hotmail, Yahoo, ProtonMail, GitHub, Twitter, Zoho, Zara i Ledger.

W praktyce nie chodzi tylko o same fałszywe strony logowania. BlueKit próbuje spiąć cały workflow kampanii: tworzenie strony, konfigurację domeny, obsługę logów, powiadomienia, zachowanie po przechwyceniu danych i narzędzia pomocnicze dla operatora. Varonis podkreśla, że badacze uzyskali dostęp do panelu i przeanalizowali go od środka, co daje bardziej wiarygodny obraz niż zwykła reklama z forum cyberprzestępczego.

To ważne, bo takie narzędzia obniżają próg wejścia. Osoba prowadząca kampanię nie musi już samodzielnie kupować domen, budować strony, konfigurować logów, integrować Telegrama i pisać własnych paneli. Coraz więcej elementów dostaje jako gotowy produkt.

Aktualizacja: BlueKit jako praktyczny przykład BitM

Netcraft opisał BlueKit jako aktywnie wykrywany wariant Phishing-as-a-Service, który rozwija technikę Browser-in-the-Middle. To ważna zmiana wobec wcześniejszego obrazu narzędzia jako zestawu w aktywnym rozwoju. Według Netcraft w ostatnim tygodniu wykryto około 70 hostnames powiązanych z wdrożeniami BlueKit.

Mechanizm różni się od klasycznego klona strony logowania. BlueKit ładuje prawdziwą stronę logowania w przeglądarce kontrolowanej przez atakującego, a następnie streamuje do użytkownika strukturę strony i interakcje. Użytkownik widzi więc interaktywny ekran, który zachowuje się znajomo, ale proces logowania nie odbywa się w normalnym, zaufanym kontekście jego urządzenia.

W praktyce BlueKit łączy kilka warstw. Najpierw próbuje odróżnić użytkownika od skanera albo analityka przez mechanizmy anti-bot, fingerprinting, zmienny kod strony i własne ekrany CAPTCHA. Dopiero potem przechodzi do właściwego etapu BitM, w którym zdalna przeglądarka, DOM stream i WebSocket stają się częścią ataku na proces logowania.

To dobry moment, aby we wpisie połączyć BlueKit z evergreenem o Browser-in-the-Middle BitM. Tam wyjaśniamy sam mechanizm. Tutaj BlueKit jest przykładem, jak taki mechanizm może zostać opakowany w panel PhaaS i udostępniony operatorom kampanii.

PhaaS dojrzewa jak zwykłe oprogramowanie

PhaaS, czyli Phishing-as-a-Service, to model, w którym phishing jest sprzedawany podobnie jak legalna usługa internetowa. Operator nie musi być autorem całego kodu. Kupuje albo wynajmuje dostęp do panelu, szablonów, domen, logów, powiadomień i instrukcji działania.

Jeszcze kilka lat temu phishing kit kojarzył się głównie z paczką plików wrzuconą na serwer. Dziś coraz częściej mówimy o platformach z panelem zarządzania, aktualizacjami, szablonami, integracjami i dokumentacją operatorską.

BlueKit dobrze wpisuje się w ten kierunek. Varonis opisuje, że panel obejmuje między innymi site creation, domain setup, captured logs, delivery tooling i campaign support features. Operator może wybrać domenę, tryb działania i szablon celu. Może też kontrolować zachowanie strony po logowaniu, przekierowania, spoofing, filtry urządzeń i elementy anti-analysis.

To już nie jest tylko strona wyłudzająca login. To narzędzie do zarządzania kampanią.

Podobny trend opisywaliśmy wcześniej w materiale Industrializacja phishingu. Jak model PhaaS zamienia pojedynczy atak w pipeline oszustwa. BlueKit jest kolejnym przykładem tego samego zjawiska: phishing coraz częściej działa jak gotowa usługa dla mniej zaawansowanych operatorów.

Jak wygląda taki panel z perspektywy operatora

Operator nie zaczyna od pustego serwera. Wybiera markę, domenę, tryb działania i szablon. W tym samym panelu widzi przechwycone logi, ustawienia przekierowań, filtry antybotowe, powiadomienia Telegram i dane sesji.

Telegram pojawia się tu nieprzypadkowo. To popularny komunikator, który w środowiskach cyberprzestępczych bywa używany do szybkich powiadomień, sprzedaży narzędzi i obsługi operatorów. W kontekście phishingu może służyć do informowania atakującego, że ofiara kliknęła, wpisała dane albo przeszła kolejny etap.

Anti-bot i anti-analysis oznaczają z kolei mechanizmy, które mają utrudnić analizę kampanii przez automaty, sandboxy i badaczy. Czasem chodzi o filtrowanie po adresie IP, języku, kraju, typie urządzenia albo zachowaniu przeglądarki. Ofiara ma zobaczyć fałszywe logowanie. Analityk albo skaner ma zobaczyć coś mniej podejrzanego albo nic wartościowego.

To właśnie zmienia ekonomię phishingu. Mniej czasu idzie na składanie infrastruktury, więcej na dobór przynęty i skalowanie kampanii.

Najważniejszy problem: sesja, nie samo hasło

W klasycznym phishingu głównym celem było hasło. W nowoczesnym phishingu coraz częściej chodzi o coś więcej: cookies, local storage, stan sesji i kontekst po uwierzytelnieniu.

Cookies i local storage to miejsca, w których przeglądarka przechowuje dane potrzebne stronie do działania. Mogą tam znajdować się ustawienia, identyfikatory, tokeny i informacje pomagające utrzymać użytkownika jako zalogowanego. Jeżeli atakujący przejmie taki kontekst, problem nie kończy się na samym haśle.

Varonis opisuje, że BlueKit śledzi session state, przechowuje powtarzane zrzuty cookies i local storage oraz utrzymuje podgląd tego, co ofiara widziała po logowaniu. To oznacza, że kit wychodzi poza prosty model credential harvesting, czyli zbierania loginu i hasła. Próbuje obsługiwać dane, które mogą pomóc w przejęciu zalogowanej sesji.

To właśnie dlatego zwykłe MFA przestaje być pełną odpowiedzią. MFA, czyli uwierzytelnianie wieloskładnikowe, nadal jest bardzo ważne. Problem zaczyna się wtedy, gdy atak nie zatrzymuje się na haśle, lecz próbuje przejąć kontekst po poprawnym logowaniu.

Ten sam mechanizm w bardziej dojrzałej i szeroko opisanej formie pokazuje Microsoft w analizie Tycoon2FA. Tycoon2FA wykorzystywał model AiTM, czyli adversary-in-the-middle. W takim ataku infrastruktura napastnika pośredniczy między użytkownikiem a prawdziwą usługą, przechwytując poświadczenia i cookies sesyjne. Dzięki temu mniej zaawansowani operatorzy mogli prowadzić kampanie, które uderzały nie tylko w hasło, ale też w cały proces logowania.

Jeśli chcesz zobaczyć szersze tło tego problemu, zobacz też wpis Phishing omijający MFA AiTM.

Jeżeli czytelnik potrzebuje szerszego kontekstu, osobno opisujemy też phishing omijający MFA i ataki AiTM, bo BlueKit jest praktycznym przykładem tego, jak problem przesuwa się z samego hasła na sesję i proces uwierzytelnienia.

Co zmienia Browser-in-the-Middle w BlueKit

W klasycznym AiTM atakujący często działa jako warstwa pośrednicząca między użytkownikiem a prawdziwą usługą. W wariancie opisanym przez Netcraft akcent przesuwa się na zdalną przeglądarkę. To po stronie infrastruktury atakującego ładowana jest prawdziwa strona logowania, a użytkownik otrzymuje interaktywny obraz procesu przez streamowany DOM.

To ogranicza część sygnałów, na których organizacje mogły polegać przy wykrywaniu przejętych sesji. Jeżeli sesja powstaje od początku w środowisku kontrolowanym przez atakującego, późniejsze użycie konta może wyglądać bardziej spójnie niż przy prostym przeniesieniu skradzionego cookie do innej przeglądarki.

Nie oznacza to, że obrona jest bezradna. Oznacza to, że trzeba obserwować cały łańcuch: źródło linku, etap logowania, nietypowe wyzwania MFA, nową sesję, urządzenie, lokalizację, działania po zalogowaniu i zmiany na koncie. Przy Microsoft 365, Google Workspace, GitHub, systemach HR albo narzędziach finansowych reakcja po podejrzeniu takiego logowania powinna dotyczyć sesji i tokenów, nie tylko hasła.

Dla użytkownika praktyczna zasada jest prosta: nie oceniaj wyłącznie wyglądu ekranu logowania. Ważniejsze pytanie brzmi, kto zainicjował proces i czy logowanie odbywa się normalną ścieżką. Jeżeli link przyszedł z wiadomości, dokumentu, komunikatora albo kodu QR i wymusza logowanie do ważnej usługi, bezpieczniej przerwać proces, otworzyć usługę z zakładki lub aplikacji i zgłosić sytuację.

AI w BlueKit: bardziej szkielet kampanii niż magiczny automat

Najbardziej medialny element BlueKit to AI Assistant. Warto jednak podejść do tego ostrożnie. Varonis opisuje, że w panelu widoczne były różne modele, w tym abliterated Llama jako domyślna opcja oraz GPT-4.1, Claude Sonnet 4, Gemini i DeepSeek. Badacze mogli jednak realnie przetestować przede wszystkim domyślny model.

Wynik nie był gotową, perfekcyjną kampanią phishingową. Varonis wskazuje, że AI Assistant generował raczej strukturę i szkic kampanii, z placeholderami i elementami wymagającymi dalszego dopracowania. To ważne. Nie warto przedstawiać BlueKit jako magicznego narzędzia, które jednym kliknięciem robi kompletny atak.

Ale nie oznacza to, że AI jest nieistotne. Wręcz przeciwnie. Nawet jeśli daje tylko szkielet, nadal skraca czas przygotowania kampanii i pomaga mniej doświadczonym operatorom przejść od pomysłu do działającej przynęty. W phishingu liczy się ekonomia. Jeśli AI obniża koszt pracy, wzmacnia cały model PhaaS.

BlueKit pokazuje kierunek: wszystko w jednym panelu

Największą wartością BlueKit z perspektywy operatora nie jest pojedyncza funkcja. Jest nią integracja. Domeny, szablony, logi, powiadomienia, filtry, sesje i AI znajdują się w jednym miejscu.

To ma praktyczne konsekwencje. Im mniej elementów trzeba składać ręcznie, tym szybciej można uruchomić kampanię. Im więcej funkcji znajduje się w jednym panelu, tym łatwiej prowadzić wiele równoległych operacji. Im więcej szablonów i marek jest dostępnych od ręki, tym łatwiej dopasować przynętę do ofiary.

W tym sensie BlueKit jest ważny nawet wtedy, gdy nie jest jeszcze najbardziej zaawansowanym kitem na rynku. Pokazuje, że PhaaS idzie w stronę wygody operatora i skracania ścieżki od zakupu do kampanii.

Dlaczego marki takie jak Apple, Google, Microsoft i GitHub są na liście

Lista szablonów nie jest przypadkowa. Apple, Google i Microsoft to konta osobiste, firmowe, pocztowe, chmurowe i tożsamościowe. GitHub to dostęp do kodu, repozytoriów i łańcucha dostaw oprogramowania. Ledger i inne usługi krypto to potencjalny dostęp do aktywów cyfrowych. ProtonMail, Yahoo, Outlook i Gmail to skrzynki, które mogą dać dostęp do resetów haseł i kolejnych kont.

Atakujący wybierają marki, które użytkownik zna i którym ufa. Im bardziej zwyczajny ekran logowania, tym mniejsza czujność. Właśnie dlatego brand phishing nadal działa tak dobrze.

Pisaliśmy o tym szerzej w materiale Phishing pod najbardziej zaufane marki. Microsoft, Apple i Google są dziś najlepszą przynętą. BlueKit jest praktycznym przykładem tego, jak takie marki trafiają do gotowych zestawów dla operatorów phishingu.

Co oznacza to dla firm

Dla organizacji BlueKit jest sygnałem, że obrona przed phishingiem nie może kończyć się na rozpoznawaniu źle napisanego maila. Jeżeli operator ma gotowe szablony, domeny, filtry anti-analysis, Telegrama i częściowe wsparcie AI, użytkownik zobaczy coraz lepiej przygotowane przynęty.

Największe ryzyko dotyczy nie tylko samego kliknięcia, ale całego procesu po kliknięciu. Czy użytkownik wpisze dane. Czy poda kod. Czy przejdzie MFA. Czy sesja zostanie przejęta. Czy aktywne tokeny zostaną unieważnione po incydencie. Czy zespół bezpieczeństwa zobaczy nietypowe logowanie, zanim konto zacznie działać jako legalny punkt wejścia.

To dobrze łączy się z wpisem Warstwa obrony przed phishingiem. Czego brakuje, gdy filtr poczty nie wystarcza. Współczesny phishing wymaga warstw: poczty, przeglądarki, tożsamości, sesji, detekcji i reakcji.

Co powinno zapalić lampkę ostrzegawczą

Najważniejszy sygnał ostrzegawczy to logowanie rozpoczęte z linku, którego użytkownik sam nie inicjował. Nawet jeśli strona wygląda jak Microsoft, Google, Apple albo GitHub, kluczowe pytanie brzmi: czy ten proces ma sens i czy użytkownik wszedł na niego własną, znaną ścieżką.

Podejrzane są też sytuacje, w których komunikat wymusza ponowną weryfikację MFA, straszy utratą dostępu, prosi o szybkie potwierdzenie albo przenosi użytkownika przez kilka ekranów wyglądających bardzo profesjonalnie, ale osadzonych pod obcą domeną.

W praktyce im bardziej standardowo wygląda przynęta, tym bardziej trzeba patrzeć na kontekst, a nie tylko na wygląd.

Co organizacje powinny zrobić praktycznie

Po pierwsze, warto przesuwać użytkowników wysokiego ryzyka w stronę metod odpornych na phishing, takich jak FIDO2, WebAuthn i passkeys. NIST podkreśla, że phishing-resistant MFA jest kluczowe, bo klasyczne metody mogą zostać obejście przez ataki pośredniczące i przejęcie procesu logowania.

FIDO2 i WebAuthn to standardy, które wiążą logowanie kryptograficznie z prawdziwą domeną usługi. Passkeys są wygodniejszą formą takiego podejścia. W praktyce chodzi o to, żeby użytkownik nie mógł skutecznie uwierzytelnić się na fałszywej stronie, nawet jeśli ta wygląda bardzo podobnie do prawdziwej.

Po drugie, trzeba monitorować nie tylko nieudane logowania, ale też nietypowe sesje, nowe urządzenia, anomalie lokalizacji, brak urządzenia zarządzanego i zachowanie użytkownika po zalogowaniu. Samo zresetowanie hasła po incydencie nie wystarczy, jeśli aktywne sesje i tokeny nie zostaną unieważnione.

Po trzecie, organizacja powinna mieć procedurę natychmiastowego unieważniania aktywnych sesji i tokenów. Przy phishingu sesyjnym sama zmiana hasła może być za mało, jeśli atakujący nadal korzysta z ważnej sesji.

Po czwarte, awareness powinien obejmować scenariusze AiTM i przejęcia sesji. Użytkownicy muszą wiedzieć, że MFA nie oznacza, że mogą spokojnie logować się z dowolnego linku. MFA pomaga, ale nie jest wymówką od weryfikacji kontekstu.

Po piąte, zespół bezpieczeństwa powinien zakładać, że phishing będzie coraz częściej wyglądał profesjonalnie. AI i PhaaS obniżają koszty przygotowania kampanii, więc stare wskaźniki typu literówki, słaby język i brzydki layout będą coraz mniej przydatne.

W programie security awareness BlueKit może być omawiany jako scenariusz decyzji, w którym użytkownik nie powinien oceniać tylko wyglądu strony, ale źródło logowania, kontekst wiadomości i moment, w którym pojawia się prośba o MFA.

Phishing staje się produktem

BlueKit nie musi być największym phishing kitem roku, żeby być ważnym sygnałem. Jego znaczenie polega na tym, że pokazuje kierunek rynku: phishing jako produkt, z dashboardem, szablonami marek, obsługą domen, kontrolą sesji, Telegramem, anti-analysis i AI Assistantem.

Dla firm oznacza to konieczność zmiany optyki. Nie wystarczy szkolić ludzi, żeby nie klikali w dziwne maile. Trzeba przygotowywać ich na kampanie, które wyglądają jak normalny proces logowania do znanej usługi, a po stronie atakującego są obsługiwane przez wygodny panel.

Nowoczesny phishing nie wygrywa tylko dlatego, że jest sprytny. Wygrywa dlatego, że jest coraz łatwiejszy do kupienia, uruchomienia i skalowania.

Jeżeli chcesz sprawdzić, czy użytkownicy zatrzymaliby się przed takim scenariuszem, dobrym początkiem jest quiz phishingowy PHISHLY.

W kontrolowanych testach phishingowych dla firm taki scenariusz warto ćwiczyć nie jako „kliknięcie w link”, ale jako pełny proces: wejście z wiadomości, próba logowania, decyzja przy MFA, zgłoszenie incydentu i reakcja zespołu IT lub Security.

Jeżeli chcesz sprawdzić, czy podobne scenariusze są dobrze opisane w Twoich procedurach, możesz skontaktować się z PHISHLY i omówić bezpieczny wariant testu dopasowany do organizacji.