Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 303 z 320

Autor: Wojciech Ciemski

GlassWorm: samorozprzestrzeniający się robak infekuje rozszerzenia VS Code i uderza w łańcuch dostaw

Wprowadzenie do problemu / definicja luki

Badacze bezpieczeństwa opisali nową kampanię malware nazwaną GlassWorm, która samodzielnie rozprzestrzenia się poprzez zainfekowane rozszerzenia Visual Studio Code publikowane w rejestrach Open VSX i Microsoft VS Code Marketplace. Atak celuje w łańcuch dostaw oprogramowania – wprost w narzędzia deweloperskie – kradnie poświadczenia (npm, GitHub), przejmuje środowiska i wykorzystuje maszyny programistów jako infrastrukturę przestępczą.

W skrócie

  • Skala: ok. 35,8 tys. instalacji złośliwych rozszerzeń; co najmniej kilka–kilkanaście paczek w obiegu w OpenVSX i na rynku Microsoftu.
  • Techniki ukrywania: „niewidzialny kod” z użyciem niewidocznych znaków Unicode w źródłach rozszerzeń, utrudniający przegląd i detekcję.
  • Zdolności: kradzież tokenów npm/GitHub, celowanie w 49 wtyczek portfeli krypto, uruchamianie SOCKS proxy i ukrytego VNC/RAT dla pełnego zdalnego dostępu.
  • Propagacja: użycie wykradzionych poświadczeń do publikowania zainfekowanych aktualizacji i przejmowania kolejnych kont/paczek.

Kontekst / historia / powiązania

Pierwsze publiczne raporty pojawiły się 20–24 października 2025 r.. Media branżowe i dostawcy bezpieczeństwa (m.in. BleepingComputer, Dark Reading) potwierdzają, że to jedna z najpoważniejszych jak dotąd kampanii wymierzonych w ekosystem VS Code. Część źródeł wiąże odkrycie z pracą badaczy Koi Security, a rozszerzenia w OpenVSX miały zostać podmienione 17 października; 2 dni później część z nich nadal rozprowadzała malware.

Analiza techniczna / szczegóły luki

Vektor wejścia. GlassWorm trafia do środowisk poprzez instalację (lub aktualizację) zainfekowanych rozszerzeń VS Code z OpenVSX oraz Microsoft Marketplace. Atakujący przejmują konta wydawców lub łańcuch CI/CD i publikują skażone wersje.

„Niewidzialny” kod. Krytycznym elementem jest ukrywanie złośliwej logiki z użyciem znaków sterujących Unicode (np. kierunków zapisu/bidirectional control), które sprawiają, że fragmenty kodu nie są widoczne przy zwykłym przeglądzie i mogą mylić zarówno recenzentów, jak i niektóre narzędzia SAST. Efekt: czysty diff, pozornie prawidłowa składnia, złośliwe ścieżki wykonania zaszyte między literami.

Zdolności po infekcji. Po zainstalowaniu, GlassWorm:

  • eksfiltruje poświadczenia npm i GitHub oraz inne sekrety deweloperskie,
  • skanuje przeglądarkę/środowisko pod kątem 49 rozszerzeń portfeli krypto i próbuje drenować środki,
  • wdraża SOCKS proxy, aby wykorzystywać hosta jako przekaźnik,
  • instaluje ukryte VNC/RAT dla pełnego zdalnego dostępu, utrzymując się w systemie,
  • używa skradzionych tokenów do przejęcia kolejnych pakietów/rozszerzeń i samoreplikacji.

Skala i telemetry. Według niezależnych relacji prasowych i firm badawczych mówimy o ~35,8 tys. instalacji/udanych pobrań skażonych rozszerzeń; atak dotknął co najmniej kilka–kilkanaście pakietów w popularnych rejestrach rozszerzeń.

Praktyczne konsekwencje / ryzyko

  • Kompromitacja łańcucha dostaw: przejęte tokeny npm/GitHub = ryzyko publikacji trojanów w repozytoriach firmy/OSS.
  • Ryzyko finansowe: celowanie w portfele krypto i możliwa utrata środków.
  • Infrastruktura przestępcza: hosty dev stają się proxy i zdalnymi stacjami sterowanymi przez atakujących (VNC/RAT) – ekspozycja sieci wewnętrznej.
  • „Blind spot” w code review: użycie niewidzialnych znaków obchodzi kontrolę peer review i statyczną analizę, co utrudnia tradycyjne procesy SDLC.

Rekomendacje operacyjne / co zrobić teraz

Natychmiast (IR – Incident Response):

  1. Inwentaryzacja rozszerzeń VS Code w organizacji (OpenVSX/Microsoft Marketplace). Wytypować i odinstalować podejrzane/ostatnio aktualizowane.
  2. Rotacja i unieważnienie wszystkich tokenów npm/GitHub/PAT, kluczy CI/CD, cookies sesyjnych przeglądarki; włączyć 2FA i ograniczyć zakres uprawnień (fine-grained PAT).
  3. Izolacja stacji roboczych dev: odłączenie od sieci, skan EDR/AV, detekcja SOCKS proxy i ukrytych usług VNC/RAT; przegląd autostartów i harmonogramów zadań.
  4. Przegląd repozytoriów i rejestrów: niezwłoczne sprawdzenie ostatnich publikacji/commitów/wersji paczek pod kątem nietypowych zmian i „niewidzialnego” Unicode.

W kolejnych dniach (hardening):

  • Wymuś weryfikację wydawcy i pinning zaufanych rozszerzeń; ogranicz instalację do listy dozwolonych (allow-list). (Praktyka zalecana przez branżę w kontekście tego incydentu).
  • W pipeline’ach dodaj kontrole Unicode (detekcja znaków sterujących Bidi, zero-width, itd.) i policy skanów dla rozszerzeń/artefaktów przed dopuszczeniem do stacji dev.
  • Egzekwuj zasadę najmniejszych uprawnień dla tokenów (scopes, TTL, rotacja), ochronę sekretów i monitoring publikacji (alerty przy zmianie maintainerów lub kluczy publikacyjnych).
  • Użyj EDR z regułami na nietypowe połączenia proxy/VNC i anomalie narzędzi deweloperskich; przegląd ruchu wychodzącego pod kątem tuneli SOCKS.

Artefakty/detekcja (przykłady do playbooka IR):

  • Skan plików źródłowych pod kątem znaków: \u202E, \u2066–\u2069, \u200B itd. (Bidi/zero-width).
  • Audyt folderów rozszerzeń ~/.vscode/extensions / %USERPROFILE%\.vscode\extensions pod kątem niepodpisanych/nieznanych vendorów i recent-modified. (Dobre praktyki zgodne z doniesieniami o wektorze).

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

W porównaniu z wcześniejszymi incydentami „tylko” trojanizującymi pojedyncze rozszerzenie, GlassWorm łączy samopropagację (wykorzystanie świeżo wykradzionych tokenów do publikacji kolejnych zainfekowanych aktualizacji) z niewidzialnym kodem Unicode, co utrudnia review i automatyczną analizę. To jakościowy skok względem znanych kampanii typosquattingu i przejęć paczek NPM/VS Code.

Podsumowanie / kluczowe wnioski

  • GlassWorm uderza w samo serce SDLC – narzędzia deweloperskie – i omija klasyczne bramki kontrolne dzięki „niewidzialnym” trikom Unicode.
  • Organizacje powinny traktować sprawę jak incydent bezpieczeństwa łańcucha dostaw: natychmiastowa rotacja sekretów, czyszczenie stacji dev, whitelisting rozszerzeń i kontrole Unicode w pipeline’ach.
  • Nawet po usunięciu skażonych wtyczek, skradzione tokeny mogą umożliwiać dalsze nadużycia – higiena kluczy i monitoring publikacji są krytyczne.

Źródła / bibliografia

  • The Hacker News – „Self-Spreading ‘GlassWorm’ Infects VS Code Extensions…” (24 października 2025). (The Hacker News)
  • BleepingComputer – „Self-spreading GlassWorm malware hits OpenVSX, VS Code registries” (20 października 2025). (BleepingComputer)
  • Dark Reading – „Self-Propagating GlassWorm Attacks VS Code Supply Chain” (20 października 2025). (Dark Reading)
  • Truesec – „GlassWorm – Self-Propagating VSCode Extension Worm” (analiza techniczna, październik 2025). (Truesec)
  • Koi Security (blog) – przegląd zdolności GlassWorm i TTP (październik 2025). (koi.ai)

Raportowanie Incydentów W Zgodzie Z NIS2 – Jak Działa Zasada 24h/72h

Dlaczego raportowanie incydentów stało się kluczowe w dyrektywie NIS2

Dyrektywa NIS2 (Network and Information Systems Directive 2) wprowadza jednolite wymogi w całej UE dotyczące cyberbezpieczeństwa, w tym obowiązek szybkiego zgłaszania poważnych incydentów bezpieczeństwa. Organizacje uznane za podmioty kluczowe lub istotne (ang. essential and important entities) muszą raportować incydenty o znaczącym wpływie na usługi zgodnie z zasadą 24h/72h.

Czytaj dalej „Raportowanie Incydentów W Zgodzie Z NIS2 – Jak Działa Zasada 24h/72h”

Lazarus (Korea Płn.) atakuje europejskie firmy obronne z sektora UAV. Nowa fala „Operation DreamJob”

Wprowadzenie do problemu / definicja kampanii

Badacze ESET opisali nową odsłonę operacji szpiegowskiej Operation DreamJob przypisywanej grupie Lazarus powiązanej z Koreą Północną. Od końca marca 2025 r. atakujący sukcesywnie zaatakowali trzy firmy z branży obronnej w Europie Środkowej i Południowo-Wschodniej, z czego co najmniej dwie są silnie związane z technologiami UAV (drony). Cel: kradzież własności intelektualnej i know-how produkcyjnego. Główne narzędzie na etapie post-exploitation to RAT ScoringMathTea.

Informacje te potwierdzają także serwisy branżowe, które podkreślają związek kampanii z rozwojem programu dronowego w KRLD oraz wykorzystanie fałszywych ofert pracy jako wektora wejścia.

W skrócie

  • Cel: szpiegostwo przemysłowe dotyczące dronów (UAV), komponentów i oprogramowania.
  • Ofiary: 3 firmy obronne (metalurgia, producent części lotniczych, firma obronna).
  • Wejście: socjotechnika „DreamJob” – rekruter + spreparowana dokumentacja / czytnik PDF.
  • Łańcuch infekcji: trojanizowane projekty OSS (np. MuPDF, wtyczki Notepad++/WinMerge, TightVNC, libpcre, DirectX), DLL sideloading, ładowanie w pamięci (MemoryModule-style).
  • Payload: ScoringMathTea RAT (~40 komend), C2 na skompromitowanych serwerach (często w katalogach WordPress).
  • Artefakt: dropppery z wewnętrzną nazwą DroneEXEHijackingLoader.dll (wskazówka na fokus „drone”).
  • Szerszy obraz: stała, ewolucyjna zmiana bibliotek do DLL proxying i dobór nowych projektów OSS do trojanizacji.

Kontekst / historia / powiązania

Operation DreamJob to długoletnia taktyka Lazarusa oparta na latach udanych kampanii z wabikami rekrutacyjnymi; nakłada się z wcześniej opisywanymi operacjami (np. North Star, DeathNote). Motywacja Lazarusa obejmuje szpiegostwo, sabotaż i zysk finansowy, ale w tej fali dominuje espionage na rzecz rozwoju zdolności wojskowych KRLD (m.in. drony). W artykule ESET wskazano również kontekst wojny Rosja–Ukraina i doniesień o przyspieszeniu programu UAV w KRLD.

Analiza techniczna / szczegóły kampanii

Wektor wejścia i initial access

  • Kontakt „rekrutera”, dokument z opisem stanowiska i trojanizowany czytnik PDF do jego otwarcia.
  • Alternatywnie – zachęta do pobrania „przydatnej” wtyczki/oprogramowania OSS z dołączonym loaderem.

Łańcuch infekcji (przykładowy)

  1. Uruchomienie trojanizowanej aplikacji/plugina (MuPDF, Notepad++/WinMerge plugin, TightVNC, libpcre, DirectX wrapper).
  2. DLL sideloading / proxying – złośliwy DLL ładowany przez zaufany proces.
  3. Loader decrypts & reflectively loads payload w pamięci (MemoryModule-style).
  4. Dostarczenie ScoringMathTea RAT lub BinMergeLoader (MISTPEN) – ten drugi potrafi nadużywać Microsoft Graph API i tokenów do pozyskiwania dalszych ładunków.

ScoringMathTea RAT

  • ~40 poleceń: zarządzanie plikami/procesami, recon, wymiana konfiguracji, otwieranie połączeń TCP, pobieranie/uruchamianie kolejnych modułów.
  • C2 często na skompromitowanych serwerach www, ukryty w folderach WordPress (motywy/wtyczki).
  • Obserwowany w atakach od 2022/2023 r., m.in. na firmy w PL (obrona), UK (automatyka), IT (aerospace), co potwierdza, że to „flagowy” ładunek DreamJob.

Artefakty i telemetry

  • Wspólna wewnętrzna nazwa DLL: DroneEXEHijackingLoader.dll.
  • Zgłoszenia do VirusTotal (IT, ES) z próbkami trojanizowanych komponentów (np. MuPDF, dinput.dll).

Praktyczne konsekwencje / ryzyko

  • Utrata IP (projekty, BOM, procesy technologiczne, sterowanie, algorytmy kontroli lotu).
  • Ryzyko supply-chain – trojanizowane biblioteki OSS w toolchainie inżynierskim.
  • Eskalacja geopolityczna – wykorzystanie wycieków do rozwoju programów zbrojeniowych KRLD i eksportu uzbrojenia.
  • Trwałość operacji – stabilny TTP (DLL sideloading + OSS trojanizacja) + niska widoczność (reflective loading).

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/IR

  1. Hunting TTP-based:
    • Wzorce DLL sideloading (nieoczekiwane biblioteki przy zaufanych EXE, anomalie w LoadLibrary),
    • Reflective loader artefakty w pamięci, nietypowe sekcje PE, brak na dysku,
    • Nienaturalne wywołania Graph API/tokeny z hostów użytkowników.
  2. Network:
    • Wykrywanie C2 w katalogach WordPress (ścieżki /wp-content/themes/, /plugins/ używane nienormalnie),
    • Egress deny-by-default + TLS inspection dla ruchu do rzadkich hostów,
    • Blokada nietypowych TCP beacons z aplikacji biurowych.
  3. EDR/OS hardening:
    • Windows Defender Application Control / WDAC lub AppLocker do whitelisting’u binarek i DLL,
    • PreferSecureLibraryLoading / Safe DLL Search Mode i blokady znanych ścieżek sideloadingu,
    • ASR rules (blokowanie ładowania DLL z katalogów użytkownika/temp). (Dobre praktyki branżowe w kontekście DLL sideloading).
  4. OSS hygiene:
    • Mirror / hash-pinning dla MuPDF, Notepad++/WinMerge plugins, TightVNC, libpcre itp.; pobrania tylko z verified release z podpisem,
    • SBOM i skan integralności w CI/CD narzędzi inżynierskich,
    • Blokada uruchamiania niepodpisanych plug-inów.
  5. Identity & SaaS:
    • MFA odporne na phishing (FIDO2),
    • Monitorowanie rzadkich grantów i uprawnień Microsoft Graph oraz tworzenia ukrytych rejestracji aplikacji.
  6. User awareness / proces HR:
    • Procedura „oddzielne środowisko” do otwierania dokumentów rekrutacyjnych (sandbox/VDI),
    • Weryfikacja rekruterów (domena, DKIM/DMARC, kontakt przez oficjalny portal),
    • Zakaz instalacji „czytników” przysłanych przez osoby trzecie.

ESET opublikował IoC (domeny, skróty binarek) do tej fali – włącz je do SIEM/EDR i feedów blokujących.

Różnice / porównania z innymi przypadkami

  • Konsekwencja zamiast rewolucji: ScoringMathTea od 2022/2023 r. zmienił się nieznacznie – Lazarus stawia na stabilny, wystarczający zestaw funkcji, a polimorfizm przenosi do warstwy dropperów/loaderów.
  • Nowe biblioteki do proxy’owania DLL i dobór mniej popularnych projektów OSS do trojanizacji zwiększają evasiveness przy zachowaniu tego samego „silnika” C2.
  • Fokus sektorowy: wcześniejsze DreamJob częściej celowały w krypto/IT; obecnie nacisk na UAV i łańcuch dostaw obronności.

Podsumowanie / kluczowe wnioski

Lazarus nie musi przeprojektowywać narzędzi – wystarczy zmieniać nośniki (OSS, wtyczki) i utrzymywać presję socjotechniczną. Organizacje z sektora obronnego, szczególnie UAV, powinny przenieść kontrolę z samej detekcji plików na TTP-first detection & hardening (DLL sideloading, reflective loading, Graph API abuse) oraz uszczelnić procesy HR.

Źródła / bibliografia

  • ESET Research – „Gotta fly: Lazarus targets the UAV sector” (23.10.2025). Najpełniejsza analiza techniczna i kontekst. (welivesecurity.com)
  • ESET Newsroom – komunikat prasowy z kluczowymi tezami i timeline. (ESET)
  • BleepingComputer – omówienie łańcuchów ataku, OSS i IoC. (BleepingComputer)
  • CyberScoop – streszczenie z akcentem na motywację i artefakt „DroneEXEHijackingLoader.dll”. (CyberScoop)
  • Dark Reading – komentarz o stabilności ScoringMathTea i ewolucji DLL proxying. (Dark Reading)

Toys “R” Us Canada: wyciek danych klientów potwierdzony. Co wiemy i jak się chronić

Wprowadzenie do problemu / definicja luki

Toys “R” Us Canada powiadomiło klientów o naruszeniu bezpieczeństwa, w wyniku którego nieuprawniony podmiot skopiował część rekordów z bazy danych klientów, a następnie je upublicznił w sieci. Firma po raz pierwszy dowiedziała się o sprawie 30 lipca 2025 r., gdy na „nieindeksowanej części internetu” pojawiły się rzekome dane klientów. Późniejsza analiza z udziałem zewnętrznych ekspertów potwierdziła autentyczność informacji.

W skrócie

  • Zakres danych: imię i nazwisko, adres korespondencyjny, e-mail, numer telefonu. Bez haseł i danych kart płatniczych.
  • Linia czasu: 30.07.2025 – odkrycie wycieku w sieci; 23.10.2025 – wysyłka powiadomień do klientów i mediów.
  • Status: Dane zostały już opublikowane online; firma zgłasza incydent regulatorom prywatności w Kanadzie i wdraża dodatkowe środki ochrony.

Kontekst / historia / powiązania

Kanadyjski sektor retail w 2025 r. mierzy się z serią incydentów dotyczących baz klientów. Kilka tygodni wcześniej Canadian Tire poinformował o naruszeniu obejmującym dane e-commerce (m.in. imię i nazwisko, adres, e-mail, rok urodzenia), co pokazuje szerszy trend ukierunkowania przestępców na bazy CRM/lojalnościowe i zaplecza sklepów internetowych.

Analiza techniczna / szczegóły luki

Z dotychczasowych komunikatów wynika, że atakujący skopiowali rekordy z bazy klientów i zrzucili je do publicznego obiegu (tzw. data dump). W powiadomieniach Toys “R” Us Canada podkreślono brak dowodów na kompromitację haseł czy danych kart oraz fakt, że skradzione atrybuty to wyłącznie PII niskiej wrażliwości (contact data). Firma nie ujawniła wektora wejścia ani okresu przebywania w systemach (dwell time).

Typy ujawnionych danych (per osoba, w różnej kombinacji):

  • imię i nazwisko,
  • adres pocztowy,
  • e-mail,
  • numer telefonu.

Proces reakcji: zatrudnienie zewnętrznych specjalistów ds. cyberbezpieczeństwa, potwierdzenie autentyczności dumpa, powiadomienie adresatów i regulatorów. Brak publicznych informacji o żądaniu okupu czy negocjacjach.

Praktyczne konsekwencje / ryzyko

Choć nie wyciekły hasła ani pełne dane kart, ryzyko dla klientów jest realne:

  • Spear-phishing i smishing (wiarygodne, spersonalizowane wiadomości podszywające się pod Toys “R” Us).
  • Account takeover przez reset hasła (jeśli ten sam e-mail jest używany w wielu usługach i wyciek łączy się z innymi zbiorami danych).
  • Ataki socjotechniczne (np. weryfikacja adresu/telefonu “w celu potwierdzenia zamówienia”).
  • Ryzyko prywatności offline (korespondencja fizyczna pod realny adres).

Rekomendacje operacyjne / co zrobić teraz

Dla osób, które otrzymały powiadomienie (i szerzej – dla klientów e-commerce w Kanadzie):

  1. Zmień hasła wszędzie, gdzie używasz tego samego e-maila; włącz MFA (aplikacja TOTP, klucze FIDO) w usługach krytycznych.
  2. Filtruj phishing: nie klikaj linków z SMS-ów/e-maili podszywających się pod sklep; wejdź ręcznie na stronę, aby zweryfikować komunikat.
  3. Ustaw alerty na koncie e-mail (reguły, ostrzeżenia logowania), monitoruj przekierowania poczty.
  4. Zastrzeż preferencje marketingowe (ogranicz profilowanie e-mail/SMS, jeśli nie chcesz otrzymywać kampanii mogących ułatwiać podszywanie).
  5. Monitoruj raporty kredytowe i rozważ alert fraudowy, jeśli pojawią się podejrzane działania.
  6. Zapisz treść otrzymanego powiadomienia (data, ID sprawy, kontakt do Privacy Officer) – ułatwi to ewentualne zgłoszenia do regulatora.

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

  • Toys “R” Us Canada (październik 2025): kontaktowe PII (imię, adres, e-mail, telefon), brak haseł/kart, publiczny dump danych. Źródłem weryfikacji była obserwacja „nieindeksowanej” części internetu i analiza ekspertów.
  • Canadian Tire (październik 2025): naruszenie bazy e-commerce (w tym szyfrowane hasła i skrócone numery kart), bez danych bankowych/lojalnościowych. Różni się zakresem atrybutów i architekturą dotkniętej bazy.

Podsumowanie / kluczowe wnioski

Publikacja danych kontaktowych klientów Toys “R” Us Canada oznacza długotrwałe ryzyko ataków socjotechnicznych. Nawet bez haseł i kart, kombinacja imię+adres+telefon+e-mail to zestaw umożliwiający skuteczne phishingi i podszywanie pod obsługę klienta. Organizacja deklaruje współpracę z ekspertami i regulatorami oraz wzmocnienie zabezpieczeń, ale higiena kont po stronie użytkowników pozostaje krytyczna.

Źródła / bibliografia

  • BleepingComputer: “Toys ‘R’ Us Canada warns customers’ info leaked in data breach” (23.10.2025). Najpełniejsze wstępne szczegóły incydentu i timeline. (BleepingComputer)
  • The Register: “Crooks swipe Toys R Us Canada customer data and dump it online” (23.10.2025). Potwierdzenia zakresu danych, brak haseł/kart, komentarz dot. ryzyk. (The Register)
  • CityNews / The Canadian Press: “Toys ‘R’ Us Canada customers notified of breach of personal information” (23.10.2025). Informacja o powiadomieniach e-mail i wyjaśnienia nt. „nieindeksowanej” sieci. (CityNews Vancouver)
  • Canadian Tire Corporation – strona incydentu (kontekst porównawczy, 10.2025). (corp.canadiantire.ca)

Rosja „zarządza” cyberprzestępcami? Nowe ustalenia: od tolerancji do aktywnego sterowania ekosystemem

Wprowadzenie do problemu / definicja zjawiska

Najnowsza analiza Recorded Future (Insikt Group) opisuje jakościową zmianę w relacjach państwo–podziemie w Rosji: od biernej tolerancji cyberprzestępców do aktywnego zarządzania nimi przez służby — z selektywnymi aresztami „użytecznych” ogniw łańcucha i ochroną graczy mających wartość wywiadowczą. Publiczne doniesienia i wycieki czatów mają wskazywać nawet na koordynację zadań między liderami grup a pośrednikami powiązanymi ze służbami.

W skrócie

  • Po 2023 r. Rosja miała przejść od parasola ochronnego do sterowania rynkiem: pokazowe zatrzymania dotykają głównie „enablerów” (np. usługi cash-out), podczas gdy trzon gangów ransomware pozostaje nietknięty.
  • Operacja Endgame (2024–2025) mocno uderzyła w łańcuch dostaw ransomware (dropp ery/loadery, botnety, infrastrukturę finansową), co wywołało reakcję i repozycjonowanie rosyjskich służb.
  • Rosyjskie śledztwa i masowe zatrzymania po sankcjach wobec Cryptex/UAPS (ok. 100 osób, konfiskata ~16 mln USD) zbiegły się w czasie z działaniami Zachodu.
  • Podziemie się fragmentuje: mniej otwartych rekrutacji RaaS, większa paranoja OPSEC, przejście na zamknięte kanały.

Kontekst / historia / powiązania

Operacja Endgame to skoordynowana akcja (UE/USA i partnerzy) rozbijająca infrastrukturę „dropperów” i botnetów (m.in. IcedID, SystemBC, Pikabot, SmokeLoader, Bumblebee), z setkami serwerów przejętych/wyłączonych i tysiącami domen pod kontrolą organów ścigania. Kontynuacja w 2025 r. uderzała w następców i nowe warianty, łącząc techniczne przejęcia z presją informacyjną (ujawnienia nazwisk, materiały wideo).

Równolegle, po sankcjach USA i komunikatach Endgame, Komitet Śledczy FR ogłosił śledztwa i zatrzymania powiązane z UAPS/Cryptex, prezentując spektakularne liczby zatrzymanych i zajętych aktywów — co analitycy interpretują jako zarządzanie reputacją i „regulację rynku”, nie jego likwidację.

Analiza techniczna / szczegóły zjawiska

Mechanizmy „zarządzania” wg Recorded Future:

  • Selektywne egzekwowanie prawa: nacisk na infrastrukturę finansową (exchangi, usługi prania), mniejsza presja na rdzeń operatorów RaaS powiązanych z aparatem państwa.
  • Kanonizacja „bezpiecznej przystani warunkowej”: ochronę zyskują podmioty mające użyteczność wywiadowczą/geopolityczną, podczas gdy „spieniężacze” stają się jednorazowi pod ostrzałem zewnętrznym.
  • OPSEC i rekrutacja: spadek otwartych naborów RaaS, przejście w pół-zamknięte programy, twardsze KYC w podziemiu, decentralizacja komunikacji.
  • Wyciek czatów Black Basta (kontynuacja linii Conti/TrickBot) dostarczył wglądu w strukturę, konflikty i relacje z dostawcami usług — a także wzmianki o rzekomych kontaktach niektórych liderów z rosyjskimi służbami.

W tle toczy się identyfikacja i „naming & shaming” figur kluczowych (np. przywództwa TrickBot/Conti w ramach Endgame), ale bez proporcjonalnych działań po stronie Rosji wobec najwyższych szczebli.

Praktyczne konsekwencje / ryzyko

  • Trwalsze ekosystemy RaaS: mniejsza widoczność naborów ≠ mniejsza aktywność; rośnie bariera zaufania i jakość OPSEC operatorów.
  • Pivot taktyczny: większa rotacja marek/aliasów, modularne „łańcuchy kill chain”, lepsze maskowanie TTPs, krótszy czas życia infrastruktur.
  • Ryzyko geopolityczne: dobór ofiar może bardziej odzwierciedlać interesy państwowe (np. przemysł krytyczny, sektor publiczny, łańcuch dostaw), co utrudnia czystą kwalifikację „crime-only”.
  • Compliance & ubezpieczenia: rośnie presja regulacyjna (raportowanie incydentów, ograniczenia płatności okupu), a decyzje o płatnościach niosą ryzyko sankcyjne.

Rekomendacje operacyjne / co zrobić teraz

  1. Zerwać łańcuch dostaw RaaS:
    • Blokady loaderów/droppers (IcedID, SystemBC, Pikabot, SmokeLoader, Bumblebee) w EDR/NDR; kontinuum Threat Hunting pod IOC z biuletynów Endgame.
  2. Hardening płatności i kryptoprzepływów:
    • Ekranizacja kanałów płatności (AML/KYC), weryfikacja pośredników, scenariusze OFAC/EU przy decyzjach okupu.
  3. Segmentacja i kopie zapasowe klasy „restore-first”:
    • Testy odtwarzania, odseparowane kopie, kontrola uprawnień (PAW/JIT/JEA), honeytokens i DRaaS.
  4. Minimalizacja blast radius:
    • U2F/FIDO2, phishing-resistant MFA, PAM, EDR z izolacją, canary accounts, blokady makr i włączona kontrola aplikacji.
  5. Telemetry for intel:
    • Systematyczny log enrichment (DNS, DHCP, proxy, EDR, SaaS), mapowanie do MITRE ATT&CK, playbooki na TTP powiązane z TrickBot/Conti/Black Basta.
  6. Ćwiczenia decyzyjne (war-gaming):
    • Scenariusze ataku sterowanego politycznie; ścieżki komunikacji/regulator, „no-ransom default” + ścieżki wyjątków.
  7. Zgodność z wytycznymi LEA:
    • Monitoruj aktualizacje i IOC publikowane w ramach Endgame/FBI/Europol i włącz do pipeline’u detekcji.

Różnice / porównania z innymi przypadkami

  • Dawniej (≈2014–2021): „tolerancja w zamian za lojalność” i okazjonalne zatrzymania pod presją; dziś — „sterowanie” rynkiem w reakcji na globalne operacje i koszty polityczne.
  • Inne państwa sankcjonowane: podobne modele (parasole ochronne nad grupami APT/fin-crime), lecz skala rosyjskiego RaaS-industrial complex i włączenie warstwy finansowej (exchangi, UAPS-like) czynią ekosystem bardziej modularnym i odpornym.

Podsumowanie / kluczowe wnioski

  • Teza „Controlled Impunity”: Rosja nie tyle likwiduje cyberprzestępczość, co steruje nią, godząc presję międzynarodową z własnym interesem.
  • Endgame zmieniła opłacalność niektórych ról w łańcuchu ransomware (zwłaszcza cash-out), ale rdzeń operatorów pozostaje aktywny i adaptacyjny.
  • Dla obrońców: przygotuj się na bardziej skryte RaaS, krótsze okna wykrycia i większy komponent geopolityczny w doborze celów.

Źródła / bibliografia

  • SecurityWeek: Russian Government Now Actively Managing Cybercrime Groups (23 października 2025). (SecurityWeek)
  • Recorded Future (Insikt Group): Dark Covenant 3.0: Controlled Impunity and Russia’s Cybercriminals (2025). (recordedfuture.com)
  • Europol: Largest ever operation against botnets… (Operation Endgame) (29 maja 2024) oraz Operation Endgame strikes again (22 maja 2025). (Europol)
  • FBI: Operation Endgame — Coordinated Worldwide Law Enforcement Action (28 maja 2024). (Federal Bureau of Investigation)
  • CyberScoop / The Record: Russia arrests nearly 100… (UAPS/Cryptex) (2 października 2024). (CyberScoop)

Hakerzy podszywają się pod kirgiskich urzędników. Kampania cyberszpiegowska wymierzona w rosyjskie instytucje (FoalShell & StallionRAT)

Wprowadzenie do problemu / definicja luki

Między majem a sierpniem 2025 r. klaster szpiegowski określany jako Cavalry Werewolf (powiązywany także z nazwami YoroTrooper i Silent Lynx) prowadził kampanię spear-phishingową wymierzoną w rosyjską administrację publiczną oraz firmy z sektorów energii, górnictwa i produkcji. Atakujący podszywali się pod kirgiskie ministerstwa, rozsyłając pisma urzędowe z archiwami RAR zawierającymi autorskie malware: FoalShell (reverse shell) i StallionRAT (RAT sterowany przez bota Telegram) — w części przypadków z wykorzystaniem skompro­m­itowanych prawdziwych skrzynek rządowych.

W skrócie

  • Wejście: spójne stylistycznie maile „z urzędu” (m.in. z resortów gospodarki i transportu KR), nierzadko z prawdziwych, przejętych adresów. Załączniki RAR prowadzą do droppera FoalShell/StallionRAT.
  • Cel: rosyjskie instytucje rządowe + przemysł (energia, górnictwo, produkcja); pojawiają się ślady zainteresowania Tadżykistanem i pliki nazwane po arabsku (rekonesans na Bliski Wschód).
  • TTPs: własne narzędzia, testowanie dodatkowych tooli (np. AsyncRAT), C2 przez Telegram, reverse shell w C# / C++ / Go.
  • Atrybucja historyczna: wcześniejsze badania Cisco Talos łączą YoroTrooper z Kazachstanem (język, waluta, profil celów).

Kontekst / historia / powiązania

YoroTrooper/Silent Lynx obserwowany jest co najmniej od 2022 r., z celami w regionie WNP i placówkach dyplomatycznych. W 2023 r. Talos opublikował obszerny przegląd kampanii YoroTrooper; w 2023–2025 pojawiały się kolejne doniesienia o podszywaniu się pod instytucje państwowe w Azji Centralnej. Najnowsza fala (lato 2025) koncentruje się na Rosji, ale wskazówki językowe i nazewnicze sugerują szersze ambicje geograficzne.

Analiza techniczna / szczegóły luki

Łańcuch infekcji

  1. Spear-phishing: wiadomości stylizowane na korespondencję urzędową (np. „trzymiesięczne wyniki wspólnych działań”, „lista pracowników do premii”), nadane z look-alike’ów lub przejętych kont urzędowych.
  2. Załącznik RAR: zawiera loader prowadzący do FoalShell (reverse shell) lub StallionRAT.
  3. Utrzymanie dostępu i C2:
    • FoalShell: wielojęzyczne implementacje (C#, C++, Go) uruchamiają ukryty cmd.exe i tunelują I/O do C2 (różne adresy IP/443 wg wariantów).
    • StallionRAT: implementacje w Go/PowerShell/Python; komunikacja i polecenia przez bota Telegram (/list, /go, /upload), exfil plików do katalogów publicznych.

Techniki (wybrane mapowanie MITRE ATT&CK):

  • T1566.001 Spear-phishing Attachment (RAR/archiwa) — wektor wejścia.
  • T1059 Command and Scripting Interpreter (PowerShell, cmd.exe).
  • T1105 Ingress Tool Transfer / T1071.001 Application Layer (Telegram jako kanał C2).
  • T1036 Masquerading (wiarygodne nazwy plików, formaty pism).

Dodatkowe obserwacje obronne (DFIR/Threat Hunting):

  • Monitorowanie tworzenia archiwów o nazwach „biurowych” w %LocalAppData%\Microsoft\Windows\INetCache\Content.Outlook\ na stacjach z Outlookiem.
  • Wykrywanie krótkotrwałych procesów cmd.exe uruchamianych przez nietypowych rodziców oraz anomalii w ruchu do Telegram API z hostów korporacyjnych.

Praktyczne konsekwencje / ryzyko

  • Kradzież danych i dostępów w instytucjach publicznych i firmach infrastrukturalnych (ryzyko wtórnych nadużyć, pivotu do OT, kompromitacji łańcucha dostaw).
  • Eskalacja geograficzna: artefakty w jęz. tadżyckim i arabskim wskazują na przygotowania do ataków poza Rosją; organizacje w Azji Centralnej i na Bliskim Wschodzie powinny podnieść czujność.
  • Inżynieria społeczna na brandach państwowych: podszywanie się pod ministerstwa zwiększa skuteczność kliknięć i utrudnia filtrowanie poczty.

Rekomendacje operacyjne / co zrobić teraz

E-mail i brama:

  • Blokowanie RAR/ACE/ISO z poczty do czasu ręcznej weryfikacji; sandboxing archiwów i skryptów.
  • Reguły YARA/EDR pod FoalShell i StallionRAT (na bazie IOCs z publikacji) oraz detekcja wywołań PowerShell z EncodedCommand/Bypass.

Host:

  • Polityki Constrained Language Mode dla PowerShell, Script Block Logging + centralna telemetria.
  • Detections na ukryte uruchomienia cmd.exe i nietypowe parent-child (np. z katalogów tymczasowych/outlook cache).

Sieć:

  • Blokowanie/monitoring ruchu do Telegram z sieci korporacyjnej; TLS inspection na wybranych strefach; listy dozwolonych.

Tożsamość i procesy:

  • Ochrona i audyt skrzynek „wysokiego zaufania” (departamenty: kadry, finanse, protokół dyplomatyczny), MFA i DMARC/DKIM/SPF w trybie reject dla domen urzędowych/partnerskich.

Threat Intel & IR:

  • Konsumpcja IOC/TTP z najnowszych analiz (BI.ZONE, Picus) i korelacja z lokalnymi logami; playbook IR na przypadki Telegram-C2.

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

  • YoroTrooper vs. inne rosyjsko-powiązane APT: Choć część klastrów w regionie bywa łączona z Rosją (np. APT28/Sednit), w przypadku YoroTrooper/Cavalry Werewolf wcześniejsze prace Cisco Talos wskazują na powiązania z Kazachstanem (język, waluta, profil celów), a nie z GRU/FSB. Nie ma jednoznacznej, oficjalnej atrybucji państwowej dla najnowszej fali; Picus jej nie stawia.
  • Kanał C2 przez Telegram odróżnia kampanię od wielu klasycznych operacji (częściej HTTP(S)/mail/OneDrive), choć aplikacyjne C2 pojawiało się już wcześniej u innych aktorów.

Podsumowanie / kluczowe wnioski

Cavalry Werewolf skutecznie eksploatuje zaufanie między instytucjami państwowymi (tu: wizerunek urzędów Kirgistanu), łącząc wysokiej jakości socjotechnikę z lekkimi, autorskimi narzędziami (FoalShell, StallionRAT). Wektor wejścia jest prosty (RAR w e-mailu), ale opakowany w wiarygodne, urzędowe narracje. Organizacje — zwłaszcza w administracji i przemyśle — powinny zaostrzyć polityki pocztowe, telemetrię PowerShell, oraz filtrować/monitorować Telegram jako potencjalny kanał C2.

Źródła / bibliografia

  1. The Record: „Hackers posing as Kyrgyz officials target Russian agencies in cyber espionage campaign”, 23 października 2025. (The Record from Recorded Future)
  2. BI.ZONE: „Espionage clusters disguise themselves as Kyrgyz state officials”, 2 października 2025. (BI.ZONE)
  3. Picus Security: „Cavalry Werewolf APT: Exposing FoalShell and StallionRAT Malware”, 20 października 2025. (Picus Security)
  4. Cisco Talos: „YoroTrooper operators likely based in Kazakhstan”, 25 października 2023. (Cisco Talos Blog)
  5. Cisco Talos: „Talos uncovers espionage campaigns targeting CIS countries… (YoroTrooper)”, 14 marca 2023. (Cisco Talos Blog)

BIND łata wysokie luki typu DNS cache poisoning (CVE-2025-40778, CVE-2025-40780). Co musisz zaktualizować i dlaczego to pilne

Wprowadzenie do problemu / definicja luki

Internet Systems Consortium (ISC) opublikowało aktualizacje BIND 9 usuwające poważne podatności umożliwiające DNS cache poisoning — wstrzyknięcie sfałszowanych rekordów DNS do pamięci podręcznej resolvera. Dwie główne luki to CVE-2025-40778 („niezamówione rekordy RRs” przyjmowane zbyt pobłażliwie) oraz CVE-2025-40780 (osłabione losowanie — możliwe przewidzenie portu źródłowego i ID zapytania), obie z oceną CVSS 8.6 (High). Łatki wydano 22–23 października 2025 r. wraz z wersjami 9.18.41, 9.20.15, 9.21.14 (oraz gałęzie S1 dla klientów wsparcia). Autorytatywne serwery zwykle nie są dotknięte, ryzyko dotyczy resolverów. Brak znanych obejść — aktualizacja jest jedyną skuteczną ochroną.

W skrócie

  • Na czym polega błąd?
    • CVE-2025-40778: resolver akceptuje „niezamówione” rekordy w odpowiedziach DNS, co pozwala zatruć cache.
    • CVE-2025-40780: słabości w PRNG umożliwiają w pewnych warunkach przewidzenie portu źródłowego i QID, co ułatwia spoofing odpowiedzi.
  • Kto jest zagrożony? Resolver BIND 9 w wielu wspieranych gałęziach (9.16/9.18/9.20/9.21 — szczegółowe zakresy poniżej). Autorytatywne instancje co do zasady nie.
  • Jakie wersje naprawiają? 9.18.41, 9.20.15, 9.21.14 (+ 9.18.41-S1, 9.20.15-S1).
  • Czy są exploity? Brak informacji o aktywnej eksploatacji w chwili publikacji.

Kontekst / historia / powiązania

ISC ujawniło trzy luki 22 października 2025 r.: oprócz dwóch błędów „cache poisoning” jest jeszcze CVE-2025-8677 (DoS przez złośliwe DNSKEY). Ogłoszenie trafiło również na listę oss-security, gdzie wskazano gotowe łatki oraz katalogi „patches” dla każdej gałęzi.

Publikacje branżowe (m.in. SecurityWeek) podkreślają, że nowe wersje BIND już są dostępne i należy je wdrożyć priorytetowo, zwłaszcza na publicznie dostępnych resolverach.

Analiza techniczna / szczegóły luki

CVE-2025-40778 – „niezamówione” rekordy RRs (unsolicited RRs)

  • Istota: w określonych okolicznościach BIND zbyt liberalnie akceptuje rekordy znajdujące się w sekcjach odpowiedzi, które nie są bezpośrednio związane z zapytaniem. To otwiera drogę do wstrzyknięcia sfałszowanych danych (np. A/AAAA/CNAME/NS) do cache.
  • Wpływ: manipulacja przyszłymi rozstrzygnięciami nazw (przekierowanie ruchu, MITM, phishing na poziomie DNS).
  • Zakres wersji podatnych (BIND): 9.11.0–9.16.50, 9.18.0–9.18.39, 9.20.0–9.20.13, 9.21.0–9.21.12; podobne dla edycji S1. Brak obejść.

CVE-2025-40780 – osłabiony PRNG (przewidywalny port/QID)

  • Istota: w pewnych warunkach słabości PRNG zmniejszają entropię kombinacji source port + query ID, co pozwala napastnikowi przygotować wiarygodną, sfałszowaną odpowiedź zanim dotrze prawdziwa.
  • Wpływ: skuteczny spoofing odpowiedzi i zatrucie cache.
  • Zakres wersji podatnych (BIND): 9.16.0–9.16.50, 9.18.0–9.18.39, 9.20.0–9.20.13, 9.21.0–9.21.12; brak znanych obejść. CVSS 8.6.

Trzecia luka: CVE-2025-8677 (DoS)

  • Opis skrótowy: możliwy DoS przy przetwarzaniu specjalnie spreparowanych rekordów DNSKEY; może prowadzić do wyczerpania CPU i spadku dostępności usługi. (Szczegóły w advisory ISC i notce SecurityWeek).

Praktyczne konsekwencje / ryzyko

  • Integritety DNS: Zatrucie cache pozwala zwrócić użytkownikom dowolne IP dla legalnej domeny (np. serwer atakującego), co ułatwia phishing, kradzież sesji i rozprzestrzenianie malware.
  • Łańcuchy zależności: usługi mikroserwisowe i IoT korzystające z lokalnych resolverów mogą przekierować ruch wewnętrzny poza zaufany perymetr.
  • Atak na skalę internetu: publiczne, rekurencyjne resolvery o dużym wolumenie zapytań są szczególnie atrakcyjne — jedna udana iniekcja rekordu NS/CNAME może mieć szeroki efekt kaskadowy.
  • Brak obejść: bez aktualizacji trudno efektywnie zredukować ryzyko, bo problem dotyka logiki akceptacji odpowiedzi i/lub entropii transakcji.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast zaktualizuj BIND do najbliższej wspieranej wersji łatającej: 9.18.41, 9.20.15 lub 9.21.14 (w edycji S1 odpowiednio 9.18.41-S1, 9.20.15-S1). Zweryfikuj, że binaria rzeczywiście pochodzą z tych gałęzi.
  2. Zweryfikuj status pakietów dystrybucyjnych. Dla Ubuntu poprawki są już propagowane (np. noble/jammy), ale wersje i numery paczek mogą się różnić — porównaj z tablicami dystrybutora.
  3. Ogranicz ekspozycję resolverów:
    • nie udostępniaj rekursji klientom spoza zaufanych AS/VLAN;
    • włącz ACL/ views i filtrowanie źródeł;
    • jeśli to możliwe, nie wystawiaj publicznych resolverów dla świata. (Dobre praktyki wspierają ograniczenie skutków nawet po aktualizacji).
  4. Wzmocnij odporność na spoofing:
    • wymuś source-port randomization i upewnij się, że żaden middlebox nie „uładza” portów;
    • utrzymuj DNS Cookies/0x20 case randomization;
    • stosuj DNSSEC (walidacja) — nie eliminuje wszystkich ryzyk operacyjnych, ale znacząco utrudnia skuteczne zatruwanie cache. (Uwaga: artykuł dotyczy luk w resolverze; DNSSEC chroni integralność danych autorytatywnych, ale wymaga poprawnej walidacji po stronie resolvera).
  5. Monitoruj anomalie DNS: nagłe zmiany w statystykach NXDOMAIN/ SERVFAIL, nieoczekiwane rekordy NS/CNAME w cache, wzrost ruchu do „nowych” upstreamów.
  6. Plan awaryjny: przygotuj szybkie „flush cache” na instancjach, playbook na rollback zmian stref, oraz możliwość przełączenia klientów na alternatywny, zaufany resolver na czas incydentu.

Różnice / porównania z innymi przypadkami

  • ECS/Rebirthday i inne wektory historyczne: wcześniejsze scenariusze cache poisoning bywały związane z EDNS Client Subnet (ECS) i specyficzną logiką mieszania odpowiedzi. Obecne luki celują wprost w politykę akceptacji rekordów (40778) oraz entropię transakcji (40780), co przywraca klasyczne ryzyko „Kaminsky-style”, ale w nowym wydaniu i na współczesnych gałęziach BIND. (Zakres techniczny i skale wersji potwierdza ISC; dystrybutorzy publikują własne statusy).

Podsumowanie / kluczowe wnioski

  • Dwie luki „High” w BIND 9 (CVE-2025-40778, CVE-2025-40780) umożliwiają zatruwanie cache resolvera.
  • Brak obejść. Jedyną sensowną odpowiedzią jest natychmiastowa aktualizacja do 9.18.41 / 9.20.15 / 9.21.14 (S1: 9.18.41-S1 / 9.20.15-S1).
  • Autorytatywne serwery co do zasady bez wpływu, ale sprawdź, czy nie wykonują rekursji „przy okazji”.
  • Uporządkuj ekspozycję resolverów i wzmocnij higienę DNS (DNSSEC, losowość portów/QID, monitoring).

Źródła / bibliografia

  1. ISC KB – CVE-2025-40778: Cache poisoning attacks with unsolicited RRs (wersje podatne, brak obejść, wersje naprawcze). (kb.isc.org)
  2. ISC KB – CVE-2025-40780: Cache poisoning due to weak PRNG (opis PRNG, zakres wersji, CVSS, fixed). (kb.isc.org)
  3. Openwall oss-security – ogłoszenie ISC o trzech lukach w BIND 9 (CVE-2025-8677/40778/40780) i lokalizacje patchy. (Openwall)
  4. SecurityWeek – przegląd aktualizacji BIND i streszczenie ryzyka/wersji. (SecurityWeek)
  5. Ubuntu CVE-2025-40778 – status dystrybucyjny i wersje paczek. (Ubuntu)