Autor: Wojciech Ciemski

Wprowadzenie do problemu / definicja luki

ClickFix to nie „luka” w sensie CVE, tylko powtarzalny wzorzec socjotechniczny: ofiara jest przekonywana, by sama uruchomiła polecenie w Windows (najczęściej przez Win+R) pod pretekstem „weryfikacji” albo „naprawy problemu”. W najnowszej odsłonie atakujący dołożyli sprytny twist: zamiast odpalać PowerShell bezpośrednio, proxy’ują wykonanie przez legalny, podpisany komponent Microsoftu związany z App-V.

W skrócie

• Kampania startuje od fałszywego CAPTCHA i instrukcji: wklej/uruchom komendę w oknie „Uruchamianie” (Win+R).
• Komenda nadużywa SyncAppvPublishingServer.vbs (App-V) odpalonego przez wscript.exe, aby „przykryć” uruchomienie PowerShell i zmienić typowy łańcuch procesów.
• Łańcuch ma bramki anty-sandbox: sprawdzanie zachowania użytkownika, kolejności uruchomienia i stanu schowka; w środowiskach analitycznych potrafi „wisieć” w nieskończoność.
• Konfiguracja jest pobierana z publicznego Google Calendar (.ics) (dead-drop), a jeden z etapów ukrywa payload w PNG (steganografia) i ładuje go w pamięci.
• Finalnie celem jest Amatera Stealer (rodzina infostealer sprzedawana jako MaaS, rozwijana i „utwardzana” pod kątem evasion).

Kontekst / historia / powiązania

Microsoft wskazuje, że ClickFix rośnie od 2024 r. i bywa łączony z phishingiem, malvertisingiem oraz kompromitacją stron — a kluczową przewagą napastnika jest wymuszenie interakcji człowieka, która potrafi ominąć część automatycznych detekcji.

W tej kampanii istotne jest „życie z ziemi” (LotL/LOLBins): MITRE opisuje nadużycie SyncAppvPublishingServer.vbs jako sub-technikę System Script Proxy Execution, gdzie legalny skrypt może proxy’ować wykonanie poleceń PowerShell zamiast bezpośredniego powershell.exe.

Analiza techniczna / szczegóły luki

Poniżej najważniejsze elementy łańcucha (z perspektywy IR/DFIR i detekcji):

1) Wejście: fake CAPTCHA → Win+R
Użytkownik widzi stronę „human verification” i dostaje instrukcję uruchomienia komendy. To klasyczny ClickFix, ale dalej robi się nietypowo.

2) Proxy wykonania: wscript.exe + SyncAppvPublishingServer.vbs
Zamiast explorer.exe → powershell.exe, pojawia się uruchomienie przez wscript.exe i skrypt App-V (SyncAppvPublishingServer.vbs). To zmienia „process ancestry” i może obniżać skuteczność reguł nastawionych na typowe wzorce PowerShell.

3) „Execution gates” i anty-analiza
Blackpoint opisuje bramkowanie oparte m.in. o:

• walidację kolejności kroków i zachowania użytkownika,
• kontrolę schowka (marker potwierdzający manualne wklejenie),
• ciche „zawieszenie” (np. nieskończone oczekiwanie), by marnować zasoby sandboxów.

4) LotL infrastruktury: konfiguracja w Google Calendar (.ics)
Zamiast twardo kodować parametry C2/loadera, kampania pobiera je z publicznego pliku kalendarza (ICS) — prostej tekstówki, którą łatwo aktualizować bez ruszania pierwszych etapów.

5) Fileless/stage’in memory + steganografia w PNG
W kolejnych etapach payload jest odszyfrowywany/rozpakowywany w pamięci, a jedna z metod dostarczania to ukrycie zaszyfrowanego ładunku w obrazie PNG (steganografia).

6) Payload: Amatera Stealer
Amatera jest opisywana przez Proofpoint jako rebranding ACR Stealera, oferowany w modelu MaaS i rozwijany pod kątem unikania detekcji; w praktyce to „warstwa monetyzacji” wielu web-inject / ClickFix-like łańcuchów.

Praktyczne konsekwencje / ryzyko

• Celowanie w środowiska firmowe: App-V częściej występuje w środowiskach Enterprise/Education; tam też „naturalnie” działa SyncAppvPublishingServer.vbs, więc aktywność łatwiej ukryć w szumie.
• Kradzież danych uwierzytelniających i sesji: infostealery typowo polują na przeglądarki, hasła, tokeny, portfele krypto i dane aplikacji — co szybko przekłada się na przejęcia kont i dalszą propagację. (Charakterystyka Amatera jako aktywnie rozwijanego stealera/MaaS.)
• Niższa skuteczność „klasycznych” reguł PowerShell: jeżeli polityki/detekcje są budowane głównie wokół powershell.exe, proxy przez wscript.exe + podpisany skrypt może wyślizgiwać się spod części alertów.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h):

1. Edukacja i komunikat do użytkowników: „Nigdy nie wklejaj poleceń do Win+R/Terminala z przypadkowych stron (CAPTCHA, ‘fix’, ‘verify’)”. Microsoft wprost wskazuje ten element jako rdzeń ClickFix i punkt, w którym szkolenie realnie obniża ryzyko.
2. Detekcja: wscript.exe → SyncAppvPublishingServer.vbs z osadzonym PowerShell
   • MITRE sugeruje monitorowanie uruchomień tego skryptu przez wscript.exe i anomalii w linii poleceń, gdzie skrypt służy jako proxy dla PowerShell.
3. Ograniczenie powierzchni: blokada skryptu, jeśli App-V nie jest wymagany
   • MITRE w mitigacjach mówi wprost: jeśli podpisane skrypty proxy-execution nie są potrzebne, warto je blokować polityką kontroli aplikacji. (WDAC/AppLocker / allow-listing).

Wzmocnienia średnioterminowe (1–4 tyg.):

• Hardening stacji: ograniczenie możliwości uruchamiania narzędzi i interpreterów skryptowych tam, gdzie nie są niezbędne (w tym kontrola VBScript/WSH w środowisku).
• Telemetria PowerShell: gdzie to możliwe, włącz/utrzymaj logowanie (Script Block Logging/AMSI) i koreluj z nietypowym proces ancestry (PowerShell bez powershell.exe na wierzchu).
• Polityki uprawnień: minimalizacja lokalnych adminów oraz kontrola makr/skryptów i stref (szczególnie gdy wektor wejścia to web).
• Polowanie po IoC/TTP: nietypowe pobieranie .ics z publicznych usług, sekwencje loaderów „in-memory”, pobieranie PNG w kontekście skryptów i późniejsze deszyfrowanie/uruchomienie.

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

Klasyczny ClickFix często sprowadza się do „wklej i uruchom PowerShell”. Microsoft opisuje, że wariantów jest wiele, ale rdzeń pozostaje ten sam: użytkownik wykonuje polecenie, bo wygląda na element weryfikacji/naprawy.

To, co wyróżnia opisywaną kampanię, to proxy execution przez App-V (LOLBin) oraz wieloetapowa, konsekwentna optymalizacja pod anty-analizę: bramkowanie schowkiem i kolejnością, dead-drop w Google Calendar i steganografia w PNG, wszystko z naciskiem na „ciche” wykonanie w pamięci.

Podsumowanie / kluczowe wnioski

• ClickFix dalej działa, bo wykorzystuje nawyk „szybkiego naprawiania” problemu — a ta kampania pokazuje, że napastnicy potrafią go połączyć z podpisanymi komponentami Windows i przemyślanym łańcuchem evasion.
• SyncAppvPublishingServer.vbs nie jest egzotyką w ATT&CK — to rozpisana technika proxy-execution; jeśli masz App-V, musisz liczyć się z nadużyciem tego elementu.
• Największy „ROI” na start: uświadomienie użytkowników + detekcje na wscript/App-V + kontrola aplikacji (blokuj, jeśli niepotrzebne).

Źródła / bibliografia

1. BleepingComputer – „New ClickFix attacks abuse Windows App-V scripts to push malware” (26 stycznia 2026) (BleepingComputer)
2. Blackpoint Cyber – „Novel Fake CAPTCHA Chain Delivering Amatera Stealer” (Blackpoint)
3. MITRE ATT&CK – T1216.002 System Script Proxy Execution: SyncAppvPublishingServer (attack.mitre.org)
4. Microsoft Security Blog – „Think before you Click(Fix): Analyzing the ClickFix social engineering technique” (21 sierpnia 2025) (Microsoft)
5. Proofpoint – „Amatera Stealer: Rebranded ACR Stealer With Improved Evasion, Sophistication” (16 czerwca 2025) (Proofpoint)