Archiwa: Phishing - Strona 56 z 99 - Security Bez Tabu

Tag: Phishing

Polska wskazuje Static Tundra jako sprawcę destrukcyjnych ataków na energetykę z 29 grudnia 2025 – co wiemy o DynoWiper, FortiGate i wektorach OT/IT

Wprowadzenie do problemu / definicja luki

29 grudnia 2025 r. w Polsce odnotowano skoordynowaną serię ataków o czysto destrukcyjnym celu (w raporcie porównywaną do „cyfrowego podpalenia”). Kampania objęła ponad 30 farm wiatrowych i fotowoltaicznych, firmę z sektora produkcyjnego oraz dużą elektrociepłownię (CHP) dostarczającą ciepło dla ok. pół miliona odbiorców. Kluczowe jest to, że incydent dotknął jednocześnie środowisk IT i OT, co nadal jest rzadkością w publicznie opisywanych zdarzeniach.

Wąskim gardłem nie była „jedna magiczna luka CVE”, tylko kombinacja: ekspozycja zdalnego dostępu, słabe uwierzytelnianie (w tym brak MFA), odziedziczone konfiguracje i praktyki (np. powtarzanie kont/ haseł między lokalizacjami), a następnie konsekwentna automatyzacja działań destrukcyjnych w sieciach stacyjnych/zakładowych.

W skrócie

  • Ataki z 29.12.2025 były skoordynowane i nastawione na sabotaż (niszczenie danych/urządzeń), a nie ransomware.
  • Wektor na obiektach OZE: urządzenia FortiGate jako VPN/firewall z wystawionym interfejsem VPN do Internetu, bez MFA; dodatkowo pojawia się wątek reuse’owania poświadczeń między obiektami.
  • W OT obserwowano m.in. działania na RTU/HMI: użycie domyślnych danych logowania (np. na kontrolerach) i próby uszkadzania/wymazywania systemów oraz elementów sterowania.
  • CERT Polska przypisał aktywność klastrowi Static Tundra (powiązywanemu z FSB / Center 16), podczas gdy część analiz zewnętrznych (m.in. ESET) wskazuje na możliwe związki z Sandworm.
  • Rząd podkreśla, że Polska obroniła się przed skutkami typu blackout, ale incydent potraktowano jako sygnał do dalszego wzmacniania systemu.

Kontekst / historia / powiązania

W ostatnich latach granica między „APT do szpiegostwa” a „APT do sabotażu” coraz częściej się zaciera. W tym incydencie istotne są dwa równoległe wątki:

  1. Atrybucja państwowa: według informacji opisywanych publicznie, strona polska wskazuje na rosyjską służbę (FSB) jako prawdopodobnego sprawcę, a sam incydent miał miejsce w okresie niskich temperatur i śnieżyc, co zwiększało potencjalną presję operacyjną na energetykę i ciepłownictwo.
  2. Spór o „kto dokładnie”: CERT przypisuje kampanię klastrowi Static Tundra, natomiast część badaczy zwraca uwagę na podobieństwa wipera DynoWiper do wcześniejszych narzędzi kojarzonych z Sandworm (w tym do wipera nazwanego przez ESET „ZOV”). To klasyczny przypadek, gdzie malware similarity ≠ jednoznaczna atrybucja, bo narzędzia i techniki mogą być współdzielone, odsprzedawane lub kopiowane.

Analiza techniczna / szczegóły luki

1) OZE i punkt przyłączenia (GCP): FortiGate jako brama wejścia

Raport wskazuje, że w badanych obiektach OZE urządzenia typu FortiGate pełniły rolę koncentratora VPN i firewalla. W każdym przypadku interfejs VPN był wystawiony do Internetu i dopuszczał uwierzytelnianie kontami z konfiguracji bez MFA. Ze względu na destrukcję, nie zawsze udało się odzyskać komplet logów, ale z analizy wynika, że część urządzeń bywała w przeszłości podatna (w tym na klasy błędów umożliwiających RCE) przez dłuższe okresy.

Dodatkowo pojawia się ważna obserwacja operacyjna: w branży ma być powszechne powtarzanie kont i haseł między wieloma lokalizacjami. To oznacza, że kompromitacja jednego obiektu może stać się „kluczem głównym” do kolejnych.

2) OT: RTU, przekaźniki zabezpieczeniowe, HMI – sabotaż zamiast tylko IT

W części środowisk sterowania obserwowano działania, które nie polegały wyłącznie na niszczeniu plików na stacjach roboczych, ale również na destabilizacji komponentów OT (np. poprzez logowanie z domyślnymi poświadczeniami i wykonywanie komend destrukcyjnych na kontrolerach). To szczególnie niebezpieczne, bo „wymazanie” lub uszkodzenie urządzeń OT może wymagać interwencji terenowej i wydłużać czas odtworzenia usług.

3) Wipery i dystrybucja: DynoWiper i LazyWiper oraz GPO/PowerShell

CERT opisuje użycie wcześniej niekojarzonych rodzin wiperów, których celem było nieodwracalne niszczenie danych, bez elementu wymuszenia okupu. W raporcie rozróżniono scenariusze uruchomienia: w środowiskach OZE malware miał być odpalany bezpośrednio na maszynie HMI, a w elektrociepłowni i firmie produkcyjnej dystrybucja odbywała się w domenie Active Directory przez skrypt PowerShell uruchomiony na kontrolerze domeny (model „szybkiego rażenia” wielu hostów).

4) Firma produkcyjna: kompromitacja urządzenia brzegowego i persistence

W przypadku firmy produkcyjnej opisano dostęp przez urządzenie brzegowe Fortinet, a także modyfikacje konfiguracji, które miały zapewnić trwałość dostępu nawet po zmianach haseł (m.in. poprzez mechanizmy skryptowe na urządzeniu).

5) Atrybucja techniczna: „Static Tundra” i zastrzeżenia dot. podobieństw do Sandworm

CERT wskazuje, że infrastruktura i charakterystyki komunikacji pokrywają się z tym, co publicznie opisywano dla klastra „Static Tundra”, a jednocześnie zaznacza, że podobieństwa DynoWiper do wiperów wiązanych z Sandworm są zbyt ogólne, by same w sobie przesądzały o sprawstwie.
Z kolei ESET opisuje podobieństwa DynoWiper do ich wcześniejszych obserwacji destrukcyjnego malware przypisywanego Sandworm (ZOV), przy jednoczesnym zastrzeżeniu, że nie wszystkie elementy operacji muszą pochodzić od jednej grupy.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko kaskadowe w OZE: nawet jeśli pojedyncza farma nie destabilizuje systemu, równoległe uderzenie w dziesiątki obiektów zwiększa obciążenie operatorów, czas reakcji i ryzyko błędów proceduralnych.
  2. Czas odtworzenia w OT: urządzenia sterujące, RTU czy elementy telemechaniki mogą wymagać fizycznej wymiany/ponownego wgrania firmware’u i walidacji – a to oznacza realny koszt i przestoje.
  3. Eskalacja intencji: publicznie podkreślano, że to incydent „sabotażowy” i jeden z poważniejszych tego typu w ostatnich latach. Taki sygnał zmienia model zagrożeń dla firm, które dotychczas projektowały ochronę głównie pod wyciek danych lub phishing.

Rekomendacje operacyjne / co zrobić teraz

Poniżej „checklista” w kolejności od działań o najwyższym ROI do bardziej złożonych:

1) Zdalny dostęp (VPN/edge) – natychmiastowe „higieniczne minimum”

  • Włącz MFA wszędzie, gdzie jest zdalny dostęp administracyjny lub operatorski (VPN, portale, jump-hosty). Brak MFA pojawia się wprost jako element ryzyka.
  • Wymuś unikalne konta i hasła per obiekt (koniec z re-use między farmami/lokalizacjami).
  • Audyt urządzeń brzegowych: aktualizacje, przegląd ekspozycji usług, usunięcie „starych” reguł i kont technicznych.

2) Segmentacja IT/OT i kontrola ścieżek lateral movement

  • Odseparuj domenę/AD od stref OT (lub przynajmniej twardo kontroluj relacje zaufania, konta serwisowe i ścieżki RDP/SMB).
  • W OT: dopuszczaj tylko niezbędne protokoły i kierunki komunikacji; rozważ jump-serwery z silnym uwierzytelnianiem i pełnym logowaniem.

3) Eliminacja domyślnych poświadczeń i twardnienie urządzeń OT

  • Usuń domyślne hasła/konta na RTU/HMI i urządzeniach pośredniczących (to w raporcie pojawia się jako realny wektor destrukcji).
  • Włącz i egzekwuj mechanizmy weryfikacji firmware (tam, gdzie dostępne) oraz kontroluj proces aktualizacji i źródła obrazów.

4) Odporność na wipery

  • Kopie zapasowe offline/immutable + testy odtworzenia (nie „mamy backup”, tylko RTO/RPO na stole).
  • EDR/monitoring na kontrolerach domeny i serwerach zarządzających: wykrywanie nietypowych działań PowerShell/GPO, masowych modyfikacji polityk, nietypowych zadań harmonogramu itp. (w raporcie opisano dystrybucję przez skrypt i domenę).

5) Przygotowanie organizacyjne

  • Scenariusze IR dla sabotażu (wiper/OT): procedury izolacji, odcięcia zdalnego dostępu, przełączeń ręcznych, kontaktów vendor/PSIRT.
  • W sektorze energii: ćwiczenia „table-top” łączące zespoły SOC + automatycy + utrzymanie ruchu.

Różnice / porównania z innymi przypadkami

Static Tundra (FSB) vs Sandworm (GRU) w tym incydencie sprowadza się do pytania: czy obserwujemy „nową fazę” tej samej grupy, współdzielenie narzędzi, czy operację mieszaną?

  • CERT argumentuje atrybucję do klastra Static Tundra m.in. na podstawie infrastruktury i jej charakterystyk, jednocześnie traktując podobieństwa DynoWiper do narzędzi sandwormowych jako niewystarczające do twardej identyfikacji.
  • ESET widzi techniczne podobieństwa DynoWiper do ZOV i łączy je z Sandworm, ale też dopuszcza, że elementy operacji mogły być rozdzielone między różne podmioty.
  • Publiczne doniesienia podkreślają, że polskie władze wskazały na FSB jako prawdopodobnego sprawcę, a sama operacja była postrzegana jako eskalacja w stronę działań destrukcyjnych.

W praktyce dla obrońców wniosek jest prosty: modeluj zagrożenie po TTP, nie po etykiecie grupy. Jeśli masz ekspozycję VPN bez MFA, re-use poświadczeń i słabą separację IT/OT – „kto” jest drugorzędne wobec „jak szybko może to powtórzyć ktoś inny”.

Podsumowanie / kluczowe wnioski

  • To był incydent, w którym sabotaż cyfrowy dotknął jednocześnie IT i OT, a celem było niszczenie, nie zysk.
  • Najbardziej „przyziemne” problemy (MFA, unikalne hasła, ekspozycja VPN, domyślne konta) okazały się krytyczne w skali krajowej.
  • Atrybucja (Static Tundra vs Sandworm) jest ważna politycznie, ale operacyjnie kluczowe są powtarzalne techniki: kompromitacja edge, ruch boczny, a potem szybka destrukcja (w tym przez mechanizmy domenowe).
  • Nawet gdy nie doszło do blackoutu, incydent pokazuje, że odporność musi obejmować wipery + OT recovery, a nie tylko ochronę przed wyciekiem danych.

Źródła / bibliografia

  1. Raport techniczny CERT: „Energy Sector Incident Report – 29 December 2025”. (cert.pl)
  2. Artykuł: The Hacker News – podsumowanie i kontekst (DynoWiper/LazyWiper, wątki FortiGate, przypisanie do Static Tundra). (The Hacker News)
  3. Analiza: ESET – „DynoWiper update: Technical analysis and attribution”. (welivesecurity.com)
  4. Komunikat rządowy: Gov.pl – o odparciu ataku i działaniach wzmacniających. (Gov.pl)
  5. Depesza: Reuters – wątek przypisania i komentarze ekspertów. (Reuters)

Microsoft Teams doda „Report a Call”: zgłaszanie podejrzanych połączeń jako nowy sygnał dla SOC

Wprowadzenie do problemu / definicja „luki”

Ataki socjotechniczne coraz częściej omijają klasyczne filtry antyphishingowe, przenosząc ciężar z e-maila do kanałów współpracy: czatów, spotkań i… połączeń VoIP. Rozmowa „rzekomo z IT”, „z banku” czy „z dostawcy” bywa trudniejsza do zweryfikowania niż wiadomość z linkiem – zwłaszcza gdy presja czasu i autorytet rozmówcy robią swoje.

Microsoft odpowiada na ten trend, dodając do Teams mechanizm umożliwiający użytkownikom zgłoszenie podejrzanego połączenia wprost z historii rozmów.

W skrócie

  • Teams dostanie funkcję „Report a Call”, pozwalającą oznaczać połączenia jako podejrzane / niechciane (scam, phishing).
  • Opcja ma być dostępna w historii połączeń dla rozmów 1:1 na Windows, macOS i w wersji web.
  • Raportowanie będzie włączone domyślnie, a administratorzy będą mogli je wyłączyć w Teams Admin Center → Calling settings.
  • Zgłoszenie udostępni ograniczone metadane (m.in. czas, długość, caller ID, identyfikatory uczestników) organizacji oraz Microsoftowi; dane mają być widoczne w Microsoft Defender portal lub w Teams Admin Center.
  • Harmonogram wg opisu wdrożenia: Targeted Release w połowie marca 2026, zakończenie w końcówce marca, GA globalnie do końca kwietnia 2026.

Kontekst / historia / powiązania

Nowa opcja raportowania wpisuje się w szerszy pakiet zabezpieczeń „na warstwie współpracy”. Microsoft równolegle rozwija mechanizmy ostrzegania o podejrzanych połączeniach od nieznanych, zewnętrznych kontaktów (scenariusze podszywania się pod markę / instytucję). Przykładem jest „Brand Impersonation Protection”, które ma wykrywać próby podszycia przy pierwszym kontakcie i ostrzegać użytkownika o ryzyku.

W praktyce to logiczna ewolucja: skoro Teams stał się „nową skrzynką odbiorczą” dla wielu firm, to telemetryka i procesy reagowania muszą objąć nie tylko czat, ale też kanał głosowy.

Analiza techniczna / szczegóły funkcji

Gdzie użytkownik zobaczy opcję?

„Report a Call” ma pojawić się w historii połączeń dla rozmów jeden na jeden. Użytkownik wybierze zgłoszenie z menu More options przy danym połączeniu.

Jakie dane trafiają do organizacji i Microsoftu?

Zgłoszenia mają przekazywać ograniczone metadane, m.in.:

  • znaczniki czasu,
  • czas trwania połączenia,
  • informacje caller ID,
  • identyfikatory Teams uczestników.

To ważne: mowa o metadanych „pod triage”, a nie o deklaracji, że treść rozmów jest automatycznie przechwytywana. Dla SOC oznacza to dodatkowy sygnał korelacyjny (kto dzwonił, kiedy, jak często, do ilu osób).

Gdzie analitycy to zobaczą?

  • Organizacje z licencjami Defender for Office 365 Plan 1/Plan 2 lub Defender XDR mają otrzymać bardziej szczegółowy wgląd w Defender portal.
  • Bez tych licencji pozostanie podstawowy wgląd w Teams Admin Center (raporty ochrony / Protection Reports).

Praktyczne konsekwencje / ryzyko

Co to realnie poprawia?

  1. Szybszy sygnał od użytkownika – zamiast „napiszcie do IT”, zgłoszenie staje się danymi do korelacji i raportowania trendów.
  2. Widoczność w SOC – nawet jeśli atak „nie zostawił linku”, nadal zostawia metadane i ślad zdarzenia w ekosystemie bezpieczeństwa.

Ryzyka wdrożeniowe

  • Szum operacyjny: jeśli użytkownicy zaczną zgłaszać wszystko, SOC dostanie „spam zgłoszeń”.
  • Fałszywe poczucie bezpieczeństwa: ostrzeżenia i przycisk zgłoszenia nie zastąpią procedur weryfikacji tożsamości rozmówcy.
  • Prywatność i governance: nawet metadane połączeń to dane wrażliwe organizacyjnie – trzeba je objąć polityką retencji, dostępów i audytu.

Rekomendacje operacyjne / co zrobić teraz

  1. Zdefiniuj playbook dla „podejrzanego połączenia”
    • kryteria: podszywanie pod IT/finanse, prośby o MFA, reset hasła, instalację narzędzia zdalnego dostępu, presja czasu;
    • działania: weryfikacja rozmówcy kanałem niezależnym, zgłoszenie incydentu, kontrola konta użytkownika (logowania, anomalie).
  2. Ustal triage i priorytetyzację
    • reguły korelacji: czy numer/konto dzwoniło do wielu osób, czy występuje wzorzec w czasie, czy są równoległe alerty (np. nietypowe logowania).
  3. Przygotuj komunikację dla pracowników
    • krótko: kiedy zgłaszać, kiedy kończyć rozmowę, czego nigdy nie podawać;
    • pokaż przykłady „pretekstów” w voice-phishingu.
  4. Sprawdź ustawienia w Teams Admin Center
    • skoro funkcja ma być domyślnie włączona, decyzja powinna być świadoma (pozostawić i okiełznać procesem, albo wyłączyć z uzasadnieniem).
  5. Jeśli masz Defender – zintegruj to z pracą SOC
    • przypisz odpowiedzialność (kto monitoruje nowe zgłoszenia),
    • zrób dashboard trendów i kampanii (miesiąc do miesiąca).

Różnice / porównania z innymi przypadkami

W Teams od pewnego czasu rozwijane jest też raportowanie podejrzanych wiadomości („Report this message”), które trafia do analizy po stronie bezpieczeństwa i przyspiesza wykrywanie zagrożeń w warstwie konwersacji.

Kluczowa różnica:

  • Wiadomości: często zawierają linki/załączniki → łatwiej o automatyczną analizę treści.
  • Połączenia: treści nie ma w zgłoszeniu, więc wartość leży w metadanych + korelacji + szybkości reakcji. Dlatego tak istotne jest, by playbook SOC nie opierał się wyłącznie na „kliknięciu zgłoś”, ale na szybkiej weryfikacji kontekstu i aktywności konta.

8Podsumowanie / kluczowe wnioski

„Report a Call” w Teams to mała zmiana w UI, ale duża zmiana w praktyce: użytkownik staje się czujnikiem, a SOC dostaje nowy sygnał o kampaniach socjotechnicznych prowadzonych głosem. Najwięcej zyskają organizacje, które:

  • połączą zgłoszenia z korelacją w Defender (jeśli mają licencje),
  • ograniczą szum jasnym szkoleniem i prostym playbookiem,
  • potraktują tę funkcję jako element strategii „secure collaboration”, obok ostrzeżeń o podszywaniu się pod marki.

Źródła / bibliografia

  • BleepingComputer: „New Microsoft Teams feature will let you report suspicious calls” (29 stycznia 2026). (BleepingComputer)
  • Microsoft 365 Roadmap: pozycja „Microsoft Teams: Report a Suspicious Call in Microsoft Teams” (status i daty na roadmapie). (Microsoft)
  • Microsoft Learn: „Microsoft Defender for Office 365 support for Microsoft Teams” (możliwości bezpieczeństwa i raportowania w Teams). (Microsoft Learn)
  • Microsoft Tech Community (Defender for Office 365 Blog): „Safeguarding Microsoft Teams…” (kontekst raportowania zagrożeń w Teams). (TECHCOMMUNITY.MICROSOFT.COM)
  • Windows Central: opis „Brand Impersonation Protection” i ostrzeżeń o podszywaniu się w połączeniach Teams (27 stycznia 2026). (Windows Central)

France Travail ukarany przez CNIL: 5 mln euro za braki w bezpieczeństwie po wycieku danych 36,8 mln osób

Wprowadzenie do problemu / definicja luki

Francuski regulator ochrony danych (CNIL) nałożył na publiczną agencję zatrudnienia France Travail (dawniej Pôle Emploi) karę 5 mln euro za niewystarczające środki techniczne i organizacyjne chroniące dane osób poszukujących pracy. Sprawa jest istotna nie tylko ze względu na skalę (dziesiątki milionów rekordów), ale też dlatego, że pokazuje „klasyczny” wektor ataku: socjotechnikę wspartą słabymi kontrolami dostępu i detekcji.

W skrócie

  • Kara: 5 mln euro; dodatkowo ryzyko kary okresowej 5 000 euro/dzień za brak wykazania działań naprawczych w terminie.
  • Atak: trwał od 6 lutego do 5 marca 2024, wykryty sygnałem anomalii 29 lutego; formalna notyfikacja do CNIL: 8 marca 2024 (uzupełniona 15 maja 2024).
  • Skala exfiltracji: 25 GB danych dotyczących 36 820 828 osób.
  • Wektor wejścia: socjotechnika i przejęcie kont doradców partnera Cap Emploi (m.in. poprzez proces resetu hasła i podszywanie się pod helpdesk).
  • Kluczowe braki (Art. 32 RODO): zbyt słabe mechanizmy uwierzytelniania, niewystarczające logowanie/monitoring oraz zbyt szerokie uprawnienia kont partnera.

Kontekst / historia / powiązania

CNIL wskazuje, że naruszenie dotyczyło danych osób zarejestrowanych w France Travail w ciągu ostatnich 20 lat oraz osób posiadających konto kandydata na portalu francetravail.fr.
W decyzji sankcyjnej podkreślono też relację operacyjną z Cap Emploi (sieć struktur wspierających zatrudnienie osób z niepełnosprawnościami) i fakt, że pracownicy partnera mieli zdalny dostęp do aplikacji biznesowej France Travail.

Analiza techniczna / szczegóły luki

1. Socjotechnika + przejęcie kont (Account Takeover)

Atakujący:

  1. zdobyli dane potrzebne do resetu hasła doradcy Cap Emploi,
  2. złożyli wniosek o reset do dostawcy wsparcia IT, podszywając się pod pracowników Cap Emploi,
  3. następnie kontaktowali się z doradcami, udając helpdesk i przekazując „nowe” hasło.

To typowy scenariusz „helpdesk-driven ATO”, gdzie bezpieczeństwo całego systemu zależy od jakości procedur weryfikacji tożsamości po stronie wsparcia oraz od tego, czy konto ma dodatkowe zabezpieczenia (np. MFA, restrykcje kontekstowe).

2. Skala dostępu i zakres wycieku

Według decyzji (SAN–2026-003) wyprowadzono m.in.: imię i nazwisko, datę urodzenia, NIR (francuski numer ubezpieczenia społecznego), adres, e-mail, telefon, status rejestracji i daty rejestracji – łącznie 36 820 828 osób i ok. 25 GB.
CNIL zaznacza jednocześnie, że napastnicy nie uzyskali dostępu do „pełnych teczek” bezrobotnych, które mogą zawierać dane szczególnie wrażliwe (np. zdrowotne).

3. Co CNIL uznał za kluczowe braki (Art. 32 RODO)

W komunikacie CNIL i materiale sprawy powtarzają się trzy filary:

  • Uwierzytelnianie kont partnera nie było wystarczająco odporne (w decyzji pojawia się m.in. krytyka progu 50 nieudanych prób logowania przed blokadą).
  • Detekcja i logowanie: niewystarczające mechanizmy monitoringu/journalizacji do szybkiego wykrywania anomalii.
  • Zasada najmniejszych uprawnień: konta doradców Cap Emploi miały uprawnienia zdefiniowane zbyt szeroko (dostęp do danych osób, których nie obsługiwali), co zwiększyło „blast radius”.
    Dodatkowo CNIL odnotował, że część właściwych środków była zidentyfikowana wcześniej (np. w analizach ryzyka), ale nie została skutecznie wdrożona.

Praktyczne konsekwencje / ryzyko

Wyciek pakietu danych typu NIR + dane kontaktowe + adres to paliwo dla:

  • kradzieży tożsamości i prób „account recovery” w bankach/telekomach,
  • ukierunkowanego phishingu (podszywanie się pod instytucje publiczne, świadczenia, rekrutację),
  • oszustw socjalnych (np. fałszywe oferty pracy i wyłudzenia opłat),
  • długoterminowego ryzyka, bo dane dotyczą osób z horyzontu 20 lat rejestracji.

Rekomendacje operacyjne / co zrobić teraz

Jeśli zarządzasz systemem z dostępem partnerów/outsourcingu (B2B/B2G), ta sprawa podpowiada priorytety:

  1. Wymuś MFA i twarde polityki dostępu dla kont zewnętrznych
    • MFA wszędzie, a dla zdalnego dostępu: warunkowe reguły (kontekst, urządzenie, geolokacja, ryzyko).
  2. Uszczelnij procesy helpdesk/resetu hasła
    • weryfikacja wielokanałowa, „no-override”, rejestrowanie i audyt działań supportu, detekcja nadużyć resetów.
  3. Least privilege i segmentacja danych
    • uprawnienia „per caseload”, ograniczenia regionalne/funkcyjne, JIT/JEA dla dostępu podwyższonego.
  4. Monitoring, logowanie i szybka reakcja
    • centralizacja logów, korelacja (SIEM), alerty na anomalie (nietypowe zapytania masowe, eksporty, wzrost zużycia zasobów), playbooki IR.
  5. Ćwiczenia z socjotechniki + „defense in depth”
    • szkolenia, testy, symulacje, ale też zabezpieczenia systemowe zakładające, że użytkownik może zostać zmanipulowany (CNIL wyraźnie podkreśla ten punkt w argumentacji).

Różnice / porównania z innymi przypadkami

W styczniu 2026 CNIL uderzył również w sektor prywatny: FREE MOBILE i FREE dostały łącznie 42 mln euro m.in. za niewystarczająco robustne uwierzytelnianie do VPN i nieskuteczną detekcję anomalii – znów wprost w kontekście Art. 32 RODO.

Wspólny mianownik obu spraw:

  • regulator premiuje podejście „proporcjonalne do ryzyka”: im większa skala i wrażliwość danych, tym większa oczekiwana dojrzałość kontroli,
  • powtarza się nacisk na uwierzytelnianie + monitoring + minimalizację uprawnień jako „bazę”, nie opcję.

Podsumowanie / kluczowe wnioski

  • To nie „egzotyczny zero-day”, tylko mieszanka socjotechniki i luk w kontrolach: ATO przez helpdesk + szerokie uprawnienia + słaba detekcja.
  • Skala (36,8 mln osób, 25 GB) i wrażliwy identyfikator (NIR) sprawiają, że incydent ma realne przełożenie na fraudy i phishing.
  • CNIL konsekwentnie stosuje Art. 32 RODO: bezpieczeństwo ma być wdrożone, a nie tylko „opisane w analizie ryzyka”.

Źródła / bibliografia

  1. CNIL – komunikat o sankcji dla France Travail (29.01.2026; decyzja 22.01.2026) (CNIL)
  2. Légifrance – Délibération SAN–2026-003 (opis incydentu, 36 820 828 osób, 25 GB, przebieg ataku) (Légifrance)
  3. The Record (Recorded Future News) – omówienie decyzji i stanowiska France Travail (The Record from Recorded Future)
  4. Help Net Security – skrót konsekwencji i kontekstu regulacyjnego (Help Net Security)
  5. CNIL – analogiczna sankcja dot. bezpieczeństwa (FREE MOBILE/FREE, 14.01.2026) (CNIL)

Hugging Face wykorzystany do dystrybucji tysięcy wariantów malware na Androida: kampania TrustBastion i „Premium Club”

Wprowadzenie do problemu / definicja luki

W końcówce stycznia 2026 r. badacze opisali kampanię Android RAT, w której przestępcy wykorzystali Hugging Face jako „zaufaną” infrastrukturę do hostowania i pobierania złośliwych plików APK. To nie jest klasyczna „luka” w sensie CVE, lecz nadużycie platformy (abuse): atakujący składowali payload w repozytoriach/datasetach, a ofiara pobierała go z domen i CDN, które rzadziej wzbudzają podejrzenia lub blokady.

W skrócie

  • Infekcja startowała od droppera „TrustBastion” podszywającego się pod narzędzie bezpieczeństwa i straszącego „zainfekowanym telefonem”.
  • Dropper nie serwował malware bezpośrednio – pobierał link przekierowujący do datasetu na Hugging Face, skąd ściągany był docelowy APK (również przez CDN Hugging Face).
  • Kampania używała polimorfizmu po stronie serwera: nowe warianty payloadu pojawiały się ~co 15 minut; repozytorium miało >6 tys. commitów w ~29 dni.
  • Payload nadużywał Accessibility Services oraz żądał uprawnień do overlay, przechwytywania ekranu itp., by kraść dane logowania (m.in. podszycia pod Alipay i WeChat) i utrzymać kontrolę.

Kontekst / historia / powiązania

To zdarzenie wpisuje się w szerszy trend: platformy współdzielenia artefaktów (repozytoria kodu, paczek, modeli, datasetów) są atrakcyjne dla atakujących, bo zapewniają:

  • renomę domeny (mniejsza podejrzaność),
  • wygodny hosting i dystrybucję,
  • szybkie iteracje (automatyzacja publikacji nowych wariantów).

W przypadku Hugging Face problem nie jest nowy: społeczność i firmy bezpieczeństwa od co najmniej 2024 r. ostrzegają przed możliwością dostarczania złośliwych treści (np. modeli prowadzących do wykonania kodu przy ładowaniu).
Jednocześnie Hugging Face rozwija mechanizmy bezpieczeństwa dla zasobów AI (np. skanowanie i alerty realizowane we współpracy z Protect AI), ale omawiana kampania pokazuje, że przestępcy potrafią „zmieścić się” w lukach kontroli treści – szczególnie gdy w grę wchodzą pliki binarne/instalatory i agresywny polimorfizm.

Analiza techniczna / szczegóły luki

1) Łańcuch infekcji (dropper → payload)

  1. Ofiara trafia na reklamę/scareware sugerującą infekcję i instalację „ochrony”. Instaluje aplikację TrustBastion (sideload).
  2. Po uruchomieniu dropper wyświetla obowiązkowy „update” z elementami łudząco podobnymi do Google Play/systemu.
  3. Dropper łączy się z trustbastion[.]com, ale zamiast pobierać APK, dostaje odpowiedź zawierającą URL do Hugging Face (dataset/repo), skąd pobiera finalny payload (APK) – finalnie po redirect do CDN Hugging Face.

2) Skala i polimorfizm

Bitdefender odnotował masowe tempo zmian: nowe buildy wrzucane ok. co 15 minut, a repozytorium miało ponad 6000 commitów przy wieku ok. 29 dni (w momencie analizy). Cel: omijanie detekcji opartej o hashe.

3) Zachowanie payloadu (RAT/spyware)

Po instalacji payload:

  • nakłania do włączenia Accessibility Services, podszywając prośbę pod „funkcję bezpieczeństwa/verification”; po uzyskaniu dostępu RAT zyskuje szeroką obserwowalność i kontrolę interakcji użytkownika,
  • dodatkowo prosi o uprawnienia umożliwiające nagrywanie/udostępnianie ekranu oraz overlay, co pozwala przechwytywać i manipulować treścią na ekranie w czasie rzeczywistym,
  • pokazuje fałszywe ekrany logowania (m.in. podszycia pod Alipay i WeChat) w celu kradzieży danych uwierzytelniających oraz przechwytuje informacje dot. blokady ekranu.

4) C2 i wskaźniki (IOCs) z publikacji badaczy

W raporcie wskazano m.in.:

  • C2: IP 154.198.48.57 (port 5000) i domenę trustbastion[.]com, a także w „drugiej fali” au-club[.]top oraz IP 108.187.7.133.
  • przykładowe nazwy pakietów: m.in. rgp.lergld.vhrthg oraz com.nrb.phayrucq.

Uwaga operacyjna: IoC szybko się „starzeją” w kampaniach polimorficznych. Traktuj je jako punkt startowy do polowań (threat hunting), nie jako jedyny warunek blokady.

Praktyczne konsekwencje / ryzyko

  • Dla użytkowników: przejęcie kont finansowych/płatniczych (phishing overlay + przechwytywanie ekranu), utrata kontroli nad urządzeniem (nadużycia Accessibility), potencjalne blokowanie prób usunięcia.
  • Dla organizacji: ryzyko kompromitacji telefonów służbowych (BYOD/COPE), eskalacja do wycieku danych (np. kody jednorazowe, dane logowania, treści ekranów), a także trudniejsze blokowanie ze względu na „zaufany” kanał pobierania (Hugging Face/CDN).
  • Dla platform: presja na rozszerzanie skanowania treści (nie tylko typowe pliki ML), lepsze reagowanie na abuse i wykrywanie anomalii (np. tysiące commitów w krótkim czasie w datasetach z binariami).

Rekomendacje operacyjne / co zrobić teraz

Jeśli bronisz środowiska firmowego (SOC/IT/MDM)

  1. Zablokuj sideloading (instalacje spoza sklepów) politykami MDM – to kluczowy punkt wejścia w tej kampanii.
  2. Wymuś polityki dla Accessibility Services: blokada/whitelist, alerty na nowe usługi dostępności, korelacja z overlay/screen capture.
  3. Dodaj detekcje sieciowe:
    • połączenia do wskazanych domen/IP (z zastrzeżeniem rotacji infrastruktury),
    • nietypowe pobrania plików APK z endpointów typu huggingface.co/.../resolve/.../*.apk.
  4. Threat hunting na urządzeniach: szukaj nazw pakietów wskazanych w IoC i anomalii uprawnień (Accessibility + overlay + screen capture).

Jeśli jesteś użytkownikiem Androida

  • Instaluj aplikacje wyłącznie z oficjalnych sklepów, unikaj „antywirusów” z reklam straszących infekcją.
  • Gdy aplikacja prosi o Ułatwienia dostępu, overlay lub przechwytywanie ekranu „bo inaczej nie zadziała” — potraktuj to jako czerwony alarm.

Jeśli utrzymujesz repozytoria/artefakty (DevSecOps / platform security)

  • Monitoruj i automatycznie flaguj:
    • nietypowe typy plików (np. APK w datasetach),
    • wysoką dynamikę commitów,
    • repozytoria służące wyłącznie jako „magazyn binarek”.
  • Rozważ skanowanie wielowarstwowe (signatures + heurystyka + reputacja) oraz szybki proces takedown po zgłoszeniach — w tej kampanii zgłoszenie doprowadziło do usunięcia złośliwych datasetów.

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

  • Tu Hugging Face był użyty głównie jako hosting payloadu APK i kanał dystrybucji (zaufana domena + CDN) w kampanii mobilnej.
  • W innych incydentach związanych z Hugging Face ryzyko częściej dotyczyło złośliwych modeli/plików typu pickle i wykonania kodu po stronie środowisk ML (supply chain dla data science). To inna powierzchnia ataku, ale wspólny mianownik jest ten sam: nadużycie otwartego ekosystemu dystrybucji artefaktów.

Podsumowanie / kluczowe wnioski

  1. Kampania TrustBastion pokazuje, że atakujący potrafią skutecznie wykorzystywać zaufane platformy (tu: Hugging Face) jako etap dystrybucji malware.
  2. Polimorfizm co ~15 minut i tysiące commitów w krótkim czasie to sygnał, że obrona „po hashach” nie wystarcza – potrzebne są detekcje behawioralne i kontrola uprawnień.
  3. W Androidzie krytycznym wektorem jest Accessibility + overlay/screen capture: to duet, który umożliwia realne przejęcie sesji i kradzież danych finansowych.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii i kontekst nadużycia Hugging Face (29 stycznia 2026). (BleepingComputer)
  2. Bitdefender Labs – analiza techniczna TrustBastion/Premium Club, polimorfizm, uprawnienia, C2, IoC (29 stycznia 2026). (Bitdefender)
  3. Hugging Face Docs – mechanizm Malware Scanning (ClamAV) dla repozytoriów. (Hugging Face)
  4. Hugging Face Blog – współpraca z Protect AI i skanowanie modeli/alerty bezpieczeństwa (kwiecień 2025). (Hugging Face)
  5. JFrog Security Research – kontekst złośliwych modeli na Hugging Face i ryzyk supply chain (luty 2024). (JFrog)

FBI przejmuje forum RAMP – ważny cios w ekosystem ransomware i handel „initial access”

Wprowadzenie do problemu / definicja luki

W świecie cyberprzestępczym fora i „marketplace’y” pełnią rolę infrastruktury krytycznej: to tam łączy się popyt (ransomware-as-a-service, brokerzy dostępu, sprzedawcy malware) z podażą (afilianci, „operatorzy”, pośrednicy od prania pieniędzy, sprzedawcy exploitów). Przejęcie takiego węzła rzadko kończy ransomware „w ogóle”, ale potrafi na pewien czas realnie spowolnić rekrutację afiliantów, handel dostępami do sieci (initial access) i dystrybucję narzędzi.

Właśnie w tym kontekście warto patrzeć na przejęcie RAMP (Russian Anonymous Marketplace) – rosyjskojęzycznego forum, które otwarcie dopuszczało promocję operacji ransomware.

W skrócie

  • 28 stycznia 2026 r. FBI przejęło zarówno wersję Tor, jak i clearnetową domenę forum ramp4u[.]io, zastępując je banerem „This site has been seized”.
  • Na banerze wskazano koordynację z U.S. Attorney’s Office for the Southern District of Florida oraz DOJ CCIPS (Computer Crime and Intellectual Property Section).
  • Widoczne są też techniczne ślady przejęcia: m.in. zmiana serwerów nazw na ns1.fbi.seized.gov i ns2.fbi.seized.gov.
  • Jeden z rzekomych operatorów („Stallman”) miał publicznie potwierdzić przejęcie.

Kontekst / historia / powiązania

RAMP wystartował w lipcu 2021 r. jako odpowiedź na sytuację, w której duże rosyjskojęzyczne fora (m.in. Exploit i XSS) zaczęły ograniczać/banować promocję ransomware pod rosnącą presją organów ścigania po głośnych incydentach (np. Colonial Pipeline). RAMP pozycjonował się jako jedno z niewielu miejsc, gdzie „ransomware jest dozwolone” – co szybko przyciągnęło gangi i afiliantów.

Wątek personalny jest równie istotny: według ustaleń opisywanych w materiałach, z RAMP wiązano postać działającą pod pseudonimem Orange (aliasy m.in. Wazawaka/BorisElcin), łączoną z ekosystemem Babuk; w tle pojawia się również Mikhail Matveev, oskarżany przez USA o udział w operacjach ransomware (m.in. LockBit, Babuk, Hive) i objęty sankcjami.

Analiza techniczna / szczegóły „takedownu”

Z perspektywy operacyjnej przejęcie RAMP jest klasycznym przykładem „domain seizure + takeover” z kilkoma elementami, które warto odnotować:

  1. Jednoczesne przejęcie Tor i clearnetu
    Fakt, że komunikat zajęcia pojawił się i na domenie publicznej, i na usłudze .onion, sugeruje działanie ukierunkowane na pełne odcięcie kanałów dostępu oraz redukcję możliwości „szybkiego powrotu” przez prostą zmianę domeny frontowej.
  2. Zmiana DNS/NS na infrastrukturę „seized”
    Przestawienie serwerów nazw na ns1.fbi.seized.gov / ns2.fbi.seized.gov jest technicznym potwierdzeniem, że organ ścigania uzyskał kontrolę nad kluczowym zasobem w warstwie DNS, co zwykle towarzyszy realizacji nakazów zajęcia.
  3. Wartość dowodowa danych forum
    W scenariuszu przejęcia infrastruktury forum, organy ścigania mogą potencjalnie uzyskać dostęp do danych takich jak: adresy e-mail, logi IP, wiadomości prywatne, metadane transakcji, wątki dot. sprzedaży dostępów itp. Wprost wskazywano, że brak odpowiedniego OPSEC może teraz przełożyć się na identyfikację i aresztowania.
  4. Efekt psychologiczny i dezintegracyjny
    Baner „trollujący” operatorów (odwołanie do hasła RAMP) pełni rolę komunikatu: „mamy kontrolę”, co zwykle zwiększa panikę wśród użytkowników i przyspiesza rozpad zaufania oraz migrację – często chaotyczną.

Praktyczne konsekwencje / ryzyko

Dla organizacji (obrońców)

  • Krótkoterminowe przetasowania w podziemiu: po takedownie często rośnie aktywność na alternatywnych forach/marketach, a brokerzy dostępu próbują szybko „odbudować kanały sprzedaży”. To okres zwiększonego szumu, ale też okazja do lepszego mapowania TTP i relacji.
  • Ryzyko wtórne: część aktorów może próbować „odkuć się” bardziej agresywnymi kampaniami phishingowymi, infostealerami i masową sprzedażą dostępów, by zrekompensować utracone kontakty/escrow.

Dla cyberprzestępców

  • Wzrost ryzyka deanonymizacji przy słabym OPSEC (powtarzalne aliasy, te same skrzynki e-mail, logowania bez tor/VPN, błędy w separacji person).
  • Utrata reputacji i escrow: na forach „zaufanie” jest walutą. Zniknięcie RAMP wymusza weryfikacje od nowa, co często prowadzi do konfliktów, scamów i rozłamów.

Rekomendacje operacyjne / co zrobić teraz

Jeśli odpowiadasz za bezpieczeństwo (SOC/CTI/IR), potraktuj ten moment jako szansę na podniesienie gotowości:

  1. Podnieś czujność na „initial access”
    Zwiększ korelację alertów dla: nietypowych logowań (VPN/RDP/VDI), anomalii w IAM, nowych tokenów OAuth, podejrzanych rejestracji urządzeń, i prób ruchu lateralnego. RAMP był wykorzystywany do handlu dostępami – migracja może podbić wolumen.
  2. Wzmocnij kontrolę tożsamości
    • MFA odporne na phishing (FIDO2/WebAuthn) tam, gdzie to realne
    • przegląd kont uprzywilejowanych, rotacja sekretów, ograniczenie stałych uprawnień
    • polityki „impossible travel” i detekcja proxy/VPN exit nodes
  3. Przygotuj scenariusze ransomware-ready
    • test odtwarzania kopii (nie tylko „backup exists”, ale „restore działa”)
    • izolacja domen/segmentacja, kontrola ruchu SMB/RDP/WinRM
    • gotowe playbooki: containment, komunikacja, decyzje dot. wyłączania usług
  4. Uważaj na „nowe fora” i podszycia
    Po głośnych przejęciach często rośnie liczba scam-forów i kampanii podszywających się pod „następcę”, co bywa wykorzystywane także do infekowania przestępców (infostealery), ale przy okazji może zwiększać liczbę wycieków narzędzi do sieci publicznej.

Różnice / porównania z innymi przypadkami

RAMP wyróżniał się tym, że był jednym z ostatnich dużych hubów pozwalających wprost na promocję ransomware. Dlatego jego utrata jest bardziej „systemowa” niż przejęcie pojedynczej grupy czy strony wyciekowej.

Z doświadczeń poprzednich takedownów wynika, że:

  • ekosystem nie znika, tylko migruje (często na kilka konkurencyjnych platform),
  • okres przejściowy generuje tarcia, scamy i błędy OPSEC,
  • dla obrońców to moment, w którym warto intensywniej zbierać sygnały o nowych kanałach rekrutacji i sprzedaży dostępów.

Podsumowanie / kluczowe wnioski

Przejęcie RAMP przez FBI (28 stycznia 2026 r.) to realne zakłócenie infrastruktury wspierającej ransomware-as-a-service, rekrutację afiliantów i rynek „initial access”.
Najważniejsze efekty będą prawdopodobnie widoczne w dwóch obszarach:

  • operacyjnym (przerwanie kanałów handlu i komunikacji, migracja),
  • kontrwywiadowczym (potencjalny dostęp organów ścigania do danych użytkowników i metadanych aktywności).

Dla organizacji to dobry moment, by założyć, że część aktorów „przegrupuje się” i spróbuje odzyskać tempo – a więc wzmocnić detekcję, IAM, backup/restore oraz gotowość IR.

Źródła / bibliografia

  • BleepingComputer – informacje o przejęciu, banerze, DNS i historii RAMP (BleepingComputer)
  • The Register – uzupełnienie kontekstu, komentarze dot. migracji i znaczenia dla ekosystemu (The Register)
  • U.S. Department of Justice (DOJ) – tło dot. Matveeva (LockBit/Babuk/Hive), CCIPS, nagroda do $10M (Department of Justice)
  • U.S. Treasury (OFAC) – sankcje na Matveeva i szerszy kontekst rosyjskiego ekosystemu ransomware (U.S. Department of the Treasury)

Mustang Panda (HoneyMyte) rozwija CoolClient: nowe moduły kradzieży danych z przeglądarek i monitor schowka

Wprowadzenie do problemu / definicja luki

Chińsko-powiązana grupa szpiegowska znana jako Mustang Panda (w nomenklaturze części dostawców także HoneyMyte / Earth Preta / Bronze President) zaktualizowała swój backdoor CoolClient tak, aby skuteczniej wspierał kradzież danych uwierzytelniających i „życie z zasobów” (LOTL) w środowiskach ofiar. Najważniejsza zmiana: CoolClient nie jest już wyłącznie furtką do zdalnego dostępu, ale stał się platformą do wdrażania infostealerów (kradzież logowań z przeglądarek) oraz monitorowania schowka i aktywnego okna.

W skrócie

  • Nowy CoolClient potrafi monitorować schowek i śledzić tytuły aktywnych okien, a także podsłuchiwać poświadczenia do proxy HTTP.
  • W kampaniach zaobserwowano trzy rodziny stealerów: pod Chrome, Edge oraz wariant „uniwersalny” dla przeglądarek Chromium.
  • Eksfiltracja danych (np. cookies) może wykorzystywać legalne usługi (np. Google Drive) i tokeny/API wbudowane w operacje, co utrudnia detekcję po samym „dokąd wychodzi ruch”.
  • Cele kampanii to m.in. instytucje rządowe w kilku krajach Azji oraz poza nią (m.in. Myanmar, Mongolia, Malezja, Rosja, Pakistan).

Kontekst / historia / powiązania

CoolClient jest kojarzony z Mustang Panda co najmniej od 2022 r. i bywał wdrażany jako dodatkowa furtka obok innych znanych implantów tej klasy (np. PlugX, LuminousMoth).
Z perspektywy „rodziny” aktora warto pamiętać, że różni dostawcy opisywali go pod wieloma nazwami (np. Earth Preta), a kampanie często opierały się o spreparowane archiwa-przynęty i klasyczny spear-phishing.
W 2025 r. IBM X-Force wskazywał na szeroki arsenał i nakładające się klastry aktywności przypisywane temu ekosystemowi (m.in. ToneShell/Pubload oraz nowe techniki dystrybucji), co dobrze tłumaczy, dlaczego CoolClient jest dziś „rozbudowywany” zamiast zastępowany.

Analiza techniczna / szczegóły luki

1) Łańcuch uruchomienia i wieloetapowość (.DAT)

Z obserwacji badaczy wynika, że CoolClient korzysta z zaszyfrowanych plików .DAT i wieloetapowego wykonania. W opisie Kaspersky widoczny jest schemat, w którym implant:

  • odszyfrowuje kolejne artefakty (np. time.dat, loader.dat, main.dat),
  • uruchamia proces-pośrednik (write.exe) i wstrzykuje do niego kolejny etap,
  • buduje trwałość przez Run key, usługę systemową oraz zaplanowane zadanie.

2) Utrzymanie uprawnień i „passuac”

Warianty widziane w terenie wspierają obejście UAC i eskalację: przy sprzyjających warunkach uruchamiany jest tryb „passuac”, a następnie ustawiana jest trwałość przez zadanie harmonogramu.

3) Nowe funkcje: schowek, aktywne okno, sniffing proxy

Nowością w aktualnych wariantach jest:

  • monitor schowka (m.in. poprzez typowe API systemowe używane przez clipboard stealery),
  • telemetria aktywnego okna (np. tytuł okna),
  • HTTP proxy credential sniffer oparty o inspekcję pakietów i ekstrakcję nagłówków.

4) Ekosystem pluginów i zdalna powłoka

CoolClient utrzymuje architekturę z pluginami ładowanymi w pamięci, rozszerzoną m.in. o:

  • plugin zdalnej powłoki (ukryty cmd.exe, I/O przez potoki),
  • plugin zarządzania usługami (enumeracja, start/stop, modyfikacje),
  • rozbudowany plugin menedżera plików (mapowanie dysków sieciowych, kompresja ZIP, wyszukiwanie, uruchamianie plików).

5) Infostealery: Chrome/Edge/Chromium i eksfiltracja „przez legalne chmury”

W operacjach udokumentowano wdrażanie stealerów kradnących loginy z przeglądarek (różne warianty pod Chrome, Edge i Chromium-based).
Co istotne operacyjnie: w części przypadków eksfiltracja (np. pliki cookies) była wykonywana narzędziowo (np. przez curl) do legalnych usług typu Google Drive, z użyciem tokenów/kluczy wbudowanych w działania aktora, co utrudnia prostą blokadę na podstawie „złośliwej domeny”.

6) Dystrybucja: legalne oprogramowanie i DLL sideloading

BleepingComputer (na bazie ustaleń Kaspersky) wskazuje, że w obserwowanych atakach malware bywał wdrażany przez legalne komponenty związane z Sangfor, a wcześniej operatorzy uruchamiali CoolClient przez DLL side-loading z wykorzystaniem podpisanych binariów (np. popularne aplikacje użytkowe).

Uwaga „na radar”: badacze sygnalizują także użycie nieopisanego wcześniej rootkita w powiązaniu z tym zestawem narzędzi, ale szczegóły mają zostać opublikowane w osobnym raporcie.

Praktyczne konsekwencje / ryzyko

  • Kompromitacja tożsamości: kradzież haseł/cookies/sesji z przeglądarek to ryzyko przejęcia dostępu do poczty, SSO, paneli administracyjnych i narzędzi chmurowych.
  • Trudniejsza detekcja na poziomie sieci: eksfiltracja przez popularne legalne usługi (np. Google Drive) może „zniknąć w szumie” i wyglądać jak typowy ruch biznesowy.
  • Wysokie ryzyko post-exploitation: pluginy (shell, zarządzanie usługami, operacje na plikach) i techniki eskalacji/UAC sprzyjają długiej obecności w sieci i lateral movement.

Rekomendacje operacyjne / co zrobić teraz

  1. Ochrona poświadczeń i sesji
  • Włącz/egzekwuj MFA odporne na phishing (FIDO2/WebAuthn) dla kont uprzywilejowanych i dostępu do krytycznych SaaS.
  • Rotuj hasła i unieważnij sesje tam, gdzie wykryto anomalie przeglądarkowe (cookies/tokens).
  1. Detekcja na endpointach (EDR)
  • Poluj na nietypowe uruchomienia i wstrzyknięcia z udziałem procesów typu write.exe oraz aktywności wokół zaszyfrowanych .dat i nietypowych usług/zadań harmonogramu.
  • Monitoruj wywołania związane ze schowkiem oraz pobieranie danych logowania z profili przeglądarek (szczególnie w kontekście narzędzi typu curl).
  1. Kontrola ruchu do usług chmurowych
  • Nie blokuj „w ciemno” Google Drive, ale wdrażaj CASB / DLP / polityki uploadu dla stacji i kont uprzywilejowanych (kto, co i skąd wysyła pliki).
  • W proxy/secure web gateway ustaw alerty na masowe uploady i podejrzane nagłówki autoryzacji w nietypowych kontekstach (np. curl na stacjach użytkowników).
  1. Higiena oprogramowania i odporność na sideloading
  • Ogranicz uruchamianie nieautoryzowanych binariów (AppLocker/WDAC), zwłaszcza z katalogów użytkownika i ścieżek tymczasowych.
  • Waliduj łańcuch dostaw: jeśli w środowisku jest oprogramowanie wykorzystywane do „legitymizacji” uruchomienia, przejrzyj modele dystrybucji i podpisy/hashe.

Różnice / porównania z innymi przypadkami

W wielu kampaniach APT backdoor służy głównie do zdalnego sterowania i pobierania kolejnych modułów. Tu widać przesunięcie akcentu: CoolClient staje się platformą do kradzieży tożsamości (infostealery, schowek, proxy sniffing) oraz do eksfiltracji „pod przykrywką” legalnych usług.
Na tle wcześniejszych opisów Earth Preta/Mustang Panda (phishing, archiwa-przynęty, szeroki arsenał) to spójna ewolucja: mniej hałaśliwe domeny C2 w warstwie eksfiltracji, większy nacisk na dostęp przez konta i sesje.

Podsumowanie / kluczowe wnioski

CoolClient w najnowszych kampaniach Mustang Panda/HoneyMyte to już nie tylko „backdoor”, ale modułowa platforma post-exploitation z funkcjami typowymi dla wyspecjalizowanych złodziei danych (schowek, przeglądarki, proxy) i z mechanizmami utrzymania dostępu (usługi, taski, obejście UAC). Priorytet obrony powinien przesunąć się na ochronę tożsamości (MFA/FIDO2), telemetry EDR wokół przeglądarek i narzędzi transferu, oraz kontrolę uploadów do legalnych chmur.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii i podsumowanie zmian w CoolClient (27 stycznia 2026). (BleepingComputer)
  2. Kaspersky Securelist (GReAT) – analiza techniczna CoolClient i stealerów (27 stycznia 2026). (Securelist)
  3. Trend Micro – tło dot. Earth Preta/Mustang Panda i taktyk kampanii (2023). (www.trendmicro.com)
  4. IBM X-Force – kontekst dot. Hive0154/Mustang Panda, arsenału i technik dystrybucji (2025). (IBM)

Ponad 6 tys. serwerów SmarterMail narażonych na automatyczne przejęcia kont admina (CVE-2026-23760)

Wprowadzenie do problemu / definicja luki

SmarterMail (serwer pocztowy i platforma współpracy od SmarterTools) znalazł się na celowniku masowych, zautomatyzowanych ataków po ujawnieniu krytycznej luki CVE-2026-23760. Błąd pozwala bez uwierzytelnienia przejąć konto administratora poprzez nieprawidłowo zaprojektowane API resetu hasła, a następnie – dzięki wbudowanym funkcjom administracyjnym – doprowadzić do zdalnego wykonania poleceń na hoście (RCE).

Równolegle organizacje typu Shadowserver raportowały tysiące instancji wystawionych do internetu, które wyglądały na podatne, a analitycy obserwowali już ataki „in the wild”.

W skrócie

  • CVE-2026-23760: obejście uwierzytelnienia w API resetu hasła; dotyczy wersji przed build 9511.
  • Wektor: POST /api/v1/auth/force-reset-password akceptuje żądania anonimowe i w krytycznej ścieżce dla sysadmina nie weryfikuje starego hasła / tokenu resetu.
  • Skutek: przejęcie konta admina → szybka eskalacja do RCE/SYSTEM przez funkcje administracyjne (np. wykonywanie komend).
  • Eksploatacja była obserwowana masowo i automatycznie (sekwencje żądań API, tworzenie „System Events”, sprzątanie śladów).
  • Skala: raportowano >6 000 publicznie dostępnych serwerów potencjalnie narażonych.

Kontekst / historia / powiązania

CVE-2026-23760 wypłynęło krótko po innej krytycznej luce w SmarterMail (CVE-2025-52691), co podbiło zainteresowanie atakujących (i presję na zespoły IT). BleepingComputer opisał sytuację jako serię zdarzeń: zgłoszenie, szybka poprawka, a następnie szybka adaptacja eksploitu i skanowanie internetu w poszukiwaniu podatnych serwerów.

Istotny kontekst operacyjny: w przypadku serwerów pocztowych ekspozycja na internet jest często „z definicji” (webmail, panel admina, API), więc okno czasowe między patchem a masową eksploatacją bywa wyjątkowo krótkie. SecurityWeek cytował watchTowr, że poprawka została szybko przeanalizowana (reverse engineering) i zaczęła być wykorzystywana na szeroką skalę.

Analiza techniczna / szczegóły luki

1) Root cause: reset hasła admina bez dowodu tożsamości

watchTowr opisał problem jako błąd w logice resetu hasła: endpoint force-reset-password jest dostępny anonimowo (co samo w sobie bywa normalne dla resetów), ale ścieżka dla kont sysadmin pozwala podać Username i NewPassword bez weryfikacji OldPassword lub tokenu resetu.

W praktyce: jeśli atakujący zna (lub zgadnie) nazwę konta administratora (często „admin”), może zresetować hasło i zalogować się jako administrator.

2) Od przejęcia konta do RCE – dwie obserwowane ścieżki

  • Ścieżka A (watchTowr): po przejęciu sysadmina możliwe jest doprowadzenie do wykonania poleceń systemowych przez wbudowane funkcje administracyjne (watchTowr opisał drogę przez ustawienia i mechanizm, który finalnie uruchamia komendę na hoście).
  • Ścieżka B (Huntress): w atakach „in the wild” widziano użycie funkcji System Events – napastnik po zdobyciu tokena dostępu tworzył złośliwy event-hook, wyzwalał go (np. dodaniem domeny), a potem wykonywał działania porządkowe (kasowanie domeny i hooka).

3) Sygnały masowej automatyzacji

Huntress pokazał typową sekwencję żądań API obserwowaną u wielu ofiar w krótkich odstępach czasu (co wygląda na automatyczne skrypty), zaczynając od wymuszenia resetu hasła, potem autoryzacji i konfiguracji mechanizmów do wykonania komend.

Praktyczne konsekwencje / ryzyko

Przejęty serwer SmarterMail to zwykle „klucz do królestwa” poczty:

  • dostęp do skrzynek, korespondencji i danych wrażliwych,
  • możliwość podszywania się (phishing/BEC), reguły przekierowań, utrwalanie dostępu,
  • infrastruktura do dalszych ataków (malware, pivot w sieci, kradzież poświadczeń),
  • ryzyko incydentu zgodności (RODO), reputacji i ciągłości działania.

NVD wprost wskazuje, że uprawnienia sysadmina w SmarterMail mogą przekładać się na administracyjne uprawnienia na hoście (SYSTEM/root) dzięki wbudowanym funkcjom zarządzania – co z perspektywy IR oznacza traktowanie takiego zdarzenia jak pełne przejęcie serwera.

Rekomendacje operacyjne / co zrobić teraz

1) Patch i weryfikacja wersji

  • Zaktualizuj do build 9511 lub nowszego (wszystko „przed 9511” jest wprost wskazywane jako podatne).

2) Jeśli nie możesz zaktualizować natychmiast (awaryjnie)

  • ogranicz dostęp do panelu/web API (VPN/allowlista IP, przynajmniej dla interfejsu administracyjnego),
  • rozważ tymczasowe reguły reverse proxy/WAF ograniczające dostęp do ścieżek API resetu hasła (uwaga: to obejście, nie „fix”),
  • włącz monitoring anomalii na endpointach /api/v1/auth/* i akcjach administracyjnych.

3) „Assume breach” – szybkie polowanie i IR

Szukaj w logach (proxy / aplikacyjnych) nietypowych żądań:

  • POST /api/v1/auth/force-reset-password oraz dalszych sekwencji API,
  • tworzenia/edycji System Events / event-hooków i operacji dodania/usunięcia domen (pattern z Huntress).

IOCs/sygnały (wg Huntress):

  • powtarzające się, szybkie sekwencje żądań API,
  • user-agent python-requests/2.32.4 widziany w atakach,
  • artefakt plikowy wskazywany w analizie Huntress (plik z wynikami rozpoznania).

4) Higiena po incydencie

  • reset haseł kont uprzywilejowanych (i rotacja kluczy/sekretów, jeśli serwer miał dostęp do innych systemów),
  • przegląd reguł przekazywania poczty, integracji i webhooków,
  • sprawdzenie trwałości (scheduled tasks, usługi, web-shelle, nieznane binaria),
  • segmentacja i minimalizacja ekspozycji usług zarządzających.

Różnice / porównania z innymi przypadkami

Warto odróżnić dwie głośne luki SmarterMail z przełomu stycznia:

  • CVE-2026-23760 – „czyste” przejęcie admina przez reset hasła bez weryfikacji (API), a potem RCE jako konsekwencja uprawnień admina i funkcji administracyjnych.
  • CVE-2025-52691 – wcześniejsza, krytyczna podatność pre-auth (opisywana jako droga do RCE na niezałatanych serwerach), wspominana w kontekście tej fali ataków.

Operacyjnie: w CVE-2026-23760 kluczowe jest, że atakujący może „wejść drzwiami frontowymi” jako admin (zmieniając hasło), co utrudnia detekcję, jeśli organizacja monitoruje wyłącznie klasyczne wskaźniki exploitów RCE.

Podsumowanie / kluczowe wnioski

  • CVE-2026-23760 to krytyczny błąd projektowy w API resetu hasła, który umożliwia przejęcie konta sysadmina i w praktyce prowadzi do pełnego kompromisu serwera.
  • Skala ekspozycji jest duża (tysiące instancji wystawionych do internetu), a eksploatacja była obserwowana jako zautomatyzowana.
  • Najważniejsze działania: aktualizacja do build 9511+, ograniczenie ekspozycji panelu/API oraz szybkie threat hunting pod kątem sekwencji API i nadużyć System Events.

Źródła / bibliografia

  • BleepingComputer – o skali ekspozycji i trwających atakach (BleepingComputer)
  • NVD (NIST) – opis CVE-2026-23760, wersje podatne, charakter wpływu (NVD)
  • watchTowr Labs – analiza techniczna root cause i PoC dla force-reset-password (watchTowr Labs)
  • Huntress – obserwacje ataków „in the wild”, sekwencje API i IOCs (Huntress)
  • SecurityWeek – kontekst masowej eksploatacji i mechaniki nadużyć (SecurityWeek)