phishing na Google

Phishing na Google to podrobiona strona logowania mająca przejąć konto wraz z powiązanymi usługami.

Architektura i wektory ataku na konta ekosystemu Google

Phishing wycelowany w infrastrukturę Google opiera się na precyzyjnej replikacji interfejsu logowania w architekturze Single Sign-On (SSO), wykorzystywanego przez usługi takie jak poczta, dysk sieciowy, system Android czy platforma deweloperska. Z technicznego punktu widzenia, atak ten nie polega na przełamywaniu zabezpieczeń kryptograficznych na serwerach docelowych, lecz na manipulacji protokołami komunikacyjnymi oraz wykorzystaniu błędów poznawczych użytkownika. Złośliwa witryna przechwytująca dane jest zazwyczaj hostowana na domenie, której adres opiera się na technikach typosquattingu, czyli celowych literówkach, lub atakach homograficznych, gdzie znaki alfabetu łacińskiego zastępowane są wizualnie identycznymi znakami z kodowania Unicode.

Współczesne wektory ataku wykorzystują zautomatyzowane ramy programistyczne do klonowania witryn. Aplikacje takie jak Evilginx2 pozwalają na dynamiczne renderowanie zawartości oryginalnej strony uwierzytelniającej dostawcy w czasie rzeczywistym. Ruch sieciowy między maszyną ofiary a docelowym serwerem jest w tym wariancie przepuszczany przez węzeł kontrolowany przez atakującego. Konfiguracja ta funkcjonuje na zasadzie odwróconego serwera proxy (reverse proxy). Użytkownik widzi autentyczny kod HTML i zasoby graficzne, ponieważ złośliwy serwer proxy pobiera je na bieżąco z prawdziwej infrastruktury Google. Wprowadzone przez użytkownika dane, w tym identyfikator oraz hasło, są rejestrowane w logach systemowych węzła w postaci zdekodowanej, a następnie przekazywane do oryginalnego interfejsu API, aby kontynuować proces logowania.

Zastosowanie architektury odwróconego proxy pozwala na pozyskiwanie nie tylko statycznych poświadczeń, ale również elementów uwierzytelniających zależnych od czasu. Kompromitacja profilu w tak złożonym ekosystemie oznacza dla intruza dostęp do wielu zintegrowanych usług powiązanych jednym identyfikatorem. Atakujący uzyskuje wgląd w archiwum poczty elektronicznej, hasła zsynchronizowane w menedżerze przeglądarki Chrome, historię logów lokalizacyjnych z urządzeń przenośnych oraz repozytoria plików. Serwery dostawcy traktują sesję nawiązaną przez proxy jako sprzętowo i protokólarnie poprawną, co skutecznie opóźnia wykrycie nieautoryzowanego dostępu przez algorytmy korelujące zdarzenia w sieci.

Mechanika przechwytywania sesji oraz omijania uwierzytelniania wieloskładnikowego

Standardowe uwierzytelnianie dwuskładnikowe (2FA), obejmujące kody przesyłane w wiadomościach SMS, aplikacje generujące tokeny czasowe (TOTP) oraz monity autoryzacyjne na urządzeniach mobilnych, wymusiło ewolucję mechanizmów phishingowych. Ataki sklasyfikowane jako AiTM (Adversary-in-the-Middle) stanowią techniczną odpowiedź na implementację dodatkowej warstwy weryfikacji. W momencie wprowadzania loginu i hasła na fałszywej stronie, złośliwy serwer natychmiast przekazuje te pakiety danych do serwerów Google. Jeśli w profilu aktywowano 2FA, system docelowy odsyła żądanie wprowadzenia drugiego składnika, a serwer proxy płynnie wyświetla odpowiedni formularz na ekranie ofiary.

Wprowadzony przez użytkownika kod czasowy lub zatwierdzony monit powoduje, że oprogramowanie atakującego przechwytuje odpowiedź weryfikacyjną i podaje ją do właściwej usługi. Po poprawnej walidacji poświadczeń, infrastruktura dostawcy wystawia ciasteczka sesyjne (session cookies), uprawniające maszynę kliencką do korzystania z zasobów konta bez konieczności powtarzania procesu logowania. Celem ataku AiTM jest ekstrakcja właśnie tych ciasteczek. Skrypty działające po stronie złośliwego serwera kopiują tokeny uwierzytelniające z nagłówków protokołu HTTP tuż przed ostatecznym zwróceniem ich do przeglądarki ofiary. Skopiowane w ten sposób pliki cookie można zaimportować do innej przeglądarki, co zapewnia autoryzowany dostęp z pominięciem jakiejkolwiek dodatkowej weryfikacji tożsamości.

Barierą technologiczną dla ataku proxy są fizyczne klucze kryptograficzne zgodne ze standardami FIDO U2F oraz FIDO2. Architektura ta wykorzystuje kryptografię asymetryczną, która weryfikuje pochodzenie (origin) witryny, na której generowane jest wyzwanie (challenge) kryptograficzne. Przeglądarka internetowa analizuje domenę widoczną w pasku adresu i w przypadku niezgodności z zapisanym parametrem usługi, odmawia wygenerowania podpisu elektronicznego. Metoda sprzętowa jest na ten moment w pełni odporna na ataki polegające na duplikacji żądań HTTP.

Następstwa przejęcia profilu i trudności w weryfikacji tożsamości

Identyfikacja udanego logowania przez podmiot nieuprawniony następuje zwykle ze sporym opóźnieniem w stosunku do czasu incydentu, często dopiero gdy intruz rozpoczyna modyfikację parametrów konfiguracyjnych konta. Standardową procedurą po uzyskaniu dostępu jest próba zapewnienia sobie trwałości sesji, czyli zablokowanie właścicielowi możliwości jej natychmiastowego przerwania. Osiąga się to poprzez zmianę głównego hasła dostępowego, modyfikację zapasowego adresu e-mail oraz nadpisanie numerów telefonów przypisanych do procedury przywracania hasła. W środowisku pocztowym wprowadzane są reguły filtrowania wiadomości, które automatycznie ukrywają komunikaty od administracji Google o nowych, nierozpoznanych urządzeniach i lokalizacjach logowania.

Próby odzyskania dostępu po takich zmianach są procesem złożonym. Zautomatyzowane algorytmy weryfikacji opierają się na analizie sygnatur sprzętowych dotychczasowych urządzeń, zapisanych wcześniej adresach IP oraz wzorcach zachowań. Całkowita zmiana parametrów odzyskiwania przez atakującego sprawia, że mechanizmy uwierzytelniające traktują żądania prawowitego właściciela jako próbę nieautoryzowanego dostępu. Dodatkowo, w przypadku wystąpienia wielu jednoczesnych prób odzyskania konta z różnych lokalizacji geograficznych, system operujący usługą może nałożyć prewencyjną blokadę konta, by zapobiec dalszej eksfiltracji przechowywanych tam zasobów danych.

Kompromitacja loginu systemowego służy nierzadko jako wektor wejściowy do ataku ukierunkowanego bezpośrednio na lokalny sprzęt. Korespondencja rozsyłana z przejętego profilu może zawierać odnośniki prowadzące do pobrania skryptów powłoki systemowej lub złośliwych makr w dokumentach. Ich egzekucja w systemie docelowym skutkuje zazwyczaj pobraniem oprogramowania szpiegującego lub szyfrującego dane, które ingeruje bezpośrednio w strukturę systemu plików na stacji roboczej.

Diagnostyka powłamaniowa i weryfikacja integralności stacji roboczej

Metody pozyskiwania poufnych danych uległy wyraźnemu przekształceniu. W przeszłości incydenty bezpieczeństwa i kradzieże danych logowania często wymagały fizycznej modyfikacji stacji roboczej, stąd wzmianka o starym lub rzadkim sprzęcie jest w tym kontekście w pełni zasadna. Starsze rozwiązania, takie jak sprzętowe keyloggery wpinane szeregowo w gniazda PS/2 na płycie głównej, czy wczesne generacje modyfikowanych wtyków USB ukrywających układy rejestrujące, stanowią obecnie rzadkość w codziennych zgłoszeniach do serwisu. Typowe wektory ataków omijają warstwę sprzętową maszyn, opierając się na eksploitacji luk w oprogramowaniu i socjotechnice. Z tego powodu samo urządzenie rzadko ulega trwałym uszkodzeniom elektronicznym wskutek odwiedzenia spreparowanej witryny, jednak system operacyjny pracujący na tym sprzęcie wymaga dokładnej oceny.

Zabezpieczenie stanowiska komputerowego, na którym wprowadzono poświadczenia w fałszywym formularzu, musi zostać przeprowadzone przed rozpoczęciem prób odzyskania loginu. Warszawskie Pogotowie Komputerowe przeprowadza weryfikację integralności nośników danych i plików systemowych, identyfikując modyfikacje wprowadzone przez niepożądane oprogramowanie. Procedura ta obejmuje skanowanie bloków pamięci masowej w poszukiwaniu nietypowych procesów rezydentnych, analizę gałęzi rejestru oraz harmonogramu zadań systemu operacyjnego, a także wyodrębnienie złośliwych modyfikacji w lokalnych bazach SQLite przeglądarek internetowych, w których przechowywane są sesyjne pliki cookie.

Przy rozległych i złożonych infekcjach systemu plików, dysk twardy wyciągany jest z urządzenia bazowego i diagnozowany w dedykowanym, odizolowanym środowisku za pośrednictwem blokerów sprzętowych uniemożliwiających operacje zapisu na analizowanym nośniku. Zakres tych prac obejmuje także podstawowy odzysk danych, jeśli działanie obcego kodu doprowadziło do uszkodzenia struktur systemowych i uniemożliwiło rozruch komputera. Konieczne jest zaznaczenie, że procedury serwisu ograniczają się stricte do lokalnego środowiska sprzętowego klienta. Zewnętrzne kwestie, takie jak usunięcie blokad na serwerach zewnętrznego usługodawcy, reset haseł na wirtualnych maszynach w chmurze czy zarządzanie zabezpieczeniami po stronie infrastruktury Google, znajdują się całkowicie poza polem manewru podmiotów zajmujących się naprawą sprzętu fizycznego.