Wprowadzenie do problemu / definicja luki
Klasyczny phishing „na login” zwykle polega na podsunięciu ofierze statycznej kopii strony logowania (HTML/CSS), która zbiera hasło i czasem kod 2FA. Problem dla przestępców jest prosty: takie klony gwałtownie się „starzeją”, łatwo je fingerprintować i blokować, a każda zmiana interfejsu po stronie prawdziwego serwisu może zdradzić fałszywkę.
Starkiller idzie krok dalej: realizuje atak typu Adversary-in-the-Middle (AiTM) / reverse-proxy phishing, gdzie ofiara wchodzi na stronę pośredniczącą, ale… ogląda prawdziwą stronę logowania serwisu (renderowaną i podawaną przez infrastrukturę napastnika). Dzięki temu MFA może „zadziałać poprawnie”, a mimo to konto zostaje przejęte — bo najważniejszy artefakt to nie sam kod MFA, tylko cookie / token sesyjny pozyskany po udanym logowaniu.
W skrócie
- Starkiller to phishing-as-a-service, który dynamicznie ładuje prawdziwe strony logowania i działa jako reverse proxy między użytkownikiem a adekwatnym serwisem.
- Platforma uruchamia kontener Docker z headless Chrome, co pomaga renderować realny frontend i „nadążać” za zmianami po stronie brandu.
- W pakiecie: keylogger, kradzież cookies/tokenów, podgląd sesji ofiary w czasie rzeczywistym, geotracking, alerty (np. Telegram) oraz analityka kampanii jak w legalnym SaaS.
- To uderza w organizacje, które opierają ochronę tożsamości na „zwykłym” MFA (SMS/TOTP/push), bez mechanizmów phishing-resistant.
Kontekst / historia / powiązania
Reverse-proxy phishing nie jest nowy — od lat istnieją narzędzia i zestawy PhaaS, które pomagają przechwytywać sesje i omijać MFA. Cisco Talos opisywał, iż dzięki gotowym „zestawom” prawie każdy może uruchomić taki atak bez zrozumienia warstwy technicznej, a operatorzy dodają techniki utrudniające automatyczne skanowanie linków czy analizę statyczną.
Nowość Starkillera polega przede wszystkim na opakowaniu (SaaS-owe UX, automatyzacja infrastruktury, niski próg wejścia) i na tym, iż zamiast polegać na szablonach stron logowania, platforma podaje ofierze realną treść z prawdziwej domeny — przez pośrednika.
Analiza techniczna / szczegóły
1. Łańcuch ataku (uproszczony)
- Ofiara dostaje link, który wizualnie przypomina prawdziwy adres (np. sztuczki z formatem URL). Krebs opisuje m.in. wariant z użyciem znaku „@” w URL, gdzie wszystko przed „@” jest traktowane jak „dane użytkownika”, a faktyczny host jest po nim.
- Po kliknięciu Starkiller uruchamia/wykorzystuje przygotowane środowisko: Docker container + headless Chrome, który ładuje prawdziwą stronę logowania brandu.
- Kontener działa jako man-in-the-middle reverse proxy: przekazuje żądania do prawdziwego serwisu i odsyła odpowiedzi do ofiary. Użytkownik widzi autentyczny UI, bo to w praktyce „prawdziwa strona przez pośrednika”.
- W trakcie logowania Starkiller rejestruje każde naciśnięcie klawisza, dane formularzy i — co najważniejsze — tokeny/cookies sesji po udanym logowaniu.
- Po przechwyceniu sesji atakujący może wykonać account takeover bez ponownego przechodzenia MFA (bo ma już „gotową” sesję).
2. Dlaczego to omija MFA „mimo iż działa”
W modelu reverse proxy MFA nie jest „łamane” kryptograficznie. Ofiara naprawdę loguje się do prawdziwego serwisu i naprawdę wpisuje kod/potwierdza push. Różnica polega na tym, iż cały przepływ przechodzi przez infrastrukturę przestępcy, więc ten może przejąć rezultat udanego logowania (cookie/token).
3. Funkcje „platformowe”, które podnoszą skuteczność
- „Panel” operatora do uruchamiania kampanii i kontenerów bez dłubania w certyfikatach/proxy.
- Real-time session monitoring (podgląd interakcji ofiary), alerty i analityka konwersji.
- Elementy maskowania linków (w tym klasyczne triki z URL) i łatwe podszywanie się pod popularne marki.
Praktyczne konsekwencje / ryzyko
Najbardziej narażone są środowiska, gdzie:
- dostęp do poczty, M365/Google Workspace, VPN/SSO i systemów finansowych opiera się na hasło + TOTP/push,
- brakuje spójnej polityki urządzeń (device posture), ograniczeń sesji i analityki tożsamości,
- reakcja na przejęcie konta jest opóźniona (np. brak korelacji logów, brak wykrywania „token replay”, brak reguł „impossible travel”).
W takich warunkach Starkiller ułatwia przejęcie kont uprzywilejowanych i uruchomienie dalszych etapów ataku: BEC, kradzież danych, lateral movement i utrzymanie dostępu przez dodanie nowych metod MFA po stronie konta (częsty pattern w AiTM).
Rekomendacje operacyjne / co zrobić teraz
Ochrona tożsamości (priorytet)
- Włącz i egzekwuj phishing-resistant MFA tam, gdzie to możliwe: FIDO2/WebAuthn / passkeys / klucze sprzętowe (wiązanie z originem utrudnia reverse-proxy phishing). Cisco Talos wprost wskazuje, iż WebAuthn ogranicza ten typ ataku, bo poświadczenia są związane z konkretną domeną/originem.
- Ogranicz żywotność sesji, stosuj Conditional Access: ryzykowne logowania, nowe urządzenia, nietypowe lokalizacje → dodatkowa weryfikacja lub blokada.
Detekcja i telemetry
- Poluj na sygnały AiTM: token/cookie reuse, dwa różne UA/IP na tej samej sesji, „impossible travel”, anomalie w logach SSO.
- W e-mail security ogranicz zaufanie do „ładnego wyglądu” strony: tu strona będzie wyglądać perfekcyjnie, bo jest prawdziwa. Stawiaj na analizę behawioralną i korelację tożsamości.
Higiena kampanii phishingowych
- Twarde reguły dla użytkowników: zawsze sprawdzaj host po „@” i finalną domenę po przekierowaniach; promuj logowanie przez bookmarki/portale, nie z linków w mailu.
- Wdróż szybkie playbooki IR dla przejęcia konta: unieważnianie sesji, reset poświadczeń, przegląd reguł skrzynki (forwarding/inbox rules), przegląd zaufanych urządzeń/metod MFA.
Różnice / porównania z innymi przypadkami
- Klasyczne PhaaS często bazuje na szablonach i „wstrzykniętym” JS. Starkiller w większym stopniu rozwiązuje problem „psujących się” klonów, bo proxy’uje live content.
- Evilginx i podobne narzędzia są znane i szeroko omawiane jako baza dla AiTM; Starkiller jest bliżej gotowego produktu „dla mas” z automatyzacją, panelem i metrykami, co obniża barierę wejścia i przyspiesza skalowanie kampanii.
Podsumowanie / najważniejsze wnioski
Starkiller to kolejny dowód, iż „MFA ≠ koniec phishingu”. Gdy atakujący staje się pośrednikiem sesji (AiTM), najcenniejszym łupem są tokeny i cookies, a nie samo hasło czy kod. W praktyce oznacza to konieczność przesunięcia ciężaru obrony z blokowania „fałszywych stron” na ochronę tożsamości, telemetrię sesji oraz phishing-resistant MFA (WebAuthn/FIDO2).
Źródła / bibliografia
- KrebsOnSecurity — “‘Starkiller’ Phishing Service Proxies Real Login Pages, MFA” (20 lutego 2026). (Krebs on Security)
- Abnormal AI — “Starkiller: New Phishing Framework Proxies Real Login Pages to Bypass MFA” (19 lutego 2026). (Abnormal AI)
- Cisco Talos — “State-of-the-art phishing: MFA bypass” (1 maja 2025). (Cisco Talos Blog)
- Dark Reading — “Best-in-Class ‘Starkiller’ Phishing Kit Bypasses MFA” (19 lutego 2026). (Dark Reading)
- ITPro — “Starkiller: … proxies real login pages” (19 lutego 2026). (IT Pro)
