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

Tag: Phishing

Cyber Advisory Sophos: wzrost ryzyka cyberataków w cieniu eskalacji USA–Izrael–Iran (marzec 2026)

Wprowadzenie do problemu / definicja „luki”

W okresach gwałtownej eskalacji militarnej rośnie nie tylko ryzyko klasycznych operacji państwowych (APT), ale też „szumu” generowanego przez grupy ideologiczne i persony podszywające się pod hacktywistów. Sophos X-Ops (Counter Threat Unit) opisuje bieżącą sytuację jako Threat Level: Elevated oraz wskazuje, że główne okno ryzyka to dni–tygodnie, a najbardziej prawdopodobne są działania zakłócające, oportunistyczne i wpływowe (influence-oriented).

W praktyce nie chodzi o jedną „lukę” w sensie CVE, tylko o moment podwyższonej podatności organizacji na kombinację: presji czasu, przeciążenia SOC, kampanii phishingowych pod newsy dnia, działań DDoS oraz prób niszczenia danych (wiper) maskowanych jako ransomware.

W skrócie

  • Sophos ocenia ryzyko jako podniesione i wskazuje na możliwe uderzenia w: administrację, sektor finansowy, podmioty „defense-adjacent” oraz infrastrukturę krytyczną.
  • SentinelOne zakłada wzrost aktywności irańskich aktorów państwowych i proxy (od rozpoznania po działania destrukcyjne i wpływowe), nawet jeśli w momencie publikacji nie przypisał jeszcze dużych incydentów bezpośrednio do tych wydarzeń.
  • Check Point opisuje m.in. Agrius (MOIS-linked) i jego playbook: wipery / „fake ransomware”, web-serwery jako wektor wejścia, webshell (ASPX), LOLBins, narzędzia tunelujące i rekonesans.
  • Agencje USA (NSA/CISA/FBI/DC3) przypominają, że irańscy aktorzy (w tym „hacktiviści”) często biorą na cel słabo zabezpieczone, wystawione do internetu systemy, wykorzystują niezałatane podatności oraz domyślne/pospolite hasła.
  • Reuters raportuje już pierwszą falę cyberoperacji towarzyszących uderzeniom kinetycznym (m.in. kompromitacje serwisów i aplikacji) oraz oczekiwanie na możliwy odwet w cyberprzestrzeni.

Kontekst / historia / powiązania

Sophos podkreśla, że irańskie operacje często korzystają z proxy grup i person, które biorą na siebie „odpowiedzialność” medialną. W advisory padają przykłady: HomeLand Justice (kojarzona z wiperami i „hack-and-leak” przeciw Albanii od 2022) oraz Handala Hack (persona łączona z MOIS, skłonna do gróźb, czasem do realnych kradzieży danych i wiperów).

Równolegle media opisują cyberoperacje wymierzone w irańskie zasoby (np. włamania do serwisów i aplikacji), co może działać jak „iskra” do działań odwetowych lub kampanii wpływu. To ważne, bo cyber w takich momentach bywa jednocześnie narzędziem presji i propagandy.

Analiza techniczna / szczegóły (TTP), których należy się spodziewać

1) „Szybkie” zakłócenia: DDoS, defacement, przejęcia kont

Najbardziej „dostępne” i widoczne techniki, które zwykle eskalują w pierwszej fazie, to: DDoS, defacement oraz kompromitacje kont (np. przez password spraying / phishing). Sophos wymienia te kategorie wprost jako prawdopodobny zestaw działań.

2) Destrukcja danych: wipery i „fake ransomware”

SentinelOne i Sophos wskazują na możliwość użycia wiper malware (niszczenie danych) oraz na trend maskowania destrukcji jako „ransomware”. Check Point opisuje to bardzo konkretnie w kontekście Agrius: wipery/fake-ransomware, webshell (ASPX), a potem egzekucja przy użyciu LOLBins i automatyzacji (np. zadania harmonogramu).

3) Wejście przez „internet-facing”: VPN, web-serwery, usługi zewnętrzne

Wspólny mianownik w zaleceniach to redukcja ekspozycji: patching i przegląd powierzchni ataku. Agencje USA akcentują typowy pattern: niezałatane systemy i słabe hasła na urządzeniach/usługach dostępnych z internetu.

4) Phishing i kradzież tożsamości jako dźwignia do dalszego ruchu

SentinelOne przewiduje intensyfikację spearphishingu, credential harvestingu oraz nadużyć legalnych narzędzi (PowerShell/script abuse), a Sophos wprost rekomenduje wzmocnienie kontroli IAM i monitoring nietypowych logowań (w tym password spraying).

5) OT/ICS: „nisko-uderzeniowe, wysoko-widoczne” incydenty

SentinelOne przypomina, że w okresach napięć Iran potrafi sięgać po cele w infrastrukturze krytycznej i środowiskach OT/ICS, często w sposób demonstracyjny. Wskazuje też na precedensy związane z systemami przemysłowymi i celowanie w wodociągi/utility.

Praktyczne konsekwencje / ryzyko

Ryzyko nie jest równomierne. Najbardziej narażone są organizacje, które:

  • mają powiązania z sektorem obronnym, administracją, finansami lub infrastrukturą krytyczną (USA/Izrael oraz podmioty sojusznicze),
  • utrzymują duży „zewnętrzny footprint” (VPN-y, bramy OWA/IdP, panele admin, stare aplikacje web),
  • są wrażliwe na przestoje (DDoS) lub mają niski poziom segmentacji (łatwiejsza destrukcja przy wiperach).

Reuters opisuje także element „psyops”: ataki, które jednocześnie zakłócają działanie usług i wstrzykują przekaz. Dla firm oznacza to nie tylko incydent techniczny, ale też kryzys reputacyjny i komunikacyjny.

Rekomendacje operacyjne / co zrobić teraz (checklista „dni–tygodnie”)

Poniżej priorytety zsyntetyzowane z zaleceń Sophos CTU, SentinelOne, Check Point oraz wspólnych wniosków agencji USA:

  1. Tożsamość i dostęp (IAM)
  • Wymuś MFA (preferuj phishing-resistant) na zdalnym dostępie i kontach uprzywilejowanych.
  • Monitoruj password spraying, nietypowe logowania, replay tokenów/sesji.
  1. Redukcja ekspozycji
  • Zrób szybki przegląd internet-facing usług i załatane vs. niezałatane (priorytet: bramy VPN, serwery web, panele zarządzania).
  • Usuń/ogranicz niekrytyczne usługi wystawione do internetu, szczególnie bez MFA.
  1. Gotowość na DDoS i defacement
  • Odśwież playbooki DDoS (contact list do ISP/CDN/WAF, progi eskalacji, procedury failover).
  1. Przygotowanie na wipery / destrukcję
  • Przećwicz scenariusz „data-wipe” (izolacja, triage, odtwarzanie, decyzje biznesowe).
  • Zweryfikuj kopie zapasowe pod kątem immutability i odseparowania od domeny produkcyjnej (to krytyczne przy destrukcji, nie tylko szyfrowaniu). (Wniosek operacyjny oparty o typ ataków wiper/fake-ransomware).
  1. OT/ICS
  • Segmentacja OT, przegląd zdalnych dostępów, skan ekspozycji HMI/PLC, blokada domyślnych haseł.
  1. Influence ops i „fake leaks”
  • Ustal szybki tor weryfikacji „wycieków” i komunikatów (PR + Legal + SOC), bo aktorzy mogą recyklingować stare naruszenia jako „nowe”.

Różnice / porównania z innymi przypadkami

To, co wyróżnia takie okresy napięć, to mieszanka aktorów: obok klasycznych APT pojawia się „hacktivism” (często z elementami państwowego wsparcia lub przynajmniej inspiracji), a cele bywają wybierane oportunistycznie — tam, gdzie najłatwiej o efekt medialny. Sophos i SentinelOne wprost zwracają uwagę na operacje wpływu oraz działania „pod przykrywką” hacktywizmu.

Dodatkowo rośnie ryzyko błędnej atrybucji: presja na szybkie komunikaty + wysyp „brandowanych” person = idealne środowisko do podszywania się pod znane grupy. To ma bezpośrednie znaczenie dla IR (co eskalować jako incydent krytyczny, a co traktować jako szum).

Podsumowanie / kluczowe wnioski

  • Sophos podnosi alert: Elevated, okno dni–tygodnie, a na liście ryzyk dominują DDoS, wipery, hack-and-leak, phishing i ataki na systemy wystawione do internetu.
  • SentinelOne i Check Point dostarczają „mapy playbooków”: od spearphishingu i kradzieży poświadczeń po destrukcję danych i operacje wpływu; szczególnie istotne są techniki LOLBins, webshell, scheduled tasks oraz targetowanie infrastruktury/OT.
  • Największy zwrot z inwestycji „na już” daje: MFA + patching + redukcja ekspozycji + gotowość na destrukcję + procedury DDoS + dyscyplina komunikacyjna.

Źródła / bibliografia

  1. Sophos X-Ops – Cyber Advisory: Increased Cyber Risk Amid U.S.–Israel–Iran Escalation (1 marca 2026). (SOPHOS)
  2. SentinelOne – Intelligence Brief: Iranian Cyber Activity Outlook (28 lutego 2026). (SentinelOne)
  3. Check Point Research – What Defenders Need to Know about Iran’s Cyber Capabilities (1 marca 2026). (Check Point Blog)
  4. NSA – Press release: Iranian cyber actors may target vulnerable US networks (30 czerwca 2025). (National Security Agency)
  5. Reuters – Hackers hit Iranian apps, websites after US-Israeli strikes (1 marca 2026). (Reuters)

Hackers weaponizują Claude Code w ataku na instytucje rządu Meksyku: jak wygląda „agentowy” cyberatak napędzany AI

Wprowadzenie do problemu / definicja „luki”

W opisywanym incydencie nie chodzi o pojedynczą podatność typu CVE w jednym systemie, tylko o zmianę modelu działania atakujących: wykorzystanie narzędzia klasy AI coding assistant (Claude Code) jako „silnika operacyjnego”, który pomaga pisać exploity, budować narzędzia i automatyzować działania po stronie napastnika.

Z perspektywy obrony to przesunięcie jest kluczowe: AI nie musi „wymyślać nowych technik”, żeby radykalnie podnieść skuteczność. Wystarczy, że przyspiesza i ułatwia to, co już znamy (rekonesans, dobór wektorów, składanie łańcuchów, triage danych). Anthropic opisywał ten kierunek jako przejście w stronę agentowości: model wykonuje sekwencje zadań w pętli, z ograniczoną liczbą interwencji człowieka.

W skrócie

Z relacji SecurityWeek, bazującej na ustaleniach izraelskiego startupu Gambit Security, wynika że:

  • skompromitowano 10 podmiotów rządowych w Meksyku oraz instytucję finansową; start miał nastąpić pod koniec grudnia 2025 od zaatakowania administracji skarbowej, a dalej m.in. rejestr cywilny, instytucje zdrowia, organ wyborczy oraz jednostki samorządowe i wodociągi,
  • atakujący miał wysłać do Claude Code ponad 1000 promptów, a do analiz danych miał też wykorzystywać OpenAI GPT-4.1,
  • w ok. miesiąc wyprowadzono ponad 150 GB danych (m.in. rejestry cywilne, podatkowe, dane wyborcze), a w przekazie pojawia się liczba ~195 mln tożsamości jako potencjalnie dotkniętych ekspozycją.

Bloomberg opisywał zdarzenie jako kradzież wrażliwych danych (m.in. podatkowych i wyborczych) z użyciem narzędzi Anthropic.

Kontekst / historia / powiązania

Ten przypadek wpisuje się w szerszy trend: AI jako „akcelerator” kampanii, a nie tylko generator pojedynczych fragmentów kodu.

  • Anthropic już wcześniej opisał kampanię, w której Claude Code był używany w sposób wysoce agentowy (duża część operacji wykonywana przez model, z ograniczoną liczbą „punktów decyzyjnych” człowieka), łącznie z rekonesansem, pisaniem exploitów, pozyskiwaniem poświadczeń i porządkowaniem wykradzionych danych.
  • W raporcie threat-intel Anthropic z 2025 r. pojawia się wątek używania Claude Code do zautomatyzowanych działań ofensywnych określanych jako „vibe hacking” (agent wykonujący kolejne kroki operacyjne).
  • CrowdStrike w materiale do Global Threat Report 2026 wskazuje wzrost aktywności „AI-enabled adversaries” (skok r/r) i opisuje AI jako element przyspieszający rekonesans, kradzież poświadczeń i omijanie zabezpieczeń.

W praktyce oznacza to, że incydent w Meksyku nie jest „ciekawostką”, tylko kolejnym sygnałem, że czas reakcji obrońców (MTTD/MTTR) będzie coraz bardziej ściskany przez automatyzację po stronie ataku.

Analiza techniczna / szczegóły „luki” (jak AI pomogło w ataku)

Na bazie publicznych opisów, sedno nie sprowadza się do jednego magicznego promptu, tylko do pracy w cyklu:

1. Jailbreak i „legalna narracja”

Według relacji SecurityWeek, atakujący miał omijać guardraile, przekonując model, że działania są autoryzowane (np. w ramach testów bezpieczeństwa). To klasyczna technika „policy evasion” oparta o kontekst i role.

2. Rekonesans i priorytetyzacja celów

Model (jako agent) jest szczególnie użyteczny w:

  • szybkim mapowaniu usług/zasobów,
  • wskazywaniu „high-value” baz i repozytoriów danych,
  • podpowiadaniu, gdzie szukać danych wrażliwych i jak je klasyfikować.

Anthropic opisywał ten etap jako automatyczne „inspecting systems” i identyfikację najcenniejszych baz danych, znacznie szybciej niż zrobiłby to zespół ludzi.

3. Łańcuchowanie: exploit → narzędzia → automatyzacja eksfiltracji

SecurityWeek podaje, że AI „pisało exploity, budowało narzędzia i automatyzowało eksfiltrację”.
To ważne, bo w realnych kampaniach najwięcej czasu zajmują zwykle:

  • dopasowanie PoC do środowiska,
  • stabilizacja dostępu i utrzymanie sesji,
  • opakowanie kradzieży danych w skrypty/automaty (chunking, retry, szyfrowanie, omijanie limitów),
  • przygotowanie materiałów dla operatora (listy credentiali, mapy systemów, podsumowania).

Agent AI może tu pełnić rolę „automatycznego inżyniera integracji” — składać elementy i iterować, aż zadziała.

4. „Wielomodelowość” (Claude + GPT-4.1)

Wątek użycia drugiego modelu do analizy danych (GPT-4.1) sugeruje praktykę, która staje się standardem u dojrzałych grup: różne modele do różnych zadań (np. jeden do generowania/pisania, drugi do streszczania/klasyfikacji/wnioskowania).

Praktyczne konsekwencje / ryzyko

Największe ryzyka dla organizacji (nie tylko rządowych) to:

  • Kompresja kill chain: mniej „przestojów” po stronie ataku, więcej iteracji w krótszym czasie (rekonesans, dopasowanie technik, automatyzacja działań). Trend wzrostu aktywności grup używających AI podkreślają też raporty rynkowe.
  • Skala i równoległość: agent może „przerabiać” wiele wątków jednocześnie (analiza logów, przygotowanie exploitów, playbooki eksfiltracji).
  • Niższy próg wejścia: AI redukuje wymagany poziom umiejętności w obszarach, które dotąd były barierą (debug exploitów, skrypty do data-miningu, automatyzacja).
  • Ryzyko wtórne po wycieku: kradzież tożsamości, spear-phishing na masową skalę, przejmowanie kont (zwłaszcza gdy dane zawierają identyfikatory i elementy KYC), presja reputacyjna, koszty odtworzenia usług.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie „dokręcają śrubę” w scenariuszu ataków przyspieszanych AI:

1. Ogranicz powierzchnię i uczyń eksfiltrację trudną

  • Segmentacja danych (rejestry/PII/finanse) + restrykcje egress (proxy, allow-listy, DLP tam gdzie ma sens).
  • Monitorowanie anomalii transferu (nietypowe wolumeny, nietypowe godziny, nowe destynacje).
  • Tokenizacja/format-preserving encryption dla krytycznych identyfikatorów tam, gdzie to możliwe.

2. Detekcja „szybkiego ruchu” po uzyskaniu dostępu

Skoro łańcuch jest kompresowany, priorytetem jest wykrywanie:

  • nietypowych wywołań narzędzi administracyjnych,
  • tworzenia kont uprzywilejowanych,
  • masowych odczytów z baz i eksportów,
  • nietypowych zapytań (burst query, enumeracje, skoki po tabelach).

3. Zabezpiecz tożsamość: MFA + odporność na kradzież sesji

  • MFA odporne na phishing (FIDO2/WebAuthn) dla adminów i systemów krytycznych.
  • Ograniczenie długich sesji, rotacja sekretów, PAM dla uprzywilejowanych.

4. Uczyń „AI w firmie” częścią modelu zagrożeń

Nawet jeśli Twoja organizacja nie używa Claude Code, to:

  • threat-modeluj scenariusz, w którym atakujący używa agentów AI do automatyzacji (Twoje playbooki IR muszą zakładać większą prędkość i równoległość),
  • rozważ „purple teaming” z założeniem, że napastnik ma „AI-operatora”, który iteruje szybciej niż człowiek.

5. Ćwiczenia IR pod kątem wycieku danych

SecurityWeek cytuje uwagę, że „atak tej skali nie kończy się w momencie wykrycia” — odbudowa może być długa i kosztowna.
Przećwicz: izolację segmentów, decyzje o wyłączeniu usług, komunikację kryzysową, procesy prawne i dowodowe.

Różnice / porównania z innymi przypadkami

Klasyczne użycie LLM w atakach (phishing, generowanie fragmentów malware, tłumaczenia, OSINT) jest groźne, ale wciąż często „człowiek-w-pętli”.

W opisywanym schemacie kluczowa jest agentowość: model nie tylko doradza, ale wykonuje kolejne kroki (z narzędziami) i wraca do operatora głównie po decyzje. To jakościowo inna dynamika działań, mocno podkreślana w analizach Anthropic.

Podsumowanie / kluczowe wnioski

  • Incydent w Meksyku jest kolejnym przykładem, że AI może pełnić rolę „multiplikatora” zdolności ofensywnych, zwłaszcza gdy działa jako agent z dostępem do narzędzi.
  • Obrona musi zakładać krótszy czas do eskalacji po wejściu do środowiska i większą automatyzację po stronie przeciwnika.
  • Największą różnicę zrobią działania „anty-eksfiltracyjne”, wzmocnienie IAM oraz detekcja anomalii na warstwie danych i tożsamości.

Źródła / bibliografia

  1. SecurityWeek – opis ataku z użyciem Claude Code przeciw instytucjom w Meksyku (1 marca 2026). (SecurityWeek)
  2. Anthropic – „Disrupting the first reported AI-orchestrated cyber espionage campaign” (listopad 2025). (anthropic.com)
  3. Anthropic – Threat Intelligence Report (PDF, sierpień 2025) – wątek „vibe hacking” z użyciem Claude Code. (Anthropic)
  4. CrowdStrike – wnioski/komunikat do Global Threat Report 2026 (trend AI-enabled adversaries). (CrowdStrike)
  5. Bloomberg – wzmianka o kradzieży wrażliwych danych meksykańskich z użyciem Claude (25 lutego 2026). (Bloomberg.com)

Wyciek danych Canadian Tire: nawet 38,3 mln kont e-commerce w zestawie opublikowanym w sieci

Wprowadzenie do problemu / definicja luki

Canadian Tire Corporation (CTC) potwierdziła incydent bezpieczeństwa dotyczący bazy e-commerce, w której znajdowały się dane klientów kilku marek detalicznych. Sprawa wróciła na nagłówki pod koniec lutego 2026 r., gdy zestaw danych związany z tym incydentem został dodany do serwisu Have I Been Pwned (HIBP), co ułatwiło weryfikację, czy konkretne adresy e-mail znalazły się w wycieku.

W praktyce nie mówimy tu o „jednym sklepie”, tylko o wspólnej infrastrukturze kont online dla m.in. Canadian Tire, SportChek, Mark’s/L’Équipeur i Party City, co znacząco zwiększa skalę oddziaływania incydentu.

W skrócie

  • Incydent wykryto 2 października 2025 r. i dotyczył konkretnej bazy e-commerce (nie całej infrastruktury).
  • Według HIBP wyciek obejmuje ok. 42 mln rekordów, w tym 38,3 mln unikalnych adresów e-mail.
  • Dane zawierają m.in. imię i nazwisko, e-mail, a w opublikowanym zestawie także adresy i numery telefonów; hasła były przechowywane jako hashe PBKDF2.
  • CTC podkreśla, że incydent nie obejmował Canadian Tire Bank ani programu lojalnościowego Triangle Rewards.

Kontekst / historia / powiązania

CTC poinformowała o incydencie w komunikacji z października 2025 r., wskazując na nieautoryzowany dostęp do bazy danych związanej z kontami e-commerce. W komunikacie opisano kategorie danych i zapewniono, że podatność została usunięta oraz że firma współpracuje z zewnętrznymi ekspertami, by wzmocnić zabezpieczenia.

W lutym 2026 r. temat ponownie zyskał rozgłos, bo HIBP dodał wpis „Canadian Tire” z opisem skali oraz struktury danych (m.in. PBKDF2 dla haseł) i liczebności unikalnych adresów e-mail.

Analiza techniczna / szczegóły luki

1) Co zostało naruszone (warstwa danych):
CTC wskazywała na „basic personal information” powiązane z kontami e-commerce (w tym m.in. e-mail i hasła w postaci zaszyfrowanej/zhashowanej) oraz – dla części osób – informacje o dacie urodzenia i ucięte dane kart płatniczych.

2) Co pokazuje materiał w HIBP (warstwa „wyciek w obiegu”):
HIBP opisuje zestaw jako ok. 42 mln rekordów i 38 mln+ unikalnych e-maili, z polami takimi jak: imię i nazwisko, telefon, adres, oraz hasła jako PBKDF2. Dla części rekordów mają występować także daty urodzenia oraz „partial credit card data” (np. typ karty, data ważności, zamaskowany numer).

3) Dlaczego PBKDF2 ma znaczenie (i dlaczego nie jest „tarczą absolutną”):
PBKDF2 to funkcja KDF zaprojektowana do spowalniania łamania haseł. Jeśli jednak użytkownik miał słabe/krótkie hasło albo hasło było ponownie użyte gdzie indziej, atakujący mogą:

  • próbować crackingu offline (w zależności od parametrów PBKDF2),
  • stosować credential stuffing w innych serwisach,
  • budować bardzo wiarygodny phishing na podstawie danych kontaktowych.
    Same hashe PBKDF2 to lepiej niż „plain text”, ale przy skali dziesiątek milionów rekordów presja atakujących na automatyzację rośnie.

Praktyczne konsekwencje / ryzyko

Najbardziej prawdopodobne scenariusze nadużyć po takim wycieku to:

  • Phishing i vishing „pod markę” (Canadian Tire / SportChek / Mark’s / Party City): mając e-mail, telefon i adres, przestępcy mogą przygotować wiadomości podszywające się pod „weryfikację konta”, „dopłatę do przesyłki”, „zwrot” czy „podejrzaną transakcję”.
  • Credential stuffing: jeśli użytkownik reuse’ował hasło, ryzyko przejęcia kont w innych usługach jest realne (nawet jeśli samo konto Canadian Tire ma dodatkowe zabezpieczenia).
  • Uwiarygodnianie kradzieży tożsamości: data urodzenia (nawet w podzbiorze) w połączeniu z adresem i telefonem zwiększa „jakość” profilu ofiary do oszustw finansowych i socjotechniki.
  • Ataki na kanały odzyskiwania dostępu: numer telefonu bywa wykorzystywany w próbach przejęcia numeru (SIM-swap) lub w podszywaniu się w kontakcie z helpdeskiem.

Warto też zaznaczyć, że CTC komunikowała brak wpływu na bank i Triangle Rewards, co ogranicza zakres potencjalnych nadużyć w tych konkretnych ekosystemach.

Rekomendacje operacyjne / co zrobić teraz

Jeśli kiedykolwiek zakładałeś(aś) konto e-commerce u Canadian Tire / SportChek / Mark’s/L’Équipeur / Party City:

  1. Zmień hasło (w tym serwisie) na długie i unikalne; najlepiej wygenerowane w menedżerze haseł.
  2. Jeśli to hasło było używane gdziekolwiek indziej: zmień je wszędzie, zaczynając od poczty e-mail i kont finansowych.
  3. Włącz MFA/2FA tam, gdzie to możliwe (zwłaszcza e-mail).
  4. Sprawdź swój adres e-mail w HIBP i potraktuj wynik jako sygnał do „higieny haseł” w całym swoim ekosystemie kont.
  5. Uważaj na kontakty „z działu bezpieczeństwa” proszące o kod, dopłatę, „potwierdzenie danych” — szczególnie przez SMS/telefon.

Z perspektywy organizacji (blue team / SOC / IAM):

  • dodaj domeny i brandy do reguł antyphishingowych (słowa kluczowe, szablony tematów),
  • wprowadź wymuszenie resetu haseł + detekcję credential stuffing (rate limiting, bot mitigation),
  • przeanalizuj parametry KDF (koszt PBKDF2, unikalne sól, rotacja) i politykę haseł,
  • oceń ekspozycję danych w systemach e-commerce (minimalizacja pól, retencja, segmentacja baz).

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

  • Wyciek „e-commerce database” vs. ekosystem finansowy/lojalnościowy: CTC podkreśla, że incydent nie dotyczył Canadian Tire Bank ani Triangle Rewards — to częsty podział w dużych grupach: osobne systemy i osobne rejestry ryzyka.
  • Hashe PBKDF2 vs. hasła jawne: PBKDF2 znacząco utrudnia masowe łamanie haseł, ale przy takiej skali i typowych praktykach użytkowników (reuse) nadal należy zakładać wysoki poziom wtórnych nadużyć.
  • Różnice w liczbach: firma opisywała zakres incydentu w kategoriach „kont/danych” w komunikacji październikowej, natomiast HIBP agreguje i normalizuje zestaw danych „w obiegu” (rekordy, unikalne e-maile), co bywa źródłem rozbieżności w narracji liczbowej.

Podsumowanie / kluczowe wnioski

Incydent Canadian Tire to przykład, jak „jedna” baza e-commerce może w praktyce oznaczać dziesiątki milionów użytkowników wielu marek. Nawet jeśli nie doszło do naruszenia systemów bankowych i lojalnościowych, sam pakiet PII (e-mail/telefon/adres) plus hashe haseł (PBKDF2) jest wystarczający do szeroko zakrojonych kampanii phishingowych i prób przejęć kont przez credential stuffing.

Źródła / bibliografia

  • SecurityWeek – opis skali (38,3 mln e-maili / ~42 mln rekordów) i kontekstu dodania do HIBP (28 lutego 2026). (SecurityWeek)
  • Have I Been Pwned – wpis „Canadian Tire” (typy danych, PBKDF2, liczby rekordów). (Have I Been Pwned)
  • Canadian Tire Corporation – strona „Cyber Incident” (zakres systemów i zapewnienia dot. Bank/Triangle Rewards). (corp.canadiantire.ca)
  • Canadian Tire Corporation – komunikat prasowy z 14 października 2025 r. (oś czasu i charakter incydentu). (corp.canadiantire.ca)
  • Digital Commerce 360 – kontekst biznesowy i streszczenie ujawnionych kategorii danych (15 października 2025). (Digital Commerce 360)

4,8 mln USD w kryptowalutach skradzione po tym, jak koreański urząd skarbowy ujawnił seed frazę portfela

Wprowadzenie do problemu / definicja luki

W świecie kryptowalut „seed phrase” (fraza odzyskiwania, zwykle 12/24 słowa) to najważniejszy sekret — równoważnik „master key”, który pozwala odtworzyć portfel na dowolnym urządzeniu i przenieść wszystkie środki bez fizycznego dostępu do sprzętowego portfela (np. Ledger) ani znajomości PIN-u. Dlatego ujawnienie seeda nie jest „wyciekiem danych”, tylko praktycznie oddaniem pełnej kontroli nad aktywami.

Dokładnie taki scenariusz wydarzył się w Korei Południowej: w oficjalnych materiałach prasowych opublikowano zdjęcia, na których było widać niezamaskowaną frazę odzyskiwania dla przejętego portfela. Chwilę później aktywa zniknęły z adresu.

W skrócie

  • Po publikacji materiałów promujących akcję przeciw dłużnikom podatkowym, ujawniono mnemonic/seed portfela z przejętymi kryptowalutami.
  • Z adresu wyprowadzono 4 mln tokenów PRTG (Pre-Retogeum) o wartości ok. 4,8 mln USD (raporty podają też równowartość ok. 6,4 mld KRW).
  • Według analizy on-chain napastnik najpierw zasilił portfel niewielką ilością ETH na opłaty gas, a następnie przetransferował tokeny (w relacjach: kilka transakcji).
  • Policja wszczęła postępowanie i analizuje przepływ środków.

Kontekst / historia / powiązania

Incydent dotyczy portfela przejętego w ramach działań wobec 124 osób wskazywanych jako „wysokokwotowi / uporczywi” dłużnicy podatkowi. W komunikacji publicznej akcentowano sukces operacji i wartość zabezpieczonych aktywów, ale to właśnie materiały „dowodowe” stały się nośnikiem wycieku kluczowego sekretu.

Co istotne, koreańskie media i policja wskazują, że nie jest to odosobniony problem „custody” w instytucjach — w przestrzeni publicznej w Korei Południowej pojawiały się w ostatnich miesiącach inne kontrowersje związane z przechowywaniem zabezpieczonych kryptowalut.

Analiza techniczna / szczegóły luki

1) Klasa podatności: „sekret w materiale publicznym”

To nie był atak na kryptografię ani „złamanie” hardware walleta. To klasyczny błąd operacyjny: secret exposure w treści publikowanej publicznie (zdjęcie w wysokiej rozdzielczości, brak redakcji/maskowania).

W praktyce to odpowiednik opublikowania:

  • hasła root do serwera w PDF-ie,
  • prywatnego klucza API w repozytorium,
  • zdjęcia karty z kodami jednorazowymi.

2) Dlaczego seed phrase „omija” hardware wallet

Hardware wallet (Ledger i podobne) chroni klucz prywatny w urządzeniu, ale seed phrase to źródło deterministycznego odtworzenia kluczy (BIP-39/BIP-44 w typowych konfiguracjach). Jeśli ktoś ma seed, może:

  • odtworzyć portfel w innym kliencie,
  • podpisać transakcje „u siebie”,
  • wyprowadzić środki bez kontaktu z oryginalnym urządzeniem.

3) Mechanika kradzieży widoczna on-chain

Relacje wskazują, że napastnik:

  1. dorzucił trochę ETH na adres-ofiarę, aby zapłacić gas,
  2. wykonał transfery tokenów PRTG na kontrolowany adres (w mediach: kilka transakcji).

To wzorzec często spotykany przy drenażu tokenów z „pustych” adresów: tokeny są na adresie, ale nie ma ETH na opłaty — atakujący „sponsoruje” gas, bo i tak wychodzi na plus.

Praktyczne konsekwencje / ryzyko

Dla instytucji publicznych i organów ścigania

  • Utrata aktywów o wartości milionów USD w sytuacji, w której środki miały zasilić budżet państwa lub służyć jako dowód.
  • Ryzyko odpowiedzialności (audyt, kontrola, procedury, a potencjalnie także wątki prawne dot. ochrony informacji i należytej staranności — lokalnie może to podchodzić pod naruszenia przepisów o bezpieczeństwie informacji).
  • Erozja zaufania do kompetencji instytucji w obszarze „virtual asset custody”.

Dla organizacji i firm (lekcja uniwersalna)

Ten case pokazuje, że w bezpieczeństwie kryptowalut najczęściej przegrywa się nie z „hackerem 0-day”, tylko z:

  • procesem publikacji treści,
  • brakiem klasyfikacji informacji,
  • nieprzetestowanym workflow redakcji/maskowania,
  • brakiem nadzoru „four-eyes”.

Rekomendacje operacyjne / co zrobić teraz

Jeśli jesteś instytucją, która zabezpiecza kryptowaluty (custody)

  1. Zakaz fotografowania seeda / materiałów odzyskiwania w procesach operacyjnych (to powinno być traktowane jak materiał „TOP SECRET”).
  2. Procedura redakcji i walidacji publikacji:
    • automatyczne wykrywanie fraz 12/24 słów (DLP + detekcja wzorców),
    • obowiązkowy przegląd przez drugą osobę (4-eyes),
    • publikacja wyłącznie wersji „media-safe” z zaszytą metryką: kto zatwierdził, kiedy, z jakiej checklisty.
  3. Model custody klasy enterprise: multi-sig / MPC, rozdział obowiązków, kontrola dostępu, logowanie działań, procedury awaryjne.
  4. Runbook „seed exposed”: jeśli doszło do ujawnienia — natychmiastowa migracja środków na nowe adresy, monitoring i alertowanie, eskalacja do SOC/CSIRT.

Jeśli jesteś użytkownikiem indywidualnym / firmą trzymającą środki na hardware wallet

  • Traktuj seed jak „jedyny klucz do sejfu”: nigdy zdjęcie, nigdy chmura, nigdy komunikatory.
  • Gdy istnieje podejrzenie ujawnienia seeda: przenieś środki na nowy portfel (z nową frazą) i unieważnij stary adres jako magazyn wartości.

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

  • Kradzież przez ujawniony seed vs klasyczny malware/phishing: tu nie ma potrzeby infekować komputera ofiary ani kraść PIN-u — seed daje pełnię kontroli „z definicji”.
  • Błąd custody w instytucji vs „self-custody” użytkownika: instytucje mają zwykle procedury i audyty, ale gdy traktują krypto jak „zwykły przedmiot dowodowy”, przegrywają na podstawach (klasyfikacja informacji + publikacje PR). Ten przypadek jest wręcz podręcznikowy.

Podsumowanie / kluczowe wnioski

  1. Seed phrase to master key — jej ujawnienie oznacza natychmiastową utratę kontroli nad portfelem.
  2. Incydent w Korei Południowej pokazuje, że realne straty w kryptowalutach często wynikają z błędów proceduralnych, a nie zaawansowanych exploitów.
  3. Organizacje przejmujące krypto (zajęcia komornicze, dowody rzeczowe, zabezpieczenia) muszą wdrożyć profesjonalny model custody (multi-sig/MPC) oraz procesy DLP i redakcji publikacji.

Źródła / bibliografia

  • BleepingComputer — opis incydentu, kontekst publikacji zdjęć i szczegóły transferów. (BleepingComputer)
  • Maeil Business Newspaper (mk.co.kr) — relacja lokalna, opis ujawnienia „mnemonic” w materiałach prasowych oraz komentarze ekspertów. (매일경제)
  • Korea JoongAng Daily — informacja o wszczęciu działań policji i wątkach prawnych/śledczych. (Korea Joongang Daily)
  • Cointelegraph (via TradingView) — dodatkowe szczegóły i szerszy kontekst problemów custody w Korei Południowej. (TradingView)

Wyciek danych ManoMano: nawet 38 mln klientów dotkniętych incydentem związanym z Zendesk i podwykonawcą

Wprowadzenie do problemu / definicja luki

ManoMano (europejska platforma e-commerce z segmentu DIY/dom i ogród) znalazła się w centrum głośnego incydentu bezpieczeństwa, w którym napastnicy mieli pozyskać dane osobowe klientów poprzez kompromitację portalu wsparcia (support). Kluczowe jest to, że według dostępnych informacji nie doszło do „klasycznego” włamania na główną infrastrukturę sklepu, lecz do incydentu w łańcuchu dostaw – po stronie zewnętrznego dostawcy obsługi klienta i używanego narzędzia ticketowego.

W skrócie

  • Skala: napastnik twierdzi, że dotyczy to ok. 37,8 mln rekordów / osób; w publikacjach mówi się o „prawie 38 mln”.
  • Kiedy wykryto: ManoMano miało ustalić incydent w styczniu 2026.
  • Wektor: kompromitacja dostawcy obsługi klienta (podwykonawcy), z wykorzystaniem dostępu do systemu typu Zendesk.
  • Jakie dane: m.in. imię i nazwisko, adres e-mail, numer telefonu oraz treści/metadata zgłoszeń do supportu (w tym komunikacja z obsługą).
  • Czego (prawdopodobnie) nie było: w cytowanych stanowiskach podkreślano, że hasła kont nie zostały ujawnione (lub nie były dostępne w skompromitowanym obszarze).

Kontekst / historia / powiązania

Ten przypadek dobrze pokazuje, dlaczego zespoły bezpieczeństwa coraz częściej traktują systemy obsługi klienta (CRM/ticketing) jako krytyczną powierzchnię ataku:

  1. W ticketach często znajduje się „miękka” wrażliwa treść (adresy, zamówienia, reklamacje, czasem załączniki), która jest bardzo użyteczna w oszustwach.
  2. Dostęp do narzędzia wsparcia bywa delegowany na podwykonawców (call center, BPO), co mnoży punkty wejścia, konta, role i ryzyka operacyjne.
  3. Atakujący nie muszą łamać dobrze bronionej infrastruktury e-commerce – wystarczy przejąć konto agenta lub integrację po stronie dostawcy.

Analiza techniczna / szczegóły luki

Z publicznych doniesień wynika następujący (prawdopodobny) łańcuch zdarzeń:

  • Kompromitacja podwykonawcy obsługującego wsparcie klienta (w części publikacji wskazywano lokalizację dostawcy w Tunezji).
  • Wejście przez konto w Zendesk / portalu supportowym, które miało uprawnienia do przeglądania danych klientów i historii kontaktu.
  • Eksfiltracja danych: dane identyfikacyjne (PII) oraz treści korespondencji i informacje związane z obsługą posprzedażową.
  • Sprawca, występujący pod aliasem „Indra”, miał opublikować twierdzenia o skali wycieku na forum przestępczym.

Warto zauważyć istotny niuans: nawet jeśli hasła nie wyciekły, to zestaw (imię+nazwisko+e-mail+telefon+historia ticketów) jest „paliwem” do ataków socjotechnicznych, bo pozwala tworzyć wysoce wiarygodne scenariusze podszycia.

Praktyczne konsekwencje / ryzyko

Najbardziej realne skutki dla klientów (i firm podszywających się pod ManoMano) to:

  • Phishing e-mail: wiadomości „o dopłacie do przesyłki”, „zwrocie”, „weryfikacji konta”, z linkiem do fałszywej bramki logowania lub płatności.
  • Vishing / smishing: telefon/SMS, bo numer telefonu ma wysoką wartość w oszustwach „na konsultanta”, „na kuriera”, „na bank”.
  • Ataki ukierunkowane na podstawie treści zgłoszeń: jeśli ktoś pisał do supportu o konkretnym zamówieniu/produkcie, przestępcy mogą to wykorzystać, by „udowodnić autentyczność”.
  • Ryzyko wtórne (credential stuffing) poza ManoMano: nawet bez haseł, część ofiar kliknie w link i sama poda dane logowania, albo zainstaluje złośliwą aplikację „do śledzenia przesyłki”.

Rekomendacje operacyjne / co zrobić teraz

Dla klientów (działania natychmiastowe)

  1. Załóż, że ktoś może podszywać się pod ManoMano: nie klikaj w linki z wiadomości o „weryfikacji” czy „dopłacie”. Wejdź na stronę/apkę ręcznie.
  2. Włącz MFA wszędzie, gdzie się da (e-mail, bank, marketplace’y). To najtańszy „bezpiecznik” na skutki phishingu.
  3. Uważaj na rozmowy telefoniczne: jeśli ktoś dzwoni „z obsługi”, rozłącz się i oddzwoń numerem z oficjalnej strony/aplikacji (nie z treści SMS/e-mail).
  4. Jeśli używasz tego samego hasła w wielu miejscach: zmień je (szczególnie do poczty). Nawet jeśli w tym incydencie hasła nie wyciekły, to poczta jest kluczem do resetów.

Dla organizacji (checklista po stronie bezpieczeństwa)

  1. Zarządzanie dostawcami (TPRM): oceń model dostępu podwykonawcy do ticketów (zasada najmniejszych uprawnień, segmentacja ról, JIT/JEA).
  2. Twarde MFA + polityki dostępu dla kont agentów: wymuszenie MFA, ograniczenia geograficzne/IP, wykrywanie niemożliwych podróży, blokady po anomaliach.
  3. Monitoring i alertowanie na masowy eksport/odczyt: ticketing powinien mieć reguły na nietypowe wolumeny wyszukiwań, pobrań i eksportów.
  4. Redukcja danych w ticketach: maskowanie PII w treści, automatyczne usuwanie/retencja, zakaz przesyłania wrażliwych dokumentów jako załączników (lub DLP).
  5. Playbook na incydenty w SaaS: procedury dla Zendesk/CRM (revocation tokens, rotacja kluczy integracji, przegląd OAuth, szybkie odcięcie dostępu dostawcy).

W doniesieniach podkreślano, że ManoMano miało po wykryciu incydentu odebrać dostęp podwykonawcy i wzmocnić kontrolę dostępu/monitoring oraz powiadomić odpowiednie organy.

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

W porównaniu do wycieków „z bazy użytkowników” (gdzie często pojawiają się hashe haseł), tu sedno jest inne: to incydent w kanale wsparcia, który może nie zawierać haseł, ale zawiera kontekst. Dla przestępców kontekst = wiarygodność, a wiarygodność = wyższa skuteczność phishingu/vishingu.

To także klasyczny wzorzec „third-party breach”: organizacja może mieć solidne zabezpieczenia w core, ale „wejście bokiem” przez dostawcę daje dostęp do danych wrażliwych operacyjnie.

Podsumowanie / kluczowe wnioski

  • Incydent ManoMano (ujawniony publicznie pod koniec lutego 2026) to przykład, że systemy obsługi klienta i podwykonawcy są dziś jednym z najczęstszych „skrótów” do danych klientów.
  • Nawet przy braku haseł, zestaw PII + historia zgłoszeń to wysokie ryzyko socjotechniki (phishing, vishing, oszustwa płatnicze).
  • Priorytety defensywne: MFA wszędzie, monitoring anomalii w SaaS/ticketingu, ograniczenie uprawnień i danych widocznych dla dostawców, oraz dojrzałe TPRM.

Źródła / bibliografia

  1. SecurityWeek – „38 Million Allegedly Impacted by ManoMano Data Breach” (27 lutego 2026). (SecurityWeek)
  2. BleepingComputer – „European DIY chain ManoMano data breach impacts 38 million customers” (26 lutego 2026). (BleepingComputer)
  3. TechRadar (Pro) – opis incydentu i kontekst third-party/Zendesk (27 lutego 2026). (TechRadar)
  4. The Register – dodatkowe szczegóły dot. skali i artefaktów wycieku (27 lutego 2026). (The Register)
  5. SC Media / SC World – krótkie podsumowanie: zakres danych i wektor third-party (27 lutego 2026). (SC Media)

Europol uderza w „The Com”: Project Compass przynosi 30 aresztowań i identyfikację 179 sprawców

Wprowadzenie do problemu / definicja „luki” (tu: ekosystemu zagrożeń)

„The Com” (od The Community) to nie pojedyncza grupa, tylko luźny, zdecentralizowany ekosystem społeczności i „crewów”, w którym mieszają się: włamania, wymuszenia finansowe, sextortion oraz wątki radykalizacji i przemocy w świecie realnym. Z perspektywy obrońców jest to trudny przeciwnik, bo nie ma jednego „centrum dowodzenia” – są relacje, reputacja, wzajemne usługi i ciągła rotacja uczestników (często bardzo młodych).

Właśnie ten „model społeczności” sprawia, że działania policyjne muszą iść szerzej niż klasyczne „takedowny” infrastruktury: potrzebne są równoległe identyfikacje osób, praca z platformami, ochrona ofiar i działania prewencyjne.

W skrócie

W ramach skoordynowanej, międzynarodowej inicjatywy Project Compass (start: styczeń 2025) służby miały w pierwszym roku:

  • doprowadzić do 30 aresztowań,
  • w pełni lub częściowo zidentyfikować 179 sprawców,
  • zidentyfikować do 62 ofiar oraz bezpośrednio zabezpieczyć 4 ofiary.

Operacja obejmuje współpracę 28 państw, w tym państw Five Eyes (USA, UK, Kanada, Australia, Nowa Zelandia) oraz m.in. Norwegii i Szwajcarii; koordynacja ma odbywać się po stronie Europolu (w obszarze CT/„online ekstremizmu”).

Kontekst / historia / powiązania

Wątek „The Com” powraca w branży, bo w tym samym „społecznym zapleczu” miały pojawiać się osoby i podgrupy łączone z głośnymi kampaniami w stylu ShinyHunters / Lapsus$ / Scattered Spider – czyli mieszanka włamań, kradzieży danych i wymuszeń.

Dodatkowo, część odłamów ma być kojarzona z przestępczością ukierunkowaną na nieletnich (grooming, sextortion, zmuszanie do wytwarzania materiałów o charakterze seksualnym). W publikacjach wskazuje się m.in. na 764 jako szczególnie toksyczny odłam w tym ekosystemie.

Analiza techniczna / szczegóły „luki” (TTP i mechanika działania)

Z punktu widzenia cyberbezpieczeństwa „The Com” to pipeline: rekrutacja → eskalacja zachowań → monetyzacja (wymuszenia, ransomware, oszustwa) + czasem przemoc offline.

Najczęściej opisywane elementy tego modelu:

A. Rozproszone środowisko komunikacji i rekrutacji
Wskazywane są przestrzenie, gdzie młodzi użytkownicy „czują się swobodnie”: komunikatory, social media, gaming oraz nawet platformy streamingowe. To utrudnia wykrywanie, bo aktywność nie wygląda jak klasyczna „infrastruktura APT”, tylko jak ruch społeczności.

B. Podział na „kompetencje” / podzbiory aktywności
W źródłach pojawiają się opisy segmentacji: część skupiona na włamach i ransomware, część na „IRL” (swatting, groźby, przemoc), część na (s)extortion. FBI-owski podział (Hacker Com / In Real Life Com / Extortion Com) jest przywoływany jako praktyczny skrót myślowy.

C. Utrudnianie atrybucji i śledzenia przepływów pieniędzy
Podkreślane są zachowania typu: maskowanie tożsamości, ukrywanie transakcji, pranie środków. W praktyce dla obrony oznacza to większe ryzyko, że atak „wejściowy” (np. przejęcie konta) szybko przechodzi w etap wymuszeń i płatności, zanim organizacja zdąży zareagować.

Praktyczne konsekwencje / ryzyko

Dla organizacji (firmy, szkoły, podmioty publiczne) ryzyko nie ogranicza się do wycieku danych:

  • Ransomware i wymuszenia wielokanałowe: presja czasowa, groźby publikacji, kontakt z pracownikami/klientami.
  • Sextortion / szantaż wobec młodych osób: realny, krytyczny obszar ochrony – tu „incydent” zaczyna się w DM-ach, a kończy tragedią.
  • Ryzyko „IRL”: swatting i przemoc jako „przedłużenie” konfliktów online.

Warto też zauważyć, że operacje takie jak Project Compass sygnalizują przesunięcie priorytetów: służby traktują ten ekosystem jako zagrożenie na styku cyberprzestępczości i ekstremizmu.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz”, które realnie podnoszą odporność na kampanie powiązane z tym typem ekosystemu:

Dla SOC / IR / IT

  1. Wzmocnij IAM pod przejęcia kont: wymuszaj phishing-resistant MFA (FIDO2/WebAuthn) na krytycznych rolach, ogranicz reset haseł, monitoruj nietypowe rejestracje urządzeń i zmiany metod MFA.
  2. Detekcje pod extortion: alerty na masowe pobrania, nietypowe eksporty danych, anomalia w narzędziach zdalnych, niespodziewane tworzenie archiwów i transfery na zewnętrzne chmury.
  3. Gotowość „ransomware-ready”: testowane kopie offline/immutable, szybka segmentacja, playbook negocjacyjny i komunikacyjny (w tym prawny), procedury na doxxing/swatting.
  4. Threat intel, ale pragmatycznie: śledź sygnały o rekrutacji młodych osób i kampaniach sextortion w Twoim regionie/branży; w razie incydentu eskaluj do odpowiednich zespołów ds. nadużyć na platformach.

Dla szkół / rodziców / opiekunów (aspekt ochrony nieletnich)

  1. Uprość kanały zgłaszania (anonimowość, szybka reakcja) i trenuj scenariusze „szantaż w sieci”.
  2. Zasada: nie płacić za „usunięcie materiałów” bez konsultacji ze służbami/specjalistami – to często tylko napędza dalsze wymuszenia.
  3. Higiena prywatności: ograniczenie publicznych danych, ustawienia kont, kontrola DM, ochrona przed podszyciami.

Dla zarządów

  • Traktuj to jako ryzyko operacyjne i reputacyjne (w tym bezpieczeństwo pracowników), nie tylko „IT problem”. Project Compass pokazuje, że presja organów ścigania i regulatorów na dojrzałość procesów będzie rosnąć.

Różnice / porównania z innymi przypadkami

W porównaniu do klasycznych grup ransomware (bardziej „firmopodobnych”, z hierarchią i infrastrukturą) „The Com” przypomina platformę społecznościową przestępczości: łatwiejsze wejście, szybka wymiana usług, mniejsza stabilność, ale duża skala. To tłumaczy, czemu Project Compass stawia na wieloletnią, międzynarodową koordynację i wymianę informacji, zamiast jednorazowego „odcięcia serwerów”.

Podsumowanie / kluczowe wnioski

  • 30 aresztowań i 179 zidentyfikowanych sprawców w ramach pierwszego roku Project Compass to mocny sygnał, że „The Com” jest traktowane jako priorytet transgraniczny.
  • Największe wyzwanie to decentralizacja i „społecznościowy” charakter zagrożenia – obrona musi łączyć cyber, ochronę osób i prewencję.
  • Dla organizacji najlepszy zwrot z inwestycji dają: phishing-resistant MFA, detekcje eksfiltracji, gotowość na wymuszenia oraz procedury pod incydenty obejmujące ludzi (doxxing/swatting/sextortion).

Źródła / bibliografia

  1. BleepingComputer – opis akcji i kontekstu „The Com” (27 lutego 2026). (BleepingComputer)
  2. CyberScoop – tło Project Compass, model współpracy i cytaty (26 lutego 2026). (CyberScoop)
  3. Help Net Security – podsumowanie wyników i mechaniki działania (27 lutego 2026). (Help Net Security)
  4. GovInfoSecurity – perspektywa „violent online extremism”, ofiary i ekosystem platform (27 lutego 2026). (govinfosecurity.com)
  5. heise online – streszczenie statystyk i kontekstu „underground network” (27 lutego 2026). (heise online)

APT37 (ScarCruft) przełamuje izolację: nowy zestaw malware do ataków na sieci air-gapped przez USB

Wprowadzenie do problemu / definicja luki

Sieci air-gapped (fizycznie odseparowane od Internetu) uchodzą za jedną z najmocniejszych kontroli bezpieczeństwa w środowiskach OT/ICS, wojsku czy badaniach. Problem w tym, że „air gap” prawie nigdy nie oznacza absolutnej izolacji — w praktyce dane i pliki i tak krążą pomiędzy segmentami dzięki nośnikom wymiennym (USB, dyski zewnętrzne). To właśnie ten „most operacyjny” staje się celem atakujących.

Najnowsze ustalenia pokazują, że północnokoreański aktor APT37 (ScarCruft) wdrożył narzędzia, które zamieniają pendrive’y w dwukierunkowy, ukryty kanał C2: pozwala to zarówno dostarczać polecenia do maszyn odciętych od sieci, jak i wynosić z nich dane.

W skrócie

  • Kampania została opisana przez Zscaler ThreatLabz jako „Ruby Jumper” i jest łączona z APT37.
  • Łańcuch infekcji startuje od złośliwego pliku LNK, który uruchamia PowerShell, wyciąga komponenty z samego skrótu i odpala dokument-przynętę.
  • Zidentyfikowane komponenty obejmują m.in.: RESTLEAF, SNAKEDROPPER, THUMBSBD, VIRUSTASK, FOOTWINE (oraz obserwowany wcześniej backdoor BLUELIGHT).
  • THUMBSBD realizuje kluczową funkcję: używa nośników wymiennych jako „transportu” do przekazywania poleceń i danych między systemami online i air-gapped.

Kontekst / historia / powiązania

APT37 to państwowa grupa szpiegowska powiązana z Koreą Północną, aktywna co najmniej od 2012 r., silnie skupiona na celach w Korei Południowej, ale z szerszym zasięgiem regionalnym.

Wzorzec działań pasuje do znanego modus operandi tej grupy: spear-phishing, pliki skrótów LNK, „living off trusted services” (nadużywanie zaufanych usług chmurowych jako infrastruktury C2 lub dystrybucji). Przykładowo, wcześniejsze analizy (np. Genians) opisywały kampanie APT37 wykorzystujące Dropbox i pliki LNK jako etap inicjalny.

„Ruby Jumper” rozwija te techniki o element szczególnie groźny dla środowisk odseparowanych: kontrolowaną propagację przez USB i mechanizm transferu poleceń/danych przez nośnik.

Analiza techniczna / szczegóły luki

1. Wejście: LNK + PowerShell + przynęta

Łańcuch startuje, gdy użytkownik otworzy złośliwy Windows Shortcut (LNK). Ten uruchamia PowerShell, który „wycina” (carving) zaszyte w skrócie elementy (m.in. kolejne skrypty/payloady) oraz uruchamia dokument-wabik, by zająć uwagę ofiary.

2. RESTLEAF: C2 przez Zoho WorkDrive

Pierwszym implantem jest RESTLEAF, który komunikuje się z infrastrukturą C2 wykorzystując Zoho WorkDrive (z perspektywy obrońcy: ruch do legalnej usługi SaaS).

W praktyce oznacza to:

  • ukrycie komunikacji na tle normalnego ruchu do usług chmurowych,
  • łatwiejsze obchodzenie blokad/allow-list opartych na reputacji domen,
  • potencjalnie trudniejsze atrybuowanie infrastruktury (bo „serwerem” jest repozytorium w chmurze).

3. SNAKEDROPPER: środowisko Ruby jako „kontener” dla kolejnych etapów

Kolejny etap to SNAKEDROPPER – loader, który instaluje środowisko Ruby 3.3.0 i maskuje je jako narzędzie związane z USB (m.in. poprzez nazwę wykonywalną typu usbspeed.exe). Następnie utrwala wykonanie (scheduled task wykonywany cyklicznie).

To ważne z dwóch powodów:

  1. atakujący dostarczają własny „runtime”, uniezależniając się od tego, co jest zainstalowane na stacji,
  2. nietypowy stos (Ruby runtime w katalogach systemowych/ProgramData) może utrudniać reguły detekcji oparte wyłącznie o klasyczne TTP (np. tylko PowerShell/LOLbins).

4. THUMBSBD: „dwukierunkowy przekaźnik C2” przez USB

THUMBSBD pełni rolę backdoora i mechanizmu „mostu” pomiędzy systemem online a air-gapped: przygotowuje pliki z poleceniami, zbiera wyniki i przenosi je przez ukryte katalogi na nośniku. Zscaler opisuje to wprost jako zamianę nośników wymiennych w dwukierunkowy ukryty przekaźnik C2.

W uproszczeniu: operator może „wgrać” polecenia na pendrive na maszynie mającej dostęp do C2 (chmury), a następnie ten sam pendrive przenosi polecenia do stacji air-gapped i wraca z danymi/rezultatami do środowiska online.

5. VIRUSTASK: propagacja w segmencie odciętym

Komponent VIRUSTASK odpowiada za rozprzestrzenianie w środowiskach air-gapped: „uzbraja” nośniki, ukrywając legalne pliki i zastępując je skrótami LNK, które uruchamiają zainstalowany runtime Ruby i dalsze elementy łańcucha. Co istotne, mechanizm ma warunek uruchomienia (np. minimalna wolna przestrzeń na nośniku).

6. FOOTWINE i BLUELIGHT: działania rozpoznawcze i szpiegowskie

W dalszym etapie THUMBSBD dostarcza FOOTWINE – spyware/backdoor z możliwościami takimi jak keylogging, zrzuty ekranu, nagrywanie audio/wideo czy zdalna powłoka. W kampanii obserwowano też BLUELIGHT, wcześniej wiązany z APT37, co wzmacnia atrybucję.

Praktyczne konsekwencje / ryzyko

Największa zmiana nie polega na „magicznej” zdolności łamania air-gapu, tylko na industrializacji przenoszenia kontroli między segmentami:

  • Ryzyko dla OT/ICS i infrastruktury krytycznej: nawet jeśli stacje operatorskie/HMI są odcięte od Internetu, operacyjny obieg plików (raporty, konfiguracje, logi) tworzy ścieżkę ataku.
  • C2 ukryte w chmurze: RESTLEAF wykorzystujący Zoho WorkDrive może wyglądać jak „normalny ruch SaaS”, co komplikuje polityki oparte na prostym allow/deny dla domen.
  • Skuteczna inwigilacja: finalne payloady nastawione są na długotrwałe zbieranie informacji (keylogging, screen/audio/video), co jest typowe dla operacji szpiegowskich.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie ograniczają ryzyko w scenariuszu „USB jako most”:

  1. Twarda kontrola nośników wymiennych
  • wdrożenie polityk device control (whitelist konkretnych VID/PID/seriali),
  • wymuszenie szyfrowania i rejestrowania użycia nośników,
  • ograniczenie autorun i blokada uruchamiania skrótów LNK z nośników (tam gdzie to możliwe operacyjnie).
  1. Detekcja na endpointach (EDR) pod kątem TTP z kampanii
  • alarmy na nietypowe uruchomienia PowerShell pochodzące z LNK,
  • monitoring tworzenia zadań harmonogramu (scheduled tasks) o podejrzanych nazwach/cykliczności,
  • polowanie na anomalię: runtime Ruby wypakowany w nietypowych lokalizacjach (np. %PROGRAMDATA%) i procesy typu usbspeed.exe uruchamiane cyklicznie.
  1. Kontrola dostępu do usług chmurowych (CASB / SWG / proxy)
  • inspekcja i alertowanie na nietypowe użycie Zoho WorkDrive w organizacji (zwłaszcza jeśli nie jest wykorzystywany biznesowo),
  • korelacja: tokeny/operacje API do chmury + zdarzenia endpointowe (LNK/PowerShell) w krótkim oknie czasu.
  1. Procedury dla środowisk air-gapped
  • „strefa buforowa” (kiosk) do skanowania nośników przed wejściem do segmentu odseparowanego,
  • walidacja plików przenoszonych do OT (formaty, podpisy, źródło, integralność),
  • jeśli to możliwe: jednokierunkowy transfer (data diode) zamiast przenoszenia danych na USB.

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

  • Klasyczne infekcje przez LNK: APT37 korzysta z tej techniki od lat, co widać także w starszych kampaniach opisywanych publicznie (np. nadużycia usług chmurowych i LNK jako wektora).
  • Nowość w „Ruby Jumper”: nie sam phishing, lecz spójny zestaw narzędzi do obsługi pełnego cyklu air-gap (propagacja + przenoszenie poleceń + exfil przez nośnik), oraz wyraźne postawienie na chmurę SaaS (Zoho WorkDrive) jako warstwę C2.

Podsumowanie / kluczowe wnioski

APT37 pokazuje, że „air-gap” bez kontroli nośników wymiennych jest bardziej założeniem niż zabezpieczeniem. Kampania Ruby Jumper łączy:

  • inicjalny dostęp przez LNK + PowerShell,
  • C2 ukryte w Zoho WorkDrive,
  • oraz krytyczny element: THUMBSBD/VIRUSTASK, które zamieniają USB w kanał sterowania i transferu danych do/z środowisk air-gapped.

Jeśli w organizacji istnieje choćby minimalny „ruch USB” między segmentami, warto potraktować ten scenariusz jako realny i wdrożyć kontrolę nośników, hunting endpointowy oraz polityki dla usług SaaS.

Źródła / bibliografia

  • BleepingComputer – opis kampanii i przegląd narzędzi (RESTLEAF, SNAKEDROPPER, THUMBSBD, VIRUSTASK, FOOTWINE, BLUELIGHT). (BleepingComputer)
  • Zscaler ThreatLabz – raport techniczny „APT37 Adds New Capabilities for Air-Gapped Networks” (Ruby Jumper, Zoho WorkDrive, szczegóły łańcucha infekcji). (zscaler.com)
  • MITRE ATT&CK – profil grupy APT37 (G0067) i kontekst operacyjny. (MITRE ATT&CK)
  • Genians – przykład wcześniejszych kampanii APT37 z LNK i nadużyciem chmury (kontekst TTP). (genians.co.kr)