Złośliwe rozszerzenie Chrome kradnie sesje firmowe

TL;DR

Złośliwe rozszerzenie Chrome może być skutkiem zwykłej wiadomości phishingowej z załącznikiem. Użytkownik widzi dokument, fakturę albo potwierdzenie, ale w tle uruchamia się łańcuch, który instaluje dodatek do przeglądarki i łączy go z komponentem lokalnym w systemie Windows.

Największe ryzyko nie kończy się na haśle. Rozszerzenie może zbierać cookies, informacje o otwartych kartach i kontekst zalogowanych usług. Jeżeli atakujący przejmie aktywną sesję, może próbować działać tak, jakby użytkownik był już poprawnie zalogowany.

Dla organizacji to scenariusz, który łączy phishing, malware, przeglądarkę, tożsamość i reakcję po incydencie. W ćwiczeniach awareness trzeba więc sprawdzać nie tylko kliknięcie w link, ale też reakcję na podejrzany plik, nietypowe rozszerzenie i konieczność szybkiego zgłoszenia.

Co opisuje ten scenariusz

Punktem wyjścia jest kampania opisana przez D3Lab. Wiadomość udawała korespondencję z fakturą, a pobrany plik wyglądał jak PDF. W rzeczywistości był to zaciemniony plik JavaScript z mylącą końcówką .pfd.js. Taki zapis wykorzystuje nieuwagę: przy szybkim spojrzeniu nazwa może wyglądać jak dokument, chociaż system uruchamia skrypt.

Po uruchomieniu pliku pojawiają się kolejne elementy łańcucha. Analiza D3Lab wskazuje na użycie podpisanego programu jako elementu pomocniczego, załadowanie złośliwej biblioteki, uruchomienie PowerShell i przygotowanie rozszerzenia Chrome. Następnie zmieniane są ustawienia polityk przeglądarki tak, aby dodatek wyglądał jak wdrożony administracyjnie, a nie jak zwykła wtyczka dodana przez użytkownika.

To ważne, bo w wielu firmach przeglądarka jest głównym miejscem pracy. Microsoft 365, Google Workspace, CRM, system księgowy, panel HR, system zgłoszeń i bankowość firmowa często działają właśnie w przeglądarce. Gdy przeglądarka traci kontrolę nad sesją, incydent dotyka nie jednego programu, ale wielu procesów biznesowych.

Jak działa złośliwe rozszerzenie Chrome

Samo rozszerzenie działa w przeglądarce, więc może mieć dostęp do danych zależnych od przyznanych uprawnień. Może widzieć cookies, karty, adresy stron, ustawienia językowe i informacje pomagające rozpoznać urządzenie. W legalnym świecie rozszerzenia robią podobne rzeczy po to, aby blokować reklamy, uzupełniać hasła, wspierać narzędzia bezpieczeństwa albo integrować aplikacje firmowe.

Problem zaczyna się wtedy, gdy rozszerzenie zostaje połączone z funkcją Native Messaging. Native Messaging to legalny mechanizm Chrome, który pozwala rozszerzeniu komunikować się z lokalną aplikacją zainstalowaną na komputerze. Korzystają z niego między innymi narzędzia firmowe, menedżery haseł i oprogramowanie bezpieczeństwa.

W opisywanym ataku ta sama funkcja stała się mostem między Chrome a systemem Windows. Rozszerzenie nie musi bezpośrednio uruchamiać programu systemowego. Wysyła komunikat do zarejestrowanego hosta, a komponent lokalny wykonuje działanie po stronie systemu. D3Lab opisało wykorzystanie tego połączenia do uruchamiania poleceń i zbierania danych z przeglądarki.

Dlaczego kradzież sesji zmienia reakcję po incydencie

W klasycznym phishingu z fałszywą stroną logowania organizacja często myśli o haśle. Użytkownik wpisał dane, więc trzeba zmienić hasło, sprawdzić logowania i wymusić dodatkową weryfikację. Przy kradzieży sesji taka reakcja może być za wąska.

Po poprawnym logowaniu aplikacja zapisuje w przeglądarce dane potwierdzające sesję. Dzięki temu użytkownik nie wpisuje hasła przy każdym odświeżeniu poczty, CRM albo panelu księgowego. Jeżeli malware wykradnie te dane, atakujący może próbować kontynuować sesję bez przechodzenia pełnego procesu logowania.

MFA, czyli uwierzytelnianie wieloskładnikowe, nadal ma sens. Ogranicza skuteczność kradzieży samego hasła i utrudnia wiele ataków na konta. Nie usuwa jednak ryzyka, gdy zainfekowane urządzenie ujawnia gotową sesję z przeglądarki. Dlatego ten scenariusz jest bliski zagrożeniom opisanym w artykule o tym, jak infostealer może zastąpić fałszywe logowanie, a także w materiale o phishingu omijającym MFA.

Zmiana hasła może być potrzebna, ale nie powinna być jedynym działaniem. Trzeba unieważnić aktywne sesje, sprawdzić logowania, urządzenia, reguły pocztowe, zgody aplikacji i aktywność w usługach SaaS po czasie otwarcia pliku.

Jak może wyglądać taki atak w polskiej firmie

W polskim kontekście przynęta nie musi dotyczyć włoskiej faktury. Może udawać dokument od biura rachunkowego, skan zamówienia, potwierdzenie przelewu, plik z portalu dostawcy, reklamację, dokument HR, specyfikację od klienta albo załącznik od firmy logistycznej.

Najbardziej narażone są osoby, które codziennie pracują z dokumentami od zewnętrznych nadawców. Dotyczy to księgowości, administracji, zakupów, sprzedaży, HR, recepcji, obsługi klienta i logistyki. W tych zespołach otwieranie plików jest normalną częścią pracy, więc sam załącznik nie uruchamia alarmu.

Dlatego scenariusz warto dopasowywać do branży. Inaczej będzie wyglądał w biurze rachunkowym, inaczej w software house, a inaczej w logistyce. PHISHLY opisuje takie różnice w stronach branżowych, między innymi dla biur rachunkowych, software house i IT oraz transportu i logistyki.

Co powinien zrobić użytkownik

Najważniejsza decyzja zapada przed otwarciem pliku. Użytkownik powinien sprawdzić, czy dokument był oczekiwany, czy nadawca pasuje do sprawy i czy rozszerzenie pliku zgadza się z deklarowaną treścią. Plik, który wygląda jak PDF, ale kończy się na .js, .lnk, .cmd, .bat, .vbs, .scr albo ma nietypową podwójną nazwę, powinien zostać zgłoszony.

Drugi sygnał to zachowanie urządzenia po otwarciu pliku. Jeżeli pojawia się nietypowe okno, prośba o uruchomienie skryptu, nagłe zamknięcie przeglądarki, nowy dodatek Chrome, ostrzeżenie bezpieczeństwa albo widoczna zmiana w ustawieniach przeglądarki, użytkownik powinien przerwać pracę z tym urządzeniem i zgłosić zdarzenie do IT lub Security.

Nie powinien dalej logować się z tego komputera do poczty, banku, systemu księgowego, CRM ani panelu administracyjnego. Każde kolejne logowanie może zwiększać liczbę sesji i danych, które trzeba później unieważniać i analizować.

Dobra zasada dla pracownika brzmi: jeżeli dokument zachowuje się jak program, nie traktuj go jak dokumentu. Zatrzymaj proces i zgłoś plik, zanim zaczniesz szukać obejścia.

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

Jeżeli użytkownik otworzył podejrzany plik, urządzenie powinno zostać odłączone od sieci zgodnie z procedurą organizacji. Nie należy usuwać wiadomości, pliku, historii przeglądarki ani rozszerzeń na własną rękę, jeżeli zespół techniczny może potrzebować tych danych do analizy.

Użytkownik powinien przekazać kontekst: od kogo przyszła wiadomość, jaki był temat, jaki plik został otwarty, o której godzinie to się stało, co pojawiło się na ekranie i do jakich usług logował się później z tego urządzenia. Te informacje pomagają zawęzić okno ryzyka.

Po stronie IT lub SOC priorytetem jest sprawdzenie, czy doszło do kompromitacji punktu końcowego i sesji. W praktyce oznacza to analizę urządzenia, przeglądarki, poczty, proxy, DNS, EDR, logów tożsamości oraz aktywności konta po zdarzeniu.

Jeżeli istnieje ryzyko kradzieży sesji, trzeba wymusić wylogowanie użytkownika ze wszystkich aktywnych sesji, zmienić hasło z czystego środowiska, przejrzeć metody MFA, sprawdzić nowe zgody aplikacji, reguły skrzynki, logowania z nietypowych lokalizacji i urządzenia powiązane z kontem. W środowisku Microsoft Entra ID dokumentacja Microsoft opisuje odwołanie sesji jako jedno z działań awaryjnego odcinania dostępu.

Co powinny sprawdzić IT, Security i SOC

Ten typ incydentu trzeba analizować szerzej niż zwykłe „użytkownik kliknął w załącznik”. Zespół techniczny powinien szukać sygnałów wskazujących na wymuszoną instalację dodatku, nietypowe polityki Chrome, nowy komponent Native Messaging oraz nietypową aktywność PowerShell lub innego procesu uruchomionego po otwarciu pliku.

Warto sprawdzić, czy na urządzeniu pojawiły się nieznane rozszerzenia Chrome, wpisy dotyczące instalacji dodatków przez politykę, nieoczekiwane źródła instalacji, nowe hosty Native Messaging i pliki wykonywalne w katalogach użytkownika. Jeżeli organizacja centralnie zarządza przeglądarką, każdy wyjątek od zatwierdzonej listy dodatków powinien mieć właściciela biznesowego i technicznego.

Po stronie tożsamości trzeba przejrzeć logowania, sesje, urządzenia, reguły pocztowe, zgody OAuth i działania wykonane z konta po czasie infekcji. Jeżeli konto miało dostęp do paneli administracyjnych, finansów, danych HR albo systemów klientowskich, zakres analizy powinien objąć te aplikacje.

Część usług wprowadza mechanizmy wiązania sesji z urządzeniem, na przykład Device Bound Session Credentials w Google Workspace. To pomocna warstwa ograniczająca użycie wykradzionych cookies na innym urządzeniu, ale nie zastępuje analizy endpointu, odwołania sesji i sprawdzenia, co użytkownik robił po infekcji.

Jak ćwiczyć ten scenariusz w security awareness

Taki atak dobrze nadaje się do kontrolowanego ćwiczenia, ponieważ obejmuje kilka realnych decyzji pracownika. Nie chodzi o to, aby uruchamiać malware w symulacji. Chodzi o bezpieczne sprawdzenie, czy użytkownik rozpozna podejrzaną nazwę pliku, nietypowy załącznik, nieoczekiwane zachowanie przeglądarki i właściwy moment zgłoszenia.

W testach phishingowych dla firm można przygotować scenariusz wiadomości z dokumentem, który wymaga weryfikacji innym kanałem. Mierzone powinno być nie tylko kliknięcie, ale też zgłoszenie wiadomości, czas reakcji, liczba osób, które poprosiły o potwierdzenie nadawcy, oraz gotowość IT do przyjęcia zgłoszenia.

W programie security awareness ten temat warto połączyć z krótką lekcją o rozszerzeniach przeglądarki, nazwach plików i sesjach. Pracownicy powinni rozumieć, że przeglądarka przechowuje dostęp do wielu usług, więc podejrzany dodatek nie jest drobiazgiem technicznym.

Taki scenariusz jest też dobrą okazją do sprawdzenia procedury po zgłoszeniu. Organizacja powinna wiedzieć, kto odbiera zgłoszenie, kto izoluje urządzenie, kto odwołuje sesje, kto komunikuje użytkownikowi dalsze kroki i kiedy trzeba uruchomić szerszą analizę incydentu.

Jak ograniczyć ryzyko przed kolejną kampanią

Pierwsza warstwa to higiena poczty i endpointu: filtrowanie załączników, blokowanie typów plików wysokiego ryzyka, kontrola uruchamiania skryptów, EDR, aktualna przeglądarka i centralne zarządzanie dodatkami. Firmy, które używają Chrome w środowisku pracy, powinny mieć jasną listę dopuszczonych rozszerzeń i proces przeglądu wyjątków.

Druga warstwa to tożsamość. MFA nadal jest potrzebne, ale trzeba dodać procedury odwoływania sesji, kontrolę ryzykownych logowań, monitoring zgód aplikacji, przegląd reguł pocztowych i reakcję na nietypowe działania w SaaS. W scenariuszu kradzieży sesji ważna jest szybkość, bo sama zmiana hasła może nie zamknąć wszystkich dróg dostępu.

Trzecia warstwa to człowiek i proces. Pracownik powinien wiedzieć, że podejrzany plik zgłasza się przed otwarciem, a dziwne zachowanie przeglądarki po otwarciu dokumentu jest sygnałem incydentu. IT powinno z kolei traktować takie zgłoszenie poważnie, nawet jeśli użytkownik „tylko otworzył fakturę”.

Jeżeli chcesz przećwiczyć podobny scenariusz w firmie i sprawdzić, czy pracownicy zgłaszają podejrzane pliki we właściwym momencie, możesz porozmawiać z PHISHLY o scenariuszach testów phishingowych.

Konkretna zasada na koniec

Dokument, który wymaga uruchomienia skryptu, instaluje dodatek albo zmienia zachowanie przeglądarki, przestaje być dokumentem. W firmie taki sygnał powinien zatrzymać pracę na urządzeniu, uruchomić zgłoszenie i rozpocząć sprawdzenie aktywnych sesji.