Wprowadzenie do problemu / definicja luki
„Stanley” to sprzedawany w modelu malware-as-a-service (MaaS) zestaw narzędzi, który umożliwia ataki phishingowe w sposób wyjątkowo podstępny: ofiara widzi w pasku adresu legalny adres strony, ale treść, z którą wchodzi w interakcję, jest podmieniona na phishingową. To uderza w najczęstszy nawyk bezpieczeństwa („sprawdź URL”), bo ten sygnał przestaje być wiarygodny.
W skrócie
- Toolkit „Stanley” był reklamowany na rosyjskojęzycznym forum, z ceną ok. 2–6 tys. USD; wariant premium ma m.in. panel zarządzania i „gwarancję” publikacji w Chrome Web Store.
- Przykładowa wtyczka („Notely”) łączy legalne funkcje z nadużyciami uprawnień przeglądarki, aby przechwytywać wizyty na stronach i nakładać pełnoekranowy phishing.
- Mechanizm opiera się m.in. o osadzanie treści w iframe i (według badaczy) obchodzenie zabezpieczeń typu X-Frame-Options / CSP.
Kontekst / historia / powiązania
Varonis opisuje „Stanley” jako kolejny etap ewolucji ataków „browser-native”: zamiast klasycznych fałszywych domen czy przekierowań – mamy manipulację sesją i treścią w przeglądarce z użyciem rozszerzenia. W tle jest też problem modelu „review-once, update-anytime” w sklepach z dodatkami: rozszerzenie może wyglądać na nieszkodliwe w momencie weryfikacji, a później zmienić zachowanie.
Analiza techniczna / szczegóły luki
1) Dystrybucja i „opakowanie” wtyczki
- W opisywanym przypadku przynętą jest rozszerzenie „Notely” (notatnik/zakładki) z realną funkcjonalnością, ale jednocześnie proszące o uprawnienia pozwalające „widzieć i kontrolować” odwiedzane strony.
- „Stanley” ma oferować różne ścieżki instalacji (w tym Web Store), a panel operatora ułatwia zarządzanie infekcjami i regułami przechwyceń.
2) Panel zarządzania i reguły „URL hijacking”
Operator dostaje webowy panel z listą hostów (identyfikowanych m.in. po IP) oraz możliwością ustawiania par źródłowy URL → docelowy URL (phishing). Istotne jest to, że reguły można aktywować/dezaktywować per ofiara, co umożliwia „atak na żądanie”.
3) Podmiana treści przy zachowaniu legalnego adresu
Z opisu wynika, że rozszerzenie przechwytuje wejście na legalną domenę i nakłada na stronę pełnoekranowy iframe z treścią atakującego – a pasek adresu dalej pokazuje prawdziwą domenę (np. giełdy krypto). To znacząco zwiększa skuteczność kradzieży danych logowania.
4) Obchodzenie zabezpieczeń anty-framing
Varonis wiąże działanie z usuwaniem/obchodzeniem nagłówków X-Frame-Options i polityk CSP (mechanizmy, które mają ograniczać osadzanie strony w ramkach i zmniejszać ryzyko clickjackingu). Jeśli atakujący potrafi doprowadzić do skutecznego framingu, może wiarygodnie „przykleić” phishing do legalnej sesji użytkownika.
5) Komunikacja z C2 i odporność operacyjna
Wtyczka ma mechanizm cyklicznego odpytywania serwera C2 oraz zapasową rotację domen, żeby utrzymać kontrolę nawet po blokadach. Varonis opisał też konkretne wskaźniki (domeny/panel) i fakt zgłoszenia sprawy do Chrome Web Store.
Praktyczne konsekwencje / ryzyko
- Użytkownicy: kradzież haseł, tokenów sesyjnych, danych MFA (np. jednorazowych kodów) – bo atak odbywa się „na żywo”, w kontekście prawdziwego URL.
- Firmy: wzrost skuteczności przejęć kont (ATO) na usługach SaaS/IdP, ryzyko BEC i eskalacji w łańcuchu dostępu (SSO), a także trudniejsza analiza incydentu, bo sygnały „phishing URL” mogą nie zadziałać.
- Zespół SOC: klasyczne szkolenia „sprawdź domenę” stają się niewystarczające – trzeba monitorować rozszerzenia, ruch przeglądarki i anomalie sesji.
Rekomendacje operacyjne / co zrobić teraz
Dla organizacji (IT/SecOps):
- Wymuś allowlistę rozszerzeń (Chrome Enterprise / Edge for Business): blokuj instalację niezatwierdzonych dodatków, ogranicz uprawnienia „read and change data on all websites”.
- Zablokuj znane IoC z raportu (domeny/panel/ID rozszerzenia) na warstwie DNS/Proxy/EDR i monitoruj komunikację przeglądarki do nietypowych domen C2.
- Detekcja zdarzeń związanych z rozszerzeniami: nowe instalacje, nagłe aktualizacje, nietypowe połączenia wychodzące procesu przeglądarki, próby wstrzykiwania treści/ramkowania.
- Wzmocnij tożsamość: FIDO2/WebAuthn (tam, gdzie możliwe), Conditional Access, krótkie sesje, ograniczanie tokenów i kontrola ryzyka logowań (zachowanie/urządzenia).
- Szybka reakcja IR: w razie podejrzenia – izolacja profilu przeglądarki/użytkownika, reset sesji, wymuszenie wylogowań globalnych, rotacja haseł, przegląd uprawnień aplikacji OAuth.
Dla użytkowników:
- Instaluj dodatki tylko, gdy są realnie potrzebne; czytaj zakres uprawnień (szczególnie dostęp do wszystkich stron).
- Jeśli „coś wygląda jak logowanie”, ale pojawiło się nietypowo (np. po powiadomieniu z przeglądarki) – przerwij, otwórz stronę od nowa, sprawdź aktywne rozszerzenia.
Różnice / porównania z innymi przypadkami
- Klasyczny phishing zwykle opiera się o podobną domenę/URL lub przekierowanie. „Stanley” celuje w sytuację, gdzie domena jest prawdziwa, a fałszywa jest warstwa interfejsu.
- To bardziej „man-in-the-browser” niż „fałszywa strona”: rozszerzenie działa z uprawnieniami przeglądarki i może modyfikować zachowanie sesji. W ATT&CK pasuje to do technik związanych z Browser Extensions (T1176) i Browser Session Hijacking (T1185).
Podsumowanie / kluczowe wnioski
„Stanley” pokazuje, że phishing coraz częściej „przeprowadza się” w przeglądarce, a nie tylko „przed przeglądarką”. Gdy pasek adresu przestaje być sygnałem ostrzegawczym, kluczowe stają się: kontrola i monitoring rozszerzeń, egzekwowanie polityk przeglądarkowych oraz twardsze mechanizmy tożsamości (FIDO2/Conditional Access).
Źródła / bibliografia
- SecurityWeek – opis kampanii i cech toolkitu „Stanley”. (SecurityWeek)
- Varonis Threat Labs – analiza techniczna, kontekst, IoC i mechanika działania. (varonis.com)
- MDN Web Docs – clickjacking oraz rola X-Frame-Options / CSP w ograniczaniu osadzania w iframe. (developer.mozilla.org)
- MITRE ATT&CK – T1176 (Software Extensions) i T1185 (Browser Session Hijacking). (attack.mitre.org)
