Mandiant: ShinyHunters eskalują vishing i „kradzież MFA”, by przejmować SSO i okradać SaaS z danych

Wprowadzenie do problemu / definicja luki

Opisany przez Mandiant przypadek nie dotyczy „magicznej” podatności w chmurze ani błędu w samych platformach SaaS. To klasyczna, ale coraz lepiej „uzbrajana” socjotechnika: vishing (voice phishing) + strony podszywające się pod firmowe portale logowania, które wyciągają od ofiary jednocześnie hasło/SSO i kody MFA lub doprowadzają do zarejestrowania nowego urządzenia MFA kontrolowanego przez atakującego.

Atak działa, bo „człowiek w pętli” potrafi zatwierdzić wszystko, jeżeli uwierzy, iż rozmawia z IT/Helpdeskiem — a nowa generacja phishing kitów potrafi w czasie rzeczywistym dopasować to, co widzi ofiara w przeglądarce, do scenariusza rozmowy.

W skrócie

• Google Threat Intelligence Group śledzi aktywność pod kilkoma klastrami: UNC6661, UNC6671 oraz UNC6240 (powiązywany z marką ShinyHunters).
• Kampanie (wczesny–połowa stycznia 2026) polegają na podszywaniu się pod IT i kierowaniu pracowników na „victim-branded” strony kradnące SSO/MFA.
• Po wejściu do środowiska atakujący „pivotują” do aplikacji SaaS i masowo wyciągają dane (m.in. dokumenty i komunikację), a następnie przechodzą do wymuszeń/ekstorsji.
• Kluczowy wniosek obronny: MFA odporne na phishing (FIDO2/passkeys/FastPass) znacząco ogranicza skuteczność tego modelu ataku.

Kontekst / historia / powiązania

Wg Mandiant obserwujemy „rozszerzenie i eskalację” taktyk kojarzonych z wymuszeniami ShinyHunters: rośnie zakres atakowanych platform chmurowych, a presja na ofiarę obejmuje nie tylko e-maile z żądaniem okupu, ale też nękanie personelu i (w niektórych przypadkach) elementy presji operacyjnej.

Ważne jest też rozdzielenie „marki” od wykonawców: GTIG podkreśla, iż śledzi aktywność jako kilka klastrów m.in. po to, by uwzględnić różne partnerstwa i możliwość podszywania się pod wcześniej znane TTP.

Równolegle Okta opisuje ewolucję phishing kitów „pod rozmowę telefoniczną” (vishing), które realnie zwiększają skalę tego typu ataków, bo pozwalają atakującemu sterować przebiegiem logowania ofiary niemal jak operatorem „z pulpitu”.

Analiza techniczna / szczegóły luki

1) Łańcuch ataku (high level)

1. Recon + wybór celu (użytkownicy, aplikacje, numery infolinii/IT).
2. Vishing: telefon „z IT” z pretekstem aktualizacji ustawień MFA / bezpieczeństwa.
3. Victim-branded phishing: ofiara trafia na stronę przypominającą firmowy portal i wpisuje dane.
4. Synchronizacja w czasie rzeczywistym: atakujący na bieżąco wprowadza przechwycone dane do prawdziwego loginu, wywołuje wyzwania MFA i instruuje ofiarę, co ma zatwierdzić/wpisać.
5. Utrwalenie: rejestracja urządzenia MFA kontrolowanego przez atakującego lub przejęcie sesji/OAuth.
6. Drenaż SaaS: dostęp do danych zależny od uprawnień skompromitowanej sesji SSO (często oportunistycznie).
7. Ekstorsja: żądanie okupu, groźby publikacji, dowody kradzieży danych.

2) Klastry i różnice w TTP

• UNC6661: wczesny–połowa stycznia 2026; domeny phishingowe często w formacie <companyname>sso.com / <companyname>internal.com; rejestracje często u NICENIC; widoczny „post-exploitation” w SaaS oraz przypadki wykorzystania przejętej poczty do dalszego phishingu (np. do podmiotów z branży kryptowalut).
• UNC6671: podobny model vishing + „victim-branded” strony, ale domeny częściej rejestrowane przez Tucows; dodatkowo Mandiant widział użycie PowerShell do pobierania wrażliwych danych z SharePoint i OneDrive; ekstorsja bywała niebrandowana i z innym Tox ID, a nękanie personelu pojawiało się jako element presji.

3) Co konkretnie jest celem w SaaS?

Mandiant opisuje wykradanie danych i komunikacji z różnych usług SaaS (w przykładach i logach pojawiają się m.in. ekosystem Microsoft 365, Salesforce oraz DocuSign). W części przypadków atakujący wykonywali też wyszukiwania pod kątem „cennych słów kluczowych” (np. „confidential”, „proposal”, „vpn”), co sugeruje selekcję danych pod presję/ekstorsję.

4) Maskowanie śladów i „living off the land”

Ciekawy detal operacyjny: w co najmniej jednym incydencie, po przejęciu konta klienta Okta, atakujący autoryzował dodatek ToogleBox Recall w Google Workspace i usuwał wiadomości mogące ujawnić rejestrację nowego sposobu MFA („Security method enrolled”). To typowy przykład „ciszy po zalogowaniu” zamiast klasycznego malware.

Praktyczne konsekwencje / ryzyko

• To nie jest „zwykły phishing”: prawdziwym przełomem jest sterowanie sesją ofiary w czasie rzeczywistym, co zwiększa skuteczność choćby przeciwko „lepszemu MFA”, jeżeli nie jest ono phishing-resistant.
• Ryzyko eskalacji przez SSO: pojedyncza udana rozmowa + SSO potrafią dać „szeroki wachlarz” aplikacji do przeszukania i eksportu danych.
• Ekstorsja bez ransomware: model „data theft + szantaż” omija część klasycznych zabezpieczeń endpointowych, a presja czasu (np. ultimatum 72h w opisywanych przypadkach) wymusza szybkie decyzje kryzysowe.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz” wprost pod ten typ kampanii (priorytetyzacja zgodna z rekomendacjami Mandiant + wnioskami Okta):

1) Natychmiastowe działania (containment)

• Odwołaj aktywne sesje i tokeny: wymuś wylogowanie, unieważnij tokeny sesyjne i autoryzacje OAuth w IdP oraz kluczowych SaaS.
• Zablokuj operacje wysokiego ryzyka: ogranicz (czasowo lub politykami) reset haseł, rejestrację nowych urządzeń MFA i zmiany metod MFA — to dokładnie te procesy, które vishing „podrabia”.
• Przejrzyj rejestracje urządzeń/MFA i uprawnienia adminów w IdP (szczególnie niespodziewane przypisanie ról, anomalie geolokacji, logowania z sieci anonimizujących).

2) Utwardzenie (hardening) pod vishing

• Wymuś phishing-resistant MFA: FIDO2/passkeys lub rozwiązania typu FastPass (tam, gdzie to ma sens). Push/SMS/OTP są podatne na „przegadanie” ofiary przez telefon.
• Zasady sieciowe i strefy zaufania: tam gdzie możliwe, ogranicz logowania i akcje administracyjne do znanych lokalizacji/stref (allowlist), a ruch z usług anonimizujących traktuj jako sygnał do polowania (hunting), niekoniecznie automatycznego blokowania „w ciemno”.
• Proces „call-back” dla IT: jeżeli pracownik dostaje telefon „z IT”, powinien oddzwonić na numer z firmowej książki/portalu, nie na numer z wyświetlacza. To proste, ale przez cały czas ekstremalnie skuteczne przeciw vishingowi (a często pomijane).

3) Detekcja i monitoring (SOC)

• Poluj na wzorce: „MFA device enrolled”, nietypowe logowania do konsoli admina IdP, masowe pobrania z SharePoint / OneDrive, użycie PowerShell do pobierania plików, autoryzacje podejrzanych aplikacji OAuth (np. ToogleBox Recall).
• Kontrola domen podobnych do marki: rejestracje w stylu my<company>sso[.]com, <company>support[.]com, <company>okta[.]com, literówki typu acess.
• Zweryfikuj, czy Twoje alerty obejmują nietypowe wolumeny pobrań i wyszukiwania po „wrażliwych słowach” w SaaS.

Różnice / porównania z innymi przypadkami

• „MFA fatigue” vs. „MFA steering”: tu nie chodzi o zalewanie pushami aż ofiara kliknie — chodzi o pełną reżyserię logowania, gdzie kit phishingowy zmienia ekrany w idealnym tempie pod rozmowę. To jakościowo inny poziom „wiarygodności” ataku.
• Ransomware niepotrzebne: o ile organizacja ma dojrzałe backupy i EDR, atakujący przez cały czas może wygrać, kradnąc dane z SaaS i stosując presję reputacyjną/prawną.
• Brak CVE jako „punktu wejścia”: to kampania oparta o procesy (helpdesk, reset MFA) i zachowania ludzi, dlatego testy podatności aplikacji nie wystarczą — potrzebne są ćwiczenia i polityki IAM.

Podsumowanie / najważniejsze wnioski

1. Kampanie przypisywane klastrom powiązanym z marką ShinyHunters pokazują, iż vishing stał się pełnoprawnym wektorem initial access do SSO i SaaS — często skuteczniejszym niż klasyczny e-mailowy phishing.
2. „Zwykłe MFA” nie wystarcza, jeżeli nie jest odporne na phishing: FIDO2/passkeys/FastPass realnie podnoszą poprzeczkę.
3. Obrona musi koncentrować się na sesjach, tokenach, rejestracji urządzeń MFA, logowaniu i detekcji anomalii w SaaS — a nie na poszukiwaniu „jednej podatności”.

Źródła / bibliografia

• Mandiant – „Vishing for Access: Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft” (30 stycznia 2026). (Google Cloud)
• Mandiant – „Proactive Defense Against ShinyHunters-Branded Data Theft Targeting SaaS” (30 stycznia 2026). (Google Cloud)
• Okta – „Phishing kits adapt to the script of callers” (22 stycznia 2026). (Okta)
• BleepingComputer – omówienie kampanii i wątków dot. vishing + MFA/SSO (31 stycznia 2026). (BleepingComputer)
• The Hacker News – streszczenie ustaleń Mandiant (31 stycznia 2026). (The Hacker News)