BlobPhish i phishing w pamięci przeglądarki. Gdy fałszywe logowanie nie ma zwykłego adresu

2026-04-29

TL;DR

BlobPhish pokazuje, że phishing coraz częściej wychodzi poza stary schemat fałszywej strony hostowanej na podejrzanej domenie. W tym modelu końcowy ekran logowania powstaje lokalnie w przeglądarce ofiary jako adres zaczynający się od blob:https://.

Dla użytkownika może to wyglądać jak zwykły formularz logowania do Microsoft 365, banku albo usługi finansowej. Dla części narzędzi bezpieczeństwa jest to trudniejsze do oceny, bo końcowa strona nie istnieje jako typowy dokument HTML pobrany z publicznego serwera. Powstaje dopiero w sesji przeglądarki.

Według ANY.RUN kampania BlobPhish była obserwowana od października 2024 roku i pozostawała aktywna w kwietniu 2026 roku. Atakujący podszywali się między innymi pod Microsoft 365, OneDrive, SharePoint, webmail oraz znane marki finansowe, takie jak Chase, Capital One, FDIC, E-Trade, Charles Schwab, PayPal i Intuit.

To nie jest ciekawostka techniczna. To kolejny przykład, że phishing trzeba analizować jako cały łańcuch zachowań, a nie tylko jako jeden podejrzany URL.

Czym właściwie jest blob URL

blob: nie jest złośliwym protokołem. To normalny mechanizm przeglądarki.

Zgodnie z dokumentacją MDN Web Docs, blob URL ma postać zbliżoną do blob:<origin>/<uuid>. Przeglądarka tworzy taki adres, aby odwołać się do danych wygenerowanych lokalnie, na przykład obrazu, pliku, wideo albo dokumentu HTML. Metoda URL.createObjectURL() tworzy tymczasowy adres wskazujący na taki obiekt.

W praktyce blob URL może być używany do całkiem legalnych rzeczy: podglądu pliku, obsługi multimediów albo pracy z danymi wygenerowanymi w aplikacji webowej. Problem zaczyna się wtedy, gdy atakujący używa tego samego mechanizmu do zbudowania lokalnej fałszywej strony logowania.

W BlobPhish phishing nie polega więc na luce w przeglądarce. Polega na nadużyciu funkcji, która została zaprojektowana do innych, prawidłowych zastosowań.

Jak działa BlobPhish krok po kroku

Najpierw użytkownik dostaje wiadomość phishingową, link do dokumentu, alert, fakturę albo QR kod prowadzący do strony pośredniej. Ta strona nie musi od razu wyglądać jak formularz logowania. Jej zadaniem jest uruchomienie kolejnego etapu.

Potem przeglądarka ładuje JavaScript. To kod wykonywany po stronie użytkownika, bezpośrednio w przeglądarce. W normalnych stronach JavaScript odpowiada za interakcje, formularze, dynamiczne elementy i wiele funkcji aplikacji webowych. W tym przypadku działa jako loader, czyli kawałek kodu przygotowujący właściwy phishing.

Następnie loader dekoduje ukryty HTML. Często takie dane są zapisane w Base64, czyli formacie pozwalającym zapisać treść w postaci tekstowej. Base64 nie jest szyfrowaniem, ale utrudnia szybki, pobieżny podgląd właściwej zawartości.

Potem JavaScript tworzy obiekt Blob z fałszywą stroną logowania i generuje lokalny adres blob:https:// przy użyciu URL.createObjectURL(). Przeglądarka przekierowuje użytkownika na ten adres.

Na końcu ofiara widzi formularz logowania do Microsoft 365, banku albo innej usługi. Strona wygląda jak znany panel, ale nie została pobrana jako zwykły dokument HTML z domeny dostawcy. Powstała lokalnie w przeglądarce.

Po wpisaniu danych formularz wysyła je do infrastruktury atakujących. W materiałach technicznych pojawiają się między innymi endpointy typu res.php, tele.php i panel.php, używane do odbierania danych. Same nazwy plików nie są dowodem ataku, ale w połączeniu z blob URL i fałszywym logowaniem tworzą mocny sygnał ostrzegawczy.

Dlaczego to utrudnia obronę

BlobPhish przenosi końcowy etap phishingu z klasycznego URL do zachowania przeglądarki. To robi różnicę.

W zwykłym phishingu fałszywa strona jest hostowana na serwerze. Można ją sprawdzić reputacją domeny, zobaczyć w logach proxy, dodać do listy blokowania i przeskanować jako publiczny adres. W BlobPhish końcowy ekran logowania powstaje lokalnie. Nie da się ocenić reputacją URL samej końcowej strony tak, jak klasycznego phishingowego hosta.

To nie znaczy, że atak jest niewidzialny. Wciąż istnieją wcześniejsze etapy: wiadomość, link, strona pośrednia, loader JavaScript i endpointy odbierające dane. Trzeba jednak patrzeć na cały łańcuch, a nie tylko na finalny adres w pasku przeglądarki.

Cofense już wcześniej zwracał uwagę, że blob URI mogą utrudniać pracę secure email gateways, czyli bramek bezpieczeństwa analizujących pocztę przychodzącą. Końcowa strona phishingowa jest dostępna tylko lokalnie w przeglądarce, która ją wygenerowała. To utrudnia automatyczną analizę i późniejsze odtworzenie incydentu.

Co widzi użytkownik

Dla użytkownika taki atak może wyglądać jak zwykłe logowanie do Microsoft 365, OneDrive, SharePointa, PayPala, banku albo platformy inwestycyjnej.

ANY.RUN wskazuje, że BlobPhish podszywał się między innymi pod Microsoft 365, OneDrive, SharePoint, Chase, FDIC, Capital One, E-Trade, American Express, Charles Schwab, Merrill Lynch, PayPal i Intuit. To marki, które mają wysoki poziom zaufania. Użytkownik widzi znajomy formularz i myśli o wykonaniu zadania, a nie o tym, czy strona została wygenerowana jako obiekt Blob.

W części kampanii pojawia się też licznik błędnych logowań albo prośba o ponowne wpisanie danych. To nie jest przypadek. Taki zabieg zwiększa szansę, że atakujący dostanie poprawne hasło, a nie literówkę wpisaną za pierwszym razem.

Najważniejsza czerwona flaga: blob:https:// przy logowaniu

Prawdziwe logowanie do Microsoft 365, banku, PayPala albo innej ważnej usługi nie powinno odbywać się na adresie zaczynającym się od blob:https://.

Taki prefiks oznacza, że przeglądarka pokazuje lokalnie wygenerowany obiekt, a nie zwykłą stronę logowania właściwego dostawcy. Fragment https:// może mylić, bo wielu użytkowników kojarzy go z bezpieczną stroną. W tym przypadku nie jest to wystarczający sygnał zaufania. Liczy się właściwa domena usługi.

Nie każdy blob: w przeglądarce jest zły. Blob URL są używane legalnie, na przykład do obsługi multimediów, podglądu plików albo tymczasowych danych. Ale ekran logowania do konta firmowego, banku albo usługi finansowej wyświetlany jako blob:https:// powinien natychmiast zatrzymać użytkownika.

Najprostsza zasada brzmi: jeśli strona prosi o hasło, kod MFA albo dane finansowe, adres powinien należeć do właściwej domeny dostawcy. Nie do blob:.

To nie jest tylko problem techniczny

BlobPhish łatwo opisać jako trik w przeglądarce, ale takie ujęcie byłoby zbyt wąskie. W praktyce chodzi o coś większego: atakujący coraz lepiej wykorzystują granice widoczności między użytkownikiem, bramką pocztową, proxy, przeglądarką i narzędziami analitycznymi.

Użytkownik ma zaufać wyglądowi formularza. Bramka pocztowa ma zobaczyć tylko część łańcucha. Proxy może nie zobaczyć końcowej strony phishingowej jako klasycznego żądania HTTP. Analityk po fakcie ma mniej prostych artefaktów do odtworzenia.

To dobrze łączy się z materiałem Warstwa obrony przed phishingiem. Czego brakuje, gdy filtr poczty nie wystarcza. Filtr poczty jest potrzebny, ale nie wystarczy, jeśli końcowy etap ataku materializuje się dopiero w przeglądarce użytkownika.

Jakie dane są celem

BlobPhish koncentruje się na danych logowania, ale konsekwencje mogą być znacznie szersze niż utrata jednego hasła.

Przejęcie konta Microsoft 365 może dać dostęp do poczty, Teams, SharePointa, OneDrive, kalendarza, dokumentów i kolejnych resetów haseł. Przejęcie konta finansowego może prowadzić do fraudu, manipulacji inwestycjami albo kradzieży środków.

ANY.RUN wskazuje, że skradzione konta mogą umożliwiać Business Email Compromise, data exfiltration i lateral movement. Po polsku: oszustwa prowadzone przez przejętą pocztę firmową, kradzież danych oraz dalsze poruszanie się po środowisku organizacji.

BlobPhish nie powinien więc być traktowany jako jeszcze jeden sposób na ukrycie strony. To potencjalny punkt wejścia do większego incydentu.

Co powinno trafić do awareness

BlobPhish jest dobrym tematem szkoleniowym, bo pokazuje ograniczenia starego skrótu myślowego: sprawdź, czy strona ma HTTPS. Dziś HTTPS nie wystarcza jako sygnał bezpieczeństwa. Użytkownik musi rozumieć, że liczy się właściwa domena i sens całego procesu.

W praktyce warto uczyć trzech prostych rzeczy.

Po pierwsze, ekran logowania do ważnej usługi nie powinien zaczynać się od blob: w pasku adresu.

Po drugie, jeżeli po kliknięciu w dokument, fakturę, QR kod albo alert użytkownik trafia na logowanie, powinien przerwać proces i wejść do usługi samodzielnie.

Po trzecie, ponowna prośba o hasło po rzekomym błędzie logowania może być elementem harvestingowym, czyli próbą zebrania poprawnych danych logowania, a nie normalnym problemem technicznym.

Dobrze łączy się to z materiałami Co to jest phishing? Mechanizm oszustw e-mailowych oraz Phishing pod zaufane marki. Microsoft, Apple i Google są dziś najlepszą przynętą. W BlobPhish marka i wygląd formularza są przynętą. Prawdziwy problem siedzi w sposobie dostarczenia strony.

Dlaczego phishing-resistant MFA jest tu szczególnie ważne

BlobPhish może ukrywać stronę, ale nadal potrzebuje danych, które da się wykorzystać. Jeśli organizacja opiera się tylko na haśle albo słabym MFA, skutki udanego wyłudzenia mogą być poważne.

MFA, czyli uwierzytelnianie wieloskładnikowe, dodaje drugi składnik do logowania. Może to być kod, aplikacja mobilna, powiadomienie push, passkey albo klucz sprzętowy. Nie każda metoda daje jednak taki sam poziom ochrony przed phishingiem.

Przy kontach Microsoft 365, finansowych i administracyjnych warto stosować phishing-resistant MFA, na przykład passkeys lub klucze FIDO2. Są to metody projektowane tak, aby uwierzytelnienie było powiązane z właściwą domeną usługi. Jeśli użytkownik trafi na lokalnie wygenerowaną stronę blob:, taki mechanizm nie powinien działać jak zwykłe wpisanie hasła do formularza.

Nie oznacza to, że awareness przestaje być potrzebny. Oznacza, że warto łączyć edukację z technologią, która nie zakłada, że człowiek zawsze zauważy różnicę.

Co powinien zrobić użytkownik po podejrzanym logowaniu

Jeśli użytkownik wpisał dane na stronie, która miała w adresie blob:https://, powinien potraktować sytuację jak wyłudzenie hasła.

W przypadku kont firmowych trzeba natychmiast zgłosić incydent do IT lub SOC, zmienić hasło znaną ścieżką, unieważnić aktywne sesje i sprawdzić, czy nie pojawiły się nowe metody MFA, reguły pocztowe albo nietypowe logowania.

W przypadku kont bankowych lub inwestycyjnych trzeba wejść samodzielnie do aplikacji albo na oficjalną stronę, sprawdzić historię operacji i skontaktować się z dostawcą usługi, jeśli pojawiło się cokolwiek nietypowego.

Najgorszy wariant to ponowne próbowanie logowania na tej samej stronie. W części kampanii właśnie o to chodzi: użytkownik ma kilka razy wpisać dane, aż atakujący dostanie poprawny zestaw.

Najważniejsza lekcja z BlobPhish

BlobPhish pokazuje, że phishing przesuwa się z prostego podszywania się pod domenę do nadużywania mechanizmów przeglądarki. Końcowa strona logowania może powstać lokalnie, działać tylko w konkretnej sesji i zniknąć, zanim analityk łatwo ją odtworzy.

Dla użytkownika najważniejsza zasada jest konkretna: blob:https:// na ekranie logowania do Microsoft 365, banku albo usługi finansowej to sygnał ostrzegawczy. Nie należy tam wpisywać hasła, kodu MFA ani danych finansowych.

Dla firm lekcja jest szersza. Obrona przed phishingiem musi widzieć nie tylko link w mailu, ale cały łańcuch: wiadomość, przekierowania, JavaScript, zachowanie przeglądarki, powstanie blob URL i późniejsze logowania do usług. Dopiero taki obraz pozwala zatrzymać atak, który nie mieści się już w starym schemacie podejrzanej domeny i fałszywego formularza.

Jeżeli chcesz sprawdzić, czy użytkownicy wychwycą taki scenariusz zanim wpiszą dane, dobrym początkiem jest quiz phishingowy PHISHLY.