Tag: Windows

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)

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)