Phishing sterowany na żywo. Jak JWR prowadzi ofiarę przez fałszywą płatność

TL;DR

Phishing coraz rzadziej musi wyglądać jak statyczna kopia strony, która tylko czeka na wysłanie formularza. JWR pokazuje bardziej adaptacyjny model: fałszywa strona utrzymuje połączenie z panelem przestępcy, a operator może obserwować, co dzieje się w sesji, i na bieżąco wybierać następny ekran.

Według Cisco Talos JWR obsługuje 44 strony phishingowe i ponad 40 poleceń sterujących. Może zbierać między innymi dane osobowe, dane kart, CVV, PIN, loginy, kody 2FA i fingerprint urządzenia. Talos obserwował kampanie dostarczane przez SMS-y o opłatach drogowych, przesyłkach i opłatach kurierskich w Azji Południowo-Wschodniej i na Bliskim Wschodzie.

Jeżeli po wejściu z SMS-a strona zaczyna prowadzić Cię przez serię „weryfikacji”, odrzuceń karty, kodów SMS i kolejnych próśb o dane, nie traktuj tego jako dowodu, że proces jest prawdziwy. Adaptacyjna reakcja strony może być częścią oszustwa.

Co właściwie zmienia JWR

W klasycznym wyobrażeniu phishingu napastnik przygotowuje fałszywy formularz, wysyła link i czeka, aż ofiara wpisze dane. Taki model nadal działa, ale JWR dodaje do niego człowieka po drugiej stronie.

Cisco Talos opisuje JWR jako system real-time, operator-driven. Fałszywa strona utrzymuje szyfrowane połączenie WebSocket z infrastrukturą atakującego. Dzięki temu operator nie musi z góry ustalać całego przebiegu. Może obserwować sesję i decydować, co ofiara zobaczy dalej.

WebSocket to technologia używana legalnie w wielu aplikacjach internetowych do dwukierunkowej komunikacji w czasie rzeczywistym. Sam WebSocket nie jest więc podejrzany. W JWR został wykorzystany jako kanał, przez który przestępca steruje przebiegiem fałszywego procesu płatności lub logowania.

Różnica jest istotna. Ofiara nie widzi jednej strony. Widzi sekwencję, która reaguje na jej zachowanie.

Atak zaczyna się od zwykłego SMS-a

Talos zaobserwował JWR w kampaniach typu smishing. Przynęty dotyczyły między innymi rzekomych opłat drogowych, usług pocztowych i kurierskich. To bardzo znany mechanizm: mała należność, prosty komunikat i link, który ma szybko zamknąć sprawę.

Ten etap sam w sobie nie jest nowy. Podobne preteksty opisujemy we wpisach o fałszywych SMS-ach kurierskich i smishingu z opłatami drogowymi.

Nowość zaczyna się po kliknięciu. Zamiast prostego formularza, który zbiera dane i kończy działanie, ofiara trafia do interaktywnego scenariusza kontrolowanego przez operatora.

To ważne z punktu widzenia awareness. Pracownik może być już wyczulony na kiepsko przygotowane strony. Trudniej mu jednak zrozumieć, że oszustwo może reagować logicznie na to, co właśnie wpisał.

Operator widzi dane, zanim klikniesz „dalej”

Jedną z najważniejszych funkcji opisanych przez Talos jest przesyłanie wpisywanych danych w czasie zbliżonym do rzeczywistego. Operator może zobaczyć częściowy numer karty, fragment hasła albo kod weryfikacyjny jeszcze zanim użytkownik formalnie wyśle formularz.

Nie oznacza to, że samo wpisanie jednej cyfry automatycznie prowadzi do utraty pieniędzy. Oznacza natomiast, że granica ryzyka przesuwa się wcześniej. Nie można zakładać, że dane są bezpieczne do chwili kliknięcia przycisku „Zapłać” czy „Zaloguj”.

Dla użytkownika praktyczna zasada jest prosta: jeśli trafiłeś na stronę z podejrzanego SMS-a, nie „testuj”, czy formularz wygląda prawdziwie przez wpisywanie danych. W nowoczesnym phishingu już samo wpisywanie może być obserwowane.

Jak oszust może sterować kolejnymi ekranami

JWR ma zestaw ponad 40 instrukcji, które pozwalają operatorowi wyświetlać kolejne kroki. Z perspektywy ofiary może to wyglądać jak normalny proces weryfikacyjny.

Scenariusz może wyglądać tak:

1. ofiara trafia z SMS-a na fałszywą stronę opłaty;
2. wpisuje dane osobowe;
3. pojawia się formularz karty;
4. operator widzi dane i decyduje, co pokazać dalej;
5. strona może zasugerować odrzucenie karty i poprosić o inną;
6. może pojawić się prośba o kod SMS, PIN, kod 2FA albo zatwierdzenie w aplikacji;
7. po zakończeniu ofiara może zostać przekierowana do prawdziwego serwisu.

Ostatni krok jest szczególnie podstępny. Przekierowanie do prawdziwej strony może sprawić, że użytkownik uzna wcześniejszy problem za zwykły błąd techniczny.

„Karta odrzucona” może być częścią scenariusza

Talos opisuje funkcje, które pozwalają operatorowi wyświetlić ofierze komunikat o odrzuconej karcie albo nieprawidłowym kodzie. To nie musi być prawdziwa odpowiedź banku czy operatora płatności.

W praktyce oszust może wykorzystać taki komunikat, aby zdobyć więcej informacji. Jeśli pierwsza karta zostanie oznaczona jako „odrzucona”, ofiara może spróbować drugiej. Jeśli kod zostanie uznany za „nieprawidłowy”, może wpisać kolejny.

To ważna zmiana psychologiczna. Użytkownik jest przyzwyczajony, że systemy płatnicze czasem odrzucają transakcje. Komunikat o błędzie nie wygląda więc jak atak. Może wyglądać jak dowód, że strona faktycznie komunikuje się z bankiem.

W JWR taka reakcja może być po prostu decyzją operatora.

Kody 2FA też mogą stać się celem

Framework ma ekrany pozwalające poprosić ofiarę o kod SMS, kod 2FA, PIN lub zatwierdzenie w aplikacji. To kolejny argument przeciwko myśleniu, że „mam MFA, więc mogę spokojnie wejść w link”.

MFA nadal jest bardzo ważnym zabezpieczeniem, ale użytkownik musi rozumieć jego rolę. Kod jednorazowy nie jest potwierdzeniem, że strona jest prawdziwa. To sekret uwierzytelniający, którego nie powinno się podawać w procesie rozpoczętym z podejrzanej wiadomości.

Nie należy też upraszczać JWR do stwierdzenia, że „omija każde MFA”. Źródło Talos potwierdza możliwość wyłudzania kodów i sterowania ekranami weryfikacji. Nie daje podstaw, żeby twierdzić, że każda metoda uwierzytelniania zostanie automatycznie przełamana.

Jeżeli chcesz zrozumieć inny model ataku, w którym napastnik próbuje przejąć kontekst uwierzytelnionej sesji, zobacz Browser-in-the-Middle. JWR jest innym przypadkiem: jego najważniejszym wyróżnikiem jest adaptacyjna fałszywa strona sterowana na żywo.

JWR to nie to samo co BlueKit

PHISHLY opisuje już BlueKit i rozwój Phishing-as-a-Service. Tam ważnym elementem jest Browser-in-the-Middle, zdalna sesja logowania oraz ryzyko przejęcia kontekstu po uwierzytelnieniu.

JWR ma inny środek ciężkości. Talos pokazuje fałszywe checkouty i logowania, 44 ekrany oraz dziesiątki instrukcji, które operator wykorzystuje do prowadzenia ofiary przez scenariusz płatniczy. To bardziej przypomina interaktywną rozmowę prowadzoną przez stronę niż statyczny formularz.

Oba przypadki pokazują jednak ten sam szerszy trend: phishing staje się usługą i procesem, a nie pojedynczą stroną.

Dlaczego to może być skuteczne

Adaptacyjny phishing wykorzystuje kilka mechanizmów psychologicznych jednocześnie.

Po pierwsze, zaczyna od codziennego pretekstu. Opłata za drogę albo przesyłkę nie wygląda jak decyzja wysokiego ryzyka.

Po drugie, strona reaguje. Gdy użytkownik widzi kolejne ekrany, błędy i weryfikacje, może uznać, że proces jest bardziej „prawdziwy” niż prosta strona wyłudzająca kartę.

Po trzecie, operator może dopasować przebieg do ofiary. Nie musi każdemu pokazywać dokładnie tego samego kroku.

Po czwarte, końcowe przekierowanie na prawdziwą stronę może zamaskować moment kradzieży danych.

To wszystko sprawia, że szkolenie pracowników nie powinno polegać wyłącznie na szukaniu literówek, złego logo czy dziwnego wyglądu formularza.

Co powinno zatrzymać użytkownika

Najważniejszy sygnał ostrzegawczy pojawia się przed formularzem: wiadomość, której się nie spodziewałeś, prosi o wejście w link i wykonanie płatności lub weryfikacji.

Jeśli sprawa może być prawdziwa, sprawdź ją innym kanałem. Otwórz oficjalną aplikację, samodzielnie wpisz adres serwisu albo skorzystaj z zapisanej wcześniej zakładki. Nie przechodź do płatności z linku w SMS-ie.

Jeżeli strona twierdzi, że karta została odrzucona, nie podawaj od razu drugiej karty. Jeżeli prosi o kolejny kod SMS albo PIN, przerwij proces. Każda dodatkowa prośba o dane zwiększa ryzyko, a nie wiarygodność strony.

W Polsce podejrzany SMS można przekazać na numer 8080, a podejrzaną stronę zgłosić do CERT Polska. Aktualne zasady zgłaszania opisuje Lista Ostrzeżeń CERT Polska.

Co powinny zrobić firmy

Pierwszy krok to rozszerzenie programu awareness poza e-mail. JWR był dostarczany przez SMS, a więc pracownik może zetknąć się z atakiem na prywatnym lub służbowym telefonie, poza klasycznym filtrem pocztowym.

Drugi krok to uczenie decyzji, a nie wyglądu. Użytkownik powinien ćwiczyć zasadę: nie rozpoczynam płatności, logowania ani weryfikacji z linku w nieoczekiwanej wiadomości.

Trzeci krok to jasna ścieżka zgłoszenia. Jeśli pracownik nie wie, komu przekazać podejrzany SMS albo stronę, może po prostu zamknąć okno i nikogo nie poinformować. Organizacja traci wtedy szansę na ostrzeżenie innych osób.

Czwarty krok to techniczne ograniczanie skutków. Filtrowanie DNS i WWW, blokowanie znanych złośliwych domen, ochrona przeglądarki, kontrola urządzeń mobilnych, monitoring logowań i phishing-resistant MFA nadal mają znaczenie. Ale żadne pojedyncze zabezpieczenie nie zastąpi dobrego procesu reakcji.

W szerszym modelu ochrony te elementy opisujemy w materiale Ochrona przed phishingiem w firmie.

Jak ćwiczyć taki scenariusz w security awareness

JWR daje dobry przykład scenariusza, którego nie da się sprowadzić do pytania „czy kliknąłeś link”.

W ćwiczeniu można mierzyć kilka decyzji:

• czy użytkownik wchodzi w link z SMS-a;
• czy zaczyna wpisywać dane osobowe;
• czy podaje dane karty;
• czy po komunikacie „karta odrzucona” próbuje innej;
• czy podaje kod SMS lub 2FA;
• czy przerywa proces i zgłasza wiadomość.

To daje znacznie więcej informacji niż sam współczynnik kliknięć. Firma widzi, na którym etapie użytkownik rozpoznaje ryzyko i czy potrafi wycofać się z pozornie wiarygodnego procesu.

Takie ćwiczenia można włączyć do ciągłego programu security awareness, zamiast ograniczać szkolenia do jednego testu raz w roku. A jeśli organizacja chce mierzyć reakcję pracowników na realistyczne przynęty, punktem wyjścia mogą być również testy phishingowe dla firm.

Najważniejsza zasada: reakcja strony nie dowodzi autentyczności

JWR pokazuje prostą, ale ważną zmianę. Fałszywa strona może wyglądać nie tylko poprawnie. Może także zachowywać się logicznie.

Może odrzucić kartę. Może poprosić o kod. Może zmienić ekran. Może zakończyć proces i przekierować użytkownika do prawdziwego serwisu. Za tymi reakcjami nie musi jednak stać bank ani operator płatności. Może stać człowiek sterujący sesją z panelu przestępczego.

Dlatego użytkownik nie powinien oceniać strony po tym, jak „realistycznie” odpowiada. Najważniejsze pytanie brzmi wcześniej: skąd trafiłem na tę stronę i czy sam rozpocząłem ten proces przez zaufany kanał?

To właśnie jest kompetencja, którą nowoczesny security awareness powinien ćwiczyć.