Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Atak na łańcuch dostaw po stronie przeglądarki to jeden z najbardziej niebezpiecznych scenariuszy dla współczesnych serwisów internetowych. Wystarczy kompromitacja pojedynczego, zaufanego skryptu zewnętrznego dostawcy, aby narazić jednocześnie wiele niezależnych witryn i ich użytkowników.
W opisywanym incydencie zmodyfikowany skrypt Adform miał podmieniać adresy portfeli kryptowalut bezpośrednio w przeglądarce. Taka manipulacja mogła skutkować przekierowaniem środków na portfele kontrolowane przez napastników, nawet jeśli ofiara korzystała z legalnej i zaufanej strony.
W skrócie
Złośliwa modyfikacja dotyczyła pliku trackpoint-async.js, osadzanego na stronach klientów jako komponent analityczny i trackingowy. Według publicznych analiz skrypt rozpoznawał adresy portfeli Bitcoin, Ethereum i Tron, a następnie zastępował je innymi wartościami.
Mechanizm ingerował nie tylko w operacje kopiowania do schowka, ale także w dane wpisywane lub wklejane do formularzy. Adform poinformował o wykryciu problemu 27 lipca 2026 roku, usunięciu złośliwego kodu oraz zalecił użytkownikom wyczyszczenie pamięci podręcznej przeglądarki.
- celem była podmiana adresów kryptowalutowych,
- atak miał charakter supply chain po stronie klienta WWW,
- zagrożenie mogło utrzymywać się dłużej z powodu cache przeglądarki.
Kontekst / historia
Ryzyko związane ze skryptami stron trzecich od dawna jest znanym problemem w bezpieczeństwie aplikacji webowych. Wiele organizacji korzysta z zewnętrznych narzędzi reklamowych, analitycznych i marketingowych, które są ładowane automatycznie na dużej liczbie podstron.
Taki model zapewnia wygodę biznesową, ale jednocześnie rozszerza powierzchnię ataku. Jeśli cyberprzestępcy przejmą kontrolę nad jednym popularnym zasobem JavaScript, mogą uzyskać wpływ na ruch użytkowników wielu serwisów bez konieczności włamywania się do każdego z nich oddzielnie.
W tym przypadku atak nie polegał na instalacji klasycznego malware w systemie operacyjnym ofiary. Zamiast tego wykorzystano logikę wykonywaną w przeglądarce, czyli tam, gdzie użytkownik podejmuje decyzję o skopiowaniu, wpisaniu lub zatwierdzeniu adresu odbiorcy transakcji.
Analiza techniczna
Według opublikowanych ustaleń do prawidłowej biblioteki dopisano dwa bloki złośliwego kodu. Ich zadaniem było przechwytywanie danych związanych z adresami kryptowalut i zastępowanie ich wartościami należącymi do operatora ataku.
Pierwszy element odpowiadał za monitorowanie operacji kopiowania oraz analizę zawartości schowka. Jeśli wykryto wzorzec pasujący do adresu portfela, skrypt podmieniał wartość jeszcze przed jej dalszym użyciem. To szczególnie groźny wariant ataku, ponieważ użytkownik mógł widzieć poprawny adres na stronie, lecz wkleić już zmienioną wersję.
Drugi komponent działał bezpośrednio na elementach strony. Analizował treść dokumentu oraz ingerował w pola input, textarea i obiekty contenteditable. Opisane zachowanie obejmowało także zachowanie pozycji kursora po modyfikacji, co zmniejszało szansę zauważenia podmiany przez użytkownika.
Publiczne analizy wskazywały również na reakcję kodu na zdarzenia copy, cut, paste oraz input. W próbkach opisywano też próbę wykonania żądania HTTP do zewnętrznego hosta z informacjami o aktualnie odwiedzanej stronie, choć pełna skala skutecznej eksfiltracji nie została jednoznacznie potwierdzona.
Z punktu widzenia bezpieczeństwa frontendowego był to klasyczny atak supply chain na zasób klientowski. Skala zagrożenia zależała od liczby serwisów korzystających z podatnego skryptu oraz od tego, jak długo użytkownicy pracowali na jego zapisanej w pamięci podręcznej wersji.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem incydentu było ryzyko trwałej utraty środków kryptowalutowych. Transakcje blockchain są z zasady nieodwracalne, dlatego nawet pojedyncza, niezauważona podmiana adresu mogła prowadzić do realnych strat finansowych.
Problem nie dotyczył wyłącznie użytkowników końcowych. Operatorzy serwisów, którzy sami nie zostali bezpośrednio zhakowani, mogli nieświadomie stać się nośnikiem ataku. To z kolei rodzi pytania o odpowiedzialność, procedury bezpieczeństwa i nadzór nad dostawcami zewnętrznego kodu.
- Użytkownicy końcowi – mogli wysłać środki na fałszywy adres mimo korzystania z poprawnej strony.
- Właściciele serwisów – stawali się pośrednim wektorem ataku na odwiedzających.
- Zespoły bezpieczeństwa – musiały mierzyć się z ograniczoną widocznością zdarzeń zachodzących wyłącznie w przeglądarce.
- Obszar prywatności – dodatkowe ryzyko mogły stanowić metadane dotyczące odwiedzanych stron.
Dodatkowym utrudnieniem była pamięć podręczna przeglądarki. Nawet po usunięciu złośliwej wersji po stronie dostawcy część użytkowników mogła nadal wykonywać skrypt z lokalnego cache, co wydłużało rzeczywiste okno ekspozycji.
Rekomendacje
Incydent pokazuje, że organizacje powinny traktować zewnętrzny JavaScript jako kod uprzywilejowany, działający bezpośrednio w kontekście ich aplikacji i użytkowników. Ochrona przed podobnymi zdarzeniami wymaga zarówno kontroli technicznych, jak i dojrzałych procesów zarządzania ryzykiem dostawców.
- Zidentyfikować wszystkie zależności frontendu – należy utrzymywać pełny rejestr skryptów, tagów i bibliotek ładowanych z domen zewnętrznych.
- Wdrożyć kontrolę integralności – tam, gdzie to możliwe, warto stosować Subresource Integrity oraz restrykcyjne polityki Content Security Policy.
- Monitorować zachowanie warstwy webowej – potrzebne są mechanizmy wykrywające nietypowe modyfikacje DOM, schowka i formularzy.
- Ograniczać liczbę skryptów stron trzecich – każdy dodatkowy komponent zwiększa powierzchnię ataku.
- Przygotować procedury reagowania – plan powinien obejmować szybkie wyłączenie dostawcy, purge cache, analizę IOC i komunikację do użytkowników.
- Wzmacniać weryfikację adresów portfeli – przy płatnościach kryptowalutowych warto stosować dodatkowe kontrole wizualne i potwierdzenia poza przeglądarką.
- Przeprowadzać due diligence dostawców – szczególnie tych, których kod wykonuje się bezpośrednio po stronie użytkownika.
Podsumowanie
Przypadek Adform pokazuje, że nowoczesny atak supply chain nie musi wykorzystywać klasycznego złośliwego oprogramowania, aby przynieść wymierne szkody finansowe. Wystarczy przejęcie popularnego skryptu klientowskiego i precyzyjna manipulacja danymi w przeglądarce.
Podmiana adresów portfeli kryptowalut to scenariusz wyjątkowo skuteczny operacyjnie, ponieważ uderza w rutynowe zachowania użytkowników i wykorzystuje niską widoczność zagrożeń w warstwie frontendowej. Dla firm jest to wyraźny sygnał, że bezpieczeństwo aplikacji webowych musi obejmować nie tylko własny kod, ale cały ekosystem zewnętrznych zależności.
Źródła
- The Hacker News — Hackers Poison Adform Script to Swap Crypto Wallet Addresses Across Customer Sites — https://thehackernews.com/2026/08/hackers-poison-adform-script-to-swap.html
- Adform Help Center — Variables (JavaScript) — https://www.adformhelp.com/hc/en-us/articles/10023217401617-Variables-JavaScript
- BleepingComputer — AppsFlyer Web SDK hijacked to spread crypto-stealing JavaScript code — https://www.bleepingcomputer.com/news/security/appsflyer-web-sdk-used-to-spread-crypto-stealer-javascript-code/
- BleepingComputer — Polymarket customers lose $3 million in supply-chain attack — https://www.bleepingcomputer.com/news/security/polymarket-customers-lose-3-million-in-supply-chain-attack/