Archiwa: Security News - Strona 230 z 297 - Security Bez Tabu

Kategoria: Security News

WatchGuard ostrzega przed aktywnie wykorzystywaną luką RCE w Firebox (CVE-2025-14733)

Wprowadzenie do problemu / definicja luki

WatchGuard opublikował ostrzeżenie dotyczące krytycznej podatności umożliwiającej zdalne wykonanie kodu (RCE) w zaporach Firebox. Luka została oznaczona jako CVE-2025-14733 i dotyczy komponentu iked w systemie Fireware OS (obsługa negocjacji IKE/IPsec, w szczególności IKEv2). Co ważne: producent potwierdził próby aktywnej eksploatacji „w naturze” (in the wild).

Z perspektywy obrony sieciowej to „klasa” podatności, której nie można traktować jak typowego błędu aplikacyjnego: przejęcie firewalla/VPN gatewaya często oznacza przejęcie „najbardziej uprzywilejowanego” punktu w infrastrukturze.

W skrócie

  • CVE: CVE-2025-14733
  • Typ: Out-of-bounds write → potencjalne RCE bez uwierzytelniania (pre-auth) w procesie iked
  • Warunki narażenia: konfiguracje Mobile User VPN (IKEv2) oraz Branch Office VPN (IKEv2) z dynamic gateway peer; dodatkowo podatność może się utrzymywać nawet po usunięciu konfiguracji (patrz sekcja techniczna).
  • Skala: dotyczy wielu gałęzi Fireware (11.x, 12.x, 2025.1) i szerokiej gamy modeli Firebox (w tym wirtualnych/chmurowych)
  • Ocena: WatchGuard podaje CVSS 9.3 (CVSS v4), a NVD prezentuje także CVSS 3.1 = 9.8.
  • Fix: aktualizacja do wersji naprawionych (m.in. 2025.1.4, 12.11.6, 12.5.15, 12.3.1 Update 4) – szczegóły niżej.
  • Sygnały ataku (przykłady): nietypowe logi IKE_AUTH/certyfikatów oraz zawieszenia/crashe procesu iked; WatchGuard opublikował też IP powiązane z aktywnością atakujących.
  • KEV: CISA poinformowała o dodaniu CVE-2025-14733 do katalogu Known Exploited Vulnerabilities (KEV).

Kontekst / historia / powiązania

Wątek „RCE w IKE/IKEv2 na bramach VPN” wraca cyklicznie w branży – jest to atrakcyjny wektor, bo usługa VPN bywa wystawiana do internetu i obsługuje złożone formaty danych (negocjacje, certyfikaty, payloady). W przypadku WatchGuard warto zauważyć, że firma wcześniej łatała bardzo podobny problem RCE w Firebox (CVE-2025-9242), a później obserwowano dużą liczbę urządzeń pozostających podatnych.

Dla obrony oznacza to jedno: nawet jeśli Twoja organizacja „zwykle patchuje”, urządzenia brzegowe trzeba traktować jako absolutny priorytet (bo okno pomiędzy publikacją poprawek a masową eksploatacją bywa krótkie).

Analiza techniczna / szczegóły luki

Co dokładnie jest podatne?

Podatność jest opisana jako out-of-bounds write w procesie iked w WatchGuard Fireware OS. Taki błąd to w praktyce korupcja pamięci, która w sprzyjających warunkach może prowadzić do wykonania kodu (RCE).

Jakie konfiguracje są krytyczne?

WatchGuard wskazuje, że problem dotyczy:

  • Mobile User VPN z IKEv2, oraz
  • Branch Office VPN z IKEv2 skonfigurowanych z dynamic gateway peer.

Istotny „haczyk”: jeśli Firebox wcześniej miał skonfigurowany Mobile User VPN IKEv2 lub BOVPN IKEv2 do dynamicznego peera, a potem te wpisy usunięto, urządzenie wciąż może pozostać podatne, jeżeli nadal skonfigurowany jest BOVPN do static gateway peer. To sugeruje, że sama „czystość” konfiguracji w GUI nie zawsze domyka powierzchnię ataku (np. pozostają aktywne ścieżki kodu/usługi).

Wersje podatne i wersje naprawione

Zgodnie z opisem producenta oraz wpisem w NVD, podatne są m.in. zakresy:

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

Wersje naprawione (wg tabeli „Resolution” WatchGuard):

  • 2025.1 → 2025.1.4
  • 12.x → 12.11.6
  • 12.5.x (modele T15 i T35) → 12.5.15
  • 12.3.1 (FIPS) → 12.3.1_Update4 (B728352)
  • 11.x → End of Life (czyli bez dalszych poprawek).

IOC/IoA – jak wygląda telemetria ataków?

WatchGuard opublikował „Indicators of Attack”, które są szczególnie przydatne operacyjnie, bo pozwalają szybciej triagować incydent:

Adresy IP powiązane z aktywnością atakujących – WatchGuard podkreśla, że połączenia wychodzące do tych IP są mocnym wskaźnikiem kompromitacji, a przychodzące mogą sugerować rekonesans/eksploatację:

  • 45.95.19[.]50
  • 51.15.17[.]89
  • 172.93.107[.]67
  • 199.247.7[.]82

Przykładowe logi IKE (IoA):

  • komunikat o zbyt długim łańcuchu certyfikatów („…longer than 8…”) przy IKE2 Auth payload z >8 certyfikatami, oraz
  • log IKE_AUTH z nienaturalnie dużym CERT payload (wskazany próg >2000 bajtów).

Zachowanie urządzenia (telemetria):

  • podczas udanej eksploatacji proces iked może się zawieszać (zrywanie negocjacji/rekey),
  • po próbie udanej lub nieudanej proces iked może crashować i generować fault report.

Praktyczne konsekwencje / ryzyko

Jeśli atakujący uzyska możliwość zdalnego wykonania kodu na firewallu/VPN gatewayu, konsekwencje zwykle wykraczają poza „jeden serwer mniej”:

  • przejęcie punktu styku z internetem (brzeg infrastruktury),
  • pivot do sieci wewnętrznej i segmentów „za firewallem”,
  • potencjalna manipulacja regułami, trasowaniem, a nawet obserwacja/zakłócanie tuneli VPN,
  • ryzyko kradzieży danych uwierzytelniających przechowywanych lokalnie oraz eskalacji do domeny/SSO (zależnie od integracji). (To są typowe scenariusze dla kompromitacji bram VPN; konkretne kroki zależą od tego, co napastnik zrobi po uzyskaniu kontroli).

NHS England ocenia dalszą eksploatację jako prawdopodobną i rekomenduje pilne zastosowanie poprawek zgodnie z advisory producenta.

Rekomendacje operacyjne / co zrobić teraz

Poniżej checklista „co robić dziś”, ułożona pod realia SOC/infra.

1) Patch (priorytet #1)

  • Zidentyfikuj wersje Fireware w całej flocie (również instancje wirtualne/chmurowe).
  • Aktualizuj do wersji naprawionych: 2025.1.4 / 12.11.6 / 12.5.15 / 12.3.1_Update4 (zgodnie z gałęzią).
  • Jeśli masz 11.x – to EOL. Tu „patch” może oznaczać migrację/upgrade sprzętu/wersji, bo poprawki nie będą dostępne.

2) Ogranicz ekspozycję IKEv2 (jeśli musisz chwilę poczekać z patchem)

Jeśli z powodów operacyjnych patchowanie wymaga okna serwisowego:

  • ogranicz dostęp do usług VPN/IKEv2 tylko do zaufanych adresów/peerów (polityki/ACL, geofencing jeśli pasuje do profilu ryzyka),
  • przejrzyj konfiguracje dynamic gateway peer i usuń/wyłącz nieużywane,
  • rozważ czasowe wyłączenie najbardziej ryzykownych ścieżek (zależnie od tego, jak masz zestawione BOVPN).

WatchGuard opisuje też tymczasowe działania dla środowisk z BOVPN, gdy nie da się natychmiast zaktualizować (m.in. wyłączenie dynamic peer BOVPN i korekta polityk).

3) Hunting/IR: sprawdź IoA/IOC

  • Przeskanuj logi pod kątem komunikatów o „peer certificate chain > 8” oraz IKE_AUTH z dużym CERT payload.
  • Sprawdź firewall/flow/EDR/NDR pod kątem połączeń wychodzących do wskazanych IP (to ma być „mocny” sygnał kompromitacji).
  • Zwróć uwagę na nietypowe crashe/zawieszenia iked (zrywanie renegocjacji, rekey, fault reports).

4) Rotacja sekretów po wykryciu śladów aktywności

Jeśli potwierdzisz podejrzaną aktywność/kompromitację, producent rekomenduje rotację lokalnie przechowywanych sekretów na podatnych urządzeniach (PSK, hasła, klucze/certy – zależnie od użycia).

5) Priorytetyzacja ryzyka

CISA sygnalizuje, że CVE-2025-14733 trafiło do katalogu KEV, co w praktyce oznacza: „to nie jest teoretyczne, to jest wykorzystywane”. W wielu organizacjach to automatycznie powinno podbić priorytet w procesie zarządzania podatnościami.

Różnice / porównania z innymi przypadkami

Najbliższym punktem odniesienia jest wspomniana wcześniej podatność CVE-2025-9242 – również dotycząca Firebox/Fireware i również opisywana jako bliska „rodzina” problemów RCE w okolicach IKE/iked. BleepingComputer zwraca uwagę, że obecna luka pojawia się niedługo po tamtym incydencie i że historycznie liczba niezałatanych urządzeń bywała wysoka.

Wniosek praktyczny: jeśli w Twojej organizacji Firebox jest traktowany jako „appliance, którego nie ruszamy”, to jest dokładnie ten moment, by zmienić podejście (SLA na łatki dla edge).

Podsumowanie / kluczowe wnioski

  • CVE-2025-14733 to krytyczna, aktywnie wykorzystywana podatność typu out-of-bounds write w iked (IKEv2) w WatchGuard Fireware OS, umożliwiająca pre-auth RCE.
  • Ryzyko dotyczy szerokiego spektrum wersji i urządzeń; szczególnie problematyczne są środowiska na 11.x (EOL).
  • WatchGuard udostępnił konkretne IoA (logi, zachowanie procesu, IP), które warto natychmiast wykorzystać w SOC.
  • Najszybsza i najpewniejsza droga redukcji ryzyka to aktualizacja do wersji naprawionych i ograniczenie ekspozycji IKEv2 tam, gdzie to możliwe.

Źródła / bibliografia

  1. WatchGuard PSIRT – WGSA-2025-00027 (CVE-2025-14733, wersje podatne/naprawione, IoA/IOC). (WatchGuard)
  2. BleepingComputer – informacja o aktywnej eksploatacji, kontekst (m.in. CVE-2025-9242) i działania tymczasowe. (BleepingComputer)
  3. NVD (NIST) – wpis CVE (opis, zakres wersji, metryki, daty publikacji). (nvd.nist.gov)
  4. NHS England Digital – alert o eksploatacji i zalecenia remediacji. (NHS England Digital)
  5. CISA Cyber (X) – komunikat o dodaniu CVE-2025-14733 do KEV. (X (formerly Twitter))

Microsoft 365 na celowniku: fala phishingu OAuth z wykorzystaniem „device code”

Wprowadzenie do problemu / definicja luki

Na przełomie końcówki 2025 roku obserwujemy wyraźny wzrost kampanii wymierzonych w konta Microsoft 365, w których atakujący nie muszą kraść hasła ani „łamać” MFA. Zamiast tego wykorzystują legalny mechanizm OAuth 2.0 Device Authorization Grant (tzw. device code flow), aby skłonić ofiarę do wprowadzenia kodu na prawdziwej stronie logowania urządzeń Microsoftu i… samodzielnego przyznania dostępu aplikacji kontrolowanej przez napastnika.

W praktyce jest to odmiana „phishingu zgody” (consent phishing) / phishingu tokenów, gdzie celem nie jest hasło, tylko tokeny dostępu (access tokens) i często także tokeny odświeżania (refresh tokens), które zapewniają trwały dostęp do zasobów M365 zgodnie z nadanymi uprawnieniami.

W skrócie

  • Ataki nadużywają mechanizmu OAuth device code: ofiara wpisuje kod na legalnym portalu logowania urządzeń Microsoftu, a napastnik przejmuje wynikowe tokeny.
  • Skala kampanii ma rosnąć istotnie od września 2025, a w działaniach biorą udział zarówno grupy finansowe, jak i powiązane państwowo.
  • W ekosystemie pojawiają się gotowe narzędzia/kity upraszczające atak (m.in. SquarePhish i Graphish).
  • Obrona to głównie: blokada/ograniczenie device code flow, twardsze polityki zgód na aplikacje (app consent), oraz monitoring zdarzeń Entra ID / Enterprise Apps.

Kontekst / historia / powiązania

„Consent phishing” nie jest nowym zjawiskiem: to naturalna konsekwencja przeniesienia tożsamości i aplikacji do chmury, gdzie użytkownik może (świadomie lub nie) nadać aplikacji uprawnienia do poczty, plików czy profilu. Microsoft wprost opisuje ten wektor jako atak polegający na nakłonieniu użytkownika do przyznania uprawnień złośliwej aplikacji, po czym aplikacja uzyskuje dostęp do danych w usługach cloud.

Nowością w bieżącej fali jest nacisk na device code phishing w większej skali: Proofpoint wskazuje, że obserwuje wiele klastrów używających tego schematu do przejęć kont M365, co przekłada się na przejęcia sesji i eksfiltrację danych.
BleepingComputer opisuje jednocześnie, że wysoki wolumen takich kampanii jest „nietypowy”, a wzrost ma trwać od września 2025.

Analiza techniczna / szczegóły luki

1) Co to jest OAuth 2.0 device authorization grant?

Device code flow powstał z myślą o urządzeniach z ograniczonym interfejsem (np. TV, urządzenia IoT, terminale), gdzie logowanie „w urządzeniu” jest niewygodne. Użytkownik dostaje krótki kod, wchodzi na stronę logowania urządzeń i po zalogowaniu potwierdza powiązanie sesji z danym kodem.

2) Jak wygląda atak krok po kroku

Typowy łańcuch (z wariantami zależnie od kampanii) wygląda następująco:

  1. Wiadomość phishingowa (często z presją czasu): „ponowna autoryzacja tokenu”, „kod jednorazowy”, „powiadomienie kadrowe” itp.
  2. Ofiara dostaje instrukcję, by przejść na legalny portal device login Microsoftu (np. microsoft.com/devicelogin) i wkleić kod.
  3. Użytkownik loguje się prawidłowo (często także przechodzi MFA), ale w efekcie autoryzuje dostęp dla aplikacji/„urządzenia” kontrolowanego przez atakującego.
  4. Napastnik odbiera z procesu autoryzacji wynik (tokeny) i uzyskuje dostęp do zasobów M365 w granicach przyznanych scope’ów.

Kluczowy detal: to nie jest „bypass MFA” w sensie technicznym — MFA działa, ale zostaje użyte przeciwko użytkownikowi, bo to ofiara sama zatwierdza logowanie/autoryzację na legalnej stronie.

3) Narzędzia upraszczające phishing

W opisach kampanii pojawiają się m.in.:

  • SquarePhish v1/v2 – publicznie dostępne narzędzie red-teamowe celujące w device grant flow (m.in. przez QR), imitujące „legitne” scenariusze MFA/TOTP.
  • Graphish – kit phishingowy dystrybuowany w podziemiu, wspierający nadużycia OAuth, Azure App Registrations oraz techniki typu adversary-in-the-middle (AiTM).

To ważne operacyjnie: obniżenie bariery wejścia oznacza, że tę technikę mogą replikować nie tylko zaawansowane grupy.

Praktyczne konsekwencje / ryzyko

Skuteczne przejęcie w tym modelu zwykle prowadzi do klasycznych scenariuszy po przejęciu tożsamości w chmurze:

  • Account takeover w M365 (poczta, SharePoint/OneDrive, Teams – zależnie od scope’ów),
  • eksfiltracja danych i dostęp do korespondencji,
  • możliwość przygotowania kolejnych etapów (np. reguły skrzynki, utrzymanie dostępu),
  • ryzyka BEC i nadużyć procesów biznesowych, jeśli przejęte konto ma uprawnienia i relacje z partnerami.

Warto też zauważyć zmianę trendu: zamiast „kraść hasło”, atakujący coraz częściej nadużywają nowoczesnych przepływów uwierzytelniania i autoryzacji. To komplikuje detekcję, bo część zdarzeń wygląda jak „zwykłe logowanie użytkownika”.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które realnie ograniczają ten wektor (od najsilniejszych kontroli):

1) Zablokuj device code flow tam, gdzie to możliwe

Microsoft wprost zaleca blokowanie device code flow, a jeśli jest wymagany — objęcie go politykami Conditional Access.

Praktyka: w wielu organizacjach device code flow nie jest potrzebny większości użytkowników. Jeśli nie masz jasnych use-case’ów — wyłącz.

2) Jeśli nie możesz zablokować — podejście allow-list w Conditional Access

Help Net Security (na bazie zaleceń Proofpoint) opisuje podejście „allow-list”: włączaj device code tylko dla zatwierdzonych użytkowników / systemów / zakresów IP (Named locations).

Dodatkowo, jeśli używasz Intune lub rejestracji urządzeń, wymagaj aby logowania do M365 pochodziły z urządzeń zgodnych/compliant lub zarejestrowanych.

3) Utwardź polityki zgód na aplikacje (consent)

W „consent phishing” fundamentem obrony jest ograniczenie, kto i na jakie aplikacje może wyrażać zgodę:

  • wymuś, by użytkownicy mogli wyrażać zgodę tylko na aplikacje o niskim ryzyku / zweryfikowanych wydawcach lub zarejestrowane w Twoim tenancie,
  • wdroż app consent policies i governance wokół Enterprise Apps.

Microsoft opisuje też, że aplikacje oznaczane jako podejrzane mogą zostać zablokowane przez Microsoft Entra ID, ale organizacja nadal powinna prowadzić własną kontrolę i higienę zgód.

4) Monitoring i reakcja: co logować i co sprawdzać

Minimum operacyjne (blue team / SOC):

  • alerty na nietypowe zgody (consent grants) i nowe/nieznane aplikacje w Enterprise Apps,
  • korelacja: zgoda na aplikację → nietypowe logowanie → działania w Graph/Exchange,
  • szybka ścieżka IR: unieważnienie sesji/tokenów, wycofanie zgód aplikacji, przegląd reguł skrzynki i delegacji.

(Źródła opisują mechanikę tokenów i ryzyko trwałego dostępu, co uzasadnia powyższą procedurę).

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

Klasyczny phishing haseł

  • Cel: hasło (czasem + kod MFA).
  • Obrona: MFA, FIDO2, filtrowanie URL, DMARC itp.

AiTM / reverse proxy

  • Cel: przechwycenie sesji i tokenów w trakcie logowania (MFA często „przechodzi” przez proxy).
  • Obrona: phishing-resistant MFA, CA, detekcje anomalii, blokady „token replay”.

Device code phishing / consent phishing (ten przypadek)

  • Cel: użytkownik sam autoryzuje dostęp (tokeny powstają „legalnie”), bez kradzieży hasła.
  • Obrona: przede wszystkim blokada/ograniczenie device code flow oraz twardsze zasady zgód na aplikacje.

Najważniejsza różnica: w device code phishing duża część sygnałów jest „poprawna” z perspektywy dostawcy tożsamości (realny login, realna strona) — dlatego governance i CA są krytyczne.

Podsumowanie / kluczowe wnioski

Fala ataków na Microsoft 365 z użyciem OAuth device code pokazuje, że napastnicy coraz częściej omijają „wojnę na hasła” i przenoszą ciężar na nadużycie legalnych mechanizmów autoryzacji. W tej technice MFA nie musi zostać złamane — wystarczy, że użytkownik da się poprowadzić do wykonania „właściwych kroków” na prawdziwej stronie Microsoftu.

Jeśli chcesz szybko obniżyć ryzyko: zacznij od wyłączenia device code flow (albo bardzo ciasnego allow-list w Conditional Access), a następnie domknij temat politykami zgód na aplikacje i monitoringiem consent grants.

Źródła / bibliografia

  1. BleepingComputer – opis fali ataków, narzędzi (SquarePhish/Graphish) i wzrostu od września 2025. (BleepingComputer)
  2. Proofpoint – „Access granted: phishing with device code authorization for account takeover” (klastry, mechanika, skutki). (Proofpoint)
  3. Microsoft Security Blog – „Defending against evolving identity attack techniques” (device code phishing, zalecenia blokady, consent phishing). (Microsoft)
  4. Microsoft Learn (Entra ID) – „Protect against consent phishing” (definicja, mechanizmy, best practices). (Microsoft Learn)
  5. Help Net Security – podsumowanie trendu i wskazówki CA/allow-list dla device code. (Help Net Security)

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)

Kimwolf: gigantyczny botnet na Androida przejmuje 1,8 mln urządzeń i „twardnieje” dzięki ENS oraz DNS-over-TLS

Wprowadzenie do problemu / definicja „luki”

Kimwolf to nowo ujawniona, masowa sieć botnet działająca na urządzeniach z Androidem (w praktyce głównie tanie TV boxy / set-top boxy i Smart TV), wykorzystywana do ataków DDoS oraz – co ważne – do funkcji typowych dla zdalnego dostępu: proxy/forwarding ruchu, reverse shell i zarządzanie plikami.

To nie jest pojedyncza „luka” w sensie CVE, tylko kampania infekcji i utrzymywania kontroli nad urządzeniami, gdzie problemem systemowym są: słabe aktualizacje firmware’u, podatny ekosystem tanich urządzeń, a także rosnąca „odporność infrastruktury” operatorów botnetu.

W skrócie

  • Skala: badacze szacują, że Kimwolf kontroluje >1,8 mln urządzeń, rozproszonych globalnie (ponad 220 krajów/regionów).
  • DDoS: zaobserwowano ~1,7 mld komend DDoS wydanych w krótkim oknie czasowym (19–22 listopada 2025).
  • Ewazja i odporność: komunikacja obejmuje m.in. DNS-over-TLS (DoT) oraz mechanizm weryfikacji poleceń (podpisy cyfrowe); po takedownach C2 botnet przeszedł na ENS (Ethereum Name Service), żeby utrudnić wyłączanie infrastruktury.
  • Powiązania: istnieją mocne przesłanki łączące Kimwolf z ekosystemem botnetu Aisuru (znanego m.in. z rekordowych wolumenów DDoS).

Kontekst / historia / powiązania

O Kimwolf zrobiło się głośno m.in. dlatego, że jeden z domenowych adresów C2 (bardzo długi, w strefie .su) miał według analiz „wystrzelić” w rankingach popularności domen (Cloudflare Domain Rankings), co było skorelowane z masową aktywnością botnetu.

XLab (QiAnXin) wskazuje, że Kimwolf jest powiązany z Aisuru – botnetem klasy „TurboMirai”, który w raportach Cloudflare przewija się jako źródło hiperwolumetrycznych ataków (włącznie z rekordami rzędu 29,7 Tbps i 14,1 mld pakietów/s).

W praktyce oznacza to możliwy scenariusz: ci sami operatorzy (lub ściśle powiązana grupa) rozwijają równoległe „armie” – i mogą je łączyć w kampaniach, w zależności od celu i presji obronnej (takedowny, detekcje).

Analiza techniczna / szczegóły działania

Poniżej najważniejsze elementy techniczne, które wyróżniają Kimwolf na tle wielu „typowych” botnetów IoT/Android:

1) Zakres funkcji: nie tylko DDoS

Kimwolf ma klasyczne możliwości botnetu DDoS, ale równolegle oferuje:

  • proxy forwarding (pośredniczenie w ruchu, potencjalnie do nadużyć i „ukrywania” źródła),
  • reverse shell (zdalna powłoka),
  • zarządzanie plikami.

To ważne, bo w takim układzie botnet może być używany nie tylko do „głośnych” ataków, ale też do cichych operacji (np. jako infrastruktura pośrednicząca).

2) Łańcuch komunikacji i utrudnianie detekcji: DoT + kryptografia

Badacze opisują użycie:

  • DNS-over-TLS (DoT) do „opakowania” zapytań DNS i utrudniania tradycyjnej inspekcji/detekcji,
  • mechanizmu weryfikacji poleceń podpisem cyfrowym (na krzywych eliptycznych), gdzie bot ma wykonywać tylko poprawnie podpisane instrukcje,
  • dodatkowo prostej warstwy szyfrowania/ukrywania danych wrażliwych (operacje XOR stosu).

Wniosek praktyczny: samo „przejęcie” kanału C2 lub podszywanie się pod operatora może być trudniejsze niż w prostych klonach Mirai, bo boty nie muszą ufać „każdemu” serwerowi.

3) Odporność infrastruktury: przejście na ENS po takedownach

XLab wskazuje, że domeny C2 były zdejmowane co najmniej kilka razy, a operatorzy reagowali „utwardzaniem” infrastruktury i przejściem na ENS (Ethereum Name Service), co jest przykładem trendu „blockchain-based naming / EtherHiding” jako odpowiedzi na klasyczne takedowny DNS.

4) Skala i geografia

XLab szacuje >1,8 mln zainfekowanych urządzeń i podaje rozkład w 222 krajach/regionach, z wysokimi udziałami m.in. w Brazylii, Indiach i USA.
Za typowe ofiary wskazywane są urządzenia klasy TV BOX / set-top box / Smart TV (często w sieciach domowych).

Praktyczne konsekwencje / ryzyko

Dla organizacji (i dostawców usług) Kimwolf to ryzyko w kilku warstwach:

  1. DDoS o bardzo dużej skali
    Jeśli XLab ma rację, potencjał Kimwolf może zbliżać się do „poziomu” największych botnetów obserwowanych w telemetrii Cloudflare.
  2. „Residential proxy” jako usługa (ciche nadużycia)
    Możliwości proxy + duża baza urządzeń domowych to idealny przepis na:
  • maskowanie źródeł ataków,
  • omijanie geoblokad,
  • automatyzację nadużyć (fraud, scraping, credential stuffing) z „wiarygodnych” IP użytkowników końcowych.
  1. Trudniejsza detekcja na poziomie DNS
    DoT oraz bardziej „dojrzałe” mechanizmy uwierzytelniania poleceń utrudniają szybkie odcięcie i proste reguły oparte o DNS.

Rekomendacje operacyjne / co zrobić teraz

Poniżej podejście „praktyczne”, bez wchodzenia w vendor-specific playbooki.

Dla zespołów SOC / sieci w firmach (szczególnie ISP, telco, hosting, e-commerce)

  • Inwentaryzuj i ogranicz IoT/Android TV w sieci: jeśli nie jest krytyczne biznesowo, trzymaj takie urządzenia poza siecią produkcyjną (osobny VLAN, brak routingu do zasobów).
  • Polityka DNS:
    • monitoruj/alertuj nietypowe wzorce DoT (TCP/853) oraz nagłe „skoki” w liczbie połączeń do resolverów/endpointów,
    • rozważ egzekwowanie DNS do firmowych resolverów (tam, gdzie to możliwe), zamiast pozwalania na „dowolny DoT na zewnątrz”. (Uwaga: DoT bywa legalny – chodzi o kontrolę i widoczność, nie ślepe blokowanie).
  • Telemetria egress: profiluj urządzenia, które generują nienaturalny ruch wychodzący (zwłaszcza UDP), albo zachowują się jak proxy.
  • Przygotuj runbook pod hiperwolumetryczne DDoS: ćwiczenia z CDN/WAF/DDoS scrubbingiem; Cloudflare raportuje, że skala takich ataków rośnie i może mieć efekt „kolateralny” na operatorów/ISP nawet gdy nie są celem.

Dla użytkowników domowych / małych firm

  • Wymuś aktualizacje (jeśli producent w ogóle je dostarcza) i unikaj urządzeń bez jasnego wsparcia.
  • Nie instaluj „podejrzanych” APK i ogranicz sideloading.
  • Jeśli TV box zachowuje się nietypowo (lagi, przegrzewanie, wysycenie łącza): reset do ustawień fabrycznych + aktualizacja; a w razie braku wsparcia – wymiana urządzenia.

Różnice / porównania z innymi przypadkami

  • Mirai i pochodne zwykle bazują na prostych mechanizmach C2 i masowym skanowaniu/eksploitacji IoT; Kimwolf wyróżnia się naciskiem na proxy oraz „twardszą” warstwę komunikacji (DoT, podpisy poleceń).
  • Aisuru jest w raportach Cloudflare symbolem hiperwolumetrycznego DDoS i botnet-for-hire; powiązania Kimwolf↔Aisuru sugerują, że operatorzy mogą prowadzić ekosystem botnetów, a nie jeden monolit.
  • Odporność na takedowny przez ENS to element „nowej generacji” infrastruktury botnetów – domeny w klasycznym DNS da się gasić szybciej niż nazwy rozwiązywane przez mechanizmy powiązane z blockchainem.

Podsumowanie / kluczowe wnioski

Kimwolf to sygnał, że botnety na Android TV/TV boxach przestały być „tylko” źródłem taniego DDoS. Skala >1,8 mln urządzeń, funkcje proxy/reverse shell, użycie DoT, kryptograficznej walidacji poleceń i przejście na ENS po takedownach pokazują botnet projektowany pod długie życie i odporność.

Jeżeli Twoja organizacja jest zależna od dostępności usług (ISP/telco, e-commerce, gaming, finanse, infrastruktura), traktuj to jako argument za: lepszą kontrolą egress/DNS, segmentacją IoT oraz gotowością na hiperwolumetryczne kampanie DDoS, których skala w telemetrii dostawców ochrony realnie rośnie.

Źródła / bibliografia

  1. SecurityWeek – „Kimwolf Android Botnet Ensnares 1.8 Million Devices” (19 grudnia 2025) (SecurityWeek)
  2. QiAnXin XLab – „Kimwolf Exposed: The Massive Android Botnet with 1.8 Million Infected Devices” (17 grudnia 2025) (blog.xlab.qianxin.com)
  3. Cloudflare – „2025 Q3 DDoS threat report” (3 grudnia 2025) (The Cloudflare Blog)
  4. Cloudflare – „Aisuru botnet: Early October attacks escalate into record-setting DDoS activity” (grudzień 2025) (Cloudflare)

Dania oficjalnie obwinia Rosję o cyberataki na infrastrukturę krytyczną i serwisy wyborcze: co wiemy i jak się przygotować

Wprowadzenie do problemu / definicja luki

Dania po raz pierwszy publicznie przypisała Rosji konkretne, „destrukcyjne i zakłócające” cyberataki: jeden wymierzony w infrastrukturę wodociągową, drugi – w serwisy internetowe związane z wyborami samorządowymi i regionalnymi. To ważny sygnał dla całej Europy: operacje w cyberprzestrzeni coraz częściej mają charakter hybrydowy (łączą presję polityczną, dezinformację, incydenty sabotażowe i cyberataki), a celami są nie tylko „duże” instytucje państwowe, ale też lokalne podmioty odpowiedzialne za ciągłość usług publicznych.

W skrócie

  • Duński wywiad wojskowy (FE/DDIS) ocenia, że pro-rosyjskie grupy Z-Pentest oraz NoName057(16) mają powiązania z państwem rosyjskim.
  • Atak na wodociągi (2024) miał charakter destrukcyjny: według doniesień doprowadził do problemów z dostawą wody (m.in. pęknięcia rur i czasowe braki u ok. 500 gospodarstw).
  • Osobno odnotowano DDoS przeciw duńskim serwisom w okresie poprzedzającym wybory samorządowe i regionalne (2025), przypisywany NoName057(16).
  • Władze traktują incydenty jako element rosyjskiej strategii destabilizacji państw wspierających Ukrainę.

Kontekst / historia / powiązania

Publiczne przypisanie odpowiedzialności (atrybucja) ma znaczenie operacyjne i polityczne. Z perspektywy bezpieczeństwa to „zamknięcie pętli”: państwo nie tylko obsługuje incydent, ale wskazuje sprawcę, opisuje modus operandi i stawia to w kontekście szerszej kampanii.

FE/DDIS wskazał, że:

  • Z-Pentest stał za destrukcyjnym atakiem na duński obiekt wodociągowy (2024),
  • a NoName057(16) za przeciążeniowymi atakami DDoS na duńskie witryny w okresie przedwyborczym (2025).

Na poziomie strategicznym Dania wpisuje te zdarzenia w rosyjną „wojnę hybrydową” przeciw państwom Zachodu.

Analiza techniczna / szczegóły luki

Atak na wodociągi: dlaczego to jest „destrukcyjne”

Incydent w sektorze wodnym jest szczególnie niebezpieczny, bo dotyka OT/ICS (systemów sterowania przemysłowego). Według relacji medialnych atak na obiekt wodociągowy w rejonie Kopenhagi doprowadził do anomalii pracy infrastruktury (m.in. wzrostu ciśnienia / uszkodzeń), co przełożyło się na awarie i przerwy w dostawach.

To typowy scenariusz, w którym:

  • atakujący szuka dostępu do paneli/sterowników,
  • zmienia parametry procesu (np. ciśnienie, tryby pracy pomp),
  • wywołuje awarię fizyczną lub kontrolowany chaos eksploatacyjny.

Nawet jeśli skala była ograniczona, „progiem sukcesu” jest tu pokazanie możliwości: że da się naruszyć ciągłość usługi publicznej.

DDoS przed wyborami: atak prosty, ale skuteczny w przekazie

Druga część historii dotyczy przeciążeniowych ataków DDoS na serwisy internetowe w okolicach wyborów samorządowych i regionalnych (2025). DDoS zwykle nie oznacza włamania ani kradzieży danych – jego celem jest czasowa niedostępność usług (przeciążenie ruchem). Ale politycznie i społecznie potrafi być bardzo dotkliwy: w dniu głosowania lub tuż przed nim uderza w informację, komunikację i zaufanie.

Atrybucja do Rosji: co faktycznie oznacza

Warto odróżnić trzy poziomy:

  1. „grupa pro-rosyjska” (deklaracje, narracja, cele),
  2. „powiązania z państwem” (wsparcie, koordynacja, zadania, zasoby),
  3. „operacja państwowa” (pełne sterowanie).

FE/DDIS publicznie ocenił powiązania obu grup z państwem rosyjskim – to mocny komunikat, ale nadal „ocena wywiadowcza”, nie ujawnienie całego materiału dowodowego (co jest standardem w takich sprawach).

Praktyczne konsekwencje / ryzyko

Dla infrastruktury krytycznej (woda, energia, transport)

  • Ryzyko realnych szkód fizycznych (awarie, przestoje, koszty napraw, odpowiedzialność regulatora).
  • Efekt mrożący: operatorzy mogą przechodzić w tryb „ręcznego sterowania” i ograniczać usługi, by odzyskać kontrolę.
  • Najsłabsze ogniwo to często styki IT–OT (zdalny dostęp, dostawcy utrzymania, nieaktualne systemy, brak segmentacji).

Dla procesów demokratycznych

  • DDoS może ograniczać dostęp do informacji (strony urzędów, komisji, mediów) i wzmacniać narrację o „państwie, które nie działa”.
  • Nawet jeśli głosowanie nie zostaje przerwane, koszt ponosi zaufanie publiczne.

AP odnotowuje, że podobne działania są elementem szerszego wzorca incydentów przypisywanych Rosji w Europie po 2022 r., obejmującego również sabotaż i cyberoperacje.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz” – szczególnie dla operatorów usług kluczowych (water/wastewater), samorządów i podmiotów okołowyborczych.

Ochrona OT/ICS (wodociągi, zakłady komunalne)

  • Segmentacja IT/OT i twarde reguły ruchu (allow-list), z kontrolą połączeń do strefy OT.
  • Zdalny dostęp tylko przez bastion (MFA, PAM, rejestrowanie sesji, czasowe uprawnienia).
  • Monitoring anomalii procesowych: alerty na nietypowe parametry (np. skoki ciśnienia, częstotliwość załączeń pomp).
  • Kopie zapasowe konfiguracji PLC/SCADA + procedury odtworzeniowe testowane w praktyce.
  • Audyt kont serwisowych i dostawców utrzymania (to częsty wektor wejścia).

Odporność na DDoS (wybory, administracja, media lokalne)

  • Włączenie ochrony na poziomie CDN/WAF i usług anty-DDoS (przynajmniej dla kluczowych domen).
  • Przygotowanie „trybu awaryjnego”: statyczne strony informacyjne, mirror, komunikaty w kanałach alternatywnych.
  • Testy obciążeniowe przed wydarzeniami wysokiego ryzyka (wybory, kryzysy).
  • Logika komunikacji kryzysowej: kto ogłasza, gdzie ogłasza, jak szybko.

Zarządzanie incydentem i „gotowość organizacyjna”

  • Scenariusze tabletop: „atak na OT” i „DDoS w dzień głosowania”.
  • Jasny podział odpowiedzialności IT/OT/PR/prawny oraz kontakty do CERT/CSIRT.
  • Retencja logów i synchronizacja czasu (NTP) – bez tego analiza incydentu bywa fikcją.

Różnice / porównania z innymi przypadkami

  • OT vs IT: atak na wodociągi pokazuje przejście od „samej niedostępności” do ryzyka oddziaływania na proces fizyczny. To inna klasa incydentu niż typowe DDoS-y.
  • Skala szkód vs efekt strategiczny: nawet ograniczony incydent (np. kilkaset gospodarstw bez wody) może mieć wysoką wartość propagandową i testową: sprawdza czas reakcji, komunikację, poziom przygotowania.
  • DDoS jako broń informacyjna: technicznie bywa „low effort”, ale świetnie działa jako element kampanii hybrydowej – zwłaszcza w momentach społecznie wrażliwych (wybory).

Podsumowanie / kluczowe wnioski

  1. Dania oficjalnie wskazała Rosję jako odpowiedzialną za konkretne cyberataki na wodociągi i infrastrukturę internetową wokół wyborów.
  2. Incydent w sektorze wodnym to ostrzeżenie: OT/ICS nie jest „za nudne, by atakować” – wręcz przeciwnie, jest idealne do działań destabilizacyjnych.
  3. DDoS nadal pozostaje prostym narzędziem o dużym wpływie społecznym.
  4. Najbardziej opłacalne kroki obronne to: segmentacja IT/OT, kontrola zdalnego dostępu, monitoring anomalii procesowych oraz przygotowane playbooki na DDoS i incydenty wyborcze.

Źródła / bibliografia

  1. FE/DDIS (Forsvarets Efterretningstjeneste) – komunikat o przypisaniu ataków grupom Z-Pentest i NoName057(16) oraz ich powiązaniach z państwem rosyjskim. (Forsvarets Efterretningstjeneste)
  2. Associated Press – opis incydentu wodociągowego, skali zakłóceń i kontekstu „hybrydowej” presji. (AP News)
  3. The Guardian – informacje o charakterze ataków, wskazanych grupach i reakcji władz. (The Guardian)
  4. Euronews – potwierdzenie publicznej atrybucji i wątku ataków na serwisy wyborcze. (euronews)
  5. SecurityWeek (reprint AP) – syntetyczne ujęcie tematu w kontekście cyberbezpieczeństwa. (SecurityWeek)