Pastebin jako wektor oszustwa: komentarze promują atak ClickFix z JavaScriptem, który przechwytuje swapy krypto - Security Bez Tabu

Pastebin jako wektor oszustwa: komentarze promują atak ClickFix z JavaScriptem, który przechwytuje swapy krypto

Wprowadzenie do problemu / definicja luki

W połowie lutego 2026 zaobserwowano kampanię, w której napastnicy wykorzystują komentarze pod wpisami na Pastebin jako kanał dystrybucji instrukcji prowadzących do kradzieży kryptowalut. Mechanizm jest podstępny: ofiara dostaje „poradnik arbitrażowy”, który rzekomo pozwala zarobić na błędzie w wycenie swapów, a w praktyce nakłania do samodzielnego uruchomienia złośliwego JavaScriptu w przeglądarce. To wariant techniki ClickFix – czyli socjotechniki, gdzie atakujący „wkłada ofierze w ręce” krok po kroku działania, które same realizują kompromitację.

W tym przypadku nie mówimy o klasycznym pobraniu malware na system, tylko o przejęciu logiki działania strony swapowej w kontekście bieżącej sesji, tak aby podmienić adres depozytowy i przekierować środki do portfeli atakującego.

W skrócie

  • Atak jest promowany masowo w komentarzach na Pastebin i kieruje na „dokumentację wycieku”/„metodę zysku”.
  • Ofiara trafia m.in. na dokument (Google Docs) opisujący rzekomy „profit method” dla Swapzone/ChangeNOW.
  • Instrukcja nakazuje wkleić do paska adresu kod uruchamiany przez schemat javascript:.
  • Wstrzyknięty, mocno zaciemniony skrypt ma nadpisywać elementy aplikacji webowej i podmieniać adresy BTC (oraz manipulować wartościami/ofertami), by wyglądało to jak działający „arbitraż”.
  • To rzadki (i ważny) zwrot: ClickFix użyty do modyfikacji działania strony w przeglądarce, a nie do uruchamiania poleceń systemowych.

Kontekst / historia / powiązania

ClickFix jest obserwowany co najmniej od 2024 roku jako rosnąca rodzina „ataków z instrukcją naprawy”, gdzie przestępcy podszywają się pod pomoc techniczną, weryfikację bezpieczeństwa, „fix” błędu w przeglądarce itp., a następnie każą ofierze wykonać komendy (np. PowerShell) lub kliknięcia, które same omijają część zabezpieczeń. Microsoft opisywał tę technikę jako świadome dołożenie interakcji użytkownika, aby wyślizgnąć się spod automatycznych detekcji.

Z kolei sektorowe ostrzeżenia (np. HC3) zwracały uwagę, że ClickFix bazuje na wiarygodnie wyglądających komunikatach i presji, by „szybko naprawić problem”, a skutkiem bywa uruchomienie szkodliwych skryptów/poleceń.

Nowość w kampanii z lutego 2026 polega na tym, że „fix” nie instaluje (bezpośrednio) złośliwego programu w systemie, tylko przestawia transakcję w webowym interfejsie w momencie wykonywania swapu.

Analiza techniczna / szczegóły luki

1) Wejście: komentarze Pastebin → link pośredni → dokument „instrukcja zysku”

Atakujący przeglądają wpisy na Pastebin i zostawiają komentarze promujące „wyciek” oraz obiecujące wysokie zyski (np. kilka/kilkanaście tysięcy USD w parę dni). Link prowadzi do hostingu z przekierowaniem, a dalej do dokumentu typu Google Docs podszywającego się pod poradnik wykorzystania rzekomego błędu w przepływie kursów między usługami (Swapzone/ChangeNOW).

2) Kluczowy trik: uruchomienie kodu przez javascript: w pasku adresu

„Poradnik” każe ofierze wkleić fragment kodu tak, aby został wykonany w kontekście aktualnie otwartej strony swapowej. Technicznie wykorzystuje to schemat javascript:, czyli mechanizm URIs, w którym „nawigacja” skutkuje wykonaniem kodu JavaScript. MDN wprost ostrzega, że używanie javascript: jest odradzane, bo może prowadzić do wykonania arbitralnego kodu.

3) Łańcuch ładunków: loader → obfuskowany payload → web-inject

Z obserwacji wynika, że pierwszy skrypt doładowuje kolejny etap (payload) i wstrzykuje go w stronę, „podmieniając” elementy odpowiedzialne za proces swapu (opisano m.in. nadpisanie legalnego komponentu aplikacji webowej). Następnie atak:

  • podmienia adres depozytowy BTC na jeden z adresów kontrolowanych przez napastnika (losowany z listy),
  • oraz modyfikuje wyświetlane wartości/oferty, by ofiara miała wrażenie, że „metoda” faktycznie daje przewagę kursową.

To ważny aspekt psychologiczny: nie tylko kradzież, ale też „scenografia” potwierdzająca skuteczność rzekomego arbitrażu.

4) Dlaczego to działa?

Bo użytkownik sam wykonuje kod w kontekście zaufanej domeny, w trakcie realnej sesji. W efekcie:

  • UI wygląda znajomo,
  • ofiara „widzi” swój swap,
  • a krytyczny element (adres depozytowy) jest już podmieniony.

Praktyczne konsekwencje / ryzyko

  • Nieodwracalność: transakcje BTC (i wielu innych kryptowalut) są w praktyce nieodwracalne – po wysłaniu środków na zły adres odzyskanie ich jest skrajnie trudne lub niemożliwe.
  • Ryzyko dla użytkowników i helpdesków: ofiara często zgłasza „bug w swapie” dopiero po fakcie – a problem nie leży po stronie giełdy, tylko w lokalnym web-inject’cie uruchomionym w przeglądarce.
  • Ryzyko dla firm: pracownicy wykonujący swapy z urządzeń służbowych (lub w środowiskach z danymi firmowymi) mogą dodatkowo narazić organizację na wtórne skutki (np. ekspozycję danych sesyjnych/przeglądarkowych, jeśli kampania ewoluuje).
  • Skalowalność: dystrybucja przez komentarze i dokumenty „poradnikowe” jest tania i masowa – a obietnica szybkiego zysku znacząco zwiększa konwersję.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (SOC/IT może to komunikować jako „security advisory”)

  1. Nigdy nie uruchamiaj kodu w pasku adresu (ani javascript:, ani poleceń „do wklejenia”), nawet jeśli pochodzi z dokumentu „instruktażowego”.
  2. Jeśli korzystasz z agregatorów swapów: weryfikuj adres depozytowy „out-of-band” (np. porównanie z adresem w aplikacji portfela, skan QR z zaufanego źródła, whitelisty adresów).
  3. Traktuj jako czerwone flagi: „leak”, „exploit doc”, „profit method”, „arbitrage bug”, „13k w 2 dni”, „stary node/backend”.

Dla organizacji (polityki i detekcje)

  1. Edukacja pod ClickFix: krótkie szkolenia i komunikaty o schematach „naprawczych”, gdzie użytkownik jest proszony o wykonanie kroków/komend.
  2. Kontrola przeglądarek (MDM/Enterprise): rozważ hardening, rozszerzenia blokujące ryzykowne zachowania, monitorowanie nietypowych wzorców (np. anomalie w ruchu do hostów z surowym tekstem / krótkich redirectów w kontekście finansów).
  3. Procedura IR dla „crypto incidents”: gdy ktoś zgłosi błędny adres lub podejrzane zachowanie swapu – zbieraj artefakty (historia, rozszerzenia, logi przeglądarki, nagranie kroków), bo to może być web-inject uruchomiony lokalnie, a nie incydent po stronie dostawcy.

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

Klasyczne kampanie ClickFix zwykle kończą się uruchomieniem komend systemowych (PowerShell, skrypty), instalacją stealerów/RAT-ów itp. (to trend opisywany m.in. przez Microsoft oraz Unit 42).
W opisywanym incydencie punkt ciężkości przesunął się w stronę „webowego przejęcia transakcji”: zamiast infekować system, atakujący „podmienia” krytyczne dane w przeglądarce podczas operacji finansowej.

To istotna ewolucja: detekcje endpointowe mogą nie zobaczyć klasycznego droppera, a mimo to dochodzi do straty środków.

Podsumowanie / kluczowe wnioski

  • Kampania z 15 lutego 2026 pokazuje, że komentarze na platformach typu Pastebin mogą pełnić rolę skutecznego kanału dystrybucji socjotechniki.
  • ClickFix dojrzewa: coraz częściej nie „łamie” technologii, tylko łamie proces decyzyjny użytkownika.
  • Wariant z javascript: jest szczególnie groźny dla krypto, bo umożliwia manipulację w ramach zaufanej sesji i podmianę adresów depozytowych bez „klasycznej infekcji”.
  • Najskuteczniejsze zabezpieczenie to połączenie: twardych zasad (nie uruchamiamy kodu z poradników) + weryfikacji adresu przed wysyłką + świadomości ClickFix.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii „Pastebin comments push ClickFix JavaScript attack to hijack crypto swaps” (15.02.2026). (BleepingComputer)
  2. Microsoft Security Blog – analiza techniki ClickFix (21.08.2025). (microsoft.com)
  3. HHS HC3 – „ClickFix Attacks” (Sector Alert, 29.10.2024). (HHS.gov)
  4. Palo Alto Networks Unit 42 – materiał o rosnących kampaniach ClickFix (10.07.2025). (Unit 42)
  5. MDN (Mozilla) – dokumentacja schematu javascript: i ryzyk bezpieczeństwa (01.07.2025). (developer.mozilla.org)