Archiwa: Phishing - Strona 83 z 98 - Security Bez Tabu

Tag: Phishing

Google pozywa chińskich cyberprzestępców stojących za zestawem phishingowym „Lighthouse” (smishing-as-a-service)

Wprowadzenie do problemu / definicja luki

Google złożył w Sądzie Okręgowym Południowego Dystryktu Nowego Jorku (SDNY) pozew cywilny przeciwko 25 nieznanym z nazwiska osobom, powiązanym z chińskojęzyczną grupą przestępczą określaną jako Smishing Triad, która oferowała platformę phishing-as-a-service (PhaaS) o nazwie Lighthouse do prowadzenia masowych kampanii smishingu (fałszywych SMS-ów). W pozwie Google żąda m.in. odszkodowania oraz nakazów sądowych mających rozbić infrastrukturę operacji. Sprawa figuruje jako Google v. Does 1–25.

W skrócie

  • Skala: ponad 1 mln ofiar w >120 krajach; około 200 tys. fałszywych witryn wygenerowanych w 20 dni; w USA od 12,7 mln do 115 mln skradzionych numerów kart (szacunki z dokumentów i analiz towarzyszących).
  • Modus operandi: zestaw PhaaS „Lighthouse” dostarczał setki gotowych szablonów podszywających się pod znane marki (np. USPS/E-ZPass/Google), generator stron, obsługę rozsyłki przez SMS/iMessage/RCS i back-end do zbierania danych.
  • Podstawa prawna: pozew opiera się m.in. na RICO, Lanham Act (naruszenie znaku towarowego), oraz CFAA – z żądaniem nakazów blokujących infrastrukturę i przekazywania domen.

Kontekst / historia / powiązania

Smishing Triad działa co najmniej od 2023 r., rozwijając model „cyberprzestępczości jako usługi”. Zestaw Lighthouse był sprzedawany w modelu subskrypcyjnym i reklamowany w kanałach społecznościowych (np. Telegram/YouTube) jako proste w użyciu „narzędzie do kampanii”, co obniżało próg wejścia dla operatorów oszustw. Google podkreśla, że część szablonów nadużywała brandingu Google (ponad sto wariantów ekranów logowania).

Wątek Lighthouse przewijał się w pracach dziennikarskich i analizach firm bezpieczeństwa, które opisywały kampanie „niedoręczonej paczki”, „nieopłaconych opłat drogowych” czy „blokady konta” – wszystkie prowadzące do stron wyłudzających dane logowania, karty i PII.

Analiza techniczna / szczegóły luki

Architektura PhaaS Lighthouse (rekonstrukcja z pozwu i relacji):

  • Warstwa front-end: setki szablonów phishingowych imitujących popularne serwisy i instytucje (np. USPS/E-ZPass/Google). Szablony zawierały gotowe formularze, logotypy, treści dopasowane językowo i geograficznie. Część z nich wykorzystywała elementy Google (ekrany sign-in), co wzmacniało wiarygodność.
  • Generator witryn / panel operatora: możliwość automatycznego tworzenia tysięcy domen/hostów w krótkim czasie (ok. 200 tys. w 20 dni), podmiany treści i dynamicznego routingu ofiar.
  • Kanały dostarczania: kampanie SMS (smishing), a także iMessage oraz RCS; treści wiadomości zawierały pretexty takie jak „zaległa opłata”, „dopłata do przesyłki”, „aktualizacja danych”, z jedno-klikowymi linkami.
  • Back-end pozyskiwania i monetyzacji: agregacja przechwyconych poświadczeń i danych płatniczych, opcje powiadomień w czasie rzeczywistym (tzw. real-time phishing), a następnie dostęp do kont/ofiar lub odsprzedaż danych. Szacunki dotyczące samych kart w USA sięgają 12,7–115 mln rekordów.
  • Ewazja i żywotność kampanii: rotacja domen, hosting u wielu dostawców, skracacze linków, dopasowanie treści do geolokalizacji, a także szybkie spin-up/spin-down kampanii – to wszystko utrudniało blokowanie. (Wnioski oparte na opisach automatyzacji i skali w pozwie).

Warstwa prawna jako wektor „techniczny”: Google równolegle stosuje „takedown by litigation”: wnioski o tymczasowe zakazy i nakazy przekazania domen/serwerów mają na celu unieszkodliwianie infrastruktury w trybie pilnym, a nie wyłącznie identyfikację osób. Pozew przywołuje RICO, Lanham Act i CFAA, by uderzyć w organizację (wzorzec działalności przestępczej), nadużycie marek i nieuprawniony dostęp/naruszenia komputerowe.

Praktyczne konsekwencje / ryzyko

  • Dla użytkowników: rosnąca „industrializacja” smishingu – nawet mało techniczni przestępcy mogą uruchamiać wiarygodne kampanie z lokalizowanymi treściami. W efekcie wzrost kradzieży środków, przejęć kont i wyłudzeń.
  • Dla firm: eskalacja ataków inicjowanych z mobile (SMS/RCS/iMessage), obejście filtrów e-mail, „brand abuse” (podszywanie się pod firmę) oraz ryzyko account takeover pracowników i klientów, co uderza w reputację i KPI bezpieczeństwa (fraud loss, chargebacki).
  • Dla ekosystemu bezpieczeństwa: presja na rejestrowanie i sinkholing domen w tempie odpowiadającym automatyzacji PhaaS, konieczność szybkich współprac prawnych i międzysektorowych (rejestratorzy, operatorzy telekomunikacyjni, dostawcy chmury).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów SOC/CSIRT:

  1. Blokowanie na poziomie DNS/HTTP: wdroż rapid blocklist ingestion z feedów TLP:CLEAR oraz własnych sinkholi; automatyczna kwarantanna nowych domen z niskim stażem (domain age < 7 dni) kierujących do stron „płatności” lub „śledzenia paczki”. Przykładowa reguła Sigma (HTTP proxy) wykrywająca smishingowe pretexty w URL/tytule: title: Suspicious Parcel/Toll Payment Landing id: 8d9f3d2a-9b2b-4f9a-96f2-lighthouse status: experimental logsource: product: webserver service: http detection: sel: cs_uri_stem|contains: - "/pay" - "/toll" - "/parcel" - "/usps" - "/e-zpass" cs_host|re: "(track|parcel|delivery|toll|invoice)[-.][a-z0-9-]{3,}\\.(com|top|shop|cfd|xyz)$" condition: sel level: medium tags: [smishing, phishing, lighthouse, brand-abuse] (dostosuj listę TLD/pretekstów do własnej telemetrii; reguła ma charakter heurystyczny).
  2. Filtry SMS/MDM: dla urządzeń zarządzanych – polityki MDM blokujące klikalność adresów URL w SMS od nieznanych nadawców oraz filtrowanie RCS/iMessage przy użyciu wbudowanych API anty-spam (gdzie to możliwe).
  3. Analiza behawioralna front-end: tworzenie fingerprintów stron (CSP, ładowane zasoby, kolejność żądań) zamiast pojedynczych IOC. Lighthouse generował ogromne wolumeny domen – sygnatury „szablonów” są trwalsze niż same hosty. (Wniosek z opisanej masowej automatyzacji).
  4. Playbook prawny i takedown: opracuj szybkie ścieżki z rejestratorami i dostawcami chmury (kontakt 24/7, wzory wniosków). Skorzystaj z precedensów: pozwy w oparciu o Lanham Act i wnioski o nakazy mogą przyspieszyć blokady i transfer domen.

Dla zespołów Fraud/Trust & Safety:

  • MFA + polityka „step-up”: wymuszaj dodatkowe uwierzytelnienie przy wprowadzaniu danych karty lub zmianie danych adresowych, jeśli użytkownik przeszedł z ruchu mobilnego z SMS/skracanego URL.
  • „No-link” UX w powiadomieniach: w komunikacji do klientów (SMS/e-mail) rezygnuj z klikalnych linków – kieruj do aplikacji lub domeny tylko wpisywanej ręcznie.

Dla użytkowników końcowych:

  • Nigdy nie klikaj linków z SMS o „zaległej opłacie”/„przesyłce”. Zamiast tego samodzielnie wpisz adres instytucji lub użyj oficjalnej aplikacji.
  • Włącz MFA i alerty transakcyjne; rozważ zastrzeżenie możliwości transakcji z card-not-present bez 3-D Secure.

Różnice / porównania z innymi przypadkami

  • Wobec klasycznych „phishing kits”: Lighthouse to pełny PhaaS – nie tylko szablony, ale i masowa orkiestracja kampanii (domeny, dystrybucja, panel), co przypomina wcześniejsze platformy e-crime (np. bulletproof SMS-spam), ale z większą automatyzacją i gotowymi brand-pretextami.
  • Wobec kampanii e-mail: smishing omija część filtrów e-mail i DLP; atak zaczyna się w kanale, gdzie użytkownicy są mniej wyczuleni na weryfikację nadawcy i gdzie brak SPF/DKIM/DMARC.
  • Wobec działań prawnych Big Tech: Google łączy strategie techniczne i prawne (takedown + pozew na RICO/Lanham/CFAA), co wpisuje się w rosnący trend „hardeningu” ekosystemu poprzez precedensy prawne.

Podsumowanie / kluczowe wnioski

  • Industrializacja smishingu dzięki PhaaS „Lighthouse” doprowadziła do kampanii o bezprecedensowej skali (setki tysięcy domen w dni). Automatyzacja > IOC – obrona musi przejść na fingerprinting i blokowanie klas zdarzeń.
  • Prawo jako broń defensywna: połączenie działań technicznych z pozwami w trybie cywilnym (RICO/Lanham/CFAA) może szybciej wygaszać infrastrukturę i zniechęcać operatorów.
  • Priorytet mobilny: kanały SMS/RCS/iMessage to dziś „pierwsza linia” socjotechniki – wymagają dedykowanych polityk MDM, filtrów i edukacji użytkowników.

Źródła / bibliografia

  • SecurityWeek: „Google Sues Chinese Cybercriminals Behind ‘Lighthouse’ Phishing Kit”. (SecurityWeek)
  • Google – wpis na blogu dot. działań prawnych wobec „Lighthouse”. (blog.google)
  • Reuters – relacja z pozwu (SDNY, Does 1–25, skala operacji). (Reuters)
  • Dark Reading – podstawy prawne (RICO, Lanham Act, CFAA). (Dark Reading)
  • The Record – szczegóły o 200 tys. domen w 20 dni i nadużyciu brandingu Google. (The Record from Recorded Future)

NHS: Synnovis zaczyna informować pacjentów o publikacji danych – po ataku Qilin z czerwca 2024 r.

Wprowadzenie do problemu / definicja luki

Synnovis – dostawca usług diagnostyki laboratoryjnej dla kilku londyńskich trustów NHS – został 3 czerwca 2024 r. zaatakowany przez grupę ransomware Qilin. Skutkiem były poważne zakłócenia świadczeń, a część danych pacjentów trafiła na stronę wyciekową przestępców. Po zakończeniu długiej analizy śledczej Synnovis rozpoczął teraz formalny proces powiadamiania organizacji NHS, których dane znajdują się w zbiorze wykradzionym i opublikowanym przez napastników. Zgodnie z brytyjskim prawem to poszczególni świadczeniodawcy mają informować konkretnych pacjentów.

W skrócie

  • Kto? Synnovis (usługi patologii i diagnostyki) – partner m.in. King’s College Hospital i Guy’s & St Thomas’. Atakujący: Qilin (ransomware).
  • Kiedy? Atak 3 czerwca 2024 r.; dane opublikowano w czerwcu 2024 r.; aktualizacja: Synnovis zakończył przegląd śledczy i do 21 listopada 2025 r. przekaże powiadomienia do wszystkich organizacji, których dane są w zbiorze.
  • Co wyciekło? M.in. dane identyfikacyjne (imię, nazwisko, data urodzenia, numer NHS) oraz formularze patologii/histopatologii, czasem z wrażliwymi objawami (np. nowotwory, choroby przenoszone płciowo).
  • Skala? Analizy podmiotów trzecich sugerują >900 tys. osób dotkniętych – oficjalny licznik nie został podany.
  • Wpływ kliniczny: tysięczne odwołania wizyt i zabiegów; w mediach branżowych odnotowano powiązanie incydentu z co najmniej jednym zgonem.

Kontekst / historia / powiązania

Po ataku z 3 czerwca 2024 r. w regionie południowo-wschodniego Londynu odwoływano zabiegi i wizyty, szczególnie dotknięte były banki krwi oraz planowe operacje. W kolejnych tygodniach Qilin zaczął publikować próbki skradzionych danych, w tym rekordy badań dotyczących m.in. HIV i nowotworów. W 2025 r. – w miarę prac analitycznych – NHS na bieżąco publikował Q&A dla opinii publicznej. 10 listopada 2025 r. pojawiła się informacja, że śledztwo Synnovis zostało domknięte i rusza sekwencja powiadomień na poziomie organizacji (trusty, GP, inne podmioty).

Analiza techniczna / szczegóły luki

Łańcuch ataku i TTPs (wysoki poziom): Qilin to ekosystem RaaS stosujący klasyczny model double extortion – szyfrowanie + publikacja danych na stronie wyciekowej. Po początkowym włamaniu (wektor nie został publicznie potwierdzony), atakujący uzyskali dostęp do systemów Synnovis, co doprowadziło do zakłóceń usług oraz eksfiltracji plików. Publikacja danych miała charakter stopniowy (samples → większe paczki), co jest typową taktyką zwiększania presji. (Wnioski na bazie raportów prasowych i komunikatów instytucji; brak pełnej publikacji IOCs przez Synnovis/NHS.)

Charakter danych: Najbardziej wrażliwą część stanowiły formularze patologia/histologia, które służą do przekazywania informacji między jednostkami medycznymi – zawierają opisy objawów i kontekstu klinicznego (np. podejrzenie STI, rodzaj zmiany nowotworowej). Zidentyfikowano także dane identyfikacyjne i, w części przypadków, dane kontaktowe. To dokładnie te typy informacji, które w kontekście RODO (UK GDPR) kwalifikują się jako szczególne kategorie danych osobowych.

Dlaczego analiza trwała tak długo? Synnovis informuje, że skradziony zestaw był „nieustrukturyzowany, niekompletny i fragmentaryczny”, co wymagało użycia specjalistycznych platform do korelacji i odtwarzania właścicieli danych (data controllers/processors). Dopiero po takim forensicu możliwe było mapowanie rekordów do konkretnych organizacji NHS i ich pacjentów. Ten etap zakończono i wyznaczono termin zakończenia powiadomień organizacji na 21 listopada 2025 r.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko prywatności: Ujawnienie informacji o stanie zdrowia (STI, onkologia) może prowadzić do szkód psychologicznych, stygmatyzacji, szantażu i doxingu. Nawet bez numerów dokumentów medyczne formularze mają wysoką wartość dla oszustów (phishing na „wyniki badań”, podszywanie się pod NHS).
  2. Ryzyko oszustw ukierunkowanych: SEL ICS i NHS podkreślają, że Synnovis nie kontaktuje pacjentów bezpośrednio – powiadomienia przyjdą z organizacji NHS. Każda prośba o dane/ płatność „w imieniu Synnovis” powinna być traktowana jako phishing.
  3. Ryzyko operacyjne: Zakłócenia w bankach krwi i diagnostyce obrazują, jak ataki na laboratoria wpływają kaskadowo na cały łańcuch świadczeń (od kwalifikacji do zabiegu po opiekę pooperacyjną). Media branżowe odnotowały także związek incydentu z co najmniej jednym zgonem.

Rekomendacje operacyjne / co zrobić teraz

Dla organizacji NHS, laboratoriów i dostawców (CIO/CISO/IG Leads)

  1. Proces powiadomień i rejestr
    • Skonsoliduj listy pacjentów zgodnie z informacją od Synnovis; przygotuj szablony pism, FAQ i landing page z aktualnościami.
    • Zadbaj o spójność komunikacji: „powiadamia organizacja NHS, nie Synnovis”.
  2. Zarządzanie ryzykiem prawnym i zgodnością
    • Rewizja DPIA/ROPA dla strumieni danych patologii/histologii; wzmocnienie podstaw przetwarzania i minimalizacji danych.
    • Przygotuj odpowiedzi na pytania ICO i pacjentów dotyczące kategorii danych oraz okresów retencji.
  3. Bezpieczeństwo techniczne (priorytety krótkoterminowe)
    • Segmentacja i zasada najmniejszego uprzywilejowania między LIS/LIMS, PACS, EPR/EMR i interfejsami wymiany (HL7/FHIR).
    • Backupy offline i procedury odtwarzania LIMS; testy odtworzeniowe.
    • Monitoring wycieku danych: wyszukuj artefakty Synnovis w SIEM/TI (skrótowe nazwy formularzy, formaty zleceń, identyfikatory).
    • Kontrola poczty i alerty anty-phishingowe na kampanie podszywające się pod NHS/Synnovis (DMARC, brand indicators).
    • Wymuszenie MFA i kluczy sprzętowych dla dostępów uprzywilejowanych do LIMS/VPN/VDA.
  4. Długoterminowo
    • Zero Trust dla integracji laboratoryjnych; broker API / gateway z inspekcją treści HL7/FHIR, DLP i tokenizacją pól wrażliwych.
    • Klastry izolowane dla przetwarzania formularzy patologii; szablony formularzy pozbawione wolnego tekstu, by ograniczyć wrażliwe narracje kliniczne.
    • Szczegółowe runbooki: tryby „degradacji” usług (paper-back, priorytetyzacja badań krytycznych, manualne transfuzje).

Dla pacjentów

  • Sprawdzaj aktualizacje na stronach swojego świadczeniodawcy/NHS; nie odpowiadaj na SMS/e-maile proszące o płatności lub dane w imieniu Synnovis.
  • Jeśli obawiasz się ekspozycji, wystąp o notatkę w dokumentacji („flag for enhanced verification”) i rozważ kod bezpieczeństwa do umawiania wizyt.

Różnice / porównania z innymi przypadkami

W porównaniu z typowymi incydentami w szpitalach, atak na dostawcę patologii generuje efekt domina: jeden LIMS obsługuje wiele trustów i GP, więc pojedynczy punkt awarii paraliżuje szeroki obszar. To tłumaczy tysięczne odwołania świadczeń w Londynie po czerwcu 2024 r. – skala zaburzeń była większa niż przy wielu pojedynczych atakach na szpitale, bo dotyczyła wspólnego węzła usługowego.

Podsumowanie / kluczowe wnioski

  • Synnovis zakończył badanie forensyczne i do 21 listopada 2025 r. powiadomi wszystkie organizacje NHS, których dane znalazły się w wycieku Qilin; następnie to te organizacje zaczną kontaktować pacjentów.
  • Najbardziej wrażliwe były formularze patologii/histologii – ryzyko szkód prywatności i celowanych oszustw jest realne.
  • Systemowa odporność łańcucha diagnostycznego (LIMS ↔ EPR/EMR ↔ banki krwi) to priorytet: segmentacja, backupy offline, runbooki degradacji i Zero Trust dla interfejsów klinicznych.

Źródła / bibliografia

  1. Synnovis – komunikat: zakończenie przeglądu forensycznego i harmonogram powiadomień (11–12 listopada 2025). (Synnovis)
  2. NHS England – strona incydentu Synnovis i Q&A (aktualizacja 10 listopada 2025). (NHS England)
  3. The Record (Recorded Future News) – informacja o rozpoczynających się powiadomieniach pacjentów i tle sprawy. (The Record from Recorded Future)
  4. Computer Weekly – przegląd skutków klinicznych i informacji o publikacji danych; wzmianka o śmiertelnym incydencie powiązanym. (Computer Weekly)
  5. BleepingComputer – podsumowanie komunikatu Synnovis i terminu 21 listopada 2025 r. (BleepingComputer)

SOC Alert Triage

Od hałasu do sygnału – logika triage w SOC

Wyobraź sobie, że jako analityk SOC L1 patrzysz na ekran zalewu alertów: dziesiątki sygnalizacji typu „Email oznaczony jako phishing”, kilka „Podejrzana lokalizacja logowania VPN” i jedno groźnie brzmiące „Wykryto Mimikatz na hoście”. Co teraz? Którym alertem zajmiesz się najpierw i dlaczego? Taka scena to codzienność w Security Operations Center. Tutaj do gry wchodzi triage alertów – proces decydujący o tym, czy potencjalny atak zostanie szybko zauważony, czy zginie w tłumie false positive.

Czytaj dalej „SOC Alert Triage”

Rhadamanthys: operatorzy infostealera tracą dostęp do paneli. Co to znaczy dla obrońców?

Wprowadzenie do problemu / definicja luki

Wczoraj (11 listopada 2025 r.) pojawiły się liczne doniesienia, że infrastruktura Rhadamanthys — popularnego infostealera sprzedawanego w modelu Malware-as-a-Service (MaaS) — została zakłócona. Użytkownicy-klienci (tzw. „abonenci” malware’u) zaczęli masowo tracić dostęp SSH do swoich paneli webowych służących do agregacji wykradzionych danych. W części przypadków tryb logowania został rzekomo wymuszony na logowanie certyfikatem, a nie hasłem root, co abonenci łączyli z działaniami organów ścigania, m.in. w Niemczech. Sprawę jako pierwsze opisało BleepingComputer, wskazując też na niedostępność onion-witryn i spekulacje o możliwym związku z Operation Endgame (międzynarodową kampanią LEA przeciwko ekosystemowi MaaS).

W skrócie

  • Co się stało: Liczni „klienci” Rhadamanthys zgłaszają utratę dostępu do serwerów paneli i zmianę metod uwierzytelniania SSH. Torowe serwisy Rhadamanthys są offline (bez klasycznych banerów przejęcia).
  • Dlaczego to istotne: Nawet częściowe przejęcie/zakłócenie zaplecza MaaS przerywa cykl monetyzacji skradzionych danych (sprzedaż logów/kont), co daje obrońcom czas na reset haseł, unieważnianie ciasteczek, blokady sesji.
  • Kontekst: W 2024–2025 Rhadamanthys szybko ewoluował (wersje 0.7.x–0.9.x), wprowadzając m.in. OCR do ekstrakcji seed phrase’ów z obrazów oraz nowe łańcuchy infekcji (np. ClickFix).
  • Hipoteza: Zakłócenie może być kolejnym „sezonem” Operation Endgame, która w 2024–2025 rozbijała infrastrukturę botnetów/loaderów i usług pomocniczych (setki serwerów, setki domen). Strona Endgame zapowiadała kolejne działania i raportowała wcześniejsze sukcesy.

Kontekst / historia / powiązania

Rhadamanthys pojawił się pod koniec 2022 r. (wczesne próbki: 2022), szybko zyskując popularność dzięki C++, modularności i agresywnym technikom anty-analizy oraz dystrybucji przez malvertising (fałszywe reklamy/„cracki”) i kampanie phishingowe. Z czasem dołączyły łańcuchy ClickFix (mshta/HTA) i kampanie podszywające się pod naruszenia praw autorskich. Grupa TA547 wykorzystywała go w atakach na niemieckie organizacje.

Równolegle Operation Endgame — koordynowana przez Europol/Eurojust i partnerów (w tym BKA, FBI, NCA, USSS) — od 2024 r. uderza w kluczowe elementy „kill chainu” cyberprzestępców: botnety, loadery, infrastrukturę proxy i usługi „AV-check”. W maju 2025 r. podano liczby: ~300 serwerów i ~650 domen wyłączonych w jednym z etapów.

Analiza techniczna / szczegóły luki

Model biznesowy Rhadamanthys (MaaS)

  • Abonamenty dają dostęp do binarek/loadera, wsparcia i panelu www zbierającego logi (hasła, cookies, dane portfeli). Panel to „punkt grawitacji” całej operacji — i kluczowy cel dla LEA.
  • Ewolucja funkcji:
    • v0.7.x (2024): dodany moduł OCR do ekstrakcji seed phrase’ów z obrazów, wsparcie uruchamiania MSI, silniejsze anty-analizy.
    • v0.9.2 (2025): istotne zmiany w pakowaniu/telemetrii i interakcjach z narzędziami badawczymi; wpływ na reguły detekcji.

Łańcuchy infekcji obserwowane w 2024–2025

  • Malvertising / „cracki” / SEO-poisoning → downloader/loader → stealer → eksfiltracja do panelu.
  • Phishing (copyright/DMCA lures) → archiwum/skrót + mshta/HTA (ClickFix) → stealer.
  • Kampanie e-mail (TA547, DE) → PowerShell, czasem artefakty składni sugerujące generację LLM → Rhadamanthys.

Co oznacza bieżące zakłócenie?

  • Utrata paneli = przecięty kanał C2/monetyzacji. Nawet jeśli binarki w terenie „żyją”, nie ma gdzie zrzucać danych lub aktorzy boją się korzystać z przejętej infrastruktury.
  • Zmiana SSH na cert-auth i odcięcie haseł root sugerują interwencję na hostach (seizure/forensic live response) lub akcję operatora infrastruktury pod nadzorem LEA. To zgodne z metodyką Endgame: uderz w serwery i domeny. (Wciąż brak oficjalnego potwierdzenia dla konkretnie Rhadamanthys.)

Praktyczne konsekwencje / ryzyko

  • Ryzyko re-spawn: Historia pokazuje, że po „takedownie” forki/następcy wracają pod inną marką, często z migracją C2 do nowych hostingów.
  • Okno możliwości dla obrony: To czas na masowe resety haseł, unieważnianie cookies/sesji, rotację tokenów OAuth, monitoring nietypowych logowań i ofensywne wyszukiwanie artefaktów.
  • Ryzyko „data leak później”: Jeśli LEA przejęły panele, część danych ofiar może zostać zabezpieczona; jeśli nie — przestępcy mogą próbować odtwarzać logi z endpointów lub backupów C2. Dlatego incydent traktujemy jak aktywny.

Rekomendacje operacyjne / co zrobić teraz

1) Reakcja na poziomie tożsamości i sesji

  • Reset haseł dla kont narażonych na exfil (przeglądarki, VPN, poczta, komunikatory).
  • Unieważnij cookies i sesje (SSO, IdP, poczta webowa).
  • Wymuś re-MFA dla użytkowników z nietypowymi logowaniami w ostatnich 60 dniach.

Przykład (Azure AD / Entra ID – wymuszenie re-logowania):

# Wymuś ponowną autoryzację (revoke sessions) dla wskazanych UPN:
Connect-MgGraph -Scopes "User.ReadWrite.All"
$users = @("user1@contoso.com","user2@contoso.com")
$users | ForEach-Object { Revoke-MgUserSignInSession -UserId $_ }

2) Hunting & detekcja dla łańcucha ClickFix/mshta

Sigma (Windows, PROC_CREATE + net):

title: Rhadamanthys ClickFix via mshta + URL + auth code
id: 7a1d1f6b-9d9a-4f32-9e3c-rc-rhada-clickfix
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  sel:
    Image|endswith: '\mshta.exe'
    CommandLine|contains|all:
      - 'http'
      - '://'
      - 'code='
  condition: sel
level: high
tags:
  - attack.t1204
  - attack.t1059

(Inspiracja wzorcami ClickFix dla Rhadamanthys w 2025 r.)

Elastic (cookies exfil / nietypowe POST po infekcji):

event.dataset == "zeek.http" and http.method == "POST" and
  url.full : "*/*" and
  (
    user_agent.original : "*WinHTTP*" or
    http.request.body.content : "*password*" or
    http.request.body.content : "*cookies*"
  ) and
  destination.ip != "internal ranges"

3) Artefakty endpointowe / EDR

  • Nietypowe wywołania mshta.exe, rundll32.exe z parametrami URL, powershell.exe -enc (TA547).
  • Pliki w katalogach tymczasowych o wysokiej entropii + autostarty (Run Keys, Scheduled Tasks).
  • Przeglądarki: gwałtowny spadek liczby cookies lub odczyty baz SQLite (Login Data, Cookies) bez interakcji użytkownika.

Polowanie (Sysmon → Splunk):

index=sysmon sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
(Image="*\\mshta.exe" OR Image="*\\rundll32.exe" OR Image="*\\powershell.exe")
| stats count min(_time) max(_time) by Computer, User, Image, CommandLine, ParentImage
| where like(CommandLine, "%http%") OR like(CommandLine, "%-enc%")

4) Twardnienie przeglądarek i hostów

  • Włącz/egzekwuj: izolację witryn, Encrypted Client Hello, partitioned cookies (Chrome/Edge), HSTS policy w aplikacjach własnych.
  • EDR policy: blokada uruchamiania mshta.exe dla zwykłych użytkowników; AppLocker/WDAC.
  • E-mail: DANE/SPF/DMARC w trybie reject, sandbox linków.

5) Sieć i proxy

  • Blokuj świeże TLD/NGTLD w dziennikach z kampanii Rhadamanthys; włącz TLS SNI/JA3 fingerprinting dla C2.
  • Egress allow-list dla serwerów z wysokim poziomem zaufania (CI/CD, jump hosts).

6) Działania wobec potencjalnie przejętych danych

  • Rotuj klucze API, tokeny PAT (GitHub/GitLab/Azure DevOps).
  • Powiadom użytkowników o potencjalnym przejęciu danych autoryzacyjnych i wymuś zmianę haseł niezarządzanych (re-use).
  • Threat intel: subskrybuj feedy logów wykradzionych (np. Have I Been Pwned partnerstwa Endgame).

Różnice / porównania z innymi przypadkami

  • Lumma, RedLine, Raccoon — wcześniejsze „takedowny” często dotyczyły konkretnych aktorów lub serwerów transakcyjnych; operatorzy wracali z rebrandem.
  • Endgame-style: skoordynowane, szerokie uderzenia w infrastrukturę i „usługi ekosystemowe” (np. AV-check), co czasowo ogranicza zdolność całego rynku MaaS do działania. Rhadamanthys — jeśli powiązany — wpisuje się w ten wzorzec.

Podsumowanie / kluczowe wnioski

  1. Zakłócenie paneli Rhadamanthys to realne okno dla obrońców: resetuj, unieważniaj, rotuj. 2) Nie licz na trwałość „takedownu” — planuj re-spawn i zmiany brandu. 3) Uderz w łańcuch ClickFix/mshta i monitoruj artefakty v0.9.x (aktualizacja reguł!). 4) Śledź oficjalne komunikaty LEA/Endgame — możliwe, że to element większej operacji.

Źródła / bibliografia

  • BleepingComputer — „Rhadamanthys infostealer disrupted as cybercriminals lose server access”, 11.11.2025. (opis incydentu, relacje „abonentów”, offline onion) (BleepingComputer)
  • Operation Endgame — strona operacji, partnerzy, komunikaty i statystyki dot. wcześniejszych uderzeń (maj 2025 i inne). (operation-endgame.com)
  • Check Point Research — „Rhadamanthys 0.9.x — walk through the updates”, 01.10.2025 (zmiany techniczne v0.9.2). (Check Point Research)
  • Recorded Future Insikt Group — „Rhadamanthys Stealer Adds Innovative AI Feature”, 26.09.2024 (OCR i nowości v0.7.0). (go.recordedfuture.com)
  • Proofpoint — „TA547 targets German organizations with Rhadamanthys”, 10.04.2024 (kampania e-mail, kontekst DE). (Proofpoint)

Androidowy trojan „Fantasy Hub”: Telegram jako panel MaaS, nadużycie roli SMS i podsłony bankowe

Wprowadzenie do problemu / definicja luki

Badacze ujawnili nowy komercyjny złośliwy pakiet na Androida – Fantasy Hub – sprzedawany w modelu Malware-as-a-Service (MaaS) na rosyjskojęzycznych kanałach Telegrama. To RAT/spyware oferujący zdalną kontrolę nad urządzeniem: kradzież SMS-ów, kontaktów, logów połączeń, multimediów, przechwytywanie/odpowiadanie/ukrywanie powiadomień oraz podsłony bankowe. Dystrybucję ułatwia bot subskrypcyjny i generator „trojanizowanych” APK, który po wgraniu dowolnego pliku instalacyjnego zwraca jego zainfekowaną wersję.

W skrócie

  • Model biznesowy: pełny MaaS z botem Telegram do zarządzania subskrypcją i builderem droppera; cennik w ujęciu tygodniowym/miesięcznym/rocznym.
  • Techniki kluczowe:
    • Native dropper w bibliotece metamask_loader odszyfrowujący zaszyty w assetach ładunek (XOR + gzip) – redukcja wskaźników statycznych.
    • Nadużycie roli „domyślnej aplikacji SMS” – jedna akceptacja = pakiet silnych uprawnień i dostęp do 2FA przez SMS.
    • WebRTC do streamingu audio/wideo na żywo (kamera/mikrofon) do C2.
    • Podsłony bankowe (Alfa, PSB, T-Bank, Sber) + możliwość tworzenia własnych okien phishingowych.
  • Wejście do łańcucha ataku: fake aktualizacje Google Play, fałszywe landing pages Google Play z opiniami, trojanizacja dowolnego APK przez usługę.
  • Skala trendu: wzrost transakcji związanych z malware na Androida; setki złośliwych aplikacji w oficjalnym sklepie wg ThreatLabz.

Kontekst / historia / powiązania

Fantasy Hub wpisuje się w trend komodytyzacji spyware/banking trojanów: łatwe panele C2, abonamenty, wsparcie „operatora”, a nawet poradniki socjotechniczne. Zimperium łączy wzorce operacyjne z wcześniejszymi rodzinami ClayRAT (nadużycie roli SMS) i HyperRat (integracja z Telegramem). Równolegle ThreatLabz raportuje 67% r/r wzrost aktywności malware mobilnego i dziesiątki milionów instalacji szkodliwych aplikacji z Google Play (2024–2025). W regionie CEE widzimy dodatkowo kampanie NFC-relay (np. NGate wymierzone w polskie banki), co wskazuje na dywersyfikację taktyk przeciwko kanałom płatności i autoryzacji.

Analiza techniczna / szczegóły luki

Łańcuch infekcji

  1. Wejście: ofiara trafia na sfałszowaną kartę Google Play (klony Telegrama i inne), bądź otrzymuje APK „aktualizacji Google Play”.
  2. Dropper (native): biblioteka metamask_loader w runtime odszyfrowuje i dekompresuje zaszyty ładunek (metadata.dat) → zapis na dysk → uruchomienie. Cel: ukrycie wskaźników statycznych przed skanerami.
  3. Eskalacja uprawnień przez UX: aplikacja żąda ustawienia jako domyślna aplikacja SMS, co automatycznie agreguje szerokie uprawnienia (czytanie/zarządzanie SMS, dostęp do kontaktów, kamer, plików).
  4. Komunikacja/C2:
    • Integracja z Telegramem – konfiguracja botów, rozdział alertów o różnym priorytecie, automatyzacja powiadomień o nowych ofiarach.
    • Panel C2 (rosyjskojęzyczny) pokazuje status urządzeń (online/offline), model, SIM-y, czas subskrypcji; pozwala wysyłać komendy (SMS, kontakty, powiadomienia, zrzuty, itp.).
    • WebRTC live stream – pobieranie bibliotek i cichy streaming A/V; system wyświetla krótką adnotację o aktywnym streamie.
  5. Monetyzacja: podsłony bankowe (wielokrotne „launcher icons” via activity-alias → WebView z phishingiem + JS-bridge) oraz przechwytywanie 2FA przez SMS.

Cennik i automatyzacja dystrybucji
Bot oferuje upload dowolnego APK → zwrot trojanizowanego APK; płatności w modelu tygodniowym/miesięcznym/rocznym. Ta automatyzacja obniża próg wejścia dla „operatorów-amatorów”.

Praktyczne konsekwencje / ryzyko

  • BYOD i dostęp korporacyjny: przejęte urządzenie = ryzyko wycieku danych firmowych (M365/Google Workspace), eskalacja przez MFA-SMS i przejęcie sesji.
  • Bankowość i płatności: kradzież poświadczeń przez overlay + 2FA w SMS → transakcje nieautoryzowane, social engineering z potwierdzeniami w czasie rzeczywistym.
  • Prywatyzacja nadzoru: live streaming kamerą/mikrofonem umożliwia podsłuch i rekonesans fizyczny (np. ekrany komputerów podczas pracy zdalnej).
  • Sklepy z aplikacjami: nawet oficjalne repozytoria nie są wolne od ryzyka (dziesiątki milionów instalacji złośliwych aplikacji wg ThreatLabz).

Rekomendacje operacyjne / co zrobić teraz

Strategia „zmniejsz zaufanie do SMS”

  • Wycofuj SMS jako główny drugi składnik w dostępie do systemów firmowych. Preferuj FIDO2/WebAuthn lub TOTP w zabezpieczonych kontenerach. (Uzasadnienie: rola domyślnej aplikacji SMS daje napastnikowi pełną kontrolę nad 2FA)

Polityki Android Enterprise / MDM

  • Wymuś instalację tylko z Google Play i blokuj „Nieznane źródła”, a także Private/Managed Play z allowlistą.
  • Zabroń zmiany domyślnej aplikacji SMS lub monitoruj eventy przekazania roli ROLE_SMS (Device Policy/Enterprise Mobility).
  • Blokuj nakładki (draw-over-other-apps) dla aplikacji spoza listy zaufanych – ogranicza skuteczność podsłon bankowych.
  • Włącz Play Protect/attestation i SafetyNet/Play Integrity oraz wymuś aktualność łatek (min. „Android security patch level” w MDM).

Twarde kontenery i zarządzanie danymi

  • W BYOD, preferuj Work Profile; wymuś, by aplikacje firmowe działały wyłącznie w profilu służbowym i nie dzieliły danych z profilem prywatnym.

Detekcja w SOC/MTD

  • Zastosuj Mobile Threat Defense (np. skanowanie behawioralne, wykrywanie „default SMS app change”, nadmiarowych uprawnień, runtime-hooków, WebRTC stream w tle, rejestrowanie requestów do zasobów C2). (Mechanizmy te opisuje m.in. Zimperium w kontekście detekcji Fantasy Hub.)
  • Monitoruj zdarzenia Accessibility Service + SYSTEM_ALERT_WINDOW, rejestrowanie intentów ROLE_SMS, prób overlay/phishing (WebView z wstrzykniętym JS-bridge).

Higiena użytkownika

  • Nie instaluj „aktualizacji Google Play” spoza sklepu, nie dawaj roli „domyślna aplikacja SMS” aplikacjom spoza listy zaufanych.
  • Zwracaj uwagę na ekran streamingu (Android system potrafi sygnalizować aktywny podgląd kamery/mikrofonu).

Szybkie playbooki IR (przykładowe kroki)

# 1) Identyfikacja (ADB lokalnie – urządzenie użytkownika)
adb shell cmd role holders android.app.role.SMS   # sprawdź, kto ma rolę SMS
adb shell pm list packages -3                     # lista aplikacji stron trzecich
adb shell dumpsys activity top | head -n 50       # aktywne aktywności (szukaj podejrzanych WebView/overlay)
adb shell cmd appops query-op CAMERA              # dostęp do kamery/mikrofonu

# 2) Kwarantanna
adb shell am force-stop <podejrzany.pkg>
adb shell pm uninstall --user 0 <podejrzany.pkg>  # tylko za zgodą użytkownika/IR-procedury
adb shell cmd role set-browser none               # tymczasowe odcięcie niestandardowych przeglądarek, jeśli uzasadnione

# 3) Triage artefaktów
adb shell run-as <podejrzany.pkg> ls files/
adb shell logcat -d | grep -i webrtc

Uwaga: operacje ADB wykonuj wyłącznie w kontrolowanym IR, z politykami RODO i zgodą właściciela urządzenia. W środowiskach zarządzanych preferuj akcje MDM (wipe profilu służbowego, blocklist, reset roli SMS).

Reguły detekcyjne – pomysły (do adaptacji)

  • SIEM: alert, gdy ROLE_SMS zmieniona na aplikację spoza allowlisty; koreluj z żądaniami sieciowymi do Telegram API i nietypową telemetrią WebRTC.
  • NTA/Proxy: anomalie WebRTC/ICE/STUN z urządzeń mobilnych poza godzinami pracy; outbound do znanych punktów C2 (gdy IoC dostępne).
  • EDR mobilny/MTD: sygnatury bibliotek metamask_loader, asset metadata.dat, dekompresje gzip w natywnych libach + XOR-pattern (36-bajtowy klucz) – na bazie opisu badaczy.

Różnice / porównania z innymi przypadkami

  • ClayRAT – podobne przejęcie roli SMS jako pojedyncza zgoda = szerokie kompetencje aplikacji. Fantasy Hub intensywnie korzysta z tego wektora.
  • HyperRat – architektura z Telegramem do notyfikacji i zarządzania, zbliżona koncepcja integracji botów.
  • Anatsa/ERMAC/TrickMo – ciężar na podsłony bankowe i wyłudzenie danych uwierzytelniających; Fantasy Hub łączy to z live-streamingiem i builderem droppera (większa „kompletność” narzędzia).
  • NGate (NFC-relay, PL) – inna technika (atak na zbliżeniowe płatności), ale podobny cel: obchodzenie mechanizmów autoryzacji w ekosystemie mobilnym.

Podsumowanie / kluczowe wnioski

Fantasy Hub pokazuje, jak niskim kosztem można dziś prowadzić pełnoskalowe operacje na Androidzie: builder trojanizujący, panel C2, automat subskrypcji i instrukcje socjotechniczne. Najgroźniejsze komponenty to rola domyślnej aplikacji SMS (2FA), podsłony bankowe i WebRTC live-stream. Dla SOC najważniejsze jest odchodzenie od SMS-2FA, twarde polityki Android Enterprise, oraz telemetria MTD kładąca nacisk na zmiany roli SMS, overlaye i anomalię WebRTC.

Źródła / bibliografia

  1. The Hacker News – Android Trojan 'Fantasy Hub’ Malware Service Turns Telegram Into a Hub for Hackers, 11 listopada 2025. (The Hacker News)
  2. Zimperium (zLabs) – Fantasy Hub: Another Russian Based RAT as M-a-a-S, 6 listopada 2025. (Zimperium)
  3. Zscaler ThreatLabz – Industry Attacks Surge, Mobile Malware Spreads: The ThreatLabz 2025 Mobile, IoT & OT Report. (zscaler.com)
  4. CERT Polska – Analysis of NGate malware campaign (NFC relay), 2025. (cert.pl)

Systemy Biometryczne: Architektura, Podatności i Zabezpieczenia

Czym są systemy biometryczne?

Systemy biometryczne wykorzystują cechy fizyczne lub behawioralne do identyfikacji i uwierzytelniania osób. Biometria obejmuje m.in. cechy fizjologiczne (twarz, tęczówka, odcisk palca, geometria dłoni, siatkówka oka) oraz behawioralne (głos, podpis odręczny, chód, sposób pisania na klawiaturze). W odróżnieniu od tradycyjnych metod (hasła, PIN-y, karty dostępu), cech biometrycznych nie da się zgubić ani zapomnieć, a próby oszukania systemu przez wykradzenie cech są trudniejsze – przynajmniej w teorii.

Czytaj dalej „Systemy Biometryczne: Architektura, Podatności i Zabezpieczenia”

Quantum Route Redirect (QRR): nowa platforma PhaaS do przekierowań, która masowo wykrada dane logowania Microsoft 365

Wprowadzenie do problemu / definicja luki

Badacze opisali nową usługę Phishing-as-a-Service (PhaaS) o nazwie Quantum Route Redirect (QRR), która automatyzuje całą kampanię phishingu – od routingu ruchu po profilowanie ofiar – i uderza w użytkowników Microsoft 365 na całym świecie. Platforma jest dostarczana „pod klucz”, wraz z setkami przygotowanych domen i gotowych szablonów wiadomości (m.in. DocuSign, HR/payroll, płatności, „missed voicemail”, a także QR-code phishing / quishing). Kluczowym elementem QRR jest inteligentne przekierowanie: boty i skanery firmowe trafiają na strony „benign”, a ludzie – na właściwe strony zbierające poświadczenia.

W skrócie

  • Skala: ~1000 domen hostujących QRR, kampanie w 90 krajach, z czego 76% ataków wymierzonych w USA.
  • Wzorzec URL: stały path z /quantum.php oraz charakterystyczne nazewnictwo hostów na zaparkowanych lub skompromitowanych domenach.
  • Omijanie zabezpieczeń: rozróżnianie botów vs. ludzi, przekierowania „czyszczące” dla Secure Email Gateway/ICES, WAF i skanerów URL.
  • Cel: kradzież poświadczeń Microsoft 365 (O365/M365) i przejęcia kont.
  • Trend: rosnąca „platformizacja” phishingu – podobnie do VoidProxy, Darcula, Tycoon2FA.

Kontekst / historia / powiązania

2024–2025 to wyraźna profesjonalizacja PhaaS. Przykładowo:

  • Tycoon2FA upowszechnił AiTM/MFA-bypass poprzez reverse proxy i relaying sesji.
  • Darcula rozwinęła globalną sieć dziesiątek tysięcy domen, celując m.in. w kanały RCS/iMessage i usługi pocztowe na całym świecie.
  • VoidProxy celuje w M365 i Google, również integrując anti-bot oraz obsługę SSO/IdP.

W tym samym czasie dostawcy i organy ścigania dezintegrują wielkie usługi PhaaS – np. RaccoonO365 (przejęto setki domen i kont Cloudflare Workers). To pokazuje, że rynek PhaaS jest dynamiczny: nowi gracze (jak QRR) szybko wypełniają lukę po rozbitych ekosystemach.

Analiza techniczna / szczegóły luki

Łańcuch ataku (TTP)

  1. E-mail phishing z tematami wysokiej konwersji (DocuSign, HR/payroll, płatności, „missed voicemail”, quishing).
  2. Kliknięcie/zeskanowanie prowadzi do centralnego routera QRR.
  3. Korelacja i fingerprinting (m.in. nagłówki, User-Agent, IP/ASN, heurystyki VPN/proxy, timing, headless/browser API).
  4. Rozgałęzienie:
    • Boty/skanery/WAF/SEG/ICES → strony bezpieczne/legit (np. portal firmy), by „udowodnić” nieszkodliwość.
    • Użytkownicy → landing phishingowy (M365) z formularzem credential harvesting.
  5. Zbieranie metryk i statystyk w panelu QRR (impressions, wizyty „human” vs. „bot”, geolokacja, przeglądarka/OS).

Wzorce infrastruktury

  • Stały path: obserwowany /quantum.php w ścieżce URL.
  • Hosty: często zaparkowane lub skompromitowane domeny, zwykle z co najmniej dwoma poziomami subdomen. Przykładowy wzorzec (simplified): https://<sub1>.<sub2>.<tld>/<...>/quantum.php?<params> (pełny regex z raportu KnowBe4 obejmuje klastry znaków i krótki TLD).

Dlaczego to działa?

  • Wiele rozwiązań bada URL „at delivery time” – QRR wykorzystuje post-delivery weaponization i dynamiczne redirecty, aby „oczyszczać” link dla silników analitycznych, a ofiary kierować na właściwy cel „time-of-click”.

Praktyczne konsekwencje / ryzyko

  • ATO (Account Takeover) w M365 → dostęp do Exchange/SharePoint/OneDrive, eskalacja do BEC, exfiltracja danych, nadużycia OAuth.
  • Trudniejsza detekcja na warstwie bramki e-mail: pozornie „czyste” linki przy dostarczeniu, realnie szkodliwe przy kliknięciu.
  • Ryzyko reputacyjne i prawne: wycieki PII/PHI, RODO, opóźnienia w procesach (np. HR/finanse).
  • Rosnąca „demokratyzacja” ataku – mniej techniczne grupy osiągają enterprise-grade skuteczność dzięki PhaaS.

Rekomendacje operacyjne / co zrobić teraz

1) Prewencja i twarde policy

  • M365/Defender for Office 365
    • Safe Links z time-of-click i blokowaniem przekierowań.
    • Zasady Anti-Phishing (impersonation prot., mailbox intelligence).
    • MFA odporne na phishing (FIDO2/Windows Hello, Passkeys; unikać OTP/SMS).
  • SEG/ICES/WAF/DNS
    • Włącz analizę łańcucha przekierowań i headless browsing w sandboxie.
    • URL detonation także po dostarczeniu (re-crawl).
    • DNS filtering + bloki na zaparkowane/świeże domeny (kryteria wieku/AS, parking-ASN).
  • Awareness
    • Szkolenia z quishing (skanery QR w telefonach służbowych → open in isolated browser).

Szybkie reguły detekcji (przykłady)

Suricata (HTTP) – wykryj charakterystyczną ścieżkę:

alert http any any -> any any (
  msg:"QRR candidate - quantum.php in path";
  http.uri; content:"/quantum.php"; nocase;
  classtype:trojan-activity; sid:24000101; rev:1;
)

Suricata (PCRE: co najmniej 2 subdomeny + quantum.php)

Uwaga: prosty, heurystyczny przykład (ogranicz nadużycia false positive lokalną listą wyjątków).

alert http any any -> any any (
  msg:"QRR candidate - multi-subdomain + quantum.php";
  http.host; pcre:"/^[^.]+\.[^.]+\.[a-z]{2,}$/Ri";
  http.uri; content:"/quantum.php"; nocase;
  classtype:trojan-activity; sid:24000102; rev:1;
)

Exchange Online PowerShell – blokuj wiadomości zawierające quantum.php w linku (Body/Headers):

Connect-ExchangeOnline

New-TransportRule -Name "Block QRR links" `
  -Priority 0 `
  -Mode Enforce `
  -Comments "Heurystyczna blokada QRR" `
  -MessageContainsWords "quantum.php" `
  -SetSCL 9 `
  -RejectMessageReasonText "Blocked: suspected QRR link"

(Rozważ zamianę na Set-Header X-Quarantine:QRR i bezpieczną kwarantannę, jeśli FP są możliwe.)

Microsoft Defender for Endpoint – prosty wskaźnik domeny/path w Custom Indicators:

  • Indicators → URLs/Domains → Add indicator → */quantum.php* → Action: Block → Scope: All devices → Expiry: 30–60 dni (z przeglądem co tydzień).

Zasada proxy/secure web gateway (np. PAC/SWG) – miękka blokada + coaching:

// fragment PAC
if (shExpMatch(url, "*/quantum.php*")) return "PROXY block.example:8080"; // lub direct: return "REJECT";

Threat hunting (KQL, M365/Defender)

Kliknięcia w podejrzane linki:

EmailUrlInfo
| where Url has "/quantum.php"
| summarize clicks=dcount(ClickRecordId), recipients=dcount(RecipientEmailAddress) by Url, bin(Timestamp, 1d)

Nietypowe logowania po kliknięciu:

let suspectUsers = 
    EmailUrlInfo
    | where Url has "/quantum.php"
    | distinct RecipientEmailAddress;
IdentityLogonEvents
| where AccountUpn in (suspectUsers)
| where Application == "Office 365"
| summarize by AccountUpn, IPAddress, AuthenticationRequirement, ResultType, bin(Timestamp, 1h)

IR playbook (skrót)

  1. Containment: reset haseł + zrywanie sesji (Invalidate Refresh Tokens), wymuszenie re-enrollment MFA FIDO/Passkeys.
  2. Scope: sprawdź OAuth consents, skrzynkę (rules/inbox forwarding), Access Review.
  3. Forensics: timeline z Unified Audit Log, exfil (SharePoint/OneDrive access logs).
  4. Notifications: RODO/klienci, TLP:AMBER do partnerów, CERT krajowy.
  5. Hardening: conditional access, step-up auth, geo-fencing, mailbox protections.

Różnice / porównania z innymi przypadkami

  • QRR vs. Tycoon2FA: Tycoon2FA słynie z AiTM/MFA-bypass (kradzież cookies/sesji). QRR koncentruje się na inteligentnym routingu i maskowaniu przed kontrolami bezpieczeństwa; nie wyklucza to jednak integracji z AiTM w kolejnych iteracjach.
  • QRR vs. Darcula: Darcula skaluje się przez ogrom ekosystemu domen i szablonów (także RCS/iMessage). QRR skaluje się przez centralny router + pre-baked domeny i profiling, aby „wybielić” link dla botów.
  • QRR vs. VoidProxy: oba celują w M365; VoidProxy akcentuje wszechstronny target (także Google/SSO) i mechanizmy anti-bot. QRR wyróżnia powtarzalny wzorzec URL i masowe wykorzystanie zaparkowanych/skompromitowanych domen.

Podsumowanie / kluczowe wnioski

  • QRR to kolejny krok w „produktowej” ewolucji PhaaS: łatwość użycia dla przestępców, trudniejsze życie dla bramek i skanerów.
  • Najszybsze wygrane dla Blue Teamu: time-of-click, detonacja redirectów, reguły na /quantum.php, DNS/WAF heurystyki oraz szkolenia z quishingu.
  • Traktuj pojedyncze IOC (np. path) jako heurystykę, nie „srebrną kulę” – utrzymuj ciągły re-crawl i threat intel sync.
  • Zakładaj, że QRR (i kolejne klony) będą aktywnie ewoluować – w tym w kierunku AiTM/MFA-bypass.

Źródła / bibliografia

  • BleepingComputer: Quantum Route Redirect PhaaS targets Microsoft 365 users worldwide (10 listopada 2025). (BleepingComputer)
  • KnowBe4 Threat Lab: Quantum Route Redirect: Anonymous Tool Streamlining Global Phishing Attack (10 listopada 2025). (blog.knowbe4.com)
  • BleepingComputer: New VoidProxy phishing service targets Microsoft 365, Google accounts (14 września 2025). (BleepingComputer)
  • Proofpoint: Tycoon 2FA: Phishing Kit Being Used to Bypass MFA (9 maja 2024). (Proofpoint)
  • Netcraft: ‘Darcula’ Phishing-as-a-Service… (27 marca 2024). (netcraft.com)