ClickFix prin blockchain: 5.400 de site-uri compromise
Netskope Threat Labs a raportat la 3 septembrie 2026 că a observat peste 5.400 de site-uri compromise, aparținând la peste 2.200 de organizații, care contactau endpoint-uri BNB Smart Chain testnet. În site-uri era injectat un loader care putea prelua dintr-un smart contract o pagină falsă de tip CAPTCHA și instrucțiuni ClickFix sau, într-o variantă mai nouă, cod pentru un canal WebRTC ascuns.
Cifrele și mecanismul provin din telemetria și analiza cercetătorului, iar BleepingComputer le-a relatat independent. Nu există însă o confirmare individuală din partea tuturor proprietarilor celor 5.400 de site-uri, iar metoda prin care ele au fost compromise inițial rămâne necunoscută. Pentru apărare, informația utilă nu este doar numărul: este legătura verificabilă dintre fiecare CMS, integritatea fișierelor sale, traficul neobișnuit și ownerul care trebuie să închidă acțiunea.
Ce este raportat și ce nu este demonstrat
Netskope spune că site-urile observate aveau puține elemente comune dincolo de faptul că aparțineau unor afaceri mici. În cazurile examinate, platforma era cel mai des WordPress și uneori PrestaShop. Cercetătorii au numărat peste 5.400 de site-uri distincte în intervalul analizat, cu peste 300 active în fiecare zi lucrătoare la momentul publicării.
Aceste date confirmă ce a văzut Netskope în propria telemetrie, nu o listă universală a tuturor victimelor. Nu este cunoscută vulnerabilitatea, parola furată, pluginul sau alt mecanism folosit pentru accesul inițial. De aceea, articolul nu atribuie o cauză comună și nu transformă prezența WordPress sau PrestaShop într-o vulnerabilitate a acelor produse.
De ce schimbă blockchain-ul răspunsul
Loaderul injectat face un apel JSON-RPC către un smart contract de pe BNB Smart Chain testnet și primește următoarea etapă. Contractul funcționează ca un dead drop: operatorul poate schimba conținutul livrat central, iar site-urile compromise citesc versiunea nouă fără ca fiecare dintre ele să fie modificat din nou.
Asta nu face atacul imposibil de detectat și nici blockchain-ul rău în sine. Schimbă însă punctele de control: blocarea unui singur domeniu de găzduire este insuficientă, iar o regulă limitată la endpoint-ul văzut inițial poate fi ocolită. Apărarea trebuie să combine integritatea site-ului, observarea apelurilor RPC și validarea traficului care nu seamănă cu funcția normală a aplicației.
ClickFix și varianta WebRTC cer două ipoteze de detecție
În lanțul ClickFix, vizitatorul vede o interfață CAPTCHA falsă care îl convinge să ruleze manual o comandă. Aceasta este o etapă de inginerie socială; alerta trebuie corelată cu activitatea proceselor de pe endpoint și cu pagina vizitată, fără a păstra sau redistribui comanda atacatorului.
În varianta WebRTC descrisă de Netskope, codul din browser deschide un canal de date criptat către infrastructura de comandă și control și execută cod primit în memorie. Cercetătorii recomandă monitorizarea traficului non-web asociat WebRTC. Un proxy HTTP care nu vede nimic suspect nu este, singur, o dovadă că sesiunea a fost sigură.
Flux defensiv pentru proprietarii de site-uri
- ▸Inventariază instanțele WordPress, PrestaShop și alte CMS-uri, inclusiv site-urile de campanie, staging, subdomeniile vechi și mediile administrate de agenții.
- ▸Înregistrează pentru fiecare activ versiunea, pluginurile sau modulele, furnizorul de hosting, ownerul tehnic, expunerea publică și ultima verificare de integritate.
- ▸Compară fișierele JavaScript, pluginurile obligatorii și directoarele de extensii cu o sursă cunoscută; investighează loader-ele și pachetele care nu au o proveniență aprobată.
- ▸Caută apeluri neobișnuite către pool-ul de endpoint-uri BSC testnet și trafic UDP non-web relevant, folosind indicatorii actualizați de cercetător, nu o copie înghețată.
- ▸Pe endpoint-uri, corelează vizitele cu alerte de script, comenzi lansate de utilizator și execuție din browser; păstrează dovezile înainte de curățare.
- ▸Închide cazul per site și per endpoint doar după eliminarea injecției, corectarea căii de acces identificate, rotația accesului relevant și reverificare.
Cum eviți două concluzii greșite
Prima concluzie greșită este că toate site-urile au fost compromise prin aceeași vulnerabilitate. Sursa primară spune explicit că accesul inițial este necunoscut. A doua este că blocarea BSC testnet rezolvă compromiterea CMS-ului. Blocarea poate reduce livrarea observată, dar nu elimină loaderul și nu repară mecanismul prin care atacatorul a modificat site-ul.
Separă acțiunile în trei piste: protejarea vizitatorilor, curățarea site-ului și investigarea accesului inițial. Notează ce este confirmat, ce este doar o ipoteză și ce dovadă ar închide fiecare necunoscut. Dacă indicatorii se schimbă, redeschide verificarea pentru activele relevante.
Cum ajută MONITOR AWARELY
MONITOR AWARELY poate lega tehnologiile urmărite de activele CMS, owneri, furnizori, termene și dovezi de verificare. Astfel, un avertisment global devine o listă concretă: care site a fost verificat, ce integritate s-a comparat, cine a evaluat traficul și ce excepție rămâne deschisă.
Platforma nu scanează fișierele site-ului, nu aplică reguli de rețea și nu confirmă compromiterea. Aceste rezultate trebuie să vină din WAF, EDR, DNS, proxy, integritate de fișiere și investigație; MONITOR AWARELY le poate păstra în fluxul de remediere pentru ca închiderea să fie verificabilă.
Leagă fiecare CMS de owner, expunere și dovadă
MONITOR AWARELY poate urmări produsele CMS, activele, ownerii, acțiunile și dovezile de verificare. Nu scanează site-uri, nu blochează trafic și nu înlocuiește EDR, WAF, analiza de integritate sau răspunsul la incident.