Archiwa: Ransomware - Strona 64 z 87 - Security Bez Tabu

Tag: Ransomware

Ponad 115 tys. firewalli WatchGuard Firebox wciąż podatnych na aktywnie wykorzystywaną lukę RCE (CVE-2025-14733)

Wprowadzenie do problemu / definicja luki

WatchGuard potwierdził aktywne próby wykorzystania krytycznej podatności typu remote code execution (RCE) w zaporach Firebox z systemem Fireware OS. Luka ma identyfikator CVE-2025-14733, dotyczy procesu iked (Internet Key Exchange daemon) i pozwala na zdalne, nieuwierzytelnione wykonanie kodu przy spełnieniu określonych warunków konfiguracyjnych. Producent ocenia ją jako Critical (CVSS 9.3).

Skala problemu jest duża: według analiz przytaczanych w mediach branżowych, >115 tys. instancji Fireboxów wystawionych do Internetu pozostawało niezałatanych w trakcie opisywanej kampanii ataków (różne źródła podają też wyniki skanów rzędu ~125 tys. IP).

W skrócie

  • Co to jest: krytyczne RCE w Fireware OS / iked (out-of-bounds write).
  • Kiedy groźne: gdy urządzenie ma/ miało konfigurację IKEv2 VPN (Mobile User VPN IKEv2 lub BOVPN IKEv2 z dynamicznym peerem); ryzyko może utrzymywać się nawet po „wyczyszczeniu” części ustawień, jeśli pozostaje BOVPN do statycznego peera.
  • Status: WatchGuard udostępnił poprawki (m.in. 2025.1.4, 12.11.6, 12.5.15, 12.3.1 Update 4).
  • Eksploatacja: producent i media potwierdzają aktywne próby ataków „in the wild”; CISA dodała CVE do katalogu KEV.

Kontekst / historia / powiązania

To kolejny przykład trendu, w którym atakujący polują na urządzenia brzegowe (firewalle/VPN), bo są:

  • wystawione do Internetu,
  • często zarządzają „kluczowymi” tunelami i ruchem,
  • a kompromitacja daje wygodny przyczółek do dalszej penetracji sieci.

Dodatkowo WatchGuard wprost wskazuje, że obserwowane próby wykorzystania CVE-2025-14733 wpisują się w szerszą kampanię wymierzoną w infrastrukturę edge u wielu dostawców.

Analiza techniczna / szczegóły luki

Mechanizm

CVE-2025-14733 to out-of-bounds write w procesie iked Fireware OS, co może prowadzić do zdalnego wykonania kodu bez uwierzytelnienia.

Zakres wersji podatnych (wg producenta)

Podatne są wersje Fireware OS:

  • 11.10.2 – 11.12.4_Update1
  • 12.0 – 12.11.5
  • 2025.1 – 2025.1.3

Warunek „czy mój Firebox jest realnie narażony?”

Kluczowy niuans: WatchGuard wyjaśnia, że urządzenia są podatne na atak tylko wtedy, gdy w grę wchodzi konfiguracja IKEv2 VPN (Mobile User VPN IKEv2 lub BOVPN IKEv2 z dynamicznym gateway peer). Co więcej, nawet jeśli część konfiguracji została usunięta, urządzenie może nadal pozostać w ryzyku, gdy nadal istnieje BOVPN do statycznego peera.

IoA (Indicators of Attack) i objawy

WatchGuard opublikował Indicators of Attack pomocne w detekcji prób eksploatacji/kompromitacji, m.in.:

  • IP-y powiązane z aktywnością atakujących (producent rozróżnia znaczenie połączeń outbound vs inbound),
  • logi sugerujące nietypowe zachowanie IKEv2 (np. nietypowo długi łańcuch certyfikatów / ponadnormatywnie duży payload CERT),
  • symptomy na urządzeniu: zawieszenie lub crash iked, co może zrywać negocjacje/re-key tuneli.

Praktyczne konsekwencje / ryzyko

Jeśli atak się powiedzie, skutki typowe dla przejęcia firewalla/VPN są bardzo poważne:

  • pełne przejęcie urządzenia brzegowego i ruchu,
  • możliwość pivotu do sieci wewnętrznej (AD, serwery plików, backupy),
  • podsłuch/ingerencja w tunele, podstawienie reguł, trwałość dostępu,
  • ryzyko incydentu ransomware lub eksfiltracji danych.

Ryzyko jest podbite przez fakt, że skany Internetu wskazują dziesiątki/ponad sto tysięcy potencjalnie podatnych instancji, a luka jest łączona z aktywną eksploatacją.

Rekomendacje operacyjne / co zrobić teraz

1) Patch natychmiast (priorytet P0)

WatchGuard udostępnił poprawione wersje, m.in.:

  • Fireware 2025.1.4+
  • Fireware 12.11.6+
  • Fireware 12.5.15+
  • Fireware 12.3.1 Update 4+

Uwaga: media wskazują, że Fireware 11.x jest EoL i może nie otrzymać poprawek — w takim przypadku realnie wchodzi w grę upgrade sprzętu/wersji albo odcięcie ekspozycji/usługi.

2) Ustal ekspozycję i warunki podatności

  • Sprawdź, czy na urządzeniu jest (lub była) konfiguracja IKEv2 VPN (Mobile User VPN IKEv2, BOVPN IKEv2 z dynamic gateway peer).
  • Zweryfikuj, czy nie pozostały elementy, które utrzymują ryzyko (np. BOVPN do statycznego peera).

3) Detekcja i hunting (krótkoterminowo)

  • Monitoruj IoA od WatchGuard: podejrzane IP, wskazane wzorce logów, objawy zawieszeń/crashy iked.
  • Jeżeli widzisz symptomy kompromitacji: traktuj urządzenie jak potencjalnie przejęte.

4) Rotacja sekretów po incydencie

WatchGuard rekomenduje rotację lokalnie przechowywanych sekretów na podatnych firewallach, jeśli wykryto oznaki złośliwej aktywności. W praktyce obejmuje to co najmniej: klucze/pre-shared keys, hasła kont lokalnych, certyfikaty/klucze prywatne używane przez VPN (w zależności od wdrożenia).

5) Minimalizacja powierzchni ataku (dobre praktyki)

Niezależnie od patchowania:

  • ogranicz wystawienie usług VPN do niezbędnych adresów (ACL, geo, allowlist),
  • chroń interfejsy zarządzania (MFA, dostęp tylko z sieci administracyjnych),
  • zbieraj logi z urządzeń brzegowych do SIEM i ustaw alerty na anomalie w IKEv2.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

BleepingComputer zwraca uwagę na podobieństwo do wcześniejszej luki w Fireboxach (CVE-2025-9242), co praktycznie oznacza dwie lekcje:

  1. IKE/IPsec na brzegu pozostaje „gorącą” powierzchnią ataku,
  2. po publikacji poprawek okno czasowe do masowego skanowania i prób eksploatacji bywa bardzo krótkie — dlatego proces patchowania urządzeń edge powinien działać w trybie „emergency change”.

Podsumowanie / kluczowe wnioski

  • CVE-2025-14733 to krytyczne, aktywnie wykorzystywane RCE w WatchGuard Firebox / Fireware OS (iked).
  • Najważniejszy krok to natychmiastowa aktualizacja do wersji zawierających fix (np. 2025.1.4 / 12.11.6 / 12.5.15 / 12.3.1 Update 4).
  • Równolegle trzeba wykonać weryfikację konfiguracji IKEv2 i przeprowadzić hunting po IoA oraz symptomach iked.
  • W środowiskach na EoL realnym remedium może być upgrade/ wymiana lub zdecydowane ograniczenie ekspozycji usług.

Źródła / bibliografia

  1. WatchGuard PSIRT Advisory: WGSA-2025-00027 (CVE-2025-14733) (watchguard.com)
  2. WatchGuard Blog: dostępne wersje Fireware 2025.1.4 / 12.11.6 / 12.5.15 / 12.3.1 Update 4 (watchguard.com)
  3. BleepingComputer: „Critical RCE flaw impacts over 115,000 WatchGuard firewalls” (BleepingComputer)
  4. SecurityWeek: „WatchGuard Patches Firebox Zero-Day Exploited in the Wild” (SecurityWeek)
  5. CISA: Known Exploited Vulnerabilities Catalog (wpis dla CVE-2025-14733) (cisa.gov)

Cyberatak na La Poste i La Banque Postale: jak DDoS potrafi sparaliżować logistykę i bankowość w szczycie sezonu

Wprowadzenie do problemu / definicja luki

Na trzy dni przed Bożym Narodzeniem francuska grupa La Poste oraz jej ramię bankowe La Banque Postale odnotowały poważne zakłócenia działania usług online. Według komunikatów i relacji medialnych przyczyną był incydent typu DDoS (Distributed Denial of Service), który „zapycha” infrastrukturę ogromną liczbą żądań, prowadząc do niedostępności serwisów i aplikacji.

W praktyce DDoS nie musi oznaczać włamania ani kradzieży danych — jego celem bywa destabilizacja i wymuszenie przestojów. Z perspektywy usług masowych (poczta, tracking przesyłek, bankowość detaliczna) to często wystarcza, by w krytycznym momencie uderzyć w ciągłość działania.

W skrócie

  • Atak DDoS uczynił niedostępnymi strony i aplikacje La Poste oraz powiązanych usług, co uderzyło w obsługę paczek i operacje wymagające dostępu do systemów wewnętrznych.
  • Problemy objęły także La Banque Postale — m.in. autoryzację płatności i część funkcji bankowości mobilnej/online; awaryjnie przeniesiono autoryzacje na SMS.
  • Według deklaracji operatora nie było wpływu na dane klientów, a dochodzenie prowadziła prokuratura w Paryżu; brak było jednoznacznej atrybucji.
  • We wtorek rano usługi nadal nie były w pełni przywrócone; wskazywano, że intensywność ataku spadła, ale działania wciąż trwają.

Kontekst / historia / powiązania

Ten incydent nie wydarzył się w próżni. Media zwracają uwagę na wzrost liczby zakłóceń i incydentów cybernetycznych dotykających administrację i duże organizacje we Francji w ostatnich tygodniach — co napędza narrację o „hybrydowej” presji na państwa europejskie, choć w tym konkretnym przypadku nie wskazano sprawcy.

Wątek DDoS jako narzędzia destabilizacji jest też spójny z obserwacjami francuskiej agencji ANSSI: ataki DDoS są jedną z najczęstszych metod działań „na zakłócenie”, szczególnie lubianą przez środowiska hacktywistyczne, ale wykorzystywaną również przez aktorów o bardziej zróżnicowanych profilach. ANSSI wskazywała też na wyraźny wzrost (globalnie „podwojenie”) liczby takich ataków obserwowanych przeciwko celom francuskim w 2024 r.

Dodatkowy smaczek kontekstowy: euronews odnotował, że niektóre z tych samych usług (np. tracking Colissimo i skrytka Digiposte) miały być zakłócone już w sobotę, zanim doszło do poniedziałkowego „dużego” incydentu — bez potwierdzenia, czy to ten sam wektor.

Analiza techniczna / szczegóły ataku

Co oznacza „DDoS” w realiach poczty i bankowości?

DDoS to przeciążenie usług z wielu źródeł jednocześnie (botnety, infrastruktura pośrednicząca, czasem „booter/stresser”). Efekt końcowy bywa identyczny jak przy awarii: aplikacje nie odpowiadają, API time-outuje, a systemy zależne (autoryzacje, tracking, formularze nadawcze) przestają działać.

W raportowanym przypadku:

  • La Poste komunikowała niedostępność usług online i brak wpływu na dane klientów, ale wyraźne zakłócenia obsługi paczek i operacji wymagających trackingu/dostępu do systemów.
  • Wskazywano niedostępność wielu witryn i aplikacji w ekosystemie (m.in. La Poste, Colissimo, La Banque Postale oraz usługi tożsamości cyfrowej).

Dlaczego autoryzacje płatności „przesiadły się” na SMS?

Jeśli bankowość mobilna/online nie jest w stanie przeprowadzić typowej ścieżki SCA (np. autoryzacja w aplikacji lub mechanizmem takim jak Certicode), bank może uruchomić obejście: alternatywny kanał potwierdzeń. W tym zdarzeniu opisywano przekierowanie zatwierdzania operacji do SMS.

To klasyczny kompromis „ciągłość działania vs. ergonomia/ryzyko”:

  • plus: klienci nadal mogą dokończyć część transakcji,
  • minus: SMS jest statystycznie słabszym kanałem (SIM swap, przejęcia numerów, malware na telefonie), więc powinien być traktowany jako tryb awaryjny z dodatkowymi limitami i monitoringiem anomalii.

Dlaczego takie incydenty potrafią trwać wiele godzin?

W relacjach podkreślano, że sytuacja utrzymywała się przez co najmniej wiele godzin i nie była w pełni rozwiązana jeszcze następnego ranka.
Przy DDoS „czas trwania” zależy m.in. od:

  • zdolności do odfiltrowania ruchu (scrubbing/Anycast/CDN),
  • charakteru ataku (wolumetryczny vs aplikacyjny),
  • tego, czy atakujący adaptuje się do filtrów,
  • oraz tego, czy organizacja ma gotowe scenariusze degradacji (np. tryb „tylko odczyt”, caching, odcięcie mniej krytycznych funkcji).

Praktyczne konsekwencje / ryzyko

Dla logistyki i klientów

  • Najbardziej dotkliwe są „punkty tarcia” na styku cyfrowego i fizycznego: nadanie/odbiór przesyłki, etykieta, tracking, płatność online. Gdy systemy trackingu i operacje zależne od systemów wewnętrznych padają, fizyczna sieć placówek nadal działa, ale efektywność gwałtownie spada.
  • Sezonowość zwiększa wrażliwość: w okresie przedświątecznym nawet krótkie okno niedostępności generuje falę zgłoszeń, kolejki i presję na personel.

Dla bankowości

  • Zakłócenie autoryzacji i dostępu do aplikacji przekłada się na opóźnienia płatności, wzrost fraud alertów i większe ryzyko błędów operacyjnych (np. klienci „ponawiają” transakcje).
  • Nawet jeśli karty i bankomaty działają, utrata kanałów cyfrowych w czasie szczytu zakupowego uderza w zaufanie i obciążenie call center/oddziałów.

Ryzyko strategiczne: DDoS jako „tani” sabotaż

ANSSI zwraca uwagę, że DDoS to częsta broń destabilizacji — relatywnie łatwa do uruchomienia, trudna do „zamknięcia” jednym ruchem i skuteczna medialnie.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista praktyk, które realnie ograniczają skutki DDoS dla usług masowych (logistyka/bankowość), bez obiecywania „magicznej odporności”:

  1. Zabezpieczenie warstwy brzegowej (edge)
  • Anycast + globalny CDN, WAF i mechanizmy bot management.
  • Stała integracja z dostawcą scrubbingu (nie „na telefon w kryzysie”).
  1. Playbooki DDoS i testy w warunkach „peak season”
  • Symulacje ataków aplikacyjnych (L7) na API i krytyczne ścieżki (tracking, logowanie, autoryzacja).
  • Runbook: kto podejmuje decyzję o degradacji funkcji, jakie progi odcięć, jak komunikować to klientom.
  1. Degradacja kontrolowana zamiast „total down”
  • Tryb tylko do odczytu dla trackingu (np. cache ostatniego statusu).
  • Kolejkowanie zadań (message queue), by operacje z placówek mogły się buforować i wrócić po przywróceniu.
  1. Awaryjna autoryzacja płatności: ogranicz ryzyko
  • Jeśli wchodzisz w SMS jako plan B, ustaw limity kwotowe/ryzyko, wymuś dodatkową analizę behawioralną, podbij monitoring na SIM swap.
  • Komunikat do klientów: jak rozpoznać phishing w czasie incydentu (atakujący lubią „podszyć się” pod kryzys).
  1. Komunikacja kryzysowa
  • Jedna strona statusowa poza główną domeną (najlepiej u niezależnego dostawcy) + aktualizacje w mediach społecznościowych.
  • Jasny opis: co działa, co nie działa, jakie obejścia są bezpieczne.

Różnice / porównania z innymi przypadkami

  • DDoS vs ransomware: ransomware zwykle uderza w integralność i poufność (często także dostępność), ale wymaga wejścia do środka. DDoS może być „czystym” atakiem na dostępność — szybciej uruchamianym i łatwiej skalowanym w czasie.
  • DDoS na usługi publiczne vs infrastruktura krytyczna: ANSSI opisywała przypadki, w których silne DDoS-y dotykały nawet bardzo istotnych elementów (np. wpływ na dostępność usług krytycznych), co pokazuje, że granica „tylko niedogodność” potrafi się przesuwać.
  • Efekt domina: tu widać typowy wzorzec — jedna fala niedostępności potrafi jednocześnie uderzyć w tracking, płatności, autoryzacje i obsługę w placówkach, bo nowoczesne procesy są silnie „API-first”.

Podsumowanie / kluczowe wnioski

DDoS w grudniu to nie tylko problem IT — to test odporności operacyjnej całej organizacji. W przypadku La Poste i La Banque Postale kluczowe było to, że atak uderzył w usługi online w krytycznym oknie przedświątecznym, powodując zakłócenia w logistyce i bankowości, przy jednoczesnych deklaracjach braku wpływu na dane klientów.

Najważniejsza lekcja jest prosta: odporność na DDoS nie kończy się na filtracji ruchu. Liczy się plan degradacji usług, alternatywne (ale bezpieczne) ścieżki autoryzacji, oraz komunikacja, która ogranicza chaos i podatność na phishing „podszywający się” pod incydent.

Źródła / bibliografia

  1. SecurityWeek (Associated Press): „Cyberattack Disrupts France’s Postal Service and Banking During Christmas Rush”. (SecurityWeek)
  2. The Guardian: „France’s national post office hit by suspected cyber-attack”. (The Guardian)
  3. Le Monde: „La Poste victime d’une cyberattaque juste avant Noël”. (Le Monde.fr)
  4. Euronews (FR): „Les services numériques de La Poste visés par une cyberattaque…”. (euronews)
  5. ANSSI / CERT-FR: „Panorama de la cybermenace 2024” (sekcja o wzroście DDoS).

RansomHouse wzmacnia szyfrowanie: „Mario” przechodzi na wielowarstwowe przetwarzanie danych

Wprowadzenie do problemu / definicja luki

Ransomware od dawna nie jest już „tylko” szyfrowaniem plików. Dla wielu grup to kompletna platforma wymuszeń: kradzież danych, presja medialna, szantaż prawny i dopiero na końcu — szyfrowanie infrastruktury krytycznej (często wirtualizacji i kopii zapasowych). RansomHouse to dobry przykład takiej ewolucji: start jako operacja data extortion, a dziś rozwijanie własnych narzędzi do blokowania środowisk, szczególnie VMware ESXi.

W grudniu 2025 badacze i media opisali istotną aktualizację szyfratora RansomHouse o nazwie „Mario”: przejście z prostego, liniowego przekształcania danych do podejścia warstwowego, trudniejszego do analizy i potencjalnie bardziej dotkliwego dla ofiar.

W skrócie

  • RansomHouse zaktualizował szyfrator „Mario” z jednoprzebiegowego przekształcania danych do dwustopniowego procesu z dwoma kluczami (32B + 8B).
  • Nowa wersja stosuje przetwarzanie plików porcjami (chunking) o zmiennym rozmiarze i próg 8 GB, a także elementy szyfrowania „rzadkiego” (sparse), czyli tylko wybranych bloków pliku.
  • Przetwarzanie jest nieliniowe i oparte o złożone obliczenia wyznaczające kolejność/offsety, co utrudnia analizę statyczną i inżynierię wsteczną.
  • Cel pozostaje ten sam: szybkie „położenie” wirtualizacji i utrudnienie odtwarzania — pliki dostają rozszerzenie .emario, a w katalogach pojawia się notatka „How To Restore Your Files.txt”.

Kontekst / historia / powiązania

Wczesne komunikaty o RansomHouse (2022) podkreślały, że grupa deklaruje model „nie szyfrujemy, tylko kradniemy” i oferuje „raport” z lukami po opłaceniu okupu — pozycjonując się niemal jak agresywni „audytorzy”.

Z czasem jednak widać było coraz bardziej „ransomware’ową” dojrzałość: rozwój narzędzi, infrastruktury negocjacyjnej oraz koncentrację na środowiskach wirtualnych. Unit 42 opisuje także narzędzie MrAgent, które służy do działań w środowisku ESXi i ułatwia wdrożenie „Mario”.

RansomHouse bywa też analizowany w szerszym ekosystemie grup, gdzie pojawiają się cross-claimy (różne gangi przypisujące sobie te same ofiary) oraz możliwe współdzielenie danych/zasobów. Analyst1 łączy jego genezę i kontekst z falą „potomków” po wycieku kodu Babuk oraz opisuje zjawisko współpracy i przenikania się działań w podziemiu.

Analiza techniczna / szczegóły luki

1) Dwustopniowe przekształcanie danych i „dwa klucze”

Kluczowa zmiana w „Mario” to przejście na dwustopniową transformację z dodatkowym kluczem. Unit 42 wskazuje, że nowsze próbki generują losowo 32-bajtowy klucz główny i 8-bajtowy klucz pomocniczy, a szyfrowanie jest przetwarzane osobno dla każdego z nich. Efekt: bez kompletu materiału kluczowego odzysk danych staje się istotnie trudniejszy.

BleepingComputer streszcza to jako odejście od „single-pass” do „two-stage transformation”, co ma zwiększać entropię i utrudniać częściowy odzysk danych.

2) Porcjowanie danych: dynamiczne „chunking” i próg 8 GB

Z perspektywy IR/DFIR druga duża zmiana to sposób obchodzenia się z dużymi plikami: „Mario” przechodzi z prostego, sekwencyjnego pętlenia po stałych segmentach do segmentów o zmiennej długości (z progiem 8 GB) i obliczeń wyznaczających rozmiary/offsety porcji.

3) „Sparse encryption”: szyfrowanie selektywne

W nowszej wersji pojawia się też sparse encryption — szyfrowanie tylko wybranych bloków pliku na określonych offsetach. Taki model potrafi drastycznie skrócić czas operacji przy zachowaniu skutecznej blokady (np. systemy plików/VM mogą przestać działać mimo, że nie zaszyfrowano 100% bajtów).

4) Nieliniowość i utrudnianie analizy

Unit 42 podkreśla, że chunking jest nieliniowy, oparty o złożone formuły matematyczne determinujące kolejność przetwarzania i różne strategie w zależności od rozmiaru pliku — to realnie utrudnia szybkie „rozpoznanie wzorca” w analizie.

5) Target: wirtualizacja (ESXi) i rozszerzenie .emario

W praktyce „Mario” skupia się na plikach związanych z wirtualizacją i backupem (m.in. typowe rozszerzenia VMware/Veeam) oraz dodaje rozszerzenie .emario. Ransom note ma nazwę How To Restore Your Files.txt.

Praktyczne konsekwencje / ryzyko

  1. Trudniejsza analiza i wolniejsze reagowanie. Nieliniowe przetwarzanie i dodatkowa warstwa kluczowania zwiększają koszt analizy wstecznej oraz utrudniają szybkie tworzenie „reguł” pod konkretne warianty.
  2. Większa presja negocjacyjna. Szybsze lub bardziej niezawodne unieruchamianie VM/backupów zwykle przekłada się na krótsze RTO w realu (czyli większą presję biznesu, by „coś” zrobić natychmiast). BleepingComputer wskazuje, że celem zmian jest m.in. lepsza skuteczność i dźwignia po szyfrowaniu.
  3. Ryzyko „podwójnego uderzenia”: dane + szyfrowanie. RansomHouse historycznie silnie akcentował warstwę wycieku danych (szantaż publikacją/sprzedażą), a jednocześnie rozwija tooling do blokowania infrastruktury — co zwiększa łączny koszt incydentu (prawny, reputacyjny, operacyjny).

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które mają największy sens „tu i teraz”, gdy widzimy ofensywne inwestycje w ESXi i w szyfrowanie selektywne:

Twardnienie i ekspozycja ESXi

  • Ogranicz dostęp do paneli zarządzania ESXi/vCenter (VPN + MFA + allowlist IP; absolutnie nie „na świat”).
  • Segmentuj sieć: oddziel zarządzanie hypervisorami, backupy, storage i sieć użytkowników.

Kopie zapasowe odporne na atak

  • Stosuj kopie offline/immutable i regularnie testuj odtwarzanie (nie tylko „czy backup się robi”).
  • Upewnij się, że repozytoria backup nie są „jednym kliknięciem” dostępne z domeny/tej samej płaszczyzny uprawnień.

Detekcja i reakcja

  • Alarmuj na pojawienie się .emario oraz pliku How To Restore Your Files.txt (to proste i często daje pierwsze sygnały skali).
  • Włącz telemetrykę dla krytycznych serwerów plików/hostów wirtualizacji (EDR/NDR, logi z vCenter/ESXi) oraz korelacje pod nietypową aktywność na dużych plikach (w tym szybkie modyfikacje/odczyty blokowe).

Gotowość proceduralna

  • Przygotuj „minimum viable IR” dla scenariusza zaszyfrowania wirtualizacji: kontakty, decyzje o izolacji, priorytety przywracania, ścieżka komunikacji do prawników i DPO.
  • Dla organizacji regulowanych: plan na obsługę wycieku danych (bo „extortion” jest w tym modelu równie ważny jak szyfrowanie).

Różnice / porównania z innymi przypadkami

Aktualizacja „Mario” wpisuje się w szerszy trend: mniej „głośnego” szyfrowania wszystkiego, więcej sprytnego przetwarzania, które:

  • skraca czas operacji (np. szyfrowanie selektywne),
  • utrudnia analizę i tworzenie uniwersalnych narzędzi obrony,
  • maksymalizuje presję na organizację (blokada VM/backup).

Ciekawostką u RansomHouse jest to, że grupa długo budowała markę w modelu „extortion-only”, a dziś rozwija dojrzałe elementy typowe dla RaaS i ekosystemu współdzielenia/krzyżowych roszczeń w podziemiu — co w praktyce zwiększa niepewność atrybucji i utrudnia przewidywanie TTP.

Podsumowanie / kluczowe wnioski

RansomHouse nie stoi w miejscu. „Mario” zyskuje dwustopniowe szyfrowanie z dwoma kluczami, dynamiczne porcjowanie i elementy sparse encryption, a do tego nieliniowe przetwarzanie utrudniające analizę.

Dla obrońców oznacza to jedno: priorytetem powinny być odporne kopie zapasowe, twardnienie i izolacja warstwy wirtualizacji (ESXi/vCenter) oraz detekcja nastawiona na szybkie uchwycenie pierwszych symptomów (np. .emario i ransom note), zanim szyfrowanie rozleje się na całą farmę.

Źródła / bibliografia

  1. BleepingComputer — „RansomHouse upgrades encryption with multi-layered data processing” (20 grudnia 2025) (BleepingComputer)
  2. Palo Alto Networks Unit 42 — „From Linear to Complex: An Upgrade in RansomHouse Encryption” (Unit 42)
  3. SentinelOne — „RansomHouse Ransomware: Analysis, Detection, and Mitigation” (SentinelOne)
  4. Help Net Security — „RansomHouse: Bug bounty hunters gone rogue?” (Help Net Security)
  5. Analyst1 — „RansomHouse: Stolen Data Market, Influence Operations & Other Tricks Up the Sleeve” (Analyst1)

Nefilim ransomware: ukraiński operator przyznaje się do winy — jak działał model „affiliate” i co to mówi o dzisiejszych kampaniach RaaS

Wprowadzenie do problemu / definicja luki

Sprawa Nefilim to dobry przykład, jak „klasyczny ransomware” ewoluował w dojrzały model usługowy: jedni dostarczają platformę i malware, inni (affiliate) włamują się do sieci ofiary, kradną dane, a potem szyfrują i szantażują publikacją. To nie „jedna luka”, tylko cały łańcuch: dostęp początkowy → rozpoznanie → eskalacja → eksfiltracja → szyfrowanie i presja negocjacyjna.

W skrócie

  • Artem Aleksandrovych Stryzhak (35 lat) przyznał się w USA do udziału w międzynarodowych atakach ransomware z użyciem Nefilim; grozi mu do 10 lat więzienia.
  • Z materiałów sprawy wynika, że otrzymał dostęp do kodu i „panelu” Nefilim w zamian za 20% udziału w okupach.
  • Operatorzy Nefilim mieli preferować firmy z USA/Kanady/Australii z przychodami > 100 mln USD (a później zachęcać do > 200 mln USD) i stosować double extortion („szyfrujemy + publikujemy wykradzione dane”).
  • Wątek ścigania współsprawcy (Volodymyr Tymoshchuk) jest wspierany nagrodą do 11 mln USD za informacje prowadzące do zatrzymania/lokalizacji.

Kontekst / historia / powiązania

Nefilim był szerzej obserwowany od 2020 r. jako „nowoczesny ransomware” celujący w duże organizacje, powiązywany z ekosystemem RaaS oraz ewolucją/continuum rodzin typu Nemty. Trend Micro opisuje go jako operację RaaS z podziałem zysków i długim „czasem przebywania” w sieci ofiary (często tygodnie) w celu maksymalizacji presji i strat.

W tle tej sprawy pojawiają się też powiązania personalne/operacyjne z innymi głośnymi rodzinami ransomware. The Record opisywał oskarżenia wobec Tymoshchuka jako administratora m.in. LockerGoga, MegaCortex i Nefilim, co pasuje do wzorca „rebrandów” i rotacji narzędzi, gdy ekosystem zostaje spalony lub pojawiają się publiczne deszyfratory.

Analiza techniczna / szczegóły luki

1) Model operacyjny: panel + per-ofiara artefakty

Z opisu postępowania wynika, że afilianci korzystali z platformy („panelu”), a dla każdej ofiary przygotowywano unikalny plik wykonywalny, klucz deszyfrujący i dedykowaną notatkę okupu. To utrudnia proste IOC-based hunting i sprzyja skalowaniu operacji.

2) Dobór ofiar i „profilowanie” pod kwotę okupu

W materiałach przytoczonych przez DataBreaches wskazano, że po uzyskaniu dostępu sprawcy badali firmę (rozmiar, przychody, dane kontaktowe), aby dobrać strategię negocjacji i cenę — to cecha kampanii „big game hunting”.

3) Double extortion i infrastruktura „leak site”

Nefilim działał w schemacie podwójnego wymuszenia: szyfrowanie było tylko jednym z elementów, a realną dźwignią stała się groźba publikacji danych na publicznie dostępnych stronach wyciekowych („Corporate Leaks”).

4) Typowy łańcuch ataku wg MITRE ATT&CK (przykładowy scenariusz)

Trend Micro mapuje typową narrację ataku Nefilim na taktyki/techniki MITRE: rozpoznanie hostów wystawionych do internetu, wejście przez podatny komponent brzegowy (w ich scenariuszu: Citrix ADC CVE-2019-19781), a następnie poruszanie się lateralne i użycie legalnych narzędzi administracyjnych, zanim dojdzie do fazy destrukcyjnej.

W praktyce: Nefilim to nie „klik w załącznik”, tylko kampanie o charakterze ukierunkowanym, gdzie bezpieczeństwo usług zdalnego dostępu, podatności edge i higiena uprawnień są krytyczne.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko operacyjne: przestoje, utrata ciągłości działania i koszty odtwarzania (nawet bez płatności okupu). Organy ścigania wskazują na milionowe straty wynikające zarówno z wymuszeń, jak i szkód w sieciach ofiar.
  2. Ryzyko prawne i regulacyjne: double extortion oznacza, że incydent szybko staje się naruszeniem poufności (potencjalne obowiązki notyfikacyjne, spory, kary).
  3. Ryzyko reputacyjne i strategiczne: długotrwałe utrzymywanie danych na leak site i „przykładowe” publikacje podbijają presję na kolejne ofiary i wzmacniają efekt kuli śniegowej.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie „przecinają” łańcuch ataku obserwowany w nowoczesnych kampaniach RaaS (takich jak Nefilim):

  1. Zabezpiecz dostęp zdalny i usługi brzegowe
  • MFA wszędzie, gdzie to możliwe (VPN, VDI, portale, panele administracyjne).
  • Zero-trust dla dostępu uprzywilejowanego: PAM, JIT/JEA, segmentacja.
  • Ogranicz ekspozycję RDP/administracji (allowlist IP, bastion host, brak bezpośredniego wystawienia).
  1. Patch management pod edge
  • Priorytet dla podatności na urządzeniach brzegowych (VPN, ADC, urządzenia publikujące aplikacje). Trend Micro wprost pokazuje, że to częsty punkt startu.
  1. Wykrywanie działań „przed szyfrowaniem”
  • Polowanie na techniki z ATT&CK: skanowanie usług, nietypowe logowania adminów, tworzenie nowych kont uprzywilejowanych, masowe zrzuty poświadczeń, wyłączanie zabezpieczeń.
  • Alerty na nietypowe narzędzia administracyjne używane „po godzinach” i z nietypowych hostów.
  1. Backupy odporne na ransomware
  • Kopie niemodyfikowalne (immutable), offline/air-gapped, testy odtwarzania (RTO/RPO).
  • Oddzielne poświadczenia do systemów backupu i monitoring zmian polityk backupowych.
  1. Gotowość na wariant „data theft”
  • DLP/egress monitoring, limity i detekcje na duże transfery, kontrola narzędzi do archiwizacji i szyfrowania po stronie atakującego.
  • Plan komunikacji i IR: playbook na „wyciek + szyfrowanie”.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • Nefilim vs LockerGoga/MegaCortex: z perspektywy praktycznej dla obrońców różnica polega nie tylko na rodzinie malware, ale na ekosystemie (rebrand, zmiana narzędzi, migracja operatorów). Wątek Tymoshchuka w The Record sugeruje, że ci sami aktorzy mogli rotować narzędziami i infrastrukturą, gdy poprzednie operacje traciły „przydatność” (np. przez publikację deszyfratorów lub presję organów ścigania).
  • Nefilim jako „RaaS z dojrzałym profilingiem”: Trend Micro podkreśla długi dwell time, victim profiling i presję double extortion jako elementy charakterystyczne dla nowoczesnych, targetowanych kampanii.

Podsumowanie / kluczowe wnioski

Sprawa Stryzhaka nie jest tylko historią o jednym „operatorze ransomware”. To migawka z rynku RaaS, w którym:

  • afilianci kupują/uzyskują dostęp do narzędzi i infrastruktury,
  • ataki są targetowane na organizacje o wysokich przychodach,
  • presja negocjacyjna opiera się na kradzieży danych i groźbie publikacji,
  • a techniczny punkt ciężkości obrony przesuwa się na edge security, tożsamość, telemetrię i odporne kopie.

Źródła / bibliografia

  1. DataBreaches.net — opis sprawy, informacje z dokumentów sądowych, szczegóły dot. panelu i profilu ofiar. (DataBreaches.Net)
  2. U.S. Department of Justice (EDNY) — komunikat o przyznaniu się do winy, ekstradycji i nagrodzie dla współsprawcy. (Department of Justice)
  3. CyberScoop — kontekst medialny, podsumowanie zakresu czasowego aktywności i skutków. (CyberScoop)
  4. The Record (Recorded Future News) — kontekst dot. Tymoshchuka i powiązań z LockerGoga/MegaCortex/Nefilim. (The Record from Recorded Future)
  5. Trend Micro — techniczny opis typowego łańcucha ataku Nefilim i mapowanie na MITRE ATT&CK. (www.trendmicro.com)

Ponad 25 tys. urządzeń Fortinet z włączonym FortiCloud SSO wystawionych na zdalne ataki – co oznaczają CVE-2025-59718 i CVE-2025-59719

Wprowadzenie do problemu / definicja luki

W grudniu 2025 r. zwrócono uwagę na bardzo niebezpieczny scenariusz: tysiące urządzeń Fortinet (m.in. FortiOS/FortiGate, FortiProxy, FortiSwitchManager oraz FortiWeb) ma włączoną funkcję “Allow administrative login using FortiCloud SSO” i jednocześnie wystawiony na Internet panel administracyjny. Internetowe skany wskazały ponad 25 000 takich adresów IP, co przy aktywnych próbach nadużyć przekłada się na realne ryzyko przejęcia kont administracyjnych i wycieku konfiguracji.

Rdzeniem problemu są dwie podatności:

  • CVE-2025-59718 – dotyczy wielu produktów (w praktyce: FortiOS/FortiProxy/FortiSwitchManager) i pozwala ominąć uwierzytelnianie FortiCloud SSO,
  • CVE-2025-59719 – analogiczny wektor dla FortiWeb.

W obu przypadkach chodzi o błędną weryfikację podpisu kryptograficznego w przepływie SAML (klasa błędu CWE-347), co umożliwia atakującemu obejście logowania SSO bez posiadania prawidłowych poświadczeń.

W skrócie

  • Skala ekspozycji: Shadowserver raportował >25 tys. IP z “odciskiem” FortiCloud SSO; w samych USA ~5,4 tys., w Indiach ~2 tys.
  • Aktywne nadużycia: Arctic Wolf obserwował intruzje z użyciem “malicious SSO logins” od 12 grudnia 2025.
  • Typowy ciąg ataku: udane logowanie admin przez SSO → eksport/ściągnięcie pliku konfiguracji przez GUI.
  • Priorytet naprawy: CISA dodała CVE-2025-59718 do KEV 16 grudnia 2025, a w NVD widać termin działań do 23 grudnia 2025 (kontekst KEV).

Kontekst / historia / powiązania

Warto podkreślić jedną rzecz, która ułatwia przeoczenie ryzyka w organizacjach: FortiCloud SSO nie musi być włączone “od zawsze”.

CERT Polska zwraca uwagę, że funkcja jest domyślnie wyłączona, ale w praktyce bywa automatycznie włączana podczas rejestracji urządzenia w FortiCare z poziomu GUI, jeśli administrator nie odznaczy odpowiedniej opcji.

W tym samym czasie (grudzień 2025) obserwujemy typowy “pattern” dla urządzeń brzegowych (edge): szybkie przejście od publikacji poprawek do masowych skanów i prób nadużyć, szczególnie gdy panel administracyjny jest dostępny z Internetu. W omawianym incydencie potwierdzono także, że liczba instancji z włączonym SSO i widocznym GUI jest zaskakująco duża.

Analiza techniczna / szczegóły luki

Na czym polega podatność?

Z technicznego punktu widzenia obie podatności sprowadzają się do tego, że urządzenie akceptuje spreparowaną odpowiedź SAML w procesie FortiCloud SSO, ponieważ weryfikacja podpisu kryptograficznego jest niewłaściwa (CWE-347). Skutkiem jest obejście uwierzytelniania – atakujący może uzyskać sesję administracyjną bez prawidłowego logowania.

Co robią atakujący w praktyce?

BleepingComputer oraz Arctic Wolf opisują spójny schemat:

  1. logowanie do panelu jako admin metodą SSO z nietypowego adresu źródłowego,
  2. następnie akcja przez GUI typu download/export system configuration,
  3. a dalej – analiza konfiguracji (interfejsy, polityki, usługi wystawione na Internet, hashe haseł).

Arctic Wolf opublikował też przykładowe adresy źródłowe (IOC) powiązane z obserwowanymi, złośliwymi logowaniami SSO oraz wskazał, że ruch pochodził z wybranych dostawców hostingu.

Jakie wersje są podatne i jakie są “fixed”?

Kanadyjskie Cyber Centre podaje jednoznacznie, do jakich wersji należy zaktualizować systemy (przykłady):

  • FortiOS: 7.6.4+, 7.4.9+, 7.2.12+, 7.0.18+
  • FortiProxy: 7.6.4+, 7.4.11+, 7.2.15+, 7.0.22+
  • FortiSwitchManager: 7.2.7+, 7.0.6+
  • FortiWeb: 8.0.1+, 7.6.5+, 7.4.10+

Praktyczne konsekwencje / ryzyko

Najbardziej “toksyczny” element tego typu incydentów to pobranie konfiguracji. Taki plik potrafi ujawnić:

  • topologię i podsieci (network layout),
  • reguły firewall / polityki,
  • listę usług wystawionych na Internet,
  • konta administracyjne i artefakty uwierzytelniania (w tym hashe, które w sprzyjających warunkach da się łamać offline).

W praktyce oznacza to, że nawet jeśli atakujący “tylko” zaloguje się i ściągnie konfigurację, konsekwencje mogą być długofalowe: dalsza eskalacja, pivot do sieci wewnętrznej, przygotowanie kampanii ransomware albo trwałe utrzymanie dostępu.

Rekomendacje operacyjne / co zrobić teraz

Poniżej playbook w kolejności, która zwykle działa najlepiej operacyjnie:

  1. Zidentyfikuj ekspozycję GUI
    • Czy panel administracyjny (HTTPS/GUI) jest dostępny z Internetu?
    • Jeśli tak: ogranicz dostęp (VPN / allowlista / segmentacja), zanim przejdziesz dalej.
  2. Natychmiast aktualizuj do wersji naprawionych
    • Kieruj się listą “Solution/Upgrade to …” podaną przez Cyber Centre (sekcja powyżej).
  3. Tymczasowo wyłącz logowanie FortiCloud SSO (jeśli nie możesz od razu zaktualizować)
    • CERT Polska oraz Arctic Wolf wskazują możliwość wyłączenia FortiCloud SSO także z CLI:config system global set admin-forticloud-sso-login disable end
  4. Sprawdź logi pod kątem wzorca nadużycia
    • Szukaj zdarzeń typu “admin login successful” z metodą sso oraz krótkiej sekwencji działań administracyjnych po logowaniu (np. pobranie konfiguracji przez GUI).
    • Porównaj adresy źródłowe z IOC publikowanymi przez Arctic Wolf.
  5. Higiena poincydentowa (jeśli widzisz oznaki kompromitacji)
    • rotacja haseł admin, przegląd kont i uprawnień,
    • weryfikacja zmian w konfiguracji i regułach,
    • jeśli plik konfiguracyjny mógł wyciec: traktuj to jako wyciek informacji wrażliwych i dostosuj model zagrożeń (np. zmiana kluczy/sekretów, przegląd ekspozycji usług).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W tym przypadku szczególnie istotne są dwie różnice względem “klasycznych” luk w GUI/SSL-VPN:

  • Warunek aktywacji wektora: atak dotyczy sytuacji, gdy jest włączona funkcja FortiCloud SSO dla logowania administracyjnego (co może się stać “przy okazji” rejestracji w FortiCare).
  • Wektor SAML/SSO: zamiast błędu w endpointach webowych, problem siedzi w obsłudze i weryfikacji SAML, co ułatwia tworzenie “logic exploitów” (obejścia), a niekoniecznie typowych exploitów pamięciowych.

Podsumowanie / kluczowe wnioski

  • Jeśli masz produkty Fortinet i kiedykolwiek rejestrowałeś je w FortiCare, sprawdź, czy nie jest włączone FortiCloud SSO dla logowania admina.
  • Traktuj tę sprawę jako pilną: potwierdzono aktywne nadużycia (od 12 grudnia 2025), a CVE-2025-59718 trafiło do kontekstu KEV (16 grudnia 2025; termin działań do 23 grudnia 2025 w NVD).
  • “Must-have” to: patch + ograniczenie dostępu do GUI + weryfikacja logów pod kątem logowań SSO i eksportów konfiguracji.

Źródła / bibliografia

  1. BleepingComputer – skala ekspozycji i kontekst Shadowserver/SSO fingerprinting (BleepingComputer)
  2. Arctic Wolf – obserwacje nadużyć, IOCs, przykładowe logi oraz wersje naprawione (Arctic Wolf)
  3. CERT Polska (moje.cert.pl) – opis warunku włączenia SSO i rekomendacje + CLI (moje.cert.pl)
  4. NVD (NIST) – opis CVE-2025-59718 oraz adnotacja dot. KEV/due date (nvd.nist.gov)
  5. Canadian Centre for Cyber Security – alert AL25-019 z listą wersji i zaleceń (Canadian Centre for Cyber Security)

Nigeria aresztuje twórcę platformy phishingowej Raccoon0365/RaccoonO365 wymierzonej w Microsoft 365

Wprowadzenie do problemu / definicja luki

Aresztowanie w Nigerii osoby podejrzewanej o tworzenie i rozwijanie zestawu phishingowego wymierzonego w Microsoft 365 to ważny sygnał: phishing-as-a-service (PhaaS) dojrzał do poziomu „produktów” sprzedawanych w modelu subskrypcyjnym, z obsługą klienta, automatyzacją kampanii i technikami obchodzenia MFA. W tym przypadku mowa o ekosystemie znanym jako Raccoon0365 / RaccoonO365, wykorzystywanym do przejmowania kont M365 i eskalacji do BEC (Business Email Compromise) oraz naruszeń danych.

W skrócie

  • Nigeryjskie służby zatrzymały trzy osoby w związku z operacją phishingową uderzającą w Microsoft 365; jako kluczowego podejrzanego wskazano Okitipi Samuel (alias m.in. “Moses Felix” / “RaccoonO365”).
  • Według komunikowanych danych, narzędzia RaccoonO365 miały posłużyć do kradzieży co najmniej 5 000 poświadczeń w 94 krajach (od lipca 2024 r.).
  • We wrześniu 2025 r. Microsoft (we współpracy z partnerami) przejął/zablokował 338 domen powiązanych z infrastrukturą RaccoonO365/Raccoon0365.
  • Model biznesowy: sprzedaż przez Telegram, płatności w kryptowalutach, ceny rzędu ~355 USD/30 dni oraz ~999 USD/90 dni.

Kontekst / historia / powiązania

Skąd się wziął RaccoonO365?

Microsoft opisał RaccoonO365 jako szybko rosnący „pakiet” phishingowy sprzedawany subskrypcyjnie i śledzony jako Storm-2246. Kluczowa cecha: zestawy pozwalały tworzyć przekonujące strony logowania i materiały podszywające się pod Microsoft i inne marki, aby wyłudzać dane dostępowe do kont M365.

Takedown infrastruktury (wrzesień 2025)

We wrześniu 2025 r. Microsoft informował o działaniach prawnych i technicznych prowadzących do przejęcia setek domen powiązanych z usługą (Reuters pisał o „prawie 340” witrynach, Microsoft podawał 338).

Aresztowania (doniesienia z grudnia 2025)

Według relacji z działań nigeryjskiego National Cybercrime Centre, przeprowadzono naloty w stanach Lagos i Edo, zatrzymując trzy osoby — z czego dwie miały nie być bezpośrednio powiązane z „rdzeniem” operacji, a Okitipi Samuel został wskazany jako osoba istotna dla rozwoju infrastruktury phishingowej.

Wątek „kto był liderem?”

Warto odnotować rozbieżność: wcześniejsze materiały o RaccoonO365 wskazywały jako domniemanego lidera Joshuy Ogundipe (m.in. w kontekście działań prawnych i przejęć domen), podczas gdy komunikacja o aresztowaniach w Nigerii akcentuje rolę Okitipi Samuel i nie zawsze wymienia Ogundipe. To może oznaczać podział ról (lider/organizator vs. deweloper/operator infrastruktury) albo niepełny obraz ujawniany publicznie na etapie postępowania.

Analiza techniczna / szczegóły ataku

RaccoonO365/Raccoon0365 wpisuje się w nową falę PhaaS, gdzie „klient” (cyberprzestępca) kupuje gotowy zestaw i uruchamia kampanie bez budowania infrastruktury od zera.

Typowy łańcuch ataku

Z opisów ekosystemu wynika następujący schemat:

  1. Wiadomość phishingowa podszywająca się pod dokument biznesowy, fakturę, plik w SharePoint/OneDrive, podpis elektroniczny itp.
  2. Często w treści: załącznik, link lub kod QR, kierujący na stronę pośrednią.
  3. Warstwa „uwiarygodnienia” i filtrów anty-bot: strona z CAPTCHA (w praktyce tego typu kampanie bywały kojarzone z rozwiązaniami Cloudflare).
  4. Finalnie: fałszywa strona logowania Microsoft 365, która wyłudza poświadczenia.

Dlaczego MFA nie zawsze ratuje?

W istotnej części nowoczesnych zestawów PhaaS (w tym opisywanych przy RaccoonO365) pojawia się mechanika adversary-in-the-middle (AiTM): ofiara loguje się „przez” serwer pośredniczący kontrolowany przez atakującego, a napastnik przechwytuje nie tylko hasło, ale też cookie sesyjne po poprawnym uwierzytelnieniu — co praktycznie pozwala ominąć MFA na danej sesji.

Automatyzacja i skala

Microsoft wskazywał, że „klienci” usługi mogli wprowadzać tysiące adresów dziennie jako cele kampanii, a sama usługa była szeroko używana globalnie (94 kraje, co najmniej 5 000 poświadczeń).

Kanały dystrybucji, płatności i „operacje”

Zatrzymany podejrzany miał prowadzić kanał na Telegramie, sprzedając zestawy w kryptowalutach, a strony phishingowe hostować m.in. z wykorzystaniem kont i zasobów powiązanych z Cloudflare (w tym kont zakładanych na dane/poświadczenia pozyskane nielegalnie).
Cennik publikowany w opisach tej operacji to rząd wielkości ~355 USD za 30 dni i ~999 USD za 90 dni (w zależności od „planu”).

Praktyczne konsekwencje / ryzyko

Przejęcie konta Microsoft 365 to często dopiero początek:

  • BEC (Business Email Compromise): zmiana danych do płatności, fałszywe faktury, podszycia pod zarząd/księgowość, przejęcia wątków mailowych.
  • Dalsze phishingi „z wewnątrz” (internal phishing) – maile wysyłane z legalnych skrzynek, trudniejsze do odfiltrowania.
  • Eksfiltracja danych z Exchange/SharePoint/OneDrive, ryzyko naruszenia tajemnic handlowych i danych osobowych.
  • Wektor wejścia do ransomware: w praktyce phishing/AiTM + przejęcie tożsamości bywa etapem inicjalnym łańcucha ataku.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które realnie podnoszą odporność organizacji na kampanie typu RaccoonO365 (zwłaszcza AiTM).

1) Zmień podejście do MFA: „phishing-resistant”

  • Priorytetem są metody odporne na AiTM: FIDO2 / passkeys, ewentualnie certyfikaty. Same kody SMS/TOTP nie rozwiązują problemu przechwytywania sesji.

2) Ogranicz ryzyko przejęcia sesji

  • W Microsoft 365/Azure AD: stosuj Conditional Access (np. wymaganie zgodnego urządzenia, lokalizacji, poziomu ryzyka logowania), oraz skracaj czas życia sesji tam, gdzie to ma sens operacyjny.
  • Monitoruj anomalie: nowe urządzenia, nietypowe lokalizacje, skoki geograficzne, nietypowe user-agent, logowania poza godzinami.

3) Wzmocnij pocztę (warstwa „przed kliknięciem”)

  • DMARC/DKIM/SPF (redukcja podszywania się pod domeny).
  • Blokada lub ostrzeganie przed QR w załącznikach (gdy Twój profil ryzyka to uzasadnia).
  • Wykrywanie kampanii z CAPTCHA + szybkim przekierowaniem na login M365 (częsty wzorzec).

4) Szybka reakcja, jeśli podejrzewasz kompromitację

  • Natychmiast unieważnij sesje (sign-out), wymuś reset hasła, sprawdź reguły przekierowań/forwarding, ukryte inbox rules i delegacje skrzynki.
  • Przejrzyj logi logowań oraz dostęp do plików (SharePoint/OneDrive).
  • Zweryfikuj aplikacje OAuth/zgody (czy nie dodano podejrzanej integracji).

5) Zrób „polowanie” na BEC

  • Szukaj zmian w danych kontrahentów, zmian numerów kont w stopkach i szablonach, podejrzanych reguł w skrzynkach finansów/CEO/księgowości.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

RaccoonO365 jest dobrym przykładem trendu, w którym phishing przestaje być „jednorazową stroną” i staje się usługą przypominającą SaaS:

  • W porównaniu do prostych kitów: tutaj istotna jest automatyzacja i „obsługa” (subskrypcje, kanały dystrybucji, aktualizacje).
  • Podobnie jak inne AiTM-kity: kluczowe ryzyko to przechwycenie cookie sesyjnego i obejście MFA, co wymusza przejście na silniejsze metody uwierzytelniania oraz kontrolę warunkową dostępu.

Podsumowanie / kluczowe wnioski

  • Aresztowania w Nigerii pokazują, że PhaaS dla Microsoft 365 stał się na tyle „produktem”, że jego twórcy/operatorzy zaczynają być namierzani nie tylko przez branżę, ale i przez organy ścigania.
  • Skala (5 000+ poświadczeń, 94 kraje) oraz model subskrypcyjny (Telegram + krypto) potwierdzają, że phishing to dziś systemowy, powtarzalny biznes.
  • Dla obrony kluczowe jest założenie, że „MFA to nie wszystko” — przy AiTM potrzebujesz phishing-resistant MFA + Conditional Access + dobrego monitoringu tożsamości i poczty.

Źródła / bibliografia

  1. BleepingComputer – informacje o aresztowaniach i powiązaniu podejrzanego z Raccoon0365/RaccoonO365. (BleepingComputer)
  2. Microsoft On the Issues – opis RaccoonO365 (Storm-2246), skala, charakterystyka, przejęcie domen. (The Official Microsoft Blog)
  3. Reuters – kontekst prawny i liczby dot. przejęcia domen oraz skali operacji. (Reuters)
  4. The Record (Recorded Future News) – dodatkowe szczegóły nalotów i aresztowań, mechanika kampanii (QR/CAPTCHA), wątek współpracy międzynarodowej. (The Record from Recorded Future)
  5. Help Net Security – opis mechaniki bypassu MFA (AiTM, przechwytywanie cookie) i modelu subskrypcji. (Help Net Security)

USA zamyka krypto-kantor E-Note. Rosjanin oskarżony o pranie pieniędzy z ransomware i ATO

Wprowadzenie do problemu / definicja „luki”

W ekosystemie cyberprzestępczym nie zawsze chodzi o zero-daye i malware. Równie krytycznym „wąskim gardłem” są usługi cash-out: infrastruktura i pośrednicy, którzy pozwalają sprawcom zamienić skradzione lub wymuszone środki na gotówkę (fiat) i „zgubić” ślad transakcyjny.

W praktyce takie podmioty często działają jak quasi-giełdy lub procesory płatności, a ich przewagą jest:

  • brak skutecznego AML/KYC,
  • gotowość do obsługi ryzykownych klientów,
  • wykorzystywanie sieci „money mules” (słupów) i przelewów transgranicznych.

Właśnie w ten obszar uderzyła najnowsza akcja amerykańskich służb przeciwko E-Note.

W skrócie

  • Władze USA ogłosiły przejęcie i wyłączenie infrastruktury E-Note – serwisu opisywanego jako giełda kryptowalut i usługa przetwarzania płatności wykorzystywana do prania pieniędzy.
  • Od 2017 r. FBI zidentyfikowało ponad 70 mln USD nielegalnych środków przerzuconych przez E-Note i powiązaną sieć „money mules”, m.in. z ataków ransomware i przejęć kont (ATO – account takeover).
  • Odsłonięto akt oskarżenia przeciwko Mykhaliowi Petrovichowi Chudnovetsowi (39 lat, obywatel Rosji) – zarzuty obejmują spisek w celu prania pieniędzy (money laundering conspiracy), z maksymalną karą do 20 lat więzienia.
  • Przejęto m.in. domeny: e-note.com, e-note.ws oraz jabb.mn, a także serwery i aplikacje mobilne.

Kontekst / historia / powiązania

Z perspektywy śledczej to typowy schemat ewolucji „usług dla przestępców”:

  1. start jako ręcznie obsługiwane zlecenia z użyciem słupów i pośredników,
  2. przejście w stronę platformy online,
  3. skalowanie – stajesz się „produktem” dla wielu grup.

Według dokumentów sądowych Chudnovets miał oferować usługi prania pieniędzy już od 2010 r., a następnie (około 2017 r.) dostarczać je przez biznes online o nazwie e-note.

Ważny jest też wymiar międzynarodowy: działania były koordynowane z partnerami zagranicznymi (w komunikacie wskazano m.in. współpracę z Niemcami i Finlandią) oraz z Michigan State Police.

Analiza techniczna / szczegóły „luki” (jak działa E-Note jako cash-out)

Z udostępnionych informacji wynika, że E-Note pełnił rolę węzła prania pieniędzy pomiędzy światem krypto a światem fiat:

  • Źródło środków: wpływy powiązane z ransomware oraz przejęciami kont (ATO).
  • Mechanizm transferu: przepływ przez usługę E-Note i powiązaną sieć słupów (money mule network).
  • Cel: transfer transgraniczny i konwersja kryptowalut do różnych walut gotówkowych (fiat).

Co jest tu kluczowe dla obrońców?

  1. To nie „klasyczny mixer” – komunikaty rządowe opisują E-Note szerzej: jako giełdę/procesor płatności + sieć cash-out.
  2. Przejęcie danych historycznych: USA informują, że poza zajęciem serwerów pozyskano także wcześniejsze kopie (obrazy) serwerów obejmujące bazy klientów i rejestry transakcji. To zwiększa ryzyko „wtórnych” konsekwencji dla użytkowników i partnerów operacyjnych przestępców (np. mule, brokerzy, osoby od wypłat).
  3. Infrastruktura domenowa i aplikacje: przejęcie domen (e-note.com, e-note.ws, jabb.mn) oraz aplikacji mobilnych sugeruje, że usługa była projektowana pod wygodę operacyjną, a nie „jednorazowe akcje”.

Co mówi akt oskarżenia (warstwa prawno-techniczna)

W akcie oskarżenia (Eastern District of Michigan) opisano m.in. ramy czasowe działalności (około 2011–2025) oraz to, że usługi obejmowały transfer środków przez granice i konwersję krypto → fiat.

Praktyczne konsekwencje / ryzyko

Dla organizacji (ofiary ransomware/ATO)

  • Jeśli Twoja organizacja była ofiarą ransomware lub dużego ATO, pojawia się realna szansa, że przepływ środków mógł zahaczać o E-Note (zwłaszcza jeśli incydent miał miejsce w latach 2017–2025).
  • Przejęte logi i bazy klientów mogą posłużyć do korelacji transakcji i identyfikacji kolejnych uczestników łańcucha (mule, rekruterzy, brokerzy dostępu).

Dla branży finansowej i krypto

  • Ten typ operacji podnosi presję na monitorowanie ryzykownych przepływów (w tym wypłat do pośredników, ramp fiat, portfeli pośrednich), bo nawet „pozałańcuchowe” elementy (mule) są aktywnie rozpracowywane.
  • Pojawia się też ryzyko „zatrucia” (taint) – środki przechodzące przez ekosystem, który później zostaje zidentyfikowany jako narzędzie prania, mogą powodować eskalację działań compliance po stronie giełd/instytucji.

Dla cyberprzestępców

  • Takedown cash-out zaburza płynność finansową grup ransomware (nie tylko ich malware). To często skuteczniejsze niż pojedyncze aresztowania operatorów technicznych, bo uderza w motywację i zdolność do monetyzacji.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które można wdrożyć bez czekania na dodatkowe szczegóły:

A) Higiena blokad i telemetryka

  • Dodaj do list blokad/detekcji domeny wskazane w komunikacie: e-note.com, e-note.ws, jabb.mn (DNS, proxy, EDR URL telemetry).
  • Sprawdź logi DNS/HTTP(S) pod kątem historycznych połączeń do powyższych domen (szczególnie środowiska, które mogły uczestniczyć w obsłudze incydentów finansowych).

B) Zespoły IR / SOC / Fraud

  • Jeśli prowadzisz dochodzenie w sprawie ransomware/ATO: dodaj hipotezę roboczą „cash-out via E-Note”, bo w komunikacie jest wprost mowa o transferach z tych kategorii incydentów.
  • Ustal wewnętrzny proces eskalacji do działów AML/Fraud (jeśli jesteś fintechiem/bankiem) w przypadku wykrycia powiązań z E-Note lub jego domenami.

C) Kwestie prawne i kontakt z organami

  • DOJ/FBI podaje adres kontaktowy dla osób, które uważają się za ofiary, których środki mogły zostać wyprane przez Chudnovetsa/E-Note: e-note-information@fbi.gov.
  • W praktyce (szczególnie w UE) warto równolegle zabezpieczyć materiał dowodowy (logi, potwierdzenia transakcji, komunikację z napastnikami) i skoordynować zgłoszenia z lokalnymi organami / CERT.

D) Długofalowo: utrudnij „cash-out”

  • Aktualizuj scenariusze threat modeling o etap monetyzacji: ransomware to nie tylko szyfrowanie i eksfiltracja, ale też łańcuch płatność → pranie → wypłata.
  • Jeśli obsługujesz płatności/krypto: wzmocnij reguły wykrywania schematów „money mule” (częste małe wpływy, szybkie wypłaty, duża rotacja rachunków, nietypowe geolokalizacje).

Różnice / porównania z innymi przypadkami

Akcja przeciwko E-Note wpisuje się w trend operacji „financial disruption”, podobnych do wcześniejszych działań wymierzonych w infrastrukturę giełd wykorzystywanych do prania.

Dla porównania: w operacji przeciwko rosyjsko-powiązanej giełdzie Garantex DOJ opisywał przejęcia domen i serwerów, uzyskanie kopii baz danych oraz współpracę międzynarodową – czyli schemat bardzo zbliżony do E-Note, tylko na inną skalę (w komunikacie o Garantex pojawia się m.in. informacja o ogromnym wolumenie transakcji oraz o zarzutach wobec administratorów).

Wniosek praktyczny: organy ścigania coraz częściej uderzają w infrastrukturę i dane (domeny, serwery, bazy klientów), a nie wyłącznie w „ludzi od malware”.

Podsumowanie / kluczowe wnioski

  • E-Note został rozpracowany jako element łańcucha monetyzacji cyberprzestępczości: ransomware + ATO → pranie → konwersja do fiat.
  • Skala wskazywana przez FBI (>70 mln USD od 2017 r.) pokazuje, że „cash-out” to nie margines, tylko krytyczny komponent ekosystemu.
  • Przejęte bazy klientów i rejestry transakcji mogą uruchomić falę dalszych identyfikacji i postępowań – to ryzyko zarówno dla przestępców, jak i dla podmiotów, które (świadomie lub nie) uczestniczyły w łańcuchu wypłat.
  • Dla obrońców najrozsądniejszy ruch „tu i teraz” to: dodać domeny do blokad, sprawdzić telemetrię historyczną i dopiąć współpracę SOC ↔ Fraud/AML.

Źródła / bibliografia

  1. Komunikat U.S. Attorney’s Office, Eastern District of Michigan: „FBI disrupts virtual money laundering service…” (Department of Justice)
  2. Akt oskarżenia (PDF) w sprawie Mykhalio Petrovich Chudnovets, Eastern District of Michigan (18 U.S.C. § 1956(h))
  3. SecurityWeek: „US Shuts Down Crypto Exchange E-Note, Charges Russian Administrator” (SecurityWeek)
  4. CyberScoop: „DOJ announces takedown of alleged laundering platform…” (CyberScoop)
  5. DOJ OPA (archiwalny komunikat porównawczy): „Garantex Cryptocurrency Exchange Disrupted in International Operation” (Department of Justice)