Archiwa: Windows - Security Bez Tabu

APT41-linked „Silver Dragon” atakuje administrację: Cobalt Strike, tunelowanie DNS i C2 przez Google Drive

Wprowadzenie do problemu / definicja luki

W marcu 2026 r. Check Point opisał aktywność klastra APT nazwanego Silver Dragon, który od co najmniej połowy 2024 r. prowadzi kampanie ukierunkowane głównie na instytucje rządowe w Europie i Azji Południowo-Wschodniej. Wyróżnikiem działań jest łączenie kilku łańcuchów infekcji z utrzymaniem dostępu poprzez nadużycie legalnych komponentów Windows, a także „ukrywanie” komunikacji C2 w zaufanych usługach (m.in. Google Drive).


W skrócie

  • Silver Dragon przypisywany jest z wysokim prawdopodobieństwem do chińskiego ekosystemu APT41 (na podstawie zbieżności technik i artefaktów operacyjnych).
  • Wejście: eksploatacja publicznie wystawionych serwerów + phishing z załącznikami.
  • Utrzymanie i C2: Cobalt Strike + tunelowanie DNS oraz własny backdoor GearDoor komunikujący się przez Google Drive.
  • Narzędzia post-exploitation: m.in. SliverScreen (zrzuty ekranu) i SSHcmd (zdalne komendy/transfer przez SSH).

Kontekst / historia / powiązania

Silver Dragon jest opisywany jako „cluster” (zestaw kampanii i TTP), a nie koniecznie zupełnie nowa, niezależna grupa. Check Point wskazuje na korelację operacyjną z APT41; The Hacker News doprecyzowuje, że powiązania wynikają m.in. z podobieństw w skryptach instalacyjnych post-exploitation oraz zbieżności mechanizmów kryptograficznych/loaderów obserwowanych wcześniej w aktywności China-nexus.

Dla przypomnienia: APT41 (MITRE: G0096) to aktor oceniany jako państwowo sponsorowany (szpiegostwo) z historią działań równolegle „dla zysku” i szerokim spektrum celów od co najmniej 2012 r.


Analiza techniczna / szczegóły kampanii

1) Trzy łańcuchy infekcji (delivery → beacon → utrwalenie)

Check Point wyróżnia trzy ścieżki dostarczania i uruchomienia Cobalt Strike:

  1. AppDomain hijacking (scenariusze .NET, nadużycie mechanizmów ładowania w domenie aplikacji)
  2. Service DLL / nadużycie usług Windows (ładunek osadzony „pod” legalną usługą)
  3. Phishing z załącznikiem LNK (skrót Windows uruchamiający łańcuch przez cmd.exe/PowerShell).

W dwóch pierwszych łańcuchach (AppDomain hijacking i Service DLL) wspólnym mianownikiem są archiwa RAR + skrypty batch oraz fakt, że bywają one wdrażane po kompromitacji podatnych serwerów wystawionych do Internetu (post-exploitation/pivot).

2) Loadery i uruchamianie w pamięci

W opisie pojawiają się m.in.:

  • MonikerLoader: .NET-owy loader służący do deszyfrowania i uruchamiania kolejnego etapu w pamięci.
  • BamboLoader: loader shellcode (opisany jako mocno obfuskowany), rejestrowany jako usługa Windows; deszyfruje/dekompresuje shellcode, a następnie wstrzykuje go do legalnego procesu (np. taskhost.exe).

3) Phishing LNK + DLL sideloading

W kampanii phishingowej wymierzonej m.in. w Uzbekistan wykorzystywano załączniki LNK, które inicjowały wykonanie PowerShell. Dalej pojawiał się zestaw plików: dokument-przynęta, legalny program podatny na DLL sideloading (w tekście: GameHook.exe), złośliwa biblioteka DLL (wariant BamboLoader) i zaszyfrowany payload Cobalt Strike.

4) C2 przez tunelowanie DNS i Google Drive

W sieci Silver Dragon często wykorzystuje DNS tunneling jako kanał C2, co ma utrudniać wykrywanie na poziomie ruchu sieciowego.

Dodatkowo wyróżnia się backdoor GearDoor, który używa Google Drive jako kanału C2 (w praktyce: komunikacja i zadania „udają” legalną aktywność w chmurze). W opisie The Hacker News pojawia się nawet konwencja rozszerzeń plików używanych do sygnalizowania typu zadania (np. „heartbeat” i tasking), a także upload wyników zadań z hosta do Drive.

5) Narzędzia wspierające operację (szpiegostwo, utrzymanie dostępu)

  • SliverScreen: okresowe zrzuty ekranu (monitoring aktywności użytkownika).
  • SSHcmd: wrapper/CLI do zdalnych komend i transferu przez SSH.

Praktyczne konsekwencje / ryzyko

  1. Trudniejsze wykrywanie: nadużycie legalnych usług Windows i „zaufanych” usług chmurowych (Google Drive) przesuwa sygnały ataku w stronę zachowań, które w wielu organizacjach nie są ściśle kontrolowane.
  2. Długotrwała obecność (persistence): priorytetem jest utrzymanie dostępu i zbieranie informacji, a nie szybka destrukcja — typowe dla szpiegostwa.
  3. Ryzyko rozlania w sieci po kompromitacji serwerów brzegowych: jeśli wejście następuje przez publicznie wystawione systemy, atakujący może szybko przejść do ruchu bocznego i wdrożenia beaconów.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „praktycznych” pod ten konkretny profil TTP (Windows services + DNS tunneling + Drive C2 + Cobalt Strike):

1) Ogranicz powierzchnię wejścia (internet-facing)

  • Zrób przegląd usług wystawionych do Internetu i priorytetowo łatkuj systemy brzegowe (VPN, web, middleware, portale). Źródła wskazują, że kompromitacja serwerów publicznych bywa etapem poprzedzającym wdrożenie łańcuchów RAR/batch.
  • Włącz wymuszenia MFA i ogranicz dostęp administracyjny (VPN/admin panels) do zaufanych adresów / urządzeń.

2) Zabezpiecz pocztę i endpointy pod LNK/DLL sideloading

  • Zablokuj lub ściśle kontroluj załączniki LNK w poczcie oraz pobieranie/uruchamianie skrótów z Internetu (ASR rules, Mark-of-the-Web).
  • Monitoruj nietypowe uruchomienia cmd.exe → PowerShell z kontekstu aplikacji użytkownika oraz anomalie DLL loading przy procesach typu „legit-exe obok podejrzanej DLL”.

3) Polowanie na persistence w usługach Windows

  • Ustal bazową listę usług i ich binarek; alertuj na:
    • tworzenie nowych usług,
    • modyfikacje istniejących,
    • nietypowe ścieżki binarek usług (np. profile użytkowników, katalogi tymczasowe),
    • zatrzymywanie/odtwarzanie usług w krótkich oknach czasowych (pattern utrwalania opisany przez Check Point).

4) Detekcja tunelowania DNS

  • Wdroż analizę: wysokie entropie subdomen, nietypowe długości nazw, wolumen NXDOMAIN, stały beaconing. Źródła wiążą to z C2 w tej kampanii.

5) Kontrola ruchu do usług chmurowych (Google Drive jako C2)

  • Jeśli organizacja używa Google Workspace: włącz logowanie zdarzeń i korelację (nietypowe tokeny/OAuth, nowe aplikacje, nietypowe uploady/downloady).
  • Jeśli nie używa: rozważ egress allowlisting i blokadę/ograniczenie Drive na hostach serwerowych oraz segmentach „high trust”. GearDoor wprost opisano jako backdoor z C2 przez Drive.

6) Gotowe „hunting cues” (bez wchodzenia w IOC-dump)

  • Nietypowe archiwa RAR + skrypty .bat w środowisku serwerowym.
  • Procesy typu taskhost.exe lub inne legalne hosty z anomaliami wątku/iniekcji (EDR).
  • Obecność Cobalt Strike (wzorce beaconingu, artefakty pamięci, nietypowe named pipes) — w kampanii wskazany jako element utrzymania dostępu.

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

  • „Cloud C2” vs klasyczne serwery C2: Google Drive jako kanał sterowania jest szczególnie problematyczny, bo miesza się z legalnym ruchem i politykami „dozwolone, bo biznes”. To odróżnia kampanię od prostszych infrastruktur VPS/domen jednorazowych.
  • Nacisk na stealth i persistence: zamiast agresywnych działań (ransomware), Silver Dragon kładzie nacisk na utrzymanie długiego dostępu (hijack usług Windows, DNS tunneling), co jest bardziej spójne z szpiegostwem i z profilem „umbrella” APT41.

Podsumowanie / kluczowe wnioski

Silver Dragon to przykład nowoczesnej kampanii szpiegowskiej, w której nie pojedynczy malware, a kombinacja technik robi różnicę: wejście przez serwery publiczne i phishing, szybkie osadzenie Cobalt Strike, utrwalenie przez legalne usługi Windows, C2 przez DNS tunneling oraz „maskowanie” komunikacji w Google Drive (GearDoor). Dla obrony oznacza to konieczność połączenia higieny perymetru (patching), twardych polityk endpointowych (LNK/DLL), oraz obserwowalności ruchu DNS i aktywności chmurowej.


Źródła / bibliografia

  • The Hacker News — opis kampanii i łańcuchów infekcji (04.03.2026). (The Hacker News)
  • Check Point Research — raport techniczny „Silver Dragon Targets Organizations in Southeast Asia and Europe” (03.03.2026). (Check Point Research)
  • Check Point Blog — podsumowanie i wnioski operacyjne (03.03.2026). (Check Point Blog)
  • Dark Reading — kontekst i streszczenie zagrożenia (04.03.2026). (Dark Reading)
  • MITRE ATT&CK — profil APT41 (G0096). (MITRE ATT&CK)

Luka w Chrome pozwalała przejąć Gemini Live i eskalować uprawnienia przez rozszerzenie (CVE-2026-0628)

Wprowadzenie do problemu / definicja luki

Integracja asystentów AI bezpośrednio w przeglądarkach (tzw. agentic browsers) przesuwa granice użyteczności, ale jednocześnie otwiera nową powierzchnię ataku: komponent AI działa „bliżej” przeglądarki i często ma szerszy dostęp do zasobów systemu niż zwykła karta WWW. Właśnie w takim miejscu pojawiła się podatność CVE-2026-0628 w Google Chrome, która mogła umożliwić złośliwemu rozszerzeniu przejęcie panelu Gemini Live i uruchomienie działań wykraczających poza jego standardowe uprawnienia.


W skrócie

  • Podatność: CVE-2026-0628 (High; w NVD widoczny też wektor CVSS 3.1 8.8 dodany przez CISA-ADP).
  • Mechanizm: niewystarczające egzekwowanie polityk w tagu WebView → możliwość wstrzyknięcia skryptu/HTML do uprzywilejowanego kontekstu.
  • Scenariusz ataku: użytkownik instaluje złośliwe rozszerzenie; następnie po uruchomieniu Gemini w panelu bocznym atakujący może przejąć kontekst panelu.
  • Skutki (wg Unit 42): potencjalny dostęp do kamery/mikrofonu, zrzutów ekranu, lokalnych plików oraz możliwość nadużyć phishingowych w „zaufanym” UI panelu.
  • Status: Google załatało błąd w aktualizacji Stable 143.0.7499.192/.193 (wydanie ogłoszone 6 stycznia 2026).

Kontekst / historia / powiązania

Badanie opisał zespół Palo Alto Networks Unit 42, wskazując na szerszy trend: „AI w przeglądarce” to nie tylko ryzyko prompt injection z poziomu stron WWW, ale również powrót klasycznych problemów bezpieczeństwa w nowym, wysoko uprzywilejowanym komponencie (panel AI).

W tym przypadku podatność została:

  • zgłoszona odpowiedzialnie do Google 23 października 2025,
  • naprawiona na początku stycznia 2026,
  • a szczegóły upubliczniono 2 marca 2026 wraz z publikacją analizy.

Media branżowe (m.in. SecurityWeek oraz Dark Reading) podkreśliły, że to przykład ryzyka „eskalacji” z pozornie ograniczonego rozszerzenia do komponentu o uprawnieniach bliskich przeglądarce.


Analiza techniczna / szczegóły luki

1) Gdzie przebiegała granica zaufania

Kluczowy detal z analizy Unit 42: Gemini web app (gemini.google[.]com/app) może być ładowany:

  • jako zwykła strona w karcie (standardowy model WWW), albo
  • wewnątrz nowego panelu Gemini z dodatkowymi „hakami” przeglądarki, które zapewniają rozszerzone możliwości potrzebne do realizacji zadań przez asystenta.

To „miejsce uruchomienia” aplikacji Gemini zmieniało stawkę: w zwykłej karcie wpływanie na treść strony przez rozszerzenie jest w wielu przypadkach oczekiwane; natomiast wpływanie na treść uprzywilejowanego panelu wbudowanego w przeglądarkę staje się problemem krytycznym.

2) Jakie API/zdolności mogły zostać nadużyte

Unit 42 opisuje, że rozszerzenie z „podstawowym” zestawem uprawnień mogło wykorzystać możliwości przechwytywania i modyfikowania ruchu WWW (w analizie wskazano declarativeNetRequest) tak, aby doprowadzić do wstrzyknięcia JavaScript w kontekście panelu Gemini.

3) Co oznacza „eskalacja” w praktyce

Gdy kod atakującego wykona się w kontekście panelu Gemini, przestaje obowiązywać typowa „nisko-uprawnieniowa” perspektywa rozszerzenia. Według demonstracji Unit 42 przejęty panel mógł umożliwiać m.in.:

  • uruchomienie kamery i mikrofonu bez standardowej ścieżki zgody,
  • wykonanie screenshotów dowolnych kart,
  • dostęp do lokalnych plików i katalogów,
  • oraz wyświetlenie treści phishingowych w UI, które użytkownicy uznają za część Chrome.

4) Jak to zostało sklasyfikowane formalnie

Opis CVE w NVD wskazuje na insufficient policy enforcement in WebView tag prowadzące do możliwości wstrzyknięcia skryptu/HTML do uprzywilejowanej strony przez spreparowane rozszerzenie (wymagana jest instalacja rozszerzenia przez użytkownika).


Praktyczne konsekwencje / ryzyko

Ryzyko dla użytkowników indywidualnych

  • Naruszenie prywatności: potencjalny podgląd audio/wideo, zrzuty ekranu, wyciek plików.
  • Phishing „z wnętrza przeglądarki”: panel Gemini jest elementem zaufanym, więc podszycie się pod komunikaty lub ekrany logowania jest psychologicznie groźniejsze niż zwykły pop-up na stronie.

Ryzyko dla firm (endpointy i dane)

W środowisku enterprise nawet pojedyncze złośliwe rozszerzenie może stać się wektorem do:

  • wycieku danych z dokumentów lokalnych,
  • podsłuchu spotkań (mikrofon/kamera),
  • kradzieży treści widocznych w aplikacjach webowych (zrzuty ekranów, treści stron).

Warto podkreślić: to nie jest „zdalny drive-by” bez udziału użytkownika — warunkiem jest instalacja rozszerzenia. Jednak w praktyce kampanie złośliwych rozszerzeń (lub przejęcia legalnych dodatków) są realnym zjawiskiem, a AI-panel zwiększa potencjalny „zwrot” z takiej infekcji.


Rekomendacje operacyjne / co zrobić teraz

1) Aktualizacja Chrome (priorytet)

  • Upewnij się, że Chrome jest co najmniej w wersji 143.0.7499.192 (Windows/Mac: 143.0.7499.192/.193; Linux: 143.0.7499.192).
  • W organizacji: wymuś aktualizacje politykami (MDM/GPO) i zweryfikuj stan wersji w inwentarzu.

2) Higiena rozszerzeń (kluczowa, bo atak wymaga instalacji)

  • Zredukuj liczbę rozszerzeń do niezbędnego minimum.
  • W firmie: allowlist i blokada instalacji spoza zatwierdzonych źródeł; cykliczny przegląd uprawnień.
  • Monitoruj rozszerzenia używające mechanizmów modyfikacji ruchu/treści (to nie znaczy, że są złe — ale to obszar wymagający nadzoru).

3) Kontrola dostępu do peryferiów i telemetryka

  • Ogranicz dostęp przeglądarki do kamery/mikrofonu tam, gdzie to możliwe (polityki, ustawienia OS).
  • Zbieraj sygnały: nietypowe uruchomienia kamery/mikrofonu, anomalie ruchu wychodzącego, nietypowe działania przeglądarki po uruchomieniu panelu AI.

4) Edukacja użytkowników (szybka, konkretna)

  • „Zaufany panel przeglądarki” ≠ „zawsze bezpieczny”.
  • Instalacja rozszerzeń „od AI / do produktywności” powinna przechodzić tę samą weryfikację co każde inne narzędzie.

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

W klasycznym modelu przeglądarki złośliwe rozszerzenie zwykle działa w granicach przyznanych mu uprawnień (np. manipulacja DOM na stronach). Tu istotna jest zmiana jakościowa: poprzez błąd izolacji/polityk, rozszerzenie mogło przejść do kontekstu wbudowanego komponentu AI o rozszerzonych możliwościach (kamera, pliki, screenshoty). To modelowo inny typ ryzyka niż np. prompt injection wyłącznie z poziomu treści strony, bo wchodzi w grę eskalacja do uprzywilejowanego elementu przeglądarki.


Podsumowanie / kluczowe wnioski

  • CVE-2026-0628 pokazało, że AI-asystenci w przeglądarce tworzą nową „warstwę uprzywilejowania”, a błędy izolacji mogą dać atakującemu dużo więcej niż w tradycyjnych scenariuszach z rozszerzeniami.
  • Naprawa jest dostępna od 6 stycznia 2026 w Stable 143.0.7499.192/.193, więc najważniejsza akcja to aktualizacja i walidacja wersji.
  • Ponieważ atak wymaga instalacji dodatku, „higiena rozszerzeń” (allowlist, kontrola uprawnień, monitoring) pozostaje jednym z najskuteczniejszych środków redukcji ryzyka.

Źródła / bibliografia

  1. Unit 42 (Palo Alto Networks) – analiza CVE-2026-0628 i scenariuszy eskalacji przez panel Gemini (publikacja: 2 marca 2026). (Unit 42)
  2. Chrome Releases (Google) – Stable Channel Update for Desktop, wersja 143.0.7499.192/.193 (data: 6 stycznia 2026). (Chrome Releases)
  3. NVD (NIST) – wpis CVE-2026-0628 (data publikacji w NVD: 7 stycznia 2026). (nvd.nist.gov)
  4. SecurityWeek – omówienie wpływu podatności na Gemini Live w Chrome (publikacja: 2 marca 2026). (SecurityWeek)
  5. Dark Reading – komentarz o ryzykach „agentic browsers” i eskalacji przez panel Gemini (publikacja: 2 marca 2026). (Dark Reading)

APT28 powiązany z CVE-2026-21513: zero-day w MSHTML pozwala ominąć MotW i uruchamiać pliki przez LNK/HTML

Wprowadzenie do problemu / definicja luki

CVE-2026-21513 to luka typu Security Feature Bypass w MSHTML Framework (silnik Trident, wciąż obecny w Windows jako komponent wykorzystywany m.in. przez aplikacje i elementy systemowe). Microsoft załatał ją w ramach Patch Tuesday z lutego 2026, jednocześnie potwierdzając, że była aktywnie wykorzystywana jako zero-day.

Na szczególną uwagę zasługuje to, że według analizy Akamai exploit był korelowany z aktywnością APT28 (rosyjski aktor państwowy), a sam mechanizm ataku pozwalał obniżyć kontekst bezpieczeństwa i ominąć popularne zabezpieczenia przy otwieraniu plików pobranych z Internetu.


W skrócie

  • CVE-2026-21513 (CVSS 8.8): obejście mechanizmów bezpieczeństwa w MSHTML.
  • Wektor: skłonienie ofiary do otwarcia złośliwego HTML lub skrótowego pliku .LNK (np. z maila / linku).
  • Efekt: obejście „ostrzeżeń”/kontroli (m.in. MotW/IE ESC w opisywanym scenariuszu) i doprowadzenie do wykonania akcji poza oczekiwanym kontekstem przeglądarki/sandboxa.
  • Status: „exploitation detected” oraz KEV (Known Exploited Vulnerabilities) – termin działań naprawczych w katalogu CISA był wyznaczony na 3 marca 2026.

Kontekst / historia / powiązania

MSHTML/Trident formalnie kojarzy się z Internet Explorerem, ale w praktyce bywa wykorzystywany nadal — dlatego kolejne błędy w tym komponencie mogą mieć wpływ na współczesne systemy Windows i aplikacje osadzające MSHTML. Rapid7 zwraca uwagę, że Microsoft „co jakiś czas” musi łatać kolejne podatności w tym obszarze, mimo że IE nie jest już przeglądarką pierwszego wyboru.

Wątek APT28 pojawia się dlatego, że Akamai skorelowało obserwowany artefakt/łańcuch z infrastrukturą przypisywaną temu aktorowi oraz opisało charakterystyczny, wieloetapowy sposób dostarczania ładunków.


Analiza techniczna / szczegóły luki

Gdzie jest błąd?

Akamai opisuje, że źródłem CVE-2026-21513 jest logika w ieframe.dll odpowiedzialna za obsługę nawigacji hiperłączy. Kluczowy problem to niewystarczająca walidacja docelowego URL, przez co dane kontrolowane przez atakującego trafiają na ścieżki kodu wywołujące ShellExecuteExW. To otwiera drogę do uruchamiania zasobów lokalnych lub zdalnych poza zamierzonym kontekstem bezpieczeństwa.

Jak wygląda łańcuch ataku?

W opisywanym scenariuszu napastnik dostarcza:

  • plik .LNK (skrót Windows), w którym po standardowej strukturze LNK doklejony jest plik HTML,
  • a następnie wykorzystuje zagnieżdżone iframe’y i wielokrotne konteksty DOM, aby manipulować granicami zaufania i doprowadzić do uruchomienia wrażliwej ścieżki nawigacji.

Akamai wskazuje również na komunikację z domeną wykorzystywaną w kampanii (w ich opisie: wellnesscaremed[.]com) oraz podkreśla, że choć zaobserwowano LNK jako nośnik, to podatna ścieżka może zostać wyzwolona przez dowolny komponent osadzający MSHTML, więc trzeba zakładać inne mechanizmy dostarczania niż tylko phishing z .LNK.


Praktyczne konsekwencje / ryzyko

  1. Skuteczniejsze kampanie phishingowe: pliki .LNK i HTML są wygodne do dystrybucji i często „mniej podejrzane” dla użytkowników niż klasyczne EXE.
  2. Obejście mechanizmów ostrzegania / etykietowania plików z Internetu: w opisie Akamai mowa o obejściu m.in. MotW i IE ESC, co w praktyce może zmniejszyć liczbę tarć w łańcuchu infekcji.
  3. Ryzyko dla środowisk enterprise: skoro MSHTML może być osadzany w różnych komponentach/aplikacjach, „wyłączenie przeglądarki” nie rozwiązuje problemu — kluczowe są aktualizacje systemu i kontrola uruchamiania skrótów/treści aktywnych.
  4. Priorytet patchowania: fakt dodania do KEV sugeruje, że zagrożenie nie jest teoretyczne.

Rekomendacje operacyjne / co zrobić teraz

1) Patch management (najważniejsze)

  • Zweryfikuj, czy w środowisku wdrożono poprawki z lutego 2026 Patch Tuesday obejmujące CVE-2026-21513.
  • Ustal priorytet dla stacji roboczych o wysokim ryzyku (użytkownicy narażeni na spearphishing, działy finansowe, kadry, asystenci zarządów, IT/OT z dostępem uprzywilejowanym).

2) Redukcja powierzchni ataku: LNK/HTML

  • Wzmocnij polityki dla uruchamiania plików .LNK z lokalizacji wysokiego ryzyka (Downloads, Temp, załączniki pocztowe synchronizowane lokalnie).
  • Rozważ reguły ASR/AppLocker/WDAC ograniczające nietypowe uruchomienia oraz egzekwujące kontrolę pochodzenia plików.

3) Detekcja i hunting

  • Dodaj do polowań (threat hunting) korelacje: uruchomienie explorer.exe / shell32 prowadzące do podejrzanych procesów potomnych po otwarciu .LNK, oraz anomalie w użyciu komponentów MSHTML/ieframe.dll.
  • Skorzystaj z IOC opublikowanych przez Akamai (w ich wpisie znajduje się osobna sekcja).

4) Świadomość użytkowników i kontrola poczty

  • Wzmocnij filtry antyphishingowe pod kątem LNK oraz archiwów i „kontenerów” (ZIP/ISO), które często przenoszą skróty.
  • Przypomnij użytkownikom, by nie otwierali skrótów/HTML z nieoczekiwanych wiadomości — zwłaszcza gdy nadawca „prosi tylko o kliknięcie”.

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

W lutym 2026 Microsoft łatał kilka zero-dayów, a Rapid7 zauważa „pakiet” podatności typu security feature bypass. CVE-2026-21513 wyróżnia się tym, że dotyka starego, ale nadal żywego komponentu renderującego (MSHTML/Trident), a więc może pojawiać się w nieoczywistych miejscach (aplikacje osadzające).

Z perspektywy obrony warto traktować to jako kolejny przypadek klasy „MotW/ostrzeżenia do ominięcia”, gdzie sam fakt „użytkownik musiał kliknąć” nie powinien obniżać priorytetu — zwłaszcza przy aktywnej eksploatacji i atrybucji do aktora APT.


Podsumowanie / kluczowe wnioski

  • CVE-2026-21513 to realnie wykorzystywany zero-day w MSHTML, pozwalający ominąć mechanizmy bezpieczeństwa i doprowadzić do wykonania akcji poza oczekiwanym kontekstem.
  • Mechanizm bazuje na błędnej walidacji w ieframe.dll i prowadzi do wywołania ShellExecuteExW, co jest krytycznym „mostem” między treścią webową a powłoką systemu.
  • Łańcuch ataku obserwowany przez Akamai używał LNK z osadzonym HTML i był powiązany z infrastrukturą przypisywaną APT28.
  • Priorytet: patchować, ograniczać LNK/HTML, polować na nietypowe uruchomienia oraz wdrożyć twarde polityki wykonywania.

Źródła / bibliografia

  1. Akamai – „Inside the Fix: Analysis of In-the-Wild Exploit of CVE-2026-21513” (20 lutego 2026). (Akamai)
  2. The Hacker News – „APT28 Tied to CVE-2026-21513…” (2 marca 2026). (The Hacker News)
  3. Rapid7 – „Patch Tuesday – February 2026” (11 lutego 2026). (Rapid7)
  4. Tenable – „Microsoft’s February 2026 Patch Tuesday…” (10 lutego 2026). (Tenable®)
  5. NVD (NIST) – wpis wskazujący na obecność w KEV (dodanie 10 lutego 2026; due date 3 marca 2026). (nvd.nist.gov)

Korea Północna publikuje 26 złośliwych paczek npm: StegaBin ukrywa C2 w Pastebin i dostarcza wieloplatformowego RAT-a

Wprowadzenie do problemu / definicja luki

Ataki na łańcuch dostaw oprogramowania nie muszą zaczynać się od włamania do repozytorium firmy. Coraz częściej napastnicy „wchodzą” do ekosystemu tak, jak każdy inny deweloper — publikując paczki w publicznych rejestrach (npm, PyPI), licząc na pomyłkę w nazwie (typosquatting) lub bezrefleksyjne doinstalowanie „narzędzia” z internetu.

Właśnie w ten schemat wpisuje się kampania, w której aktorzy powiązani z Koreą Północną opublikowali 26 złośliwych pakietów npm, podszywających się pod narzędzia dla programistów. Celem jest infekcja stacji roboczych deweloperów i wykradanie sekretów oraz zdalne sterowanie hostem (RAT).


W skrócie

  • 26 paczek npm udaje „developer tools”, a po instalacji uruchamia kod w hooku instalacyjnym.
  • C2 nie jest zapisane wprost: loader używa Pastebin jako dead-drop i wyciąga adresy infrastruktury z tekstu przy pomocy steganografii na poziomie znaków.
  • Następny etap pobierany jest z domen hostowanych na Vercel (zidentyfikowano wiele deploymentów/domen).
  • Ładunek końcowy to zestaw modułów do: persistence (m.in. przez VS Code), keylogging/clipboard theft, kradzieży haseł z przeglądarek, skanowania sekretów (TruffleHog), eksfiltracji repozytoriów/Git/SSH i funkcji RAT.

Kontekst / historia / powiązania

Badacze łączą tę falę z długotrwałą kampanią Contagious Interview, w której napastnicy „rekrutują” deweloperów (fałszywe oferty pracy, zadania techniczne), a następnie przemycają malware poprzez zależności i narzędzia developerskie. W tym wariancie kampania otrzymała nazwę StegaBin (od steganografii w Pastebin).

Atrybucja w materiałach badaczy jest spójna z północnokoreańskim klastrem aktywności określanym jako FAMOUS CHOLLIMA.

Warto też zauważyć, że ten sam klaster eksperymentuje z alternatywnymi „stagerami” kolejnych etapów — np. Google Drive jako nośnik payloadu (co utrudnia proste blokady oparte o klasyczne paste-sites).


Analiza techniczna / szczegóły luki

1) Wejście: typosquatting + hook instalacyjny npm

Złośliwe paczki są publikowane tak, by wyglądały na „linty”, „walidatory”, „narzędzia” itp. Kluczowy mechanizm uruchomienia to install script w package.json, odpalany automatycznie podczas npm install.

Cechy charakterystyczne:

  • install hook uruchamia plik w stylu ./scripts/test/install.js, który następnie ładuje właściwy payload z lokalizacji udającej „vendor” popularnej biblioteki (np. ścieżka sugerująca scrypt-js).
  • napastnicy często dodają jako zależność prawdziwy, legitny pakiet, pod który się podszywają — żeby projekt „działał” i nie wzbudzał podejrzeń.

2) Ukrywanie infrastruktury: Pastebin jako dead-drop + steganografia

Zamiast trzymać C2 w kodzie, loader pobiera treść z Pastebin, która wygląda jak niewinna notatka/esej. W rzeczywistości wybrane znaki (w równych odstępach) są podmienione tak, by po złożeniu dawały listę adresów infrastruktury.

Opis działania dekodera (w uproszczeniu):

  • usuwa znaki typu zero-width Unicode,
  • czyta znacznik długości na początku,
  • wylicza pozycje znaków „co N”,
  • skleja znaki i dzieli wynik separatorem (np. |||) do uzyskania tablicy domen C2.

3) Routing i hosting C2: Vercel + dalsze etapy

Zdekodowane adresy prowadzą do domen hostowanych na Vercel, które serwują kolejne etapy (w tym skrypty powłoki i komponenty RAT). W analizie Socket wymieniono szereg domen Vercel powiązanych z kampanią.

4) Działanie na hoście: modułowy infostealer + RAT

Z publicznie opisanych elementów wynika, że po stronie ofiary aktywowane są moduły odpowiadające m.in. za:

  • persistence w VS Code poprzez modyfikację tasks.json i trigger runOn: "folderOpen",
  • keylogging/clipboard theft i telemetrię aktywnego okna,
  • kradzież haseł z magazynów przeglądarek,
  • kradzież rozszerzeń/walletów kryptowalutowych (np. MetaMask i inne),
  • enumerację plików wg wzorców i eksfiltrację .ssh, Git credentials oraz repozytoriów,
  • pobranie legalnego TruffleHog do wyszukiwania sekretów i ich wyprowadzenia,
  • funkcje RAT (zdalne komendy / interaktywne sterowanie).

Lista zidentyfikowanych paczek npm (wg publikacji)

  • argonist@0.41.0
  • bcryptance@6.5.2
  • bee-quarl@2.1.2
  • bubble-core@6.26.2
  • corstoken@2.14.7
  • daytonjs@1.11.20
  • ether-lint@5.9.4
  • expressjs-lint@5.3.2
  • fastify-lint@5.8.0
  • formmiderable@3.5.7
  • hapi-lint@19.1.2
  • iosysredis@5.13.2
  • jslint-config@10.22.2
  • jsnwebapptoken@8.40.2
  • kafkajs-lint@2.21.3
  • loadash-lint@4.17.24
  • mqttoken@5.40.2
  • prism-lint@7.4.2
  • promanage@6.0.21
  • sequelization@6.40.2
  • typoriem@0.4.17
  • undicy-lint@7.23.1
  • uuindex@13.1.0
  • vitetest-lint@4.1.21
  • windowston@3.19.2
  • zoddle@4.4.2

Praktyczne konsekwencje / ryzyko

Największy problem w tego typu incydentach to blast radius: jedna błędnie zainstalowana paczka na laptopie dewelopera może otworzyć napastnikom drogę do:

  • kluczy SSH, tokenów CI/CD, sekretów chmurowych, .env, plików konfiguracyjnych,
  • dostępu do repozytoriów (Git credentials, session tokens),
  • portfeli kryptowalutowych i rozszerzeń przeglądarki,
  • trwałej obecności na stacji roboczej (persistence w narzędziach developerskich),
  • a w konsekwencji — do kompromitacji pipeline’ów i produkcji.

Dodatkowo, użycie Pastebin/Vercel i steganografii zmniejsza skuteczność prostych reguł opartych o „twardo zakodowane IOC”.


Rekomendacje operacyjne / co zrobić teraz

Dla zespołów SecOps / SOC

  1. Hunting na procesy Node.js wykonujące połączenia do nietypowych usług „paste/hosting”, szczególnie w trakcie instalacji zależności (czas npm install).
  2. Monitoruj anomalie: uruchamianie skryptów instalacyjnych, tworzenie/modyfikacje w katalogach konfiguracji VS Code (np. tasks.json) i nagłe żądania wychodzące po otwarciu folderu projektu.
  3. Rozważ blokady/alerty na wybrane kategorie egress (Pastebin, Vercel) dla stacji developerskich, przynajmniej w trybie detekcji i z wyjątkami. (Uwaga: Vercel bywa legalnie używany — lepiej iść w detekcję + allowlist dla znanych projektów).

Dla developerów i platform engineering

  1. W środowiskach CI i na wrażliwych hostach używaj instalacji z ograniczeniami, np.:
    • npm ci (z lockfile),
    • rozważ --ignore-scripts tam, gdzie to możliwe (i świadomie włączaj skrypty tylko dla zaufanych paczek).
  2. Włącz automatyczne skanowanie zależności (SCA), polityki blokowania typosquattingu i allowlisty dla paczek krytycznych.
  3. Używaj wewnętrznego proxy/repozytorium (registry cache) z kontrolą publikacji i reputacji paczek.
  4. Edukuj zespół: paczki typu „expressjs-lint”/„loadash-lint” wyglądają wiarygodnie właśnie po to, by wygrać z rutyną.

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

  • StegaBin wyróżnia się tym, że C2 jest „wyciągane” z tekstu w Pastebin metodą steganografii znakowej (zamiast jawnego URL w kodzie).
  • W obserwacjach kmsec.uk widać też testowanie Google Drive jako stagera kolejnego etapu (inny wektor ukrycia i „legalny” CDN/hosting treści).
  • Szerszy trend: rośnie skala i automatyzacja ataków supply-chain na open source; CISA zwracała uwagę na masowe kompromitacje w ekosystemie npm i mechanizmy propagacji po przejęciu kont deweloperskich (co pokazuje, że zagrożenie jest systemowe, nie incydentalne).

Podsumowanie / kluczowe wnioski

  • Publiczne rejestry paczek to dziś pierwszorzędny wektor dla aktorów państwowych — szczególnie przeciw deweloperom.
  • W tej fali ataku 26 paczek npm używa install hooków, ukrytego C2 w Pastebin i infrastruktury Vercel, by dostarczyć modułowego infostealera i RAT na Windows/macOS/Linux.
  • Obrona powinna łączyć kontrolę egress, polityki instalacji zależności (lockfile, ograniczenie skryptów), SCA oraz monitoring zachowań narzędzi developerskich (VS Code).

Źródła / bibliografia

  1. The Hacker News – opis kampanii i lista paczek (02.03.2026). (The Hacker News)
  2. Socket – analiza StegaBin, Pastebin dead-drop, mechanika install hooków i IOC (27.02.2026). (Socket)
  3. kmsec.uk – „DPRK tests Google Drive as a malware stager” (21.02.2026). (kmsec.uk)
  4. CISA – alert dot. kompromitacji supply-chain w ekosystemie npm (23.09.2025). (CISA)

QuickLens: przejęte rozszerzenie Chrome kradło krypto i uruchamiało ataki ClickFix

Wprowadzenie do problemu / definicja luki

Incydent z QuickLens – Search Screen with Google Lens to klasyczny przykład supply chain attack na ekosystem rozszerzeń przeglądarki: narzędzie, które wyglądało legalnie i miało realną bazę użytkowników, zostało przejęte (po zmianie właściciela) i zaktualizowane w sposób, który umożliwił dystrybucję złośliwych ładunków oraz kradzież danych – w tym danych umożliwiających przejęcie kryptowalut.

Kluczowy element tej historii to wykorzystanie ClickFix – techniki socjotechnicznej, w której ofiara jest nakłaniana do wykonania „czynności naprawczej” (np. uruchomienia polecenia lub „weryfikacji”), co w praktyce uruchamia etap infekcji.


W skrócie

  • QuickLens miał ok. 7 tys. użytkowników i w pewnym momencie otrzymał nawet wyróżnienie w Chrome Web Store.
  • 17 lutego 2026 pojawiła się wersja 5.8, która zawierała złośliwe skrypty: komponent ClickFix oraz funkcje kradzieżowe (infostealer).
  • Rozszerzenie żądało nowych uprawnień i miało reguły modyfikujące ruch/odpowiedzi stron w sposób ułatwiający wstrzyknięcie złośliwego JS.
  • Google usunęło rozszerzenie ze sklepu, a Chrome automatycznie je wyłączało u użytkowników.

Kontekst / historia / powiązania

Najgroźniejsze w atakach na rozszerzenia przeglądarkowe jest to, że nie musisz „czegoś podejrzanego instalować” w dniu ataku. W tym przypadku:

  • QuickLens startował jako funkcjonalny dodatek do wyszukiwania obrazem (Google Lens) w przeglądarce.
  • Po czasie doszło do zmiany właściciela (co jest częstym wektorem nadużyć: kupno „czystej” wtyczki z reputacją i użytkownikami, a potem podmiana aktualizacji).
  • Wersja 5.8 weszła jako „zwykła aktualizacja” — to dokładnie ten moment, w którym zaufanie użytkownika do dodatku działa przeciwko niemu.

Równolegle warto zauważyć, że ClickFix to nie pojedyncza kampania, tylko rosnąca rodzina schematów socjotechnicznych. Microsoft i Kaspersky opisują, jak atakujący modyfikują „wabiki” (fałszywe CAPTCHA, „naprawa błędu”, „weryfikacja”), żeby użytkownik sam uruchomił etap infekcji.


Analiza techniczna / szczegóły luki

1. Co zmieniła złośliwa aktualizacja

Z opisu analizy wynika, że wersja 5.8:

  • poprosiła o dodatkowe uprawnienia, m.in. związane z przechwytywaniem/obróbką żądań oraz regułami dostępu hostów (istotne, bo to rozszerza realny „zasięg” ataku do wielu witryn),
  • zawierała plik reguł, który usuwał nagłówki bezpieczeństwa z odpowiedzi stron, m.in. Content-Security-Policy (CSP), X-Frame-Options i X-XSS-Protection. To ważne, bo takie nagłówki utrudniają wstrzykiwanie i uruchamianie nieautoryzowanych skryptów.

W praktyce mówimy o scenariuszu, gdzie rozszerzenie:

  1. ma szerokie uprawnienia,
  2. potrafi osłabić ochronę po stronie przeglądarki/strony,
  3. może uruchamiać/ładować logikę ataku w kontekście stron, które odwiedza ofiara.

2. ClickFix jako mechanizm „domknięcia” infekcji

ClickFix w typowym ujęciu (wg Microsoft) zaczyna się od doprowadzenia ofiary do strony-wabika i przekonania jej do wykonania akcji, która skutkuje uruchomieniem złośliwego kodu (często przez polecenia/uruchomienie skryptu). To podejście jest skuteczne, bo część zabezpieczeń automatycznych gorzej radzi sobie z atakiem „wykonanym ręką użytkownika”.

CERT Orange Polska opisuje ClickFix jako socjotechnikę nastawioną na to, aby ofiara „sama się zainfekowała”, zwykle poprzez uruchomienie poleceń, które ściągają kolejne etapy (stealery/RAT-y).


Praktyczne konsekwencje / ryzyko

W tym incydencie zagrożenia były wielowarstwowe:

  • Kradzież kryptowalut: BleepingComputer wskazuje na próby przejęcia środków i rekomenduje migrację funduszy do nowego portfela, jeśli korzystasz z wymienionych portfeli.
  • Eksfiltracja danych z usług webowych: wśród działań wymieniono m.in. scraping zawartości Gmail oraz pozyskiwanie danych z Facebook Business Manager i YouTube.
  • Ryzyko przejęcia kont (hasła/tokens/sesje): jeśli rozszerzenie miało dostęp do przeglądarki i treści stron, konsekwencją mogą być kradzieże poświadczeń lub przejęcia sesji.
  • Zasięg i „cicha” dystrybucja: użytkownik nie musi nic ponownie instalować — wystarczy autoaktualizacja rozszerzenia.

Dodatkowo pojawiły się relacje, że celem mogli być też użytkownicy macOS (w kontekście stealerów). W tym konkretnym fragmencie redakcja zaznaczała brak pełnej weryfikacji niezależnej.


Rekomendacje operacyjne / co zrobić teraz

Jeśli QuickLens był zainstalowany w Twoim środowisku (domowym lub firmowym), potraktuj to jak incydent:

  1. Usuń rozszerzenie i sprawdź, czy nie pozostały powiązane komponenty/profil przeglądarki.
  2. Wymuś reset haseł do kluczowych usług (priorytet: poczta, konta reklamowe, giełdy/portfele krypto, SSO) oraz rozważ unieważnienie sesji (log out from all devices).
  3. Skan stacji (EDR/AV) + przegląd mechanizmów persistence (autostart, LaunchAgents/LaunchDaemons na macOS, harmonogram zadań na Windows).
  4. Jeśli używasz krypto: przenieś środki do nowego portfela (nowy seed), zwłaszcza jeśli używałeś portfela w przeglądarce na tej samej maszynie.
  5. Higiena rozszerzeń w firmie:
    • polityka allowlist (tylko zatwierdzone rozszerzenia),
    • monitoring zmian uprawnień (alert, gdy dodatek nagle żąda nowych permissions),
    • okresowe audyty rozszerzeń oraz telemetryka przeglądarek.

Różnice / porównania z innymi przypadkami

  • ClickFix zwykle kojarzy się z fałszywymi CAPTCHA i „instrukcjami naprawy” na stronach (często po wejściu z reklamy, phishingu lub na skompromitowaną witrynę). QuickLens pokazuje, że ClickFix może być też dostarczany przez zaufany łańcuch aktualizacji (rozszerzenie), a nie tylko przez pojedynczy landing page.
  • W klasycznych kampaniach ClickFix finałem bywają stealery/RAT-y uruchamiane po komendzie użytkownika. CERT Orange i Microsoft wymieniają tę kategorię zagrożeń jako typowy skutek techniki.

Podsumowanie / kluczowe wnioski

QuickLens to ostrzeżenie, że:

  • nawet „normalne” rozszerzenie z historią i użytkownikami może stać się złośliwe po zmianie właściciela i aktualizacji,
  • uprawnienia oraz możliwość manipulowania ruchem/nagłówkami bezpieczeństwa to czerwone flagi, które powinny uruchamiać alert w organizacji,
  • ClickFix dalej ewoluuje i działa dlatego, że przenosi krytyczny krok infekcji na użytkownika (a więc poza część automatycznych barier).

Źródła / bibliografia

  1. BleepingComputer – opis incydentu QuickLens, daty, mechanika złośliwej aktualizacji, działania i rekomendacje. (BleepingComputer)
  2. Microsoft Security Blog – analiza łańcucha ataku ClickFix i powodów skuteczności tej techniki. (Microsoft)
  3. Kaspersky – warianty ClickFix i ewolucja „wabików” oraz metod dostarczania. (Kaspersky)
  4. CERT Orange Polska – ClickFix w praktyce (mechanika socjotechniki, konsekwencje, przykładowe łańcuchy infekcji). (CERT Orange)
  5. SC Media – przykłady kampanii ClickFix z fałszywymi CAPTCHA i kradzieżą danych/portfeli. (SC Media)

Microsoft testuje „bezpieczny tryb” dla plików BAT/CMD w Windows 11: blokada modyfikacji w trakcie uruchomienia i mniej kosztowne sprawdzanie podpisu

Wprowadzenie do problemu / definicja luki

Pliki wsadowe .bat i .cmd są „starym” mechanizmem automatyzacji, ale w praktyce nadal napędzają mnóstwo procesów: logon scripts, instalacje, naprawy, narzędzia helpdesku, taski w harmonogramie, procedury odzyskiwania czy operacje w środowiskach z ograniczonym dostępem do PowerShella.

Ich słabym punktem jest to, że są tekstowe i łatwo je zmienić — a w pewnych scenariuszach atakujący może próbować podmienić zawartość skryptu w trakcie jego wykonywania (klasa problemów typu TOCTOU: time-of-check vs time-of-use). Microsoft właśnie testuje mechanizm, który ma ograniczyć ten wektor.


W skrócie

W najnowszych kompilacjach Windows 11 Insider Microsoft dodaje opcję uruchamiania BAT/CMD w bardziej „sztywnym” trybie:

  • Skrypt wsadowy nie może zmienić się podczas wykonania (system ma go „zablokować” w trakcie uruchomienia).
  • Gdy w środowisku działa Code Integrity, system ma wykonywać walidację podpisu tylko raz (zamiast narzutu „per instrukcja/linia” w skrypcie), co ma poprawić zarówno bezpieczeństwo, jak i wydajność.
  • Funkcja jest opisywana jako kontrola dla administratorów oraz autorów polityk Application Control for Business.

Ważna uwaga: w źródłach pojawia się różne nazewnictwo wartości rejestru (szczegóły niżej) — to normalne na etapie Insider, ale trzeba to brać pod uwagę w testach i automatyzacji.


Kontekst / historia / powiązania

Zmiana została ogłoszona w kanałach Insider (m.in. wpis Windows Insider Blog) i jest komunikowana jako rozszerzenie kontroli dla:

  • administratorów systemów (ustawienia lokalne, rejestr),
  • autorów polityk App Control for Business (czyli praktycznie następcy/ewolucji podejścia WDAC w kierunku łatwiejszego zarządzania).

Drugi element układanki to Code Integrity oraz ochrona oparta o wirtualizację (HVCI / „Memory integrity”), które w wielu organizacjach są elementem twardych baseline’ów bezpieczeństwa. Jeśli CI jest włączone, Microsoft chce ograniczyć koszt weryfikacji podpisów podczas wykonywania dłuższych skryptów.


Analiza techniczna / szczegóły luki

1. „Locking” plików wsadowych podczas wykonania

Idea jest prosta: jeśli BAT/CMD jest uruchomiony, system ma zapewnić, że jego treść nie zmieni się w trakcie działania. Ma to utrudnić scenariusze, w których:

  • skrypt startuje jako „zaufany” (lub podpisany),
  • a następnie jest podmieniany „w locie” na złośliwą wersję, zanim dojdzie do wykonania dalszych poleceń.

W praktyce sprowadza się to do wprowadzenia bezpieczniejszego trybu przetwarzania, który „zamraża” wejście skryptu na czas jego wykonania.

2. Gdzie i jak to włączyć

Z komunikatów wynika, że tryb da się włączyć:

  • przez wartość w rejestrze w gałęzi Command Processor,
  • oraz przez kontrolę w mechanizmie polityk aplikacyjnych (manifest/ustawienie dla autorów polityk App Control).

Rozbieżność nazwy klucza:

  • Windows Insider Blog wskazuje wartość LockBatchFilesWhenInUse (DWORD 0/1) pod HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor.
  • BleepingComputer opisuje to jako LockBatchFilesInUse w tym samym miejscu.

Na etapie Insider to może oznaczać: doprecyzowanie nazewnictwa, korektę w kolejnych buildach albo różnice między gałęziami/kanałami. W praktyce: automaty wdrożeniowe powinny wykrywać build i weryfikować faktyczną obsługiwaną nazwę (np. poprzez test w labie i kontrolę zachowania, a nie tylko „set registry and pray”).

3. Podpisy i Code Integrity: „walidacja tylko raz”

Drugi element jest szczególnie ciekawy dla środowisk z włączonym Code Integrity. Microsoft deklaruje, że:

  • wcześniej w tym trybie walidacja mogła odbywać się z większym narzutem,
  • teraz ma być wykonana jednorazowo, co redukuje koszt i daje bardziej przewidywalny runtime dla dłuższych skryptów.

To jest ważne, bo długie, „linijkowe” BAT-y potrafią być krytyczne dla operacji (np. deployment w nocy), a każdy dodatkowy narzut potrafi wydłużyć okna serwisowe.


Praktyczne konsekwencje / ryzyko

Co zyskujesz

  • Większa odporność na manipulację skryptem w trakcie wykonania (ważne przy skryptach uruchamianych z udziałów sieciowych, repo narzędziowych, katalogów roboczych z szerokimi uprawnieniami, itp.).
  • Mniej kosztowna weryfikacja podpisu w scenariuszach z Code Integrity, co może poprawić stabilność i czas wykonywania automatyzacji.

Co może pójść nie tak

  • Skrypty, które same siebie modyfikują (tak, to się zdarza…), generują kolejne pliki wsadowe „w locie” w tym samym miejscu lub polegają na nietypowym łańcuchu include/call mogą zachowywać się inaczej.
  • Jeśli organizacja ma rozbudowane pipeline’y, które „podmieniają” treść BAT-a podczas rollout’u, blokada może ujawnić ukryte problemy procesowe (brak wersjonowania, brak atomowych podmian, złe uprawnienia do udziałów).

Rekomendacje operacyjne / co zrobić teraz

  1. Nie włączaj tego na produkcji w ciemno – potraktuj jako zmianę semantyki wykonywania BAT/CMD. Zacznij od labu/VM z buildem Insider.
  2. Zidentyfikuj „krytyczne” skrypty wsadowe (logowanie, deployment, naprawy, runbooki) i sprawdź:
    • czy skrypt jest wykonywany z lokalnego dysku vs udział sieciowy,
    • kto ma prawo zapisu do lokalizacji,
    • czy w trakcie działania nie następuje „podmiana” pliku przez inne narzędzia.
  3. Jeśli używasz Application Control for Business, podejdź do tego „politykowo”: wymuś spójność uruchamiania w organizacji poprzez mechanizmy App Control, zamiast lokalnych „tweaków”.
  4. Dopnij higienę repozytoriów skryptów:
    • atomowe wdrożenia (np. zapis do nowej nazwy + rename),
    • minimalizacja uprawnień zapisu,
    • podpisywanie, jeśli to ma sens w twoim modelu zaufania.
  5. W środowiskach z HVCI/Memory integrity zweryfikuj wpływ na czasy wykonań — Microsoft sugeruje poprawę, ale realny efekt zależy od tego, jak i gdzie uruchamiasz skrypty.

Różnice / porównania z innymi przypadkami

  • Smart App Control / App Control to kontrola „czy coś w ogóle może się uruchomić” (zależnie od podpisu/reputacji/polityki).
  • Opisywana zmiana dla BAT/CMD dotyka dodatkowo integralności skryptu w czasie wykonania oraz kosztu weryfikacji przy Code Integrity. To inny poziom: nie tylko „allow/deny”, ale też „runtime hardening”.

Podsumowanie / kluczowe wnioski

Microsoft testuje w Windows 11 Insider mechanizm, który:

  • ma uniemożliwiać modyfikację BAT/CMD w trakcie uruchomienia, ograniczając klasyczny wektor TOCTOU,
  • oraz ma zmniejszać narzut walidacji podpisu w środowiskach z Code Integrity (walidacja „raz na start”).

Dla organizacji, które wciąż polegają na wsadówkach, to potencjalnie bardzo sensowna zmiana — pod warunkiem, że przejdzie przez testy kompatybilności i nie rozjedzie istniejących procesów automatyzacji.


Źródła / bibliografia

  1. Windows Insider Blog – ogłoszenie kompilacji z nową kontrolą dla BAT/CMD i opisem „signature validation only once”. (Windows Blog)
  2. BleepingComputer – omówienie nowości i sposobu włączenia (Insider). (BleepingComputer)
  3. Microsoft Learn – Application Control for Windows / Smart App Control (kontekst polityk aplikacyjnych). (Microsoft Learn)
  4. Microsoft Learn – Virtualization-based protection of code integrity (HVCI/Memory integrity) – kontekst „Code Integrity”. (Microsoft Learn)

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)