Archiwa: Phishing - Strona 97 z 150 - Security Bez Tabu

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)

Trend Micro ostrzega przed krytycznymi lukami RCE w Apex One: CVE-2025-71210 i CVE-2025-71211

Wprowadzenie do problemu / definicja luki

Trend Micro (w segmencie enterprise komunikujące się też marką TrendAI) opublikowało ostrzeżenie o dwóch krytycznych podatnościach typu Remote Code Execution (RCE) w konsoli zarządzającej Trend Micro Apex One dla Windows. Luki mają charakter directory/path traversal (CWE-22) i mogą umożliwić atakującemu wgranie złośliwego kodu oraz wykonanie poleceń na serwerze zarządzającym — czyli w newralgicznym miejscu całego systemu ochrony endpointów.


W skrócie

  • Podatności: CVE-2025-71210 i CVE-2025-71211 (obie CVSS 9.8, krytyczne).
  • Komponent: Apex One Management Console (Windows).
  • Warunek istotny operacyjnie: Trend Micro podkreśla, że atakujący musi mieć dostęp do konsoli zarządzającej — dlatego szczególnie ryzykowne są środowiska, w których IP/GUI konsoli jest wystawione do Internetu lub szerokich sieci.
  • Naprawa: dla on-prem Apex One 2019 wydano Critical Patch (CP) Build 14136; środowiska SaaS zostały już zmitigowane.

Kontekst / historia / powiązania

Apex One (oraz ekosystem produktów „Apex”) jest regularnie celem badaczy, bo konsola zarządzająca stanowi „punkt centralny” do dystrybucji polityk i agentów. W najnowszym biuletynie Trend Micro zaznacza też, że CP zawiera dodatkowe usprawnienia ochrony związane z wcześniejszymi krytycznymi problemami (m.in. CVE-2025-54948 / CVE-2025-54987), co jest sygnałem, że producent wzmacnia obszary historycznie narażone na nadużycia w warstwie zarządzania.

Warto odnotować, że bieżące luki zostały zgłoszone w ramach odpowiedzialnego ujawniania przez Zero Day Initiative (ZDI), a identyfikatory ZDI-CAN-28001 i ZDI-CAN-28002 pojawiają się w dokumentacji i harmonogramie advisory ZDI.


Analiza techniczna / szczegóły luki

Co oznacza „directory/path traversal” w konsoli zarządzającej?

W uproszczeniu: błąd typu traversal pojawia się, gdy aplikacja nie ogranicza poprawnie ścieżek plików do „bezpiecznego” katalogu bazowego. Atakujący może wtedy manipulować parametrami (np. sekwencjami ../) tak, aby:

  • zapisać plik poza dozwolonym katalogiem (np. w lokalizacji wykonywalnej),
  • albo odwołać się do zasobów, do których nie powinien mieć dostępu.

W tym przypadku Trend Micro opisuje scenariusz, w którym podatność może pozwolić zdalnemu atakującemu na przesłanie złośliwego kodu i wykonanie komend w środowisku konsoli.

Dwie podatności, podobny mechanizm – inny „punkt zaczepienia”

  • CVE-2025-71210: Console Directory Traversal RCE (ZDI-CAN-28001).
  • CVE-2025-71211: analogiczna klasa błędu, ale dotycząca innego pliku wykonywalnego w obrębie konsoli (ZDI-CAN-28002).

Ważny warunek eksploatacji (nie ignoruj go)

Trend Micro wprost wskazuje, że do skutecznego ataku wymagany jest dostęp do Apex One Management Console; jeśli konsola ma publicznie dostępny adres IP, producent sugeruje stosowanie ograniczeń źródeł (source restrictions) jako czynnika mitygującego ryzyko.

To nie czyni luk „niegroźnymi” — w praktyce dostęp do konsoli bywa osiągalny przez:

  • przejęte konto administratora (phishing/credential stuffing),
  • tunelowanie z sieci wewnętrznej po wcześniejszym foothold,
  • błędne wystawienie panelu w Internecie,
  • nadużycia w segmentacji sieci.

Praktyczne konsekwencje / ryzyko

Jeśli atakujący uzyska RCE na serwerze zarządzającym Apex One, konsekwencje eskalują szybciej niż w typowym incydencie endpointowym:

  • przejęcie dystrybucji polityk (wyłączenie ochrony, wyjątki, manipulacja konfiguracją),
  • potencjalne rozsyłanie payloadów do hostów zarządzanych,
  • pivot do innych systemów (konsola często ma szerokie uprawnienia i łączność),
  • ryzyko „quiet takeover”: napastnik może działać pod przykrywką legalnych mechanizmów zarządzania.

Choć publiczne doniesienia koncentrują się na samej naprawie, sens operacyjny jest prosty: konsola bezpieczeństwa po przejęciu staje się narzędziem ataku.


Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj on-prem Apex One 2019 do CP Build 14136 (priorytet P1).
  2. Jeśli używasz wariantu SaaS (Apex One as a Service / Trend Vision One Endpoint – Standard Endpoint Protection), sprawdź status, ale Trend Micro wskazuje, że SaaS zostało już zmitigowane.
  3. Zablokuj ekspozycję konsoli:
    • usuń publiczny dostęp do panelu,
    • wymuś dostęp wyłącznie przez VPN/ZTNA,
    • zastosuj allowlistę źródeł (source restrictions), o której wspomina producent.
  4. Wymuś twarde uwierzytelnianie do konsoli:
    • MFA,
    • rotacja haseł kont uprzywilejowanych,
    • dedykowane konta admin (bez poczty/WWW).
  5. Monitoring i detekcja:
    • przegląd logów serwera zarządzającego i zdarzeń aplikacyjnych,
    • alerty na nietypowe uploady/operacje plikowe w katalogach aplikacji,
    • kontrola nowych procesów uruchamianych przez usługi konsoli.
  6. Higiena uprawnień:
    • ogranicz prawa konta/serwisu, jeśli architektura na to pozwala,
    • odseparuj serwer konsoli w sieci (segment + reguły egress).

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

  • Nowe luki (CVE-2025-71210/71211) to CWE-22 (traversal) w konsoli i mają CVSS 9.8, ale Trend Micro podkreśla wymóg dostępu do panelu.
  • W 2025 r. głośne były podatności CWE-78 (command injection) w on-prem konsoli (np. CVE-2025-54948), które również dotykały warstwy zarządzającej — NVD opisuje je jako możliwość uploadu złośliwego kodu i wykonania komend.

Wspólny mianownik: konsola zarządzająca jako „high-value target”. Różnica: klasa błędu i detale warunków wejściowych, ale skutek operacyjny (przejęcie serwera zarządzającego) pozostaje podobnie groźny.


Podsumowanie / kluczowe wnioski

  • Dwie krytyczne podatności traversal w konsoli Apex One mogą prowadzić do RCE (CVE-2025-71210 i CVE-2025-71211, CVSS 9.8).
  • Największe ryzyko mają środowiska, gdzie konsola jest dostępna z zewnątrz lub gdzie łatwo o kradzież poświadczeń do panelu.
  • Dla on-prem Apex One 2019 kluczowa jest aktualizacja do CP Build 14136; SaaS jest już po stronie dostawcy zmitigowany.

Źródła / bibliografia

  1. Trend Micro (TrendAI) – Security Bulletin: Apex One and Apex One (Mac) – February 2026 (KA-0022458). (success.trendmicro.com)
  2. BleepingComputer – Trend Micro warns of critical Apex One code execution flaws (26 lutego 2026). (BleepingComputer)
  3. SecurityWeek – Trend Micro Patches Critical Apex One Vulnerabilities. (SecurityWeek)
  4. Zero Day Initiative – wpisy dotyczące ZDI-CAN-28001 / ZDI-CAN-28002 (harmonogram/advisories). (zerodayinitiative.com)
  5. NVD (NIST) – kontekst wcześniejszych luk w Apex One (np. CVE-2025-54948). (nvd.nist.gov)