Phishing przez adres IPv4 mapowany jako IPv6

TL;DR

SANS Internet Storm Center opisał phishing bankowy, w którym złośliwy link nie używał zwykłej domeny ani klasycznego adresu IPv4. W wiadomości pojawił się adres zapisany w formie przypominającej IPv6, na przykład hxxp://[::ffff:5511:74be]/.... Po rozłożeniu zapisu okazało się, że to adres IPv4 zakodowany w formacie IPv4-mapped IPv6.

Ten zabieg nie sprawia, że phishing staje się magicznie niewykrywalny. Pokazuje jednak ważny problem: proste filtry, skrypty i reguły bezpieczeństwa mogą szukać domen albo klasycznych adresów IP, a pominąć nietypową formę URL. Użytkownik widzi dziwny techniczny link, a system może nie znormalizować go przed oceną.

Dla firm wniosek jest konkretny. Weryfikacja linków nie może polegać wyłącznie na prostym dopasowaniu tekstu. URL trzeba parsować, normalizować i oceniać po rzeczywistym celu połączenia, przekierowaniach oraz kontekście wiadomości. W awareness warto pokazywać, że podejrzany link nie zawsze wygląda jak literówka w domenie banku.

Jak działa adres IPv4 mapowany jako IPv6

Adres IPv4 mapowany jako IPv6 to techniczny sposób reprezentowania adresu IPv4 w formacie IPv6. RFC 4291 opisuje format, w którym część adresu IPv6 zawiera osadzony 32-bitowy adres IPv4. W praktyce często pojawia się prefiks ::ffff:, a końcowe bity reprezentują właściwy adres IPv4.

W przykładzie opisanym przez SANS link miał postać podobną do:

hxxp://[::ffff:5511:74be]/kWC5PHA1

Nawiasy kwadratowe w URL mówią parserowi, że wewnątrz znajduje się literalny adres IPv6. To normalna składnia dla adresów IPv6 w URL, bo dwukropki mogłyby pomylić się z separatorem portu. Problem polega na tym, że zapis ::ffff:5511:74be nie jest zwykłym adresem IPv6 w sensie użytkowym. Końcówka zawiera zakodowane oktety adresu IPv4.

SANS rozłożył ten przykład na wartości szesnastkowe i dziesiętne. 0x55, 0x11, 0x74 i 0xBE odpowiadają kolejno wartościom 85, 17, 116 i 190. W efekcie realny adres URL prowadził do adresu IPv4 85.17.116.190, a następnie przekierowywał do właściwego zestawu phishingowego.

Dla zwykłego użytkownika to szczegół techniczny. Dla zespołów bezpieczeństwa to sygnał, że link trzeba oceniać po znormalizowaniu, a nie tylko po tym, jak wygląda w treści wiadomości.

Dlaczego taki link może pomóc atakującemu

Atakujący nie używa takiego zapisu po to, aby zachwycić się IPv6. Używa go, aby utrudnić detekcję i analizę. Wiele prostych kontroli bezpieczeństwa szuka w wiadomościach domen, klasycznych adresów IPv4 albo typowych wzorców URL. Jeśli reguła działa jak proste wyrażenie regularne, nietypowy zapis może przejść obok niej.

To szczególnie istotne w phishingu bankowym. Wiadomość może wyglądać jak klasyczny komunikat o bankowości elektronicznej, ale link nie musi zawierać domeny podobnej do banku. Może prowadzić przez adres IP zapisany w formie, której część narzędzi nie rozpozna od razu. Po kliknięciu użytkownik zostaje przekierowany dalej, już do strony z właściwym panelem wyłudzającym dane.

W takim modelu adres startowy pełni rolę kamuflażu. Nie musi być końcowym miejscem ataku. Wystarczy, że przeniesie użytkownika przez pierwszy etap, utrudni automatyczną analizę albo opóźni reakcję.

To przypomina inne techniki używane w phishingu: skracacze linków, wiele przekierowań, CAPTCHA, legalne platformy hostingowe, zagnieżdżone linki w plikach PDF albo strony pośrednie. Różnica polega na tym, że tutaj kamuflaż znajduje się w samej składni adresu URL.

Co widzi użytkownik

Użytkownik nie musi rozumieć IPv6, aby prawidłowo zareagować. W praktyce powinien zauważyć coś prostszego: link do banku nie powinien wyglądać jak techniczny adres IP w nawiasach kwadratowych.

Jeżeli wiadomość rzekomo pochodzi od banku, operatora płatności, urzędu, dostawcy SaaS albo systemu firmowego, a link zaczyna się od nietypowego adresu, nie należy go otwierać. Banki i duże usługi nie wymagają logowania przez losowy adres IP, skrócony link albo URL, którego użytkownik nie potrafi powiązać ze znaną domeną.

Warto też pamiętać, że brak klasycznej literówki w domenie nie oznacza bezpieczeństwa. Użytkownicy często uczą się rozpoznawać phishing przez podobne domeny, takie jak dodatkowa kreska, zmieniona litera albo obcy sufiks. Ten przykład pokazuje inną sytuację: domeny może nie być wcale.

To dobry temat do edukacji, bo pomaga przesunąć uwagę z jednego prostego pytania czy domena wygląda podobnie do prawdziwej na lepsze pytanie: czy cała ścieżka logowania ma sens.

Polski i firmowy kontekst

Choć opisany przykład dotyczył banku z Belgii, ten sam mechanizm może zostać użyty w Polsce. Przynęta może podszywać się pod bank, BLIK, operatora płatności, firmę kurierską, urząd skarbowy, system kadrowy, dostawcę hostingu albo firmowy portal logowania.

W polskiej firmie taki link mógłby pojawić się w wiadomości o blokadzie konta bankowego, potwierdzeniu przelewu, aktualizacji danych, zwrocie podatku, weryfikacji konta pocztowego albo dostępie do dokumentu. Scenariusz nie zależy od marki. Zależy od tego, czy odbiorca uzna wiadomość za pilną i kliknie bez sprawdzenia kanału.

Dla organizacji to ważne również poza bankowością. Jeżeli użytkownik poda dane do firmowej poczty, Microsoft 365, Google Workspace, systemu ERP, CRM albo panelu HR, skutkiem może być przejęcie konta, kradzież sesji, dalszy phishing, BEC albo dostęp do danych kontrahentów.

Dlatego ten temat dobrze łączy się z edukacją o linkach, ale także z techniczną stroną obrony. Użytkownik ma przerwać proces, a systemy bezpieczeństwa mają normalizować URL i sprawdzać, dokąd naprawdę prowadzi.

Co powinien zrobić użytkownik

Jeżeli wiadomość prowadzi do logowania, płatności albo weryfikacji danych, użytkownik nie powinien oceniać linku wyłącznie wzrokiem. To szczególnie ważne, gdy link wygląda technicznie, zawiera nawiasy kwadratowe, dwukropki, adres IP, nietypowy zapis albo krótką ścieżkę bez jasnej domeny.

Najbezpieczniejsza reakcja jest prosta: nie otwierać linku z wiadomości i wejść do usługi znanym kanałem. W przypadku banku oznacza to aplikację mobilną, ręcznie wpisany adres albo zakładkę zapisaną wcześniej. W przypadku systemu firmowego oznacza to firmowy portal aplikacji, menedżera haseł albo intranet.

Jeżeli wiadomość dotyczy płatności, blokady, mandatu, zwrotu środków albo aktualizacji danych, warto potraktować ją jak próbę wywołania presji. Atakujący chce, aby użytkownik działał szybko i nie sprawdził, czy adres logowania ma sens.

Podejrzaną wiadomość należy zgłosić do IT, Security albo przez wewnętrzny przycisk raportowania. Jeśli organizacja prowadzi testy phishingowe dla firm, taki scenariusz warto omawiać nie jako zagadkę z IPv6, ale jako przykład nietypowego linku, którego nie wolno traktować jako normalnej ścieżki logowania.

Co powinny zrobić IT, Security i SOC

Zespoły IT i Security powinny założyć, że atakujący będą korzystać z nietypowych reprezentacji adresów, jeśli proste filtry dają się obejść. Dotyczy to nie tylko IPv4-mapped IPv6, ale też adresów zapisanych dziesiętnie, szesnastkowo, przez przekierowania, skracacze i legalne platformy pośrednie.

Podstawą jest normalizacja URL przed oceną. System powinien rozumieć, że zapis w nawiasach kwadratowych może reprezentować adres IPv6, a w części przypadków adres IPv4 osadzony w formacie IPv6. Następnie powinien ocenić rzeczywisty adres, reputację celu, przekierowania, certyfikaty, historię domeny i kontekst wiadomości.

Nie wystarczy reguła typu znajdź domenę lub znajdź klasyczny adres IPv4. Takie podejście może pominąć link, który parser przeglądarki lub narzędzia HTTP obsłuży poprawnie. SANS już wcześniej pokazywał, że przeglądarki i wybrane narzędzia potrafią obsługiwać adresy IPv4 mapowane jako IPv6, a na poziomie sieci ruch może skończyć jako zwykły IPv4.

SOC powinien zwrócić uwagę na kilka sygnałów: wiadomości z literalnymi adresami IP, URL z nawiasami kwadratowymi, prefiks ::ffff:, przekierowania z adresów IP do domen phishingowych, brak rekordu DNS na pierwszym etapie oraz logowania do paneli bankowych lub firmowych po przejściu przez nietypową ścieżkę.

W firmach dojrzałych warto dodać takie przypadki do testów detekcji i parserów. To dobry przykład, który sprawdza, czy narzędzia bezpieczeństwa analizują URL tak, jak zrobi to przeglądarka, a nie tak, jak najprostszy skrypt.

Co zrobić, jeśli to już się stało

Jeżeli użytkownik kliknął link, ale nie podał danych, powinien zgłosić wiadomość i link do IT lub Security. Zespół może sprawdzić przekierowania, zablokować adresy i ustalić, czy podobne wiadomości trafiły do innych osób.

Jeżeli użytkownik podał login i hasło do banku, poczty lub systemu firmowego, trzeba natychmiast zmienić hasło, unieważnić aktywne sesje i sprawdzić wieloskładnikowe uwierzytelnianie, czyli MFA. W przypadku kont firmowych należy przejrzeć logowania, reguły pocztowe, aplikacje z dostępem do konta i nietypowe operacje.

Jeżeli użytkownik podał dane karty, należy skontaktować się z bankiem, zastrzec kartę lub ograniczyć jej użycie zgodnie z procedurą banku oraz sprawdzić transakcje. W przypadku firmowej karty płatniczej trzeba powiadomić finanse i osobę odpowiedzialną za rozliczenia.

Jeżeli po kliknięciu pobrano plik albo uruchomiono coś na komputerze, urządzenie powinno zostać potraktowane jako potencjalnie skompromitowane. Nie należy kasować artefaktów przed kontaktem z IT/Security, bo historia przeglądarki, pobrany plik, logi i pamięć systemu mogą pomóc w ustaleniu zakresu incydentu.

Jak ćwiczyć ten scenariusz w awareness

Ten przypadek dobrze nadaje się do ćwiczeń, ale nie powinien być przedstawiany użytkownikom jako lekcja z IPv6. Lepszy wniosek brzmi: jeśli link do ważnej usługi wygląda technicznie, nietypowo albo nie prowadzi przez znany kanał, trzeba przerwać proces.

W kontrolowanym ćwiczeniu można pokazać użytkownikom kilka wariantów linków: domenę z literówką, skrócony link, link przez legalną platformę, kod QR oraz adres zapisany jako literalny IP. Następnie warto zapytać nie tylko, który link jest podejrzany, ale dlaczego żadna pilna wiadomość nie powinna wymuszać logowania poza znaną ścieżką.

Dla IT i SOC taki scenariusz można potraktować jako test parserów, sandboxów, filtrów URL i reguł SIEM. Celem nie jest nauczenie każdego pracownika rozkładania adresu ::ffff: na oktety. Celem jest sprawdzenie, czy organizacja nie ufa prostym wzorcom bardziej niż rzeczywistej analizie linku.

Konkretna zasada na koniec

Nietypowy adres URL nie musi być zrozumiały dla użytkownika, aby był niebezpieczny. Jeżeli link do banku, poczty lub systemu firmowego nie prowadzi przez znany, ręcznie wybrany kanał, użytkownik powinien przerwać proces, a organizacja powinna mieć narzędzia, które oceniają znormalizowany cel linku, nie tylko jego wygląd w wiadomości.