Archiwa: VPN - Strona 90 z 102 - Security Bez Tabu

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)

Synology łata zero-day w BeeStation po Pwn2Own Ireland 2025 (CVE-2025-12686)

Wprowadzenie do problemu / definicja luki

Synology opublikowało aktualizację bezpieczeństwa dla BeeStation OS, usuwając krytyczną podatność zademonstrowaną publicznie podczas konkursu Pwn2Own Ireland 2025. Błąd otrzymał identyfikator CVE-2025-12686 i klasyfikowany jest jako klasyczny buffer overflow (CWE-120), co umożliwia zdalne wykonanie kodu (RCE) bez interakcji użytkownika. Producent zaleca aktualizację BeeStation OS do wersji 1.3.2-65648 lub nowszej; obejmuje to wszystkie linie 1.0–1.3 (brak obejść/mitigacji bez aktualizacji).

W skrócie

  • Co się stało? Na Pwn2Own Ireland 2025 badacze z Synacktiv pokazali exploita dającego uprawnienia root na Synology BeeStation Plus; za udany atak przyznano 40 000 USD.
  • Jaki błąd? Krytyczny buffer copy without checking size of inputRCE (CVSS 9.8).
  • Co naprawiono? Synology wydało poprawkę w BeeStation OS 1.3.2-65648+; aktualizacja jest jedynym zalecanym remedium.
  • Dlaczego to ważne? BeeStation to konsumenckie „personal cloud” z dostępem przez Internet; podatność może prowadzić do pełnego przejęcia urządzenia i danych.

Kontekst / historia / powiązania

Pwn2Own to cykliczne zawody organizowane przez Trend Micro ZDI. W edycji irlandzkiej 2025 wykazano 73 zero-daye i przyznano ponad 1 mln USD nagród. Synology było jednym z głównych celów w kategorii NAS; poza BeeStation atakowano też DiskStation DS925+ i ActiveProtect. Sam producent podkreśla, że współpraca z badaczami w ramach Pwn2Own i programu bug bounty jest elementem jego strategii bezpieczeństwa.

Warto przypomnieć, że również w 2024 r. BeeStation miało zestaw luk ujawnionych po Pwn2Own (RCE, odczyt plików, zapis plików w scenariuszu MiTM), co zaowocowało poradnikiem Synology-SA-24:23 i poprawkami w marcu 2025. Dzisiejsza luka to nowy błąd z innym CVE.

Analiza techniczna / szczegóły luki

  • Identyfikator: CVE-2025-12686
  • Klasa błędu: buffer overflow (CWE-120) → kopiowanie danych bez weryfikacji długości wejścia.
  • Wektor ataku: zdalny, bez uwierzytelnienia, bez interakcji użytkownika (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
  • Skutki: zdalne wykonanie dowolnego kodu na urządzeniu (RCE) z możliwością uzyskania uprawnień root.
  • Zakres produktów: wszystkie gałęzie BeeStation OS 1.0–1.3 przed 1.3.2-65648.
  • Atrybucja PoC: @Tek_7987 i @_Anyfun (Synacktiv) – demonstracja exploita podczas Pwn2Own Ireland 2025 na BeeStation Plus.

Choć Synology nie publikuje szczegółów implementacyjnych (CVE ma status RESERVED na cve.org), publiczny opis ZDI z dnia zawodów wskazuje na stack-based overflow prowadzący do root-level code execution. Do czasu pełnej publikacji ZDI szczegóły (np. konkretna usługa/endpoint) pozostają niejawne z uwagi na odpowiedzialne ujawnianie.

Praktyczne konsekwencje / ryzyko

  • Przejęcie urządzenia i danych: atakujący może uzyskać pełny dostęp do plików („personal cloud”), dodać konta, podmienić kopie zapasowe lub użyć urządzenia jako przyczółka w sieci domowej/SMB.
  • Ransomware i exfiltracja: NAS z publicznym dostępem (QuickConnect, port forwarding, eksponowane reverse proxy) to atrakcyjny cel dla operatorów ransomware.
  • Botnety i pivoting: przejęte BeeStation mogą zostać użyte do DDoS/cryptojackingu oraz jako pivot do kolejnych hostów (np. router, stacje robocze).
  • Ryzyko łańcucha dostaw rodzinnej/chmurowej: współdzielone foldery, klienty desktop/mobile i mapowane dyski zwiększają powierzchnię nadużyć.

Te scenariusze są typowe dla RCE na urządzeniach NAS, a medialne doniesienia potwierdzają wagę problemu w tej konkretnej luce.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowa aktualizacja (MUST):
Zaktualizuj BeeStation OS do ≥ 1.3.2-65648. Brak rekomendowanych mitigacji zastępczych. W GUI: Ustawienia → Aktualizacje → Sprawdź aktualizacje → Zainstaluj. Jeżeli używasz trybu offline, pobierz obraz z portalu wsparcia Synology i wykonaj aktualizację ręczną.

2) Ogranicz ekspozycję sieciową:

  • Wyłącz przekierowania portów w routerze do BeeStation, jeżeli nie są absolutnie konieczne.
  • Preferuj VPN do dostępu zdalnego zamiast wystawionych usług.
  • Jeśli korzystasz z reverse proxy, ogranicz do autoryzowanych adresów/IP (ACL) i włącz 2FA na kontach Synology. (Dobre praktyki ogólne dla NAS.)

3) Twarde polityki kont i haseł:

  • Wyłącz/usuń nieużywane konta, wymuś unikalne hasła, włącz 2FA.
  • Audytuj uprawnienia współdzielonych folderów (zasada najmniejszych uprawnień).

4) Monitoring i detekcja:

  • Przejrzyj logi logowania/administracyjne i historię zadań (nietypowe logowania, nowe konta, zmiany w regułach udostępnień).
  • Na brzegu sieci wprowadź reguły IDS/IPS (np. reguły dla protokołów HTTP(S) urządzenia) i alerty na nietypowy outbound (np. kopanie krypto, połączenia do TLD dynamicznych).
  • Rozważ segmentację (VLAN „IoT/NAS”) i ruch kontrolowany politykami L3/L7.

5) Kopie zapasowe i odzyskiwanie:

  • Wykonaj świeży backup 3-2-1 poza BeeStation (np. WORM/immutable snapshot w innej lokalizacji).
  • Test odzyskiwania (table-top) po aktualizacji.

6) Respond & harden (opcjonalnie – dla SOC/SecOps):

  • IOCs: szukaj nietypowych procesów/binarek w /usr/*, nowych zadań crontab, połączeń stałych do zewnętrznych VPS.
  • Jeżeli urządzenie było publicznie dostępne przed łatą, rozważ incident review: kopia forensic, zmiana haseł, rotacja tokenów.

Różnice / porównania z innymi przypadkami

  • BeeStation 2024 (SA-24:23): pakiet luk obejmował RCE, odczyt plików oraz zapis plików w scenariuszu MiTM. Obecna podatność 2025 to oddzielny zero-day (nowe CVE), także RCE, lecz wskazany wprost jako buffer overflow z CVSS 9.8 i bez mitigacji poza aktualizacją.
  • Inne cele NAS na Pwn2Own 2025: poza BeeStation, na podium były DS925+ i ActiveProtect; nagrody i wektory ataku w regulaminie ZDI potwierdzają wagę kategorii NAS.

Podsumowanie / kluczowe wnioski

  • CVE-2025-12686 to krytyczne RCE w Synology BeeStation OS, ujawnione na Pwn2Own Ireland 2025.
  • Jedyną skuteczną ochroną jest aktualizacja do 1.3.2-65648+bez obejść konfiguracyjnych.
  • Zredukowanie ekspozycji NAS (brak port-forwardingu, dostęp przez VPN, segmentacja) i twarde polityki kont/monitoringu pozostają najlepszą praktyką obronną.

Źródła / bibliografia

  1. Synology-SA-25:12 – BeeStation (PWN2OWN 2025) – oficjalna porada bezpieczeństwa z wersjami naprawczymi i CVSS/CWE. (Synology)
  2. BleepingComputer – „Synology fixes BeeStation zero-days demoed at Pwn2Own Ireland” – kontekst medialny, data, opis Pwn2Own i statystyki edycji. (BleepingComputer)
  3. ZDI Blog – „Pwn2Own Ireland 2025: Day One Results” – potwierdzenie wektora (stack overflow), zespołu i nagrody za BeeStation Plus. (Zero Day Initiative)
  4. ZDI – Pwn2Own Ireland 2025 Rules – wartości nagród i kategoria NAS (BeeStation Plus, DS925+, ActiveProtect). (Zero Day Initiative)
  5. Synology-SA-24:23 – BeeStation (PWN2OWN 2024) – kontekst historyczny wcześniejszych luk BeeStation. (Synology)

SAP łata krytyczne luki w SQL Anywhere Monitor i Solution Manager (listopad 2025)


Wprowadzenie do problemu / definicja luki

11 listopada 2025 r. SAP opublikował pakiet poprawek bezpieczeństwa obejmujący 18 nowych i aktualizacje wcześniejszych not bezpieczeństwa. Wśród nich znalazły się co najmniej dwie luki o krytycznej wadze: maksymalnie poważna słabość w SQL Anywhere Monitor (Non-GUI) oraz bardzo poważna podatność w SAP Solution Manager umożliwiająca wstrzyknięcie kodu. Informacje te potwierdzają komunikaty SAP oraz niezależne serwisy branżowe.


W skrócie

  • SQL Anywhere Monitor (Non-GUI): luka z kategorią HotNews (CVSS 10.0), związana z twardo zakodowanymi poświadczeniami i zarządzaniem kluczami/sekretami. Skutkiem może być zdalne wykonanie kodu (RCE) bez uwierzytelnienia.
  • SAP Solution Manager: podatność CVE-2025-42887 (CVSS 9.9). Brak sanityzacji danych wejściowych w zdalnie wywoływanym module funkcji (RFC) pozwala uwierzytelnionemu atakującemu wstrzyknąć kod i przejąć pełną kontrolę nad systemem.
  • SAP zachęca do pilnego wdrożenia not bezpieczeństwa z listopadowego Patch Day.

Kontekst / historia / powiązania

Ekosystem SAP regularnie otrzymuje poprawki w comiesięcznym cyklu „Security Patch Day”. Listopadowe wydanie wpisuje się w trend z 2025 r., w którym kilkukrotnie łatano luki o ocenie 9.8–10.0 w NetWeaver/AS Java i komponentach towarzyszących. Dodatkowe omówienia od partnerów (Onapsis, SecurityBridge) wskazują, że bieżący zestaw obejmuje trzy krytyczne problemy (dwie „dziesiątki” i jedną „9.9”), w tym SQL Anywhere Monitor oraz Solution Manager.


Analiza techniczna / szczegóły luk

1) SQL Anywhere Monitor (Non-GUI) — „hardcoded credentials” / zarządzanie sekretami

  • Opis: w obrazie/usłudze monitora wykryto twardo zakodowane poświadczenia (np. konto serwisowe / klucz), co umożliwia nieautoryzowany dostęp do zasobów monitora, a w konsekwencji zdalne wykonanie kodu na hostach, które monitor obsługuje lub na samym komponencie.
  • Klasyfikacja: HotNews, CVSS 10.0. Noty SAP identyfikują obszar jako BC-SYB-SQA-ADM (SQL Anywhere Monitor).
  • Wektory ataku: zdalne, sieciowe, bez interakcji użytkownika; brak uwierzytelnienia po stronie atakującego (w przypadku wykorzystania ujawnionych stałych sekretów).
  • Skutki: RCE, eskalacja uprawnień, przejęcie monitoringu oraz lateral movement do serwerów baz danych/instancji, które Monitor nadzoruje.

2) SAP Solution Manager — CVE-2025-42887 (code injection przez RFC)

  • Opis: brak sanityzacji danych wejściowych w zdalnie wywoływanym module funkcji (Remote-Enabled Function Module, RFC/FM) umożliwia wstrzyknięcie kodu przez uwierzytelnionego użytkownika (niski poziom uprzywilejowania). NVD klasyfikuje podatność jako CWE-94 (Improper Control of Code Generation), z metryką AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
  • Skutki: pełne przejęcie systemu Solution Manager (konf., integralność i dostępność na poziomie „High”). Istotny jest fakt, że SolMan często integruje się z wieloma systemami satelitarnymi (landscape), co multiplikuje ryzyko łańcuchowe.
  • Doniesienia prasowe podkreślają wagę CVE-2025-42887 i wskazują ocenę 9.9.

Praktyczne konsekwencje / ryzyko

  • RCE i przejęcie środowiska: w przypadku SQL Anywhere Monitor atakujący może uzyskać natychmiastowy dostęp systemowy oraz pivotować do baz danych i serwerów aplikacyjnych SAP.
  • Atak wewnątrz-organiczny/„low-priv”: CVE-2025-42887 wymaga autoryzacji, ale w dużych krajobrazach SAP niski poziom uprawnień użytkownika technicznego bywa powszechny. To otwiera drogę do abuse of RFC, z możliwością skryptowania wywołań FM i eskalacji na SolMan.
  • Łańcuch dostaw IT/OT: SolMan jako „central brain” ALM dotyka transportów, jobów, interfejsów — kompromitacja przenosi się na krajobraz produkcyjny.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe działania (0–24 h)

  1. Zidentyfikuj ekspozycję:
    • Odszukaj instancje SQL Anywhere Monitor (Non-GUI) i sprawdź, czy są osiągalne z sieci korporacyjnej/Internetu. W skanerze/CMDB szukaj nazw usług/procesów zawierających sqlanywhere / dbmon / monitor. (Wiele wdrożeń publikuje porty admin/HTTP monitora.) Źródło o krytyczności i RCE:
    • W Solution Manager przejrzyj listę RFC-destinations (SM59) oraz logi Security Audit Log i dev_rfc* pod kątem anomalii wywołań modułów FM.
  2. Wdróż noty SAP (Patch Day XI-2025):
    • Zastosuj odpowiednie SAP Security Notes z 11.11.2025 r. (SNOTE/transporty/SUM zależnie od komponentu). Informację o wydaniu i priorytetach potwierdza SAP.
    • Dla SQL Anywhere Monitor zastosuj notę HotNews (identyfikowaną przez partnerów jako Note 3666261 dot. CVE-2025-42890). Wdrożenie usuwa podatny komponent/sekrety lub wymusza ich bezpieczne zarządzanie.
  3. Segmentacja i ograniczenie dostępu:
    • Tymczasowo ogranicz do zaufanych zarządców/VPN dostęp sieciowy do monitora i interfejsów SolMan (firewall, NAC, ZTNA).

2) Krótkoterminowo (1–7 dni)

  • Rotacja sekretów/kont serwisowych używanych przez monitor i powiązane bazy/usługi. (Hardcoded credentials -> ryzyko wtórnego użycia).
  • Hardening RFC w SolMan:
    • Przegląd uprawnień technicznych użytkowników RFC (SU01/PFCG).
    • Wymuś whitelisting zdalnych FM: ogranicz do niezbędnych, monitoruj wywołania z SM59 i ST03N. Podstawa: charakter podatności RFC/code-injection.
  • Detekcje w SIEM/IDS (przykładowe reguły):
    • Wzorce nietypowych wywołań RFC z nowymi parametrami/ładunkami (korelacja z logami SAProuter/Gateway).
    • Alerty na niespodziewane połączenia wychodzące z hosta monitora (pivot).
  • Testy regresyjne po patchowaniu: monitorowanie stabilności krajobrazu ALM.

3) Średnioterminowo (do 30 dni)

  • Przegląd ekspozycji SAP do Internetu (AS Java, NetWeaver, SolMan, monitory, integracje).
  • SBOM & secret management: wdrożenie skanów sekretów i cyklu rotacji (np. HashiCorp Vault/Azure Key Vault), weryfikacja kontenerów/obrazów pod kątem wstrzykniętych kluczy.
  • Ćwiczenia IR specyficzne dla SAP: scenariusz „kompromitacja SolMan/monitoring”.

Przykładowe komendy/akcje operacyjne (dla zespołów)

  • Zgromadzenie listy RFC-destinations (raport w SAP GUI):
    • Transakcja SM59Utilities → Display/Compare → Eksport do CSV → korelacja w SIEM.
  • Szybki skan z zewnątrz (na własnej infrastrukturze): # przykładowy Nmap na znanych portach admin/HTTP monitora (dostosuj do swojej sieci!) nmap -sV -p 80,443,8080,8090,50013,50014 <zakres_IP> --open -oA sap-sqlanywhere-monitor
  • Poszukiwanie artefaktów w logach RFC (host aplikacyjny): # przykładowo na serwerze z plikami trace SAP (ścieżki dostosuj) grep -iE "CALL_FUNCTION|RFC|REMOTE.*FUNCTION" /usr/sap/<SID>/DVEBMGS*/work/dev_rfc*

Różnice / porównania z innymi przypadkami

  • Insecure deserialization (AS Java, CVE-2025-42944, CVSS 10.0) z października/listopada 2025 dotyczył kanału RMI-P4 w AS Java (zdalne RCE) — inny komponent i inna klasa błędu niż omawiane tu hardcoded credentials oraz RFC code injection. Wciąż jednak wpisuje się w szerszy wzorzec krytycznych błędów SAP w 2025 r., wymagających szybkiego patchowania.
  • Wcześniejsze „n-daye” w 2025 pokazały, że opóźnienia w aktualizacjach prowadzą do realnych kompromitacji (kampanie nadużywające luk NetWeaver). Wniosek: nawet „tylko” SolMan/RFC czy monitor mogą stać się wektorem pierwotnym. (Kontekst trendu i ostrzeżenia branżowe).

Podsumowanie / kluczowe wnioski

  • Patch now: SQL Anywhere Monitor (Non-GUI) – HotNews (CVSS 10.0) oraz CVE-2025-42887 w Solution Manager (CVSS 9.9) to luki wysokiego ryzyka. Wdrożenie not SAP z 11.11.2025 r. powinno być priorytetem.
  • Zabezpiecz sekrety i RFC: usuń stałe poświadczenia, rotuj konta serwisowe; w SolMan ogranicz i monitoruj wywołania RFC.
  • Monitoruj oznaki RCE/pivotu: nietypowe połączenia z hostów monitorujących, anomalia w logach RFC/Gateway.
  • Ucz się z 2025: krytyczne luki SAP pojawiają się regularnie — potrzebny jest stały cykl: asset inventory → szybkie patchowanie → detekcje nadużyć → ćwiczenia IR.

Źródła / bibliografia

  1. SAP Support Portal – Security Patch Day (listopad 2025): liczba not, zalecenia wdrożenia. (SAP Support Portal)
  2. SecurityWeek – omówienie luk (hardcoded credentials/RCE w SQL Anywhere Monitor; krytyczność pakietu). (SecurityWeek)
  3. NVD – karta CVE-2025-42887 (Solution Manager, code injection przez RFC; metryka CVSS/CWE). (NVD)
  4. Onapsis – przegląd listopadowych not SAP, kontekst i akcent na SQL Anywhere Monitor + SolMan. (Onapsis)
  5. SecurityBridge – zestawienie not z numerami (m.in. Note 3666261 / CVE-2025-42890, SQL Anywhere Monitor – HotNews 10.0). (SecurityBridge)

CVE-2025-42887 — Code Injection w SAP Solution Manager

TL;DR

Krytyczna podatność CVE‑2025‑42887 w SAP Solution Manager (ST 720) umożliwia wstrzyknięcie kodu podczas wywołania zdalnie udostępnionego modułu funkcyjnego (RFC) przez uwierzytelnionego atakującego. Skutkiem może być pełna kontrola systemu (wysokie C/I/A). CVSS v3.1: 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Dostawca opublikował poprawkę w Security Note 3668705 — należy wdrożyć niezwłocznie oraz ograniczyć dostęp do SAP RFC Gateway (porty 33xx) i monitorować Security Audit Log (SM20) i logi bramy RFC/ICM.


Krótka definicja techniczna

Błąd walidacji danych wejściowych w SAP Solution Manager pozwala podczas wywołania remote‑enabled function module na umieszczenie i wykonanie złośliwego kodu w kontekście aplikacyjnym. Wektor ataku jest sieciowy, z niską złożonością, wymaga niskich uprawnień (PR:L), nie wymaga interakcji użytkownika i zmienia zakres (Scope: Changed).


Gdzie występuje / przykłady platform

  • Produkt: SAP Solution Manager 7.2 (komponent ST 720) – krajobrazy on‑prem (Windows/Linux) i IaaS (AWS/Azure/GCP).
  • Protokół/warstwa dostępu: SAP RFC/Gateway (TCP 33xx/sapgw<inst>), HTTP(S)/ICM w wybranych scenariuszach SOAP RFC.
  • Przykładowe wdrożenia demo/PoC: oficjalne systemy pokazowe SolMan 7.2 (ST 720).

Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)

Mechanizm RFC umożliwia wywoływanie w ABAP funkcji oznaczonych jako Remote‑Enabled. W CVE‑2025‑42887 brak właściwego oczyszczania danych wejściowych przy takim wywołaniu prowadzi do wstrzyknięcia kodu i jego wykonania po stronie serwera SolMan. Ponieważ podatność dotyczy elementu administracyjnego (Solution Manager), kompromitacja może kaskadowo oddziaływać na systemy zarządzane i integracje (zmieniony zakres). W praktyce błąd wpisuje się w łańcuch TTP: eksploatacja usługi (T1190/T1210) → wykonanie/podniesienie uprawnień (T1068/T1059). Krytyczność rośnie, gdy RFC Gateway jest dostępny spoza zaufowanych segmentów lub gdy konta techniczne mają szerokie uprawnienia S_RFC/S_RFCACL.


Artefakty i logi

ŹródłoTyp/IDPole / EID / EventWzorzec / co szukaćUwagi
SAP Security Audit Log (SM19/SM20)AplikacjaKlasy „RFC/CPIC”, logony RFC, wywołania FMNietypowe logony RFC (pory, hosty), skoki liczby wywołań; nieudane/odrzucone autoryzacje S_RFCPodstawowy strumień audytowy ABAP.
SAP RFC Gateway (gw_log / dev_rd, GWMON)AplikacjaZdarzenia bramy (rejestracja, połączenia, wywołania)Niespodziewane źródła, nietypowe programy rejestrowane, błędy autoryzacji/ACLPorty 33xx; obserwuj reg_info/sec_info.
ICM/HTTP (dev_icm, log HTTP)AplikacjaŻądania do endpointów RFC/SOAPNietypowe POST do ścieżek RFC/SOAP z zewnątrzW zależności od konfiguracji.
Firewall/NetFlow/VPC Flow LogsSiećdstPort 3300–3399 (sapgw*)Połączenia z niezalistowanych ASN/VPC; skoki wolumenuDobre do korelacji z SAL.
Windows SysmonEID=1ParentImage = disp+work.exe/gwrd.exe/sapstartsrv.exe → child cmd.exe/powershell.exeEgzekucja powłoki przez procesy SAPW SolMan na Windows.
Linux auditdSYSCALL/EXECVEexe parent disp+work/gwrd/bin/sh, /bin/bashJak wyżej dla Linux
AWS VPC Flow Logs (CloudWatch)dstPort 3300..3399, action=ACCEPTŹródła poza allowlistą, krótkie serie połączeńCloudTrail nie rejestruje ruchu sieciowego.
K8s audit / M365[nie dotyczy]

(Porty RFC Gateway 33xx potwierdza KBA; komponent SolMan 7.2 = ST 720).


Detekcja (praktyczne reguły)

Sigma — nieautoryzowane wejścia na SAP RFC Gateway (sieć)

title: Suspicious Access to SAP RFC Gateway (sapgw 33xx) From Untrusted Source
id: 1c9b8f8b-2c0f-4c2b-a8a2-7b2b7b33f9e1
status: experimental
description: Detect inbound connections to SAP RFC Gateway ports (33xx) from non-approved networks
author: Badacz CVE
date: 2025/11/12
logsource:
  category: network_connection
detection:
  selection:
    destination.port|gte: 3300
    destination.port|lte: 3399
    network.direction: inbound
  filter_allowlist:
    source.ip|cidr:
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16
      # uzupełnij o własne sieci i partnerów
  condition: selection and not filter_allowlist
fields:
  - source.ip
  - destination.ip
  - destination.port
  - network.transport
falsepositives:
  - Zdalne serwisy administracyjne w zaufowanych strefach
level: high
tags:
  - attack.T1190
  - attack.T1210

Sigma — egzekucja powłoki z procesów SAP (Windows Sysmon)

title: Shell Spawned by SAP Work/Gateway Process
id: 9e7f4d95-2a8f-4ff0-9f6a-1d0b6e18bb3e
status: experimental
logsource:
  product: windows
  service: sysmon
  definition: Event ID 1 (Process Create)
detection:
  selection:
    EventID: 1
    ParentImage|endswith:
      - '\disp+work.exe'
      - '\gwrd.exe'
      - '\sapstartsrv.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
  condition: selection
level: high
tags:
  - attack.T1059
  - attack.T1068

Splunk (SPL) — ruch do sapgw i korelacja z hostami SolMan

| tstats count min(_time) as first_seen max(_time) as last_seen 
  from datamodel=Network_Traffic 
  where All_Traffic.dest_port>=3300 All_Traffic.dest_port<=3399 
  All_Traffic.action=allowed 
  All_Traffic.dest IN ($SOLMAN_HOSTS$)
  by All_Traffic.src, All_Traffic.dest, All_Traffic.dest_port
| `drop_dm_object_name("All_Traffic")`
| eval duration=last_seen-first_seen
| where count>=5 OR duration < 60

KQL (Microsoft Sentinel) — CommonSecurityLog / ASIM

let Allowed = dynamic(["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16"]);
imNetworkSession
| where DstPort between (3300 .. 3399)
| where not( ipv4_is_in_any_range(SrcIpAddr, Allowed) )
| summarize cnt=count(), firstSeen=min(TimeGenerated), lastSeen=max(TimeGenerated)
          by SrcIpAddr, DstIpAddr, DstPort, NetworkProtocol
| where cnt >= 5 or datetime_diff("minute", lastSeen, firstSeen) <= 1

AWS CloudWatch Logs Insights — VPC Flow Logs (przykład + AWS CLI)

Zapytanie:

fields @timestamp, srcAddr, dstAddr, dstPort, action, bytes
| filter dstPort >= 3300 and dstPort <= 3399 and action = 'ACCEPT'
| stats count() as flows, sum(bytes) as totalBytes, min(@timestamp) as firstSeen, max(@timestamp) as lastSeen by srcAddr, dstAddr, dstPort
| sort by flows desc

CLI:

aws logs start-query \
  --log-group-name /vpc/flowlogs/production \
  --start-time $(date -d '15 minutes ago' +%s) \
  --end-time $(date +%s) \
  --query-string 'fields @timestamp, srcAddr, dstAddr, dstPort, action | filter dstPort >= 3300 and dstPort <= 3399 and action="ACCEPT" | stats count() by srcAddr, dstAddr, dstPort'

Elastic Security — EQL (sieć) i KQL (host)

EQL (sieć):

network where destination.port >= 3300 and destination.port <= 3399
  and not cidrmatch(source.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")

KQL (Windows host):

event.code:1 and event.provider:"Microsoft-Windows-Sysmon" and
process.parent.name:( "disp+work.exe" or "gwrd.exe" or "sapstartsrv.exe" ) and
process.name:( "cmd.exe" or "powershell.exe" )

Uzasadnienie doboru portów i usług: SAP RFC Gateway nasłuchuje na 33xx (sapgw<inst>), co potwierdzają oficjalne materiały SAP.


Heurystyki / korelacje (co łączyć)

  • Łańcuch sieć → aplikacja → host: (1) inbound na 33xx z adresów spoza allowlisty → (2) wzrost liczby logonów RFC/odrzuconych autoryzacji S_RFC w SM20 → (3) pojawienie się powłoki/nietykowego procesu potomnego spod disp+work/gwrd.
  • Anomalia kont technicznych: Nagle wzmożone wywołania RFC przez rzadko używany service user lub nowe destynacje SM59.
  • Zmiana zakresu (Scope Changed): aktywność na hostach zarządzanych przez SolMan po zdarzeniu na SolMan (lateral movement).
  • „Public‑facing” vs. „internal”: traktuj SolMan jak krytyczny admin plane – ekspozycja bramy RFC/ICM poza segment IT Ops zwiększa ryzyko T1190/T1210.

False positives / tuning

  • Legitmny monitoring/automaty (np. EEM, integracje, batch) generują stały ruch RFC — whitelistuj znane źródła/VPN/VPC oraz konta S‑user.
  • Działania adminów w oknach serwisowych (SM59 testy, importy) – uwzględnij harmonogramy.
  • W regułach hostowych ogranicz do serwerów roli SolMan ABAP i do procesów rodziców SAP.

Playbook reagowania (kroki + komendy)

Triage

  1. Zweryfikuj podatność: czy Security Note 3668705 jest zaimplementowana (SNOTE), jaka wersja ST 720 SP.
    • Linux: sapcontrol -nr <inst> -function GetVersionInfo | egrep -i "ST *720|SAP BASIS"
    • Windows PowerShell: sapcontrol.exe -nr <inst> -function GetVersionInfo
    • Sprawdź dziennik wdrożeń not SAP.
  2. Zbierz logi: SM20, gw_log/dev_rd, dev_icm; artefakty hostowe (Sysmon/auditd).

Containment

  • Ogranicz ruch: ACL/Firewall – zamknij 33xx spoza allowlisty; jeżeli w chmurze – NSG/SG.
  • Czasowo zablokuj konto użyte w podejrzanych logonach RFC; wymuś rotację haseł/kluczy SNC.

Eradication

  • Natychmiast wdroż poprawkę (Note 3668705).
  • Zweryfikuj i doprecyzuj role S_RFC/S_RFCACL; wymuś SNC/TLS dla RFC.

Recovery + Lessons

  • Testy regresji krytycznych funkcji SolMan; przywróć dostęp etapami; dopisz kontrolę bazową w SIEM.

(Poprawka i opis CVE wg NVD/SAP Patch Day).

Przydatne szybkie komendy (bezpieczne):

# Linux: nasłuchy i procesy SAP
ss -ltnp | egrep ':33[0-9]{2}\s'         # RFC Gateway
ps -ef | egrep 'disp\+work|gwrd|sapstartsrv|icman'

# Windows (PowerShell): połączenia na 33xx
Get-NetTCPConnection -LocalPort 3300..3399 | 
  Select-Object LocalAddress,LocalPort,RemoteAddress,State

Przykłady z kampanii / case studies

  • CVE‑2020‑6207 (SolMan EEM) – publiczny exploit i aktywne skanowanie/exploity w 2021 r.; pełny kompromis agentów SMD. To pokazuje, że CVE w SolMan są szybko wykorzystywane, jeśli nie spatchowane.
  • CVE‑2025‑31324 (NetWeaver Visual Composer) – aktywna eksploatacja RCE w 2025 r.; potwierdzenie, że n‑day SAP bywają na celowniku.

Status CVE‑2025‑42887: na moment 2025‑11‑12 brak publicznych raportów o aktywnej eksploatacji; zalecane działanie jak dla krytycznych RCE (patch + ograniczenie ekspozycji). (Wnioski na podstawie komunikatów prasowych i NVD).


Lab (bezpieczne testy) — przykładowe komendy

Środowisko: izolowane NON‑PROD SolMan 7.2 (ST 720). Testy nie polegają na eksploatacji CVE — służą weryfikacji detekcji.

  1. Wygeneruj zdarzenia RFC (SM59 → „Test connection”) z hosta testowego spoza allowlisty — powinny pojawić się wpisy w SM20 i w logach Gateway.
  2. Symuluj ruch sieciowy
# skan portów sapgw
nmap -Pn -p 3300-3399 <ip_solman>
  1. Sprawdź logi bramy RFC (GWMON → Logs/Traces) i zweryfikuj, że reguły Sigma/SIEM z pkt 7 wyłapują wejścia spoza allowlisty.
  2. Host telemetry (Windows/Linux) – uruchom prosty proces testowy z poziomu SAP (legalne zadanie/rapport), aby potwierdzić, że reguła „shell spawned by SAP” działa — NIE uruchamiaj poleceń wrażliwych.

Mapowania (Mitigations, Powiązane techniki)

Techniki ATT&CK (Enterprise)

  • T1190 – Exploit Public‑Facing Application (jeśli RFC/ICM wystawione publicznie).
  • T1210 – Exploitation of Remote Services (wykorzystanie RFC w sieci wewnętrznej/lateral).
  • T1068 – Exploitation for Privilege Escalation (eskalacja po uzyskaniu wykonania w ABAP/host).
  • T1059 – Command and Scripting Interpreter (ew. wtórne wykonanie poleceń).

Mitigations ATT&CK

  • M1051 – Update Software (wdrożenie SAP Note 3668705/Patch Day).
  • M1030 – Network Segmentation (izolacja SolMan/RFC Gateway; dostęp tylko z sieci admin).
  • M1040 – Behavior Prevention on Endpoint (EDR/ASR na hostach Windows SolMan).

Źródła / dalsza literatura

  • NVD: opis, wektor CVSS, odniesienia do SAP Note 3668705. (NVD)
  • SAP Security Patch Day (listopad 2025): lista not, CVE‑2025‑42887 (CVSS 9.9), produkt/wersja. (SAP Support Portal)
  • BleepingComputer / SecurityWeek: przegląd poprawek SAP, wzmianka o CVE‑2025‑42887. (BleepingComputer)
  • SAP docs — Security Audit Log, RFC Gateway, S_RFC/S_RFCACL, ACL: konfiguracja i logging. (SAP Help Portal)
  • Porty RFC Gateway (33xx): artykuł KBA/Community. (SAP Support Portal)
  • Kontekst kampanii (SolMan/NetWeaver): Onapsis/Tenable/NVD/Darktrace. (Onapsis)

Checklisty dla SOC / CISO

SOC (operacyjne, 24/7):

  • Reguły SIEM na 33xx inbound + korelacja z SM20 i procesami hosta.
  • Watchlist kont S_RFC/S_RFCACL i destynacji SM59.
  • Alarm „shell from disp+work/gwrd”.
  • Dashboard: status wdrożenia Note 3668705 na wszystkich SolMan.

CISO / GRC (strategiczne):

  • Polityka segmentacji – SolMan wyłącznie w strefie admin z dostępem z bastionów.
  • Harmonogram Patch Day SAP + SLA krytycznych poprawek ≤ 7 dni.
  • Przegląd uprawnień RFC (least privilege) + SNC/TLS obowiązkowe.
  • Testy kontrolne: skan ekspozycji (33xx/ICM), przegląd konfiguracji reg_info/sec_info.

QNAP łata luki wykorzystane na Pwn2Own Ireland 2025: co musisz zaktualizować i jak zabezpieczyć NAS

Wprowadzenie do problemu / definicja luki

QNAP opublikował pakiet poprawek dla ~24 podatności w swoim portfolio, z czego 7 to 0-daye zademonstrowane podczas Pwn2Own Ireland 2025 (kategoria NAS/SoHo). W grze są zarówno systemy QTS/QuTS hero, jak i aplikacje o wysokich uprawnieniach: HBS 3 (Hybrid Backup Sync), Malware Remover oraz Hyper Data Protector. Skutki obejmują zdalne wykonanie kodu (RCE), ujawnienie informacji, ominięcie mechanizmów bezpieczeństwa oraz DoS. Aktualizacje są już dostępne i powinny zostać wdrożone niezwłocznie.


W skrócie

Minimalne wersje naprawcze:

  • QTS: 5.2.7.3297 (build 20251024+)
  • QuTS hero: h5.2.7.3297+ lub h5.3.1.3292+
  • HBS 3: 26.2.0.938+ (CVE-2025-62840, CVE-2025-62842)
  • Malware Remover: 6.6.8.20251023+ (CVE-2025-11837)
  • Hyper Data Protector: 2.2.4.1+ (CVE-2025-59389)

Po aktualizacji QNAP zaleca zmianę wszystkich haseł do kont i usług.


Kontekst / historia / powiązania

Na Pwn2Own Ireland 2025 zaprezentowano szereg łańcuchów ataku na QNAP. Team DDOS wykazał m.in. łańcuch 8 błędów na routerach i NAS-ach QNAP (nagroda 100 tys. USD), a DEVCORE skleił kilka podatności (iniekcje + błąd formatu) zdobywając 40 tys. USD. Summoning Team i badacz Chumy Tsai (CyCraft) pokazali kolejne wektory w aplikacjach backupowych. QNAP opublikował odpowiednie biuletyny bezpieczeństwa i patche.


Analiza techniczna / szczegóły luki

Zakres i klasy podatności (przykładowe):

  • QTS / QuTS hero – zestaw 3 błędów (m.in. iniekcje i format string), umożliwiający RCE / eskalację w określonych warunkach. Naprawione w QTS 5.2.7.3297 i odpowiednich buildach QuTS hero. (Atrybucja: DEVCORE).
  • HBS 3 (Hybrid Backup Sync) – dwa błędy (m.in. w ścieżkach wykonywania zadań backupu/synchronizacji), które w łańcuchach ataku pozwalały na zdalne wykonanie kodu i manipulację treścią kopii (CVE-2025-62840, CVE-2025-62842). Załatane w 26.2.0.938.
  • Malware Remover – krytyczny code injection (CVE-2025-11837); komponent działa z wysokimi uprawnieniami, więc RCE skutkuje przejęciem NAS-a. Patch: 6.6.8.20251023.
  • Hyper Data Protector – krytyczna podatność (CVE-2025-59389) pozwalająca na kompromitację hosta backupu VM; naprawiona w 2.2.4.1.

Dowód eksploatacji na Pwn2Own (fragmenty łańcuchów, nagrody, celowane modele jak TS-453E) został odnotowany w raportach ZDI z poszczególnych dni konkursu.


Praktyczne konsekwencje / ryzyko

  • Zatrucie i sabotaż kopii zapasowych: przejęcie HBS 3 umożliwia modyfikację/wymazywanie danych w repozytoriach off-site (rsync/S3/SMB/WebDAV), co może zniweczyć strategię 3-2-1 i utrudnić odtworzenie po incydencie.
  • Eskalacja uprawnień przez komponenty zaufane: Malware Remover i Hyper Data Protector działają z uprawnieniami systemowymi; ich kompromitacja = pełne RCE i potencjalny lateral movement do hipernadzorców/serwerów wirtualizacji.
  • Brak sygnałów o atakach „in the wild” na moment publikacji, ale historia QNAP pokazuje, że luki w NAS-ach szybko stają się celem grup ransomware/botnetów – dlatego czas reakcji ma krytyczne znaczenie.

Rekomendacje operacyjne / co zrobić teraz

1) Aktualizacja systemu i aplikacji

  • GUI (zalecane):
    Panel sterowania → SystemAktualizacja oprogramowania (QTS/QuTS hero).
    App Center → wyszukaj: HBS 3, Malware Remover, Hyper Data ProtectorUpdate.
    Wersje docelowe: patrz sekcja „W skrócie”.
  • CLI (sprawdzenie wersji QPKG):
# Na QNAP (BusyBox). Odczyt z /etc/config/qpkg.conf
getcfg "HBS 3 Hybrid Backup Sync" QPKG_Ver -f /etc/config/qpkg.conf
getcfg "Malware Remover"          QPKG_Ver -f /etc/config/qpkg.conf
getcfg "Hyper Data Protector"     QPKG_Ver -f /etc/config/qpkg.conf

2) Po aktualizacji – zmień hasła

Zmień hasła do wszystkich kont lokalnych, myQNAPcloud, udziałów i usług (rsync/FTP/SMB/WebDAV), rozważ też rotację kluczy/API używanych przez zadania HBS 3. Rekomendacja producenta po wdrożeniu poprawek.

3) Ogranicz ekspozycję NAS-a

  • Wyłącz bezpośredni dostęp z Internetu (port-forwarding, UPnP).
  • Używaj VPN/ZTN do administracji; reguły QuFirewall: whitelisting IP/Admin, geo-IP, blokada nietypowych portów.

4) Utwardzenie aplikacji backupu

  • HBS 3: stosuj repozytoria WORM/immutable, wersjonowanie, testy odtwarzania (restore drills).
  • Hyper Data Protector: separuj konta serwisowe (najmniejsze uprawnienia), monitoruj logi z zadaniami VM.

5) Monitoring i detekcja (przykładowe sygnały do SIEM)

  • Nietypowe modyfikacje zadań HBS 3 (nagłe zmiany destynacji/S3 bucket).
  • Nowe konta admin lub rotacja haseł poza oknem serwisowym.
  • Wywołania skryptów/system() przez procesy QPKG (próby RCE).

Wskazówka: jeśli nie możesz patchować natychmiast, przynajmniej wyłącz HBS 3/Hyper Data Protector/ekspozycję WAN i odizoluj NAS segmentacją.


Różnice / porównania z innymi przypadkami

  • W odróżnieniu od dawnych, pojedynczych RCE w panelach WWW NAS-ów, tutaj „gorącym” celem są aplikacje backupowe (HBS 3, Hyper Data Protector) – ich kompromitacja daje większą dźwignię: modyfikacja kopii, pivot do hostów wirtualizacji, niszczenie ścieżek odtworzeniowych.
  • Łańcuchy na Pwn2Own (złożone exploity, łączenie iniekcji z błędami formatu/uwierzytelniania) pokazują rosnącą złożoność ataku i wartość testów red team/bug bounty dla dostawców.

Podsumowanie / kluczowe wnioski

  1. Patch first: QTS/QuTS hero + HBS 3 + Malware Remover + Hyper Data Protector do wersji wskazanych powyżej.
  2. Zmień hasła i klucze natychmiast po aktualizacji.
  3. Zamknij ekspozycję WAN i wymuś administrację przez VPN/ZTN.
  4. Zabezpiecz backup (immutability, testy restore, konta o najmniejszych uprawnieniach).
  5. Monitoruj anomalie w zadaniach backupu i logach QPKG.

To nie jest „zwykły” patch Tuesday – dotyczy komponentów, które decydują o przetrwaniu incydentu (backup i odtwarzanie). Działaj od razu.


Źródła / bibliografia

  • SecurityWeek – przegląd poprawek QNAP po Pwn2Own Ireland 2025 (daty, CVE, wersje) (SecurityWeek)
  • QNAP QSA-25-46 – Multiple Vulnerabilities in HBS 3 Hybrid Backup Sync (wersja 26.2.0.938+) (qnap.com)
  • QNAP QSA-25-47 – Vulnerability in Malware Remover (CVE-2025-11837; 6.6.8.20251023+) (qnap.com)
  • QNAP QSA-25-48 – Vulnerability in Hyper Data Protector (CVE-2025-59389; 2.2.4.1+) (qnap.com)
  • ZDI – Pwn2Own Ireland 2025 (wyniki dzienne; potwierdzenie łańcuchów i nagród) (zerodayinitiative.com)

Cl0p publikuje listę ~30 ofiar kampanii na Oracle E-Business Suite. Co wiemy o atakach i jak się bronić

Wprowadzenie do problemu / definicja luki

Grupa powiązana z Cl0p opublikowała na swoim portalu około 30 rzekomych ofiar kampanii wymierzonej w klientów Oracle E-Business Suite (EBS) — popularnego systemu ERP. Na liście wymieniono m.in. Logitech, The Washington Post, Cox Enterprises, Pan American Silver, LKQ Corporation i Copeland. Część podmiotów (np. The Washington Post) potwierdziła naruszenie, większość jednak milczy lub prowadzi dochodzenia wewnętrzne. Źródła branżowe łączą tę falę incydentów z krytyczną podatnością CVE-2025-61882 (CVSS 9.8) w komponencie BI Publisher Integration pakietu EBS, która umożliwia zdalne, nieautoryzowane ataki przez HTTP. Oracle załatał błąd w trybie alarmowym na początku października 2025 r.


W skrócie

  • Atakujący: klaster przestępczy kojarzony z FIN11 i marką Cl0p (ekstorsja + wycieki).
  • Wektor: wykorzystanie luk w Oracle EBS; najbardziej prawdopodobna — CVE-2025-61882 (RCE bez uwierzytelniania) w zakresach wersji 12.2.3–12.2.14.
  • Skala: dziesiątki organizacji; ok. 29 pozycji na stronie Cl0p, wycieki danych u co najmniej 18 z nich (częściowo wieluset-GB/TB).
  • Linia czasu: masowe maile z szantażem od 29 września; łatki Oracle — 4–5 października 2025 r.; kolejne potwierdzenia ofiar w październiku-listopadzie.
  • Status: część firm potwierdziła incydent (np. The Washington Post), inne nie komentują publicznie.

Kontekst / historia / powiązania

Specjaliści Google Threat Intelligence i Mandiant opisali na początku października zmasowaną kampanię ekstorsyjną: do menedżerów spływały e-maile z twierdzeniami o kradzieży danych z ich środowisk EBS. Równolegle Reuters i inne media informowały o kolejnych ofiarach (np. Envoy Air/AA, Harvard), a Oracle potwierdził problem i wydał Security Alert z łatą. SecurityWeek zebrał listę ~30 nazw wskazanych przez Cl0p, podkreślając, że część danych rzeczywiście wygląda na pochodzące z instancji Oracle. Tę kampanię osadzono w modus operandi znanym z wcześniejszych akcji Cl0p (MOVEit, Fortra, Cleo) — presja medialna + publikacja wykradzionych pakietów.


Analiza techniczna / szczegóły luki

CVE-2025-61882 (Oracle E-Business Suite – Concurrent Processing / BI Publisher Integration)

  • Zakres wersji: 12.2.3–12.2.14.
  • Skutki: zdalne przejęcie komponentu (CIA: C/I/A=H, CVSS 9.8), bez uwierzytelniania przez HTTP.
  • Charakter: „easily exploitable”; sprzyja RCE i dostępowi do wrażliwych danych przetwarzanych w EBS.
  • Eksploatacja: raporty wskazują na aktywny exploit przed publikacją poprawki (zero-day).

Uwaga: w doniesieniach pojawia się także druga luka z tej samej „rodziny”, jednak na dziś to CVE-2025-61882 jest jednoznacznie potwierdzone przez Oracle/NVD jako krytyczny wektor RCE.

Prawdopodobny łańcuch ataku (uogólniony)

  1. Skany internetowo dostępnych instancji EBS (typowe ścieżki /OA_HTML/…).
  2. Wykorzystanie CVE-2025-61882 do wykonania kodu w komponentach związanych z BI Publisher/Concurrent Processing.
  3. Utrwalenie (np. web-shell, konto aplikacyjne) i zbieranie danych (eksporty, raporty, zrzuty tabel).
  4. Ekstorsja: kontakt do kadry zarządzającej z żądaniem okupu + groźbą publikacji plików.
  5. Publikacja paczek na stronie Cl0p w razie braku płatności.

Praktyczne konsekwencje / ryzyko

  • Kompromitacja danych ERP: finanse, łańcuch dostaw, HR, logistyka — wysokie ryzyko wtórnych oszustw i fraudów.
  • Zakłócenia operacji: ryzyko zatrzymania procesów (AP/AR, zamówienia, produkcja).
  • Ryzyko prawno-regulacyjne: RODO/PCI/sox — kary administracyjne, obowiązki notyfikacyjne.
  • Efekt łańcuchowy: EBS z reguły integruje się z innymi systemami (ESB, hurtownie danych) — możliwość lateral movement.
  • Ryzyko reputacyjne: Cl0p publikuje duże wolumeny danych (setki GB do TB), co zwiększa presję na zapłatę.

Rekomendacje operacyjne / co zrobić teraz

1) Patching i konfiguracja

  • Natychmiast zastosuj Security Alert dla CVE-2025-61882 (EBS 12.2.3–12.2.14). Zweryfikuj, że poprawka została wdrożona na wszystkich węzłach (apps tier/db tier).
  • Ogranicz ekspozycję EBS do internetu: jeśli to możliwe, dostęp wyłącznie przez VPN/ZTNA; przeglądarkowy interfejs użytkownika (OA_HTML) nie powinien być publiczny.
  • WAF/Reverse proxy: tymczasowe reguły blokujące nietypowe żądania do endpointów raportowania/BI, rozmiary odpowiedzi i długotrwałe transfery.

2) Detekcja i monitoring (przykładowe reguły)

  • Netflow/Proxy/Firewall – wykrywanie dużych POST/GET do zewnętrznych adresów z hostów EBS:
    • Splunk (prosty szkic): index=proxy OR index=nginx sourcetype=http (uri_path="/OA_HTML/*" OR cs_uri_stem="/OA_HTML/*") | stats sum(bytes_out) as out, values(cs_uri_query) as q by src_ip, uri_path, http_method | where out > 500000000 /* >500MB dziennie */
  • System – nietypowe procesy JVM/Java z parametrami uruchamianymi przez użytkowników aplikacyjnych:
    • Linux (ad-hoc): ps -ef | egrep 'java|weblogic' | egrep -i 'curl|wget|nc|bash -i|sh -i'
  • Pliki aplikacyjne – poszukiwanie web-shelli w katalogach serwisujących EBS: find $INST_TOP/ora/10.1.3/j2ee -type f -mtime -30 -size +50k \ -iname "*.jsp" -exec grep -H -E "(Runtime|getRuntime|ProcessBuilder)" {} \;
  • Logi HTTP – anomalie w BI Publisher/Concurrent Processing (duże odpowiedzi, 5xx po dużych POST, nagły skok 2xx): awk '{print $7, $9, $10}' access_log | grep -E "BIPublisher|Concurrent|OA_HTML" | sort | uniq -c | sort -nr | head

(Powyższe to wzorce poszukiwań – dostosuj do swojej topologii i ścieżek w danym wydaniu EBS.)

3) Łagodzenie skutków i IR

  • Załóż kompromitację dla instancji nienaprawionych przed 4–5 października 2025 r.; przeprowadź triage pamięci (Volatility/AVML) i przegląd harmonogramów (Concurrent Requests), kont oraz pakietów raportowych.
  • Rotacja haseł/kd. integracyjnych i przegląd SSO jeśli EBS zintegrowany jest z IdP.
  • Segmentacja: izoluj serwery apps/db do czasu zakończenia dochodzenia, wstrzymaj zadania eksportów masowych.
  • Zgłoszenia regulacyjne: oceń zakres danych wg jurysdykcji (np. RODO) i czasów detekcji.

4) Twardnienie (hardening) „na jutro”

  • Minimalizacja powierzchni: odłącz zbędne moduły/servlety, wymuś TLS 1.2+, nagłówki bezpieczeństwa.
  • Kontrola egress: EBS zwykle nie potrzebuje otwartego ruchu wychodzącego do internetu — egres pod ścisłą allowlistą.
  • Kopia zapasowa planu odtworzeniowego: test odtworzenia offline; backupy szyfrowane i odseparowane (immutability).

Różnice / porównania z innymi przypadkami

  • MOVEit/Fortra/Cleo vs Oracle EBS: podobny model ekstorsji (nacisk medialny, tablica wstydu, hurtowe wycieki). Różnica: zamiast podatności w menedżerach transferu plików, celem jest system ERP — więc jakość i kontekst danych (finanse, logistyka) mają zwykle wyższą wartość operacyjną dla przestępców i większy impakt biznesowy. SecurityWeek wskazuje, że wcześniejsze skojarzenia Cl0p-FIN11 tłumaczą użycie brandu Cl0p jako „frontu” kampanii.

Podsumowanie / kluczowe wnioski

  • CVE-2025-61882 w Oracle EBS to krytyczna luka RCE, realnie wykorzystywana w kampanii ekstorsyjnej. Łatka od Oracle jest dostępna — patchuj natychmiast.
  • Lista Cl0p obejmuje ~29 organizacji, a część z nich potwierdziła incydenty (np. The Washington Post). Nie zakładaj, że „to tylko straszak”.
  • Traktuj EBS jak system krytyczny: zamknięcie ekspozycji internetowej, kontrola egresu, ciągły monitoring i „assume breach” dla okien bez łatek z końca września/początku października 2025 r.

Źródła / bibliografia

  1. SecurityWeek – lista ~30 ofiar i kontekst kampanii Cl0p (10 listopada 2025). (SecurityWeek)
  2. Reuters – The Washington Post potwierdza naruszenie związane z Oracle EBS (6 listopada 2025). (Reuters)
  3. Oracle Security Alert – CVE-2025-61882 (EBS) – opis i łatki. (Oracle)
  4. NVD – karta podatności CVE-2025-61882 (CVSS 9.8, RCE bez uwierzytelniania). (NVD)
  5. Google Threat Intelligence – wpis o zero-day w Oracle EBS i kampanii ekstorsyjnej (9 października 2025). (Google Cloud)

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/ICESstrony bezpieczne/legit (np. portal firmy), by „udowodnić” nieszkodliwość.
    • Użytkownicylanding 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)