Blog
Phishing și inginerie socială7 septembrie 202610 min de citit

ClickFix pe 5.400 de site-uri compromise: de ce un site legitim nu face instrucțiunea legitimă

Netskope a observat ClickFix pe peste 5.400 de site-uri compromise. Cum exersezi refuzul comenzilor, raportarea și răspunsul pe roluri.

Netskope Threat Labs a anunțat la 3 septembrie 2026 că a observat peste 5.400 de site-uri compromise, aparținând unui număr de peste 2.200 de organizații, care contactau endpointuri din BNB Smart Chain testnet. Pe multe dintre site-uri, codul injectat încărca o capcană ClickFix: un CAPTCHA fals care cere vizitatorului să deschidă fereastra Run și să lipească o comandă. Netskope a analizat și o variantă diferită care folosește un canal WebRTC pentru comandă și control.

Cifrele reprezintă telemetria Netskope din propria fereastră de observație, nu numărul tuturor site-urilor compromise de pe internet și nici numărul persoanelor infectate. Cercetătorii spun că metoda inițială prin care au fost compromise site-urile rămâne necunoscută. Varianta WebRTC este o ramură distinctă și nu trebuie descrisă ca rezultat al fiecărui CAPTCHA ClickFix.

Încrederea în site și în instrucțiune sunt două decizii diferite

Site-urile observate erau în principal ale unor afaceri mici, fără o industrie, regiune sau proprietar comun; în cazurile examinate, Netskope a întâlnit cel mai des WordPress și uneori PrestaShop. Vizitatorul poate ajunge pe un domeniu real, cunoscut și criptat HTTPS. Toate acestea verifică doar conexiunea și identitatea domeniului, nu integritatea fiecărui script care rulează în acel moment.

Tehnica numită EtherHiding folosește un contract inteligent ca loc din care scriptul compromis citește următoarea etapă. Operatorul poate schimba conținutul dintr-un singur loc, iar site-urile infectate îl cer din nou. Pentru utilizator, detaliul blockchain este secundar. Decizia critică rămâne simplă: o verificare CAPTCHA nu are nevoie ca persoana să deschidă un instrument de sistem și să execute text primit de pe pagină.

Regula memorabilă și excepția care nu trebuie inventată

Un CAPTCHA legitim nu îți cere să deschizi Run, Command Prompt, Terminal sau PowerShell și să lipești o comandă. O instrucțiune de acest tip trebuie oprită și raportată, chiar dacă pagina se află pe un site pe care îl cunoști.

Trainingul trebuie să evite formulări precum „nu folosi niciodată PowerShell”, deoarece administratorii și dezvoltatorii îl folosesc legitim. Controlul uman este legat de context și autoritate: cine a cerut acțiunea, prin ce procedură aprobată, pe ce dispozitiv și cu ce posibilitate de verificare. Un text copiat automat de o pagină web nu devine comandă administrativă autorizată.

Ce face fiecare rol când vede sau primește raportarea

  • Angajatul închide pagina, notează adresa și ora și raportează prin canalul intern; nu repetă pașii pentru capturi mai bune.
  • Help desk-ul întreabă dacă instrucțiunea a fost doar văzută, copiată sau executată și evită să ceară utilizatorului să reproducă acțiunea.
  • SOC-ul separă expunerea la pagină de execuția comenzii și caută procese, conexiuni și schimbări potrivite cronologiei raportate.
  • Echipa de identitate evaluează credențialele și sesiunile accesibile pe dispozitiv dacă o comandă a fost executată.
  • Ownerul site-ului sau furnizorul CMS păstrează dovezi, verifică integritatea fișierelor și extensiilor și nu se limitează la eliminarea overlay-ului vizibil.
  • Comunicarea spune că un site a fost compromis doar când există dovadă și nu transformă numărul site-urilor observate în număr de utilizatori infectați.

Tabletop cu două organizații afectate diferit

Exercițiul poate lega compania al cărei site a fost compromis de compania al cărei angajat a vizitat pagina. Acestea au obligații și dovezi diferite. Pentru fiecare inject, cereți decizia, ownerul, termenul și limita afirmațiilor publice.

  • Inject 1 — un angajat raportează un CAPTCHA care i-a cerut să deschidă Run, dar spune că s-a oprit înainte de execuție. Ce investigați și ce nivel de incident declarați?
  • Inject 2 — un al doilea angajat a urmat instrucțiunea. Cum izolați dispozitivul, păstrați dovezile și evaluați identitatea fără a presupune deja furtul de date?
  • Inject 3 — site-ul companiei afișează aceeași capcană doar pentru unii vizitatori. Cine implică furnizorul, cine conservă artefactele și cine decide revenirea în producție?
  • Inject 4 — un jurnalist întreabă câți clienți au fost infectați. Cum explicați diferența dintre site compromis, vizită, comandă executată și dispozitiv confirmat compromis?

Măsurători care testează decizia, nu memoria termenului ClickFix

  • Procentul participanților care refuză instrucțiunea chiar dacă domeniul este legitim și pagina folosește HTTPS.
  • Timpul până la raportare și calitatea informațiilor păstrate fără repetarea acțiunii riscante.
  • Procentul cazurilor în care help desk-ul diferențiază „am văzut”, „am copiat” și „am executat”.
  • Timpul până la izolarea dispozitivului și implicarea echipei de identitate după execuție.
  • Capacitatea ownerului web de a identifica activele, furnizorul, backupul curat și criteriul de repunere în funcțiune.

Cum poate ajuta Learning Awarely

Learning Awarely poate transforma aceeași situație într-un exercițiu scurt pentru utilizatori și într-un tabletop separat pentru help desk, SOC, identity, echipa web și comunicare. Rezultatele pot arăta cine a refuzat comanda, cine a escaladat și unde procesul nu are owner. Platforma nu detectează scriptul, nu curăță site-ul și nu înlocuiește investigația endpoint.

Schimbarea utilă de comportament este trecerea de la „recunosc site-ul, deci pot urma instrucțiunea” la „verific dacă această acțiune are sens și este autorizată”. Această regulă rămâne valabilă chiar dacă infrastructura de livrare se mută între cloud, blockchain sau alte servicii legitime.

#ClickFix#EtherHiding#fake CAPTCHA#PowerShell#WordPress#social engineering#awareness#incident response