Archiwa: Malware - Strona 92 z 126 - Security Bez Tabu

Tag: Malware

Ransomware w mieście New Britain: co wiemy o ataku na systemy urzędu i jak minimalizować ryzyko w samorządach

Wprowadzenie do problemu / definicja luki

W drugiej połowie stycznia 2026 r. samorząd New Britain poinformował o poważnym incydencie cyberbezpieczeństwa, który zakłócił działanie miejskich systemów IT i łączności. Z perspektywy bezpieczeństwa to klasyczny scenariusz „zakłócenia ciągłości działania” wywołanego ransomware: złośliwym oprogramowaniem, które szyfruje zasoby i wymusza okup, często łącząc to z groźbą publikacji danych (tzw. data extortion).

W tym przypadku władze podkreślają, że służby bezpieczeństwa publicznego funkcjonowały, ale część usług urzędu była ograniczona (m.in. telefonia i systemy komputerowe).

W skrócie

  • Atak ransomware uderzył w systemy miejskie od wczesnej środy (28 stycznia 2026), powodując przestoje w telefonii i systemach komputerowych wielu wydziałów.
  • Burmistrz Bobby Sanchez informował o pracach naprawczych prowadzonych także w weekend, przy wsparciu organów stanowych i federalnych oraz zewnętrznych specjalistów.
  • Władze zaznaczają, że zakres szkód i ewentualny wyciek danych wciąż jest ustalany (brak wiążących publicznych informacji o skali eksfiltracji).
  • W sprawę zaangażowano Federal Bureau of Investigation.

Kontekst / historia / powiązania

Incydenty ransomware w administracji publicznej są trudne z dwóch powodów:

  1. wysoka wrażliwość danych (mieszkańcy, podatki, świadczenia, sprawy urzędowe),
  2. zależność od usług cyfrowych (telefonia, obieg dokumentów, systemy zgłoszeń).

W New Britain komunikacja władz wskazuje na równoległe prowadzenie dwóch strumieni prac: przywracanie usług oraz dochodzenie (ustalenie wektora wejścia, zakresu kompromitacji, ewentualnej kradzieży danych). To standard w dojrzałym IR – odtworzenie „na siłę” bez zrozumienia źródła incydentu często kończy się reinfekcją.

Analiza techniczna / szczegóły luki

Na dziś publicznie dostępne informacje (z komunikacji miasta i relacji medialnych) potwierdzają ransomware oraz zakłócenia usług – bez ujawnienia nazwy grupy, wykorzystanej podatności czy poziomu dostępu napastników.

W takich zdarzeniach w samorządach najczęściej spotyka się kilka wzorców (poniższe punkty to typowe scenariusze, a nie potwierdzone dla New Britain):

  • Kradzież poświadczeń (phishing, password spraying, wycieki haseł) i wejście przez VPN/RDP lub usługi zdalne.
  • Eksploatacja podatnych urządzeń brzegowych (firewall/VPN, serwery dostępu, systemy pocztowe).
  • Ruch boczny i eskalacja uprawnień (np. przejęcie kontrolera domeny), a następnie masowe szyfrowanie.
  • Coraz częściej: podwójne wymuszenie – szyfrowanie + eksfiltracja, co podnosi presję negocjacyjną. (To powszechny trend opisywany w materiałach rządowych dot. ransomware).

W praktyce, dopóki nie ma publicznego raportu powłamaniowego (albo chociaż IoC/TTP), kluczowe jest podejście „assume breach” podczas przywracania środowiska: odtwarzać usługi warstwowo, z segmentacją i dodatkowymi kontrolami.

Praktyczne konsekwencje / ryzyko

Nawet jeśli „dla mieszkańców” zakłócenia są minimalne, ryzyko operacyjne może być istotne:

  • Przestoje usług: ograniczona łączność i systemy obsługi spraw wydłużają czas realizacji procesów.
  • Ryzyko wycieku danych: przy ransomware nie można zakładać, że skończyło się na szyfrowaniu – brak potwierdzenia eksfiltracji to nie to samo co jej brak.
  • Koszty odtworzeniowe: forensics, wymiana/rekonfiguracja infrastruktury, nadgodziny, komunikacja kryzysowa.
  • Ryzyko wtórne: oszustwa i phishing „na incydent” (podszywanie się pod urząd, zmianę numerów kont, dopłaty, itp.) – klasyczny efekt uboczny głośnych incydentów w sektorze publicznym.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które wprost wynikają z oficjalnych checklist i zaleceń rządowych dla ransomware – przydatne zarówno w trakcie incydentu, jak i po nim.

1) Natychmiastowe kroki IR (0–72h)

  • Izolacja zainfekowanych segmentów / hostów, wstrzymanie „niepewnych” kanałów zdalnych, kontrola kont uprzywilejowanych.
  • Zabezpieczenie dowodów (obrazy dysków, logi, EDR) zanim środowisko zostanie „wyczyszczone”.
  • Praca według checklisty reakcji na ransomware (#StopRansomware) – to pomaga nie pominąć krytycznych etapów (triage → containment → eradication → recovery → lessons learned).

2) Zgłoszenia i współpraca z organami

  • Zgłaszanie incydentów do organów właściwych: kontakt z lokalnym biurem FBI Internet Crime Complaint Center i egzekwowaniem prawa jest rekomendowany wprost przez FBI.
  • W modelu USA często dochodzi też współpraca z Cybersecurity and Infrastructure Security Agency oraz partnerami stanowymi; miasto wskazało wsparcie służb stanowych i federalnych.

3) Odtwarzanie usług „bezpiecznie, nie tylko szybko”

  • Odtwarzaj z kopii offline/immutable, uprzednio skanowanych pod kątem malware (żeby nie odtworzyć infekcji).
  • Wymuś reset poświadczeń (priorytet: konta uprzywilejowane), włącz MFA wszędzie, gdzie to możliwe.
  • Przywracaj krytyczne usługi w odseparowanych strefach (segmentacja), z tymczasowo zaostrzonym monitoringiem.

4) Utwardzenie po incydencie (2–8 tygodni)

  • Segmentacja sieci (oddzielenie stacji roboczych, serwerów, OT/SCADA, kopii zapasowych).
  • Minimalizacja uprawnień i twarde zasady dla adminów (PAW, oddzielne konta, JIT/JEA).
  • Zbieranie i korelacja logów (SIEM), telemetria EDR, retencja logów do celów forensics.
  • Ćwiczenia tabletop + testy odtwarzania (DR) – w samorządach to często najsłabsze ogniwo, a najszybszy „boost” odporności.

Ważne: FBI konsekwentnie podkreśla, że płacenie okupu nie daje gwarancji odzyskania danych i wzmacnia model przestępczy. W praktyce decyzje są złożone, ale warto opierać je o ryzyko, prawo, ubezpieczenie i twarde dane z forensics – nie o presję czasu.

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

W komunikacji New Britain widać element, który odróżnia część dojrzałych reakcji od „chaotycznego recovery”: nacisk na równoległe dochodzenie i ostrożność w formułowaniu wniosków co do zakresu incydentu.

Typowa różnica między incydentami o małej i dużej skali to:

  • czy doszło tylko do szyfrowania ograniczonego segmentu,
  • czy napastnicy osiągnęli domenę/backup i wykonali eksfiltrację,
  • jak szybko organizacja potrafi odtworzyć usługi z kopii odpornych na modyfikację.

Na dziś – bez publicznych IoC i bez informacji o grupie – nie da się wiarygodnie sklasyfikować zdarzenia w New Britain do konkretnego „klastra” kampanii.

Podsumowanie / kluczowe wnioski

  • Incydent w New Britain to potwierdzony przypadek ransomware z zauważalnym wpływem na systemy urzędu, przy deklarowanym utrzymaniu działania usług bezpieczeństwa publicznego.
  • Kluczowa niewiadoma to zakres kompromitacji i ewentualna kradzież danych – miasto sygnalizuje, że ustalenia trwają.
  • Dla samorządów najważniejsze „lekcje” są powtarzalne: odporne kopie (offline/immutable), segmentacja, MFA, monitoring oraz ćwiczenia IR/DR zgodnie z checklistami CISA/FBI.

Źródła / bibliografia

  1. CT Insider – informacje o incydencie i działaniach miasta. (CT Insider)
  2. WFSB – potwierdzenie charakteru ataku i kontekstu operacyjnego. (https://www.wfsb.com)
  3. Cybersecurity and Infrastructure Security Agency – #StopRansomware Guide / checklisty reakcji. (cisa.gov)
  4. Federal Bureau of Investigation – strona informacyjna o ransomware i raportowaniu. (Federal Bureau of Investigation)
  5. FBI Internet Crime Complaint Center – zalecenia dot. reakcji (w tym stanowisko ws. płacenia okupu). (Internet Crime Complaint Center)

Mandiant: ShinyHunters eskalują vishing i „kradzież MFA”, by przejmować SSO i okradać SaaS z danych

Wprowadzenie do problemu / definicja luki

Opisany przez Mandiant przypadek nie dotyczy „magicznej” podatności w chmurze ani błędu w samych platformach SaaS. To klasyczna, ale coraz lepiej „uzbrajana” socjotechnika: vishing (voice phishing) + strony podszywające się pod firmowe portale logowania, które wyciągają od ofiary jednocześnie hasło/SSO i kody MFA lub doprowadzają do zarejestrowania nowego urządzenia MFA kontrolowanego przez atakującego.

Atak działa, bo „człowiek w pętli” potrafi zatwierdzić wszystko, jeśli uwierzy, że rozmawia z IT/Helpdeskiem — a nowa generacja phishing kitów potrafi w czasie rzeczywistym dopasować to, co widzi ofiara w przeglądarce, do scenariusza rozmowy.

W skrócie

  • Google Threat Intelligence Group śledzi aktywność pod kilkoma klastrami: UNC6661, UNC6671 oraz UNC6240 (powiązywany z marką ShinyHunters).
  • Kampanie (wczesny–połowa stycznia 2026) polegają na podszywaniu się pod IT i kierowaniu pracowników na „victim-branded” strony kradnące SSO/MFA.
  • Po wejściu do środowiska atakujący „pivotują” do aplikacji SaaS i masowo wyciągają dane (m.in. dokumenty i komunikację), a następnie przechodzą do wymuszeń/ekstorsji.
  • Kluczowy wniosek obronny: MFA odporne na phishing (FIDO2/passkeys/FastPass) znacząco ogranicza skuteczność tego modelu ataku.

Kontekst / historia / powiązania

Wg Mandiant obserwujemy „rozszerzenie i eskalację” taktyk kojarzonych z wymuszeniami ShinyHunters: rośnie zakres atakowanych platform chmurowych, a presja na ofiarę obejmuje nie tylko e-maile z żądaniem okupu, ale też nękanie personelu i (w niektórych przypadkach) elementy presji operacyjnej.

Ważne jest też rozdzielenie „marki” od wykonawców: GTIG podkreśla, że śledzi aktywność jako kilka klastrów m.in. po to, by uwzględnić różne partnerstwa i możliwość podszywania się pod wcześniej znane TTP.

Równolegle Okta opisuje ewolucję phishing kitów „pod rozmowę telefoniczną” (vishing), które realnie zwiększają skalę tego typu ataków, bo pozwalają atakującemu sterować przebiegiem logowania ofiary niemal jak operatorem „z pulpitu”.

Analiza techniczna / szczegóły luki

1) Łańcuch ataku (high level)

  1. Recon + wybór celu (użytkownicy, aplikacje, numery infolinii/IT).
  2. Vishing: telefon „z IT” z pretekstem aktualizacji ustawień MFA / bezpieczeństwa.
  3. Victim-branded phishing: ofiara trafia na stronę przypominającą firmowy portal i wpisuje dane.
  4. Synchronizacja w czasie rzeczywistym: atakujący na bieżąco wprowadza przechwycone dane do prawdziwego loginu, wywołuje wyzwania MFA i instruuje ofiarę, co ma zatwierdzić/wpisać.
  5. Utrwalenie: rejestracja urządzenia MFA kontrolowanego przez atakującego lub przejęcie sesji/OAuth.
  6. Drenaż SaaS: dostęp do danych zależny od uprawnień skompromitowanej sesji SSO (często oportunistycznie).
  7. Ekstorsja: żądanie okupu, groźby publikacji, dowody kradzieży danych.

2) Klastry i różnice w TTP

  • UNC6661: wczesny–połowa stycznia 2026; domeny phishingowe często w formacie <companyname>sso.com / <companyname>internal.com; rejestracje często u NICENIC; widoczny „post-exploitation” w SaaS oraz przypadki wykorzystania przejętej poczty do dalszego phishingu (np. do podmiotów z branży kryptowalut).
  • UNC6671: podobny model vishing + „victim-branded” strony, ale domeny częściej rejestrowane przez Tucows; dodatkowo Mandiant widział użycie PowerShell do pobierania wrażliwych danych z SharePoint i OneDrive; ekstorsja bywała niebrandowana i z innym Tox ID, a nękanie personelu pojawiało się jako element presji.

3) Co konkretnie jest celem w SaaS?

Mandiant opisuje wykradanie danych i komunikacji z różnych usług SaaS (w przykładach i logach pojawiają się m.in. ekosystem Microsoft 365, Salesforce oraz DocuSign). W części przypadków atakujący wykonywali też wyszukiwania pod kątem „cennych słów kluczowych” (np. „confidential”, „proposal”, „vpn”), co sugeruje selekcję danych pod presję/ekstorsję.

4) Maskowanie śladów i „living off the land”

Ciekawy detal operacyjny: w co najmniej jednym incydencie, po przejęciu konta klienta Okta, atakujący autoryzował dodatek ToogleBox Recall w Google Workspace i usuwał wiadomości mogące ujawnić rejestrację nowego sposobu MFA („Security method enrolled”). To typowy przykład „ciszy po zalogowaniu” zamiast klasycznego malware.

Praktyczne konsekwencje / ryzyko

  • To nie jest „zwykły phishing”: prawdziwym przełomem jest sterowanie sesją ofiary w czasie rzeczywistym, co zwiększa skuteczność nawet przeciwko „lepszemu MFA”, jeśli nie jest ono phishing-resistant.
  • Ryzyko eskalacji przez SSO: pojedyncza udana rozmowa + SSO potrafią dać „szeroki wachlarz” aplikacji do przeszukania i eksportu danych.
  • Ekstorsja bez ransomware: model „data theft + szantaż” omija część klasycznych zabezpieczeń endpointowych, a presja czasu (np. ultimatum 72h w opisywanych przypadkach) wymusza szybkie decyzje kryzysowe.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz” wprost pod ten typ kampanii (priorytetyzacja zgodna z rekomendacjami Mandiant + wnioskami Okta):

1) Natychmiastowe działania (containment)

  • Odwołaj aktywne sesje i tokeny: wymuś wylogowanie, unieważnij tokeny sesyjne i autoryzacje OAuth w IdP oraz kluczowych SaaS.
  • Zablokuj operacje wysokiego ryzyka: ogranicz (czasowo lub politykami) reset haseł, rejestrację nowych urządzeń MFA i zmiany metod MFA — to dokładnie te procesy, które vishing „podrabia”.
  • Przejrzyj rejestracje urządzeń/MFA i uprawnienia adminów w IdP (szczególnie niespodziewane przypisanie ról, anomalie geolokacji, logowania z sieci anonimizujących).

2) Utwardzenie (hardening) pod vishing

  • Wymuś phishing-resistant MFA: FIDO2/passkeys lub rozwiązania typu FastPass (tam, gdzie to ma sens). Push/SMS/OTP są podatne na „przegadanie” ofiary przez telefon.
  • Zasady sieciowe i strefy zaufania: tam gdzie możliwe, ogranicz logowania i akcje administracyjne do znanych lokalizacji/stref (allowlist), a ruch z usług anonimizujących traktuj jako sygnał do polowania (hunting), niekoniecznie automatycznego blokowania „w ciemno”.
  • Proces „call-back” dla IT: jeśli pracownik dostaje telefon „z IT”, powinien oddzwonić na numer z firmowej książki/portalu, nie na numer z wyświetlacza. To proste, ale nadal ekstremalnie skuteczne przeciw vishingowi (a często pomijane).

3) Detekcja i monitoring (SOC)

  • Poluj na wzorce: „MFA device enrolled”, nietypowe logowania do konsoli admina IdP, masowe pobrania z SharePoint / OneDrive, użycie PowerShell do pobierania plików, autoryzacje podejrzanych aplikacji OAuth (np. ToogleBox Recall).
  • Kontrola domen podobnych do marki: rejestracje w stylu my<company>sso[.]com, <company>support[.]com, <company>okta[.]com, literówki typu acess.
  • Zweryfikuj, czy Twoje alerty obejmują nietypowe wolumeny pobrań i wyszukiwania po „wrażliwych słowach” w SaaS.

Różnice / porównania z innymi przypadkami

  • „MFA fatigue” vs. „MFA steering”: tu nie chodzi o zalewanie pushami aż ofiara kliknie — chodzi o pełną reżyserię logowania, gdzie kit phishingowy zmienia ekrany w idealnym tempie pod rozmowę. To jakościowo inny poziom „wiarygodności” ataku.
  • Ransomware niepotrzebne: jeżeli organizacja ma dojrzałe backupy i EDR, atakujący nadal może wygrać, kradnąc dane z SaaS i stosując presję reputacyjną/prawną.
  • Brak CVE jako „punktu wejścia”: to kampania oparta o procesy (helpdesk, reset MFA) i zachowania ludzi, dlatego testy podatności aplikacji nie wystarczą — potrzebne są ćwiczenia i polityki IAM.

Podsumowanie / kluczowe wnioski

  1. Kampanie przypisywane klastrom powiązanym z marką ShinyHunters pokazują, że vishing stał się pełnoprawnym wektorem initial access do SSO i SaaS — często skuteczniejszym niż klasyczny e-mailowy phishing.
  2. „Zwykłe MFA” nie wystarcza, jeśli nie jest odporne na phishing: FIDO2/passkeys/FastPass realnie podnoszą poprzeczkę.
  3. Obrona musi koncentrować się na sesjach, tokenach, rejestracji urządzeń MFA, logowaniu i detekcji anomalii w SaaS — a nie na poszukiwaniu „jednej podatności”.

Źródła / bibliografia

  • Mandiant – „Vishing for Access: Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft” (30 stycznia 2026). (Google Cloud)
  • Mandiant – „Proactive Defense Against ShinyHunters-Branded Data Theft Targeting SaaS” (30 stycznia 2026). (Google Cloud)
  • Okta – „Phishing kits adapt to the script of callers” (22 stycznia 2026). (Okta)
  • BleepingComputer – omówienie kampanii i wątków dot. vishing + MFA/SSO (31 stycznia 2026). (BleepingComputer)
  • The Hacker News – streszczenie ustaleń Mandiant (31 stycznia 2026). (The Hacker News)

Coupang: policja przesłuchuje p.o. CEO w śledztwie po wycieku danych — w tle zarzuty utrudniania dochodzenia

Wprowadzenie do problemu / definicja luki

Sprawa wycieku danych w Coupang pokazuje dwa równoległe ryzyka, które coraz częściej splatają się w incydentach cyber: (1) sam incydent naruszenia poufności danych oraz (2) ryzyko „post-incident”, czyli błędy w obsłudze dowodów, logów i komunikacji z organami nadzoru/ścigania.

Według doniesień medialnych południowokoreańska policja przesłuchiwała p.o. CEO firmy, Harold Rogers, w ramach dochodzenia dotyczącego możliwego utrudniania państwowego śledztwa po masowym naruszeniu danych ujawnionym publicznie w listopadzie.

W skrócie

  • Skala incydentu jest raportowana na poziomie ok. 33,7 mln kont klientów; ujawnione dane miały obejmować m.in. identyfikatory i dane kontaktowe oraz wybrane informacje o zamówieniach (bez danych kart i bez haseł/logowania — wg komunikacji firmy przytaczanej przez media).
  • Policja bada podejrzenia manipulacji lub ukrywania dowodów w toku wewnętrznego dochodzenia i współpracy z organami.
  • Wątek dowodowy koncentruje się m.in. na laptopie powiązanym ze sprawą oraz na tym, czy i jak firma prowadziła własną analizę forensyczną przed/obok działań organów.
  • Media w South Korea informowały o wielogodzinnym przesłuchaniu oraz o rozbieżnościach między szacunkami władz a wynikami „samodzielnego” dochodzenia firmy (np. liczba 3 tys. vs dziesiątki milionów).

Kontekst / historia / powiązania

Kluczowa oś czasu (na podstawie relacji cytowanych przez media):

  • Czerwiec (rok poprzedzający ujawnienie): naruszenie miało rozpocząć się wcześniej niż moment jego wykrycia/ujawnienia (media wskazują na czerwiec jako potencjalny start).
  • Listopad: sprawa wycieku danych została upubliczniona; od tego czasu narasta presja regulacyjna i reputacyjna.
  • Grudzień: policja uruchamia dedykowane działania/TF; w tle pojawiają się doniesienia o pozyskiwaniu i zabezpieczaniu nośników (w tym laptopa).
  • Styczeń: przesłuchania kierownictwa i spór o rzetelność i wpływ wewnętrznego dochodzenia na śledztwo.

Dodatkowym, wrażliwym kontekstem jest komponent „governance”: czy organizacja podjęła działania, które mogły utrudniać postępowanie (np. brak pełnej transparentności co do tego, jakie analizy zostały wykonane na kluczowym nośniku i kiedy).

Analiza techniczna / szczegóły luki

Z publicznie dostępnych informacji (na dziś) wynika, że rdzeń incydentu dotyczył wycieku danych klientów na masową skalę. Media cytujące ustalenia/komunikaty wskazują, że miały wyciec m.in.:

  • imiona i nazwiska,
  • adresy e-mail,
  • numery telefonów,
  • adresy dostaw,
  • wybrane elementy historii zamówień.

Wątek, który czyni tę sprawę szczególnie istotną dla praktyków IR/DFIR, to kontrowersje wokół postępowania z dowodami:

  • Organy miały badać, czy firma kontaktowała się z podejrzewaną osobą i prowadziła własną analizę forensyczną nośnika bez konsultacji z prowadzącymi sprawę, a następnie przekazała sprzęt policji bez ujawnienia pełnego kontekstu działań.
  • W relacjach prasowych pojawia się również opis odzyskania uszkodzonego laptopa z rzeki, co sugeruje możliwą próbę fizycznego zniszczenia materiału dowodowego (to istotne, bo nawet „smashed” sprzęt bywa częściowo odzyskiwalny, ale łańcuch dowodowy staje się krytyczny).

Warto podkreślić: na tym etapie doniesienia koncentrują się bardziej na procesie obsługi incydentu i dowodów (obstruction/evidence handling) niż na pełnym, publicznym opisie wektora ataku (np. exploit, malware, błąd konfiguracyjny).

Praktyczne konsekwencje / ryzyko

Dla użytkowników i organizacji podobnych do Coupang realne skutki są wielowarstwowe:

  1. Ryzyko nadużyć tożsamości i phishingu
    Zestawy danych typu: imię/nazwisko + e-mail + telefon + adres + historia zamówień są paliwem dla ataków dopasowanych (spear phishing, smishing, vishing) i oszustw logistycznych („dopłata do przesyłki”, „weryfikacja adresu”).
  2. Ryzyko prawne i regulacyjne
    Nawet jeśli wrażliwe dane płatnicze nie wyciekły, skala naruszenia i sposób reakcji mogą prowadzić do dotkliwych konsekwencji finansowych i nadzorczych. Reuters wskazuje też na możliwość wysokich kar w reżimie lokalnym oraz presję polityczną na zaostrzenie podejścia do zaniedbań.
  3. Ryzyko „secondary incident” w organizacji
    Gdy pojawiają się zarzuty dot. niszczenia/ukrywania dowodów, organizacja wchodzi na pole wysokiego ryzyka: utrata wiarygodności, utrudnione negocjacje z regulatorami, większa skłonność organów do środków przymusu (przeszukania, zabezpieczenia), a także dług techniczny w obszarze logowania i retencji.

Rekomendacje operacyjne / co zrobić teraz

Jeśli prowadzisz SOC/CSIRT, bezpieczeństwo aplikacji albo compliance, ta sprawa jest dobrą checklistą „czego nie przegapić” po incydencie:

  1. Legal hold + twarda retencja logów od pierwszej minuty
    Natychmiastowe wstrzymanie rotacji/retencji dla logów krytycznych (IAM, API gateway, WAF, CDN, DB audit, systemy zamówień, narzędzia CI/CD, EDR). Zrób to formalnie (ticket + zatwierdzenie + ślad audytowy).
  2. Zarządzanie dowodami jak projektem forensycznym, nie jak „IT taskiem”
    • łańcuch dowodowy (chain of custody),
    • izolacja nośników i obrazowanie (bit-by-bit),
    • kontrola dostępu do artefaktów,
    • dziennik działań (kto/co/kiedy).
      Kontrowersje w tej sprawie pokazują, że „wewnętrzne śledztwo” bez rygoru DFIR może stać się problemem samym w sobie.
  3. Rozdziel role: komunikacja kryzysowa ≠ analiza techniczna ≠ relacje z organami
    W praktyce potrzebujesz „incident commander”, niezależnego DFIR lead oraz osoby odpowiedzialnej za interfejs prawny/regulacyjny.
  4. Transparentne, weryfikowalne szacunki skali
    Rozbieżności typu „3 tys. kont” vs „dziesiątki milionów” niszczą zaufanie i podbijają koszty (kary, pozwy, odpływ klientów). Jeśli nie wiesz — komunikuj przedziały i metodologię.
  5. Monitoring nadużyć po stronie klientów
    Wymuś/zalecaj MFA, wykrywanie logowań anomalii, alerty o zmianie adresu dostawy, mechanizmy anty-ATO (account takeover). Nawet bez wycieku haseł, dane kontaktowe + OSINT dają atakującym przewagę.

Różnice / porównania z innymi przypadkami

W wielu wyciekach największym problemem jest sam wektor ataku. Tu równie istotny jest „drugi akt”: obsługa incydentu i dowodów. To różnica, która często decyduje o:

  • skali kar i środków nadzorczych,
  • tempie zamknięcia sprawy,
  • możliwości przypisania winy,
  • wiarygodności organizacji wobec klientów i regulatora.

Podsumowanie / kluczowe wnioski

  • Sprawa Coupang jest przykładem incydentu, w którym ryzyko prawne i reputacyjne może zostać spotęgowane przez nieprawidłową obsługę dowodów.
  • Przy wyciekach na poziomie dziesiątek milionów rekordów sama kontrola szkód nie wystarczy — liczy się proces: retencja logów, łańcuch dowodowy, niezależna forensyka i spójna komunikacja.
  • Dla zespołów bezpieczeństwa to mocny argument, by mieć gotowe procedury DFIR „na papierze” (i przećwiczone), zanim wydarzy się incydent.

Źródła / bibliografia

  • The Record (Recorded Future News) — opis przesłuchania i wątku potencjalnego ukrywania/niszczenia dowodów. (The Record from Recorded Future)
  • Reuters — kontekst skali wycieku, zakres ujawnionych danych, tło regulacyjne. (Reuters)
  • KBS World — streszczenie zarzutów dot. utrudniania dochodzenia i wewnętrznego „self-probe”. (world.kbs.co.kr)
  • The Korea Times — szczegóły dot. przesłuchania (czas, wątki dowodowe, rozbieżności w liczbach). (The Korea Times)
  • Korea JoongAng Daily — potwierdzenie kluczowych elementów relacji (12 godzin, 2:22 a.m., wątki laptopa i wewnętrznej analizy). (Korea Joongang Daily)

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)

Łotwa: Rosja nadal największym zagrożeniem cybernetycznym — rekord ataków i rosnące ryzyko dla OT/ICS

Wprowadzenie do problemu / definicja luki

Łotewskie służby i zespoły reagowania na incydenty sygnalizują, że presja ze strony Rosji w cyberprzestrzeni nie słabnie, a 2025 r. przyniósł rekordowy poziom zarejestrowanych zagrożeń. Problem nie dotyczy „jednej luki CVE”, lecz systematycznej kampanii łączącej cyberataki (DDoS, włamania, malware), działania o charakterze sabotażowym oraz presję psychologiczną i polityczną — szczególnie w okresach „wrażliwych” decyzji publicznych.

Istotnym elementem ostrzeżeń jest rosnąca ekspozycja systemów OT/ICS (Operational Technology / Industrial Control Systems) w sektorach energii, wody i transportu — środowisk, w których zaległości w segmentacji, monitoringu i zarządzaniu poprawkami bywają normą, a skutki incydentu mogą wyjść poza IT i uderzyć w usługi krytyczne.

W skrócie

  • Rosja pozostaje głównym źródłem ryzyka dla Łotwy; aktywność ma związek z geopolityką i wsparciem dla Ukrainy.
  • Większość incydentów to cyberprzestępczość i oszustwa, ale występują też poważniejsze zdarzenia: włamania, dystrybucja malware, kompromitacje urządzeń i DDoS.
  • CERT.LV utrzymuje, że od 2022 r. Łotwa obserwuje stały wysoki poziom incydentów (ok. 500–700 kwartalnie); w Q3 2025 odnotowano 671 incydentów.
  • Widać wzrost znaczenia botnetów/IoT i automatycznej eksploatacji podatności, co przekłada się na rosnącą liczbę „skompromitowanych urządzeń”.
  • W tle europejskim utrzymuje się trend, w którym hacktywiści i DDoS stanowią dużą część wolumenu ataków na administrację publiczną (m.in. NoName057(16)).

Kontekst / historia / powiązania

Z perspektywy Łotwy kluczowym punktem odniesienia jest okres po pełnoskalowej inwazji Rosji na Ukrainę (2022), po którym — według CERT.LV — „niska intensywność” przestała być normą, a ryzyko utrzymuje się stale na wysokim poziomie.

SAB (łotewski Constitution Protection Bureau) wskazuje, że Rosja postrzega konfrontację z Zachodem szeroko (globalnie i ideologicznie) i utrzymuje wachlarz narzędzi wpływu, w tym gotowość do działań w cyberprzestrzeni oraz działań sabotażowych. W tym ujęciu cyberataki mają funkcję nie tylko „techniczną”, ale także strategiczno-psychologiczną: testowanie odporności, zastraszanie, karanie za decyzje polityczne.

Analiza techniczna / szczegóły luki

1) Dominujące techniki: od DDoS po kompromitacje i malware

SAB w podsumowaniach (na bazie 2025 r.) wymienia jako najpoważniejsze zdarzenia m.in. intrusion attempts, malware distribution, equipment compromise oraz DDoS.
CERT.LV w Q1 2025 pokazuje strukturę incydentów, gdzie ilościowo dominują oszustwa (fraud), ale w TOP5 pojawiają się też próby włamań, złośliwy kod, skompromitowane urządzenia oraz incydenty dostępności usług.

2) Botnety, IoT i automatyzacja eksploatacji

CERT.LV raportuje, że rośnie liczba skompromitowanych urządzeń i wskazuje na wejście w „nową fazę” zagrożeń: botnety/IoT, malware oraz automatyczne skanowanie i eksploatację podatności. W Q3 2025 zarejestrowano 671 incydentów, a dynamika kompromitacji urządzeń była wyraźnie wzrostowa.

3) Eksploatacja podatności w popularnych produktach

W Q3 2025 CERT.LV odnotowuje aktywne wykorzystywanie krytycznych podatności m.in. w Microsoft SharePoint i WinRAR, a co szczególnie istotne — przynajmniej jeden przypadek kompromitacji wykryto w sektorze infrastruktury krytycznej.

4) OT/ICS jako najbardziej ryzykowny wektor

SAB oraz CERT.LV podkreślają ryzyko dla systemów OT/ICS w sektorach takich jak energia i woda. W praktyce takie środowiska bywają trudniejsze do aktualizacji, słabiej monitorowane, a zarządzanie tożsamością i segmentacją jest często historycznie „długiem technicznym”.

Praktyczne konsekwencje / ryzyko

  1. Zdarzenia masowe bez spektakularnego skutku ≠ brak ryzyka. SAB zaznacza, że wiele incydentów nie powodowało poważnych zakłóceń, ale to nie unieważnia trendu wzrostowego i gotowości przeciwnika do eskalacji.
  2. „Polityczne kalendarze” jako wyzwalacze ataków. Według SAB rosyjskie DDoS-y na instytucje rządowe i samorządy często zgrywają się z wrażliwymi datami/decyzjami; jako przykład podano silny atak po ogłoszeniu wyniku międzynarodowego kontraktu dronowego (lipiec).
  3. Ryzyko ciągłości działania w administracji i usługach publicznych. ENISA dla sektora administracji publicznej w UE opisuje krajobraz, w którym DDoS stanowi znaczną część incydentów, a aktywność hacktywistów (napędzana m.in. wojną) utrzymuje się na wysokim poziomie — co dobrze „skaluje się” do doświadczeń Łotwy jako państwa frontowego w domenie hybrydowej.
  4. Najgroźniejszy scenariusz: OT/ICS. Krótkotrwałe zakłócenia w OT (energia/woda/transport) mogą mieć efekt kaskadowy: przerwy w usługach, koszty operacyjne, presja polityczna i spadek zaufania społecznego. SAB wprost wskazuje gotowość rosyjskich aktorów do ataków na systemy przemysłowe, co zwiększa wagę prewencji.

Rekomendacje operacyjne / co zrobić teraz

Dla IT (administracja, samorządy, instytucje publiczne)

  • Higiena podatności i aktualizacji: twarde SLA na łatki dla systemów wystawionych do Internetu (szczególnie platformy współdzielenia treści/portale).
  • Odporność na DDoS: CDN/WAF, rate-limiting, geofencing tam, gdzie uzasadnione, scenariusze przełączeń i testy „na zimno”.
  • MFA i twarde zasady dostępu: warunkowy dostęp, ograniczenie kont uprzywilejowanych, rozdział ról, logowanie i alertowanie na anomalie.
  • Kopie zapasowe + test odtwarzania: szczególnie pod kątem ransomware i kompromitacji usług krytycznych w administracji.

Dla OT/ICS (energia, woda, ciepłownictwo, transport)

  • Segmentacja IT/OT i minimalizacja ekspozycji: separacja stref, brak „płaskich” sieci, kontrola zdalnego dostępu (jump host, MFA, rejestrowanie sesji).
  • Monitorowanie specyficzne dla OT: detekcja anomalii protokołów przemysłowych, widoczność zasobów i zależności.
  • Zarządzanie podatnościami w OT: tam, gdzie nie da się łatkować szybko — kompensacje (reguły firewall, allow-listing, izolacja usług).
  • Ćwiczenia IR „end-to-end”: scenariusze DDoS + próba wejścia + incydent w OT (wspólny playbook IT/OT).

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

Łotwa wyróżnia się ciągłym, wysokim tłem zagrożeń oraz naciskiem na komponent państwowo-geopolityczny (Rosja jako główne źródło ryzyka).
Jednocześnie wektor „wolumenowy” (DDoS/hacktywizm) wpisuje się w obserwacje ENISA dla administracji publicznej w UE: duży udział ataków zakłócających dostępność i kampanii napędzanych wydarzeniami geopolitycznymi, z rozpoznawalnymi grupami pokroju NoName057(16).

Podsumowanie / kluczowe wnioski

  • 2025 r. to dla Łotwy rekord zarejestrowanych zagrożeń, a Rosja pozostaje głównym źródłem presji w cyberprzestrzeni.
  • Statystyki CERT.LV pokazują stabilnie wysoki poziom incydentów od 2022 r. i rosnącą wagę botnetów/IoT oraz automatycznej eksploatacji podatności.
  • Kluczowe ryzyko strategiczne przesuwa się w stronę OT/ICS, gdzie „krótkie zakłócenie” może stać się realnym problemem dla usług krytycznych.
  • Dla organizacji publicznych i operatorów infrastruktury krytycznej priorytetem powinny być: patching, odporność na DDoS, segmentacja IT/OT oraz dojrzały IR.

Źródła / bibliografia

  1. The Record (Recorded Future News): materiał o ostrzeżeniach SAB i rekordzie zagrożeń w 2025 r. (The Record from Recorded Future)
  2. SAB — Annual Report 2025 (ENG), unclassified part.
  3. CERT.LV: Latvian Cyberspace Situation Q3 2025.
  4. CERT.LV: The situation in Latvian cyberspace Q1 2025. (cert.lv)
  5. ENISA: Sectorial Threat Landscape – Public Administration (2024 data). (ENISA)

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)