ClickFix pe site-uri WordPress compromise: cum găsești CAPTCHA-ul fals injectat, elimini scriptul care îl încarcă și dovedești că site-ul este curat

Dacă site-ul tău WordPress compromis a început să afișeze o verificare falsă în stil Cloudflare, un mesaj de tipul „I am human” sau un pseudo-CAPTCHA care le cere vizitatorilor să ruleze comenzi în Windows Run ori PowerShell, nu mai ai de-a face cu un caz obișnuit de spam injectat. În acel moment, site-ul tău nu mai este doar compromis. A devenit un mijloc de livrare pentru o fraudă activă împotriva vizitatorilor. Problema nu se mai rezumă la „șterg niște fișiere și merg mai departe”. Trebuie să oprești imediat servirea acelei pagini, să găsești mecanismul care o injectează, să elimini persistența și să dovedești că site-ul este sigur din exterior, nu doar din interiorul wp-admin.

Asta schimbă radical felul în care trebuie tratat incidentul. Mulți proprietari de site-uri pornesc de la o presupunere greșită: dacă homepage-ul lor arată normal, site-ul este în regulă. Nu este. Un site WordPress compromis poate afișa un fake CAPTCHA doar în anumite condiții, numai vizitatorilor noi, doar anumitor user-agent-uri sau abia după ce un script intermediar verifică starea browserului. Cu alte cuvinte, tu poți intra pe site, poți vedea totul aparent curat și totuși utilizatorii reali să primească o capcană care îi împinge să ruleze comenzi malițioase pe propriul sistem.

Acest articol nu este un ghid generic de curățare pentru WordPress hackuit. ServerSpan are deja materiale conexe pentru compromisuri recurente și cleanup clasic, inclusiv Cum să rezolvi problemele persistente de malware în WordPress pe găzduirea partajată. Articolul de față este mai specific. Este procedura practică pentru site-uri compromise care pot servi un fake Cloudflare CAPTCHA, un loader de tip ClickFix sau un lanț condiționat de scripturi malițioase care pune vizitatorii în pericol chiar și după ce tu crezi că „ai curățat site-ul”.

De ce un compromis cu CAPTCHA fals este diferit de un cleanup WordPress obișnuit

Multe compromisuri WordPress clasice înseamnă SEO spam, redirecturi ascunse, linkuri injectate sau backdoor-uri. Un atac de tip ClickFix adaugă încă un strat de gravitate. Site-ul tău nu mai este doar o victimă. Este folosit ca suprafață de atac împotriva vizitatorilor. Asta schimbă prioritățile.

• Nu îți aperi doar site-ul. Îi protejezi și pe cei care îl vizitează.
• Codul malițios poate fi servit condiționat și să nu apară în orice sesiune.
• Injecția poate veni dintr-un script extern scurt și aparent banal, nu dintr-un fișier mare și evident infectat.
• Impactul principal se poate produce în browserul vizitatorului, nu doar pe server.
• Faptul că „acum pare curat” nu valorează nimic dacă nu verifici conținutul public livrat către utilizatori reali.

De aceea ghidul acesta pune accent pe inspectarea paginilor publice, inventarul scripturilor externe, identificarea mecanismului de încărcare, eliminarea persistenței, analiza logurilor și demonstrarea faptului că vizitatorii nu mai sunt expuși. Dacă te limitezi la o scanare de fișiere și la o concluzie rapidă, faci o curățare superficială și atât.

Pasul 1: oprește expunerea vizitatorilor cât timp investighezi

Dacă ai motive serioase să crezi că site-ul servește o verificare falsă, prima obligație este să limitezi expunerea vizitatorilor. Nu lăsa site-ul live doar pentru că vrei „să te mai uiți puțin” înainte să iei o măsură. Dacă paginile compromise sunt încă accesibile, riști să trimiți oameni reali într-o fraudă activă.

• Pune site-ul într-o pagină de mentenanță, dacă impactul comercial îți permite.
• Restricționează accesul după IP dacă ai control la nivel de server.
• Oprește temporar campaniile plătite, newsletterele și orice sursă de trafic pe care o poți controla până când verifici ce livrează efectiv site-ul în public.

Pe un VPS cu NGINX, o regulă temporară de mentenanță este mai curată decât să te bazezi pe un plugin WordPress activat în grabă în timpul unui compromis. Pe Apache, ideea este aceeași. Dacă injecția trăiește într-un fișier de temă, într-un MU plugin sau într-un script introdus mai sus în lanțul de execuție, un plugin de mentenanță poate intra prea târziu în joc ca să te ajute cu adevărat.

Dacă nu controlezi web serverul și singura ta metodă de a opri traficul este tot prin CMS, acesta este deja un indiciu că mediul este prea limitat pentru o gestionare sigură a incidentului în regim DIY.

Pasul 2: confirmă dacă fake CAPTCHA-ul este încă servit

Nu te baza pe browserul în care ești deja logat și în care ai istoric, cookie-uri și sesiuni deschise. Testează din medii curate și tratează site-ul ca nesigur până când poți demonstra contrariul.

Începe cu o verificare brută a răspunsului HTTP și a HTML-ului livrat public:

curl -I https://example.com/
curl -s https://example.com/ | head -100
curl -s -A "Mozilla/5.0" https://example.com/ | grep -Ei "captcha|cloudflare|verify|clipboard|powershell|mshta|wscript"
curl -s -A "Mozilla/5.0" https://example.com/ | grep -Ei "<script|src="

Aceste comenzi îți arată rapid trei lucruri utile:

• dacă HTML-ul public conține limbaj suspect legat de verificare sau CAPTCHA
• dacă există taguri de script ori surse externe care nu ar trebui să fie acolo
• dacă răspunsul diferă în funcție de user-agent

Apoi testează dintr-un profil de browser complet nou, din incognito și, ideal, de pe alt dispozitiv sau dintr-o mașină virtuală curată. Multe injecții WordPress de tip fake CAPTCHA nu apar pentru oricine și oricând. Se pot baza pe cookie-uri, pe referrer, pe geolocație sau pe alte condiții de browser. O singură verificare reușită nu înseamnă nimic. Mai multe verificări curate, în condiții diferite, încep să însemne ceva.

Nu testa doar homepage-ul. Verifică și pagini de articol, arhive, pagini de categorie, rezultate de căutare și chiar 404-uri. Un site compromis poate servi prima pagină normal și, în același timp, să injecteze conținut malițios pe alte tipuri de pagini pe care utilizatorii chiar ajung.

Pasul 3: fă un inventar al scripturilor externe înainte să ștergi orice

Unul dintre cele mai comune motive pentru care astfel de compromisuri revin este că proprietarul vede „un script dubios”, îl șterge în grabă și nu înțelege cum era compusă pagina. Asta este exact ordinea greșită. Înainte să ștergi ceva, trebuie să înțelegi ce încarcă pagina publică și de unde.

Descarcă HTML-ul actual și extrage sursele de script:

curl -s https://example.com/ > /tmp/example-home.html
grep -Eoi '<script[^>]+src="[^"]+"' /tmp/example-home.html
grep -Eoi 'https?://[^"]+' /tmp/example-home.html | sort -u

Ținta este să obții o listă scurtă, clară și explicabilă. Elemente legitime sunt, de regulă, analytics, fonturi, resurse servite prin CDN, componente de consimțământ sau una-două librării de frontend. Ce nu ar trebui să vezi sunt domenii necunoscute, hostname-uri nou apărute sau scripturi externe fără rol clar în arhitectura site-ului tău.

Dacă găsești un script extern suspect, nu te opri la ștergerea tagului. Întrebarea reală este de unde a fost introdus:

• din header-ul sau footer-ul temei
• dintr-un MU plugin
• dintr-un plugin fals sau compromis
• dintr-o opțiune din baza de date care injectează cod în pagină
• dintr-un container de tag manager
• dintr-un câmp folosit pentru integrarea analytics sau reclame
• dintr-o modificare făcută la nivel de server, în afara WordPress

Aici se face diferența dintre un cleanup real și o iluzie de cleanup. Dacă sursa era un plugin fals sau o opțiune malițioasă din admin, site-ul nu devine curat pentru că ai șters un singur script. Dacă sursa era în afara WordPress, atunci wp-admin poate să nu îți spună nimic relevant.

Pasul 4: caută mecanismul de încărcare injectat în WordPress

Aici se consumă, de obicei, munca reală. Fake CAPTCHA-ul pe care îl vede vizitatorul nu este aproape niciodată obiectul principal. Este doar partea vizibilă. Problema reală este mecanismul care decide când și cum să îl încarce.

Începe cu fișierele modificate recent:

find . -type f -mtime -10 -ls
find wp-content -type f -mtime -10 -ls
find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.js" \) -ls

Apoi caută tiparele tipice folosite de asemenea mecanisme:

grep --include=*.php -Rni . -e "base64_decode" -e "gzinflate" -e "fromCharCode" -e "eval\s*(" -e "document.createElement('script')" -e "document.write" -e "atob("

grep --include=*.js -Rni . -e "clipboard" -e "powershell" -e "mshta" -e "wscript" -e "captcha" -e "cloudflare" -e "verify you are human"

Nu trata fiecare rezultat ca pe dovada finală. Unele potriviri pot aparține unui cod legitim. Scopul este să identifici ce nu are ce căuta acolo. Cele mai importante puncte de verificare sunt de obicei:

• wp-content/mu-plugins/
• directoare neașteptate de pluginuri
• functions.php din tema activă
• header.php și fișierele de footer ale temei
• wp-config.php
• .htaccess
• intrări din wp_options care stochează cod inserat în header sau footer

Verifică și mecanismele de execuție programată:

wp cron event list
crontab -l
ls -la /etc/cron* 2>/dev/null

Dacă scriptul malițios reapare după ce îl ștergi, persistența este foarte probabil programată sau reintrodusă automat. Asta se vede mai ales în scenariile în care proprietarul site-ului spune că „a curățat tot” și, după câteva ore, problema reapare sau reapare un cont de administrator necunoscut.

Și da, apariția unui administrator necunoscut este un semnal extrem de serios. Verifică lista de administratori din linia de comandă, nu doar vizual în wp-admin:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Dacă există un administrator pe care nu l-ai creat tu, presupune că site-ul nu a fost curățat cu adevărat. Ștergerea contului este necesară, dar nu rezolvă singură problema. Tot trebuie să găsești ce l-a creat sau ce a păstrat accesul deschis.

Pasul 5: dovedește că WordPress core, pluginurile și tema sunt din nou de încredere

Să ștergi niște fișiere nu înseamnă că ai demonstrat integritatea site-ului. Dacă vrei să poți spune serios că site-ul este curat, începe cu ce poate fi verificat obiectiv.

wp core verify-checksums
wp plugin verify-checksums --all --strict

Asta îți dă dovadă reală pentru WordPress core și pentru pluginurile din repository. Nu rezolvă însă pluginurile premium, codul custom sau componentele abandonate. Acolo trebuie să judeci conservator:

• reinstalează WordPress core dintr-o sursă curată
• reinstalează pluginurile oficiale din surse curate
• reinstalează tema dintr-o sursă curată
• elimină componentele abandonate, nulled sau imposibil de verificat

Să păstrezi un folder vechi de plugin „ca să fie” după un compromis este o prostie. Dacă nu poți spune clar de unde vine codul și de ce ar trebui să ai încredere în el, atunci nu ai voie să susții că site-ul este curat.

Aici compromisurile de tip ClickFix se întâlnesc și cu problema mai largă a reinfectării recurente. Dacă site-ul împarte același cont cu alte instalări WordPress vechi, copii abandonate sau backupuri uitate, curățarea site-ului principal poate să nu elimine sursa reală a compromiterii. Din acest motiv, articolul ServerSpan despre malware persistent pe găzduire partajată este relevant și aici. Reinfectarea indică, de obicei, dezordine în mediu, nu ghinion.

Pasul 6: verifică stratul de server, nu doar WordPress

Dacă te oprești la fișierele WordPress, riști să ratezi exact mecanismul care încarcă conținutul malițios. Un site compromis poate injecta JavaScript ostil din afara CMS-ului, mai ales pe găzduire slabă sau pe VPS-uri configurate improvizat.

Revizuiește logurile și căile de configurare care chiar controlează conținutul public:

• /var/log/nginx/
• /var/log/apache2/
• /etc/nginx/
• /etc/apache2/

Caută:

• rescrieri neașteptate
• include-uri injectate
• requesturi suspecte către admin, uploads sau fișiere JS necunoscute
• abuz repetat pe POST din aceleași intervale de IP
• încercări de acces către fișiere care nu ar trebui să existe
• redirecturi condiționale sau comportament ciudat dependent de referrer

Dacă ai root, compară configurațiile active de vhost cu ceea ce ar trebui să existe în mod normal. Dacă nu ai root și nici acces real la loguri sau config, fii sincer în privința limitelor tale. În acel punct faci doar o curățare superficială într-un mediu pe care nu îl poți verifica complet.

Abia aici începe să aibă sens și un WAF, dar în ordinea corectă. Un WAF nu este primul răspuns pentru un site deja compromis. Este un strat suplimentar de întărire după cleanup. Dacă rulezi pe un VPS și vrei să pui un web application firewall serios după incident, ServerSpan are deja un ghid practic pentru ModSecurity cu NGINX. Folosește-l după ce elimini mecanismul de încărcare malițios, nu în locul acelei eliminări.

Pasul 7: demonstrează din exterior că vizitatorii sunt în siguranță

Aici greșesc mulți proprietari de site-uri. Se opresc la „am scos fișierul suspect”. Asta nu este dovadă. Dovada înseamnă că site-ul public nu mai servește fake CAPTCHA-ul, nu mai încarcă lanțul de scripturi malițioase și nu se mai comportă diferit pentru utilizatorii reali față de cum se comportă pentru tine.

Înainte să declari site-ul curat, fă toate aceste verificări:

• extrage paginile publice cu curl dintr-o rețea externă curată
• testează din incognito și dintr-un profil complet nou de browser
• verifică mai multe tipuri de pagini, nu doar homepage-ul
• refă inventarul de scripturi externe și compară-l cu fotografia pe care ai făcut-o înainte de cleanup
• verifică Security Issues în Search Console dacă Google a semnalat site-ul

Dacă Google a marcat site-ul ca periculos, tratează raportul Security Issues ca punct de referință. Dacă acolo problema încă apare, site-ul nu este încă „terminat” din perspectiva Google, chiar dacă tu nu mai poți reproduce avertismentul. Dacă ai nevoie de review, cere-l doar după ce poți explica exact ce cod malițios ai scos și ce vulnerabilitate sau cale de acces ai închis.

Asta contează și mai mult în cazul unui fake Cloudflare CAPTCHA, pentru că nu mai vorbim doar despre „o problemă de imagine”. Vorbim despre o formă de fraudă sau livrare de malware care poate afecta direct vizitatorii. Dacă trimiți un review request fără să poți descrie remedierea reală, doar pierzi timp.

Pasul 8: întărește mediul astfel încât același incident să nu revină

După cleanup, întărirea mediului nu este opțională. Dacă site-ul a fost compromis o dată, întrebarea nu mai este dacă trebuie să îmbunătățești securitatea. Întrebarea este câtă încredere mai poți avea în mediul actual.

• rotește toate credențialele relevante, nu doar parola din wp-admin
• revizuiește toți administratorii și elimină accesul latent
• dezactivează editarea directă de fișiere din dashboard
• impune 2FA pentru administratori
• redu numărul de pluginuri și elimină componentele abandonate
• verifică permisiunile de fișiere și căile de execuție ale web serverului
• țină copiile de test și backupurile în afara aceluiași cont dezordonat, dacă poți

Dacă compromisul s-a produs pe găzduire partajată slabă, într-un cont cu mai multe instalări WordPress, resturi vechi și vizibilitate redusă, trebuie să încetezi să gândești doar în termeni de „pluginuri de securitate” sau „un fișier dubios”. Problema reală poate fi stratul de hosting. Unele site-uri pot rămâne pe găzduire partajată bine administrată. Unele trebuie mutate într-un mediu managed mai curat. Unele au nevoie de control real la nivel de VPS, dar numai dacă există cineva capabil să-l administreze corect.

Aici este și concluzia comercială serioasă. Dacă site-ul este deja compromis, vizitatorii pot fi expuși și tu tot nu poți spune clar de unde a venit scriptul care a încărcat pagina falsă, atunci DIY poate să nu mai fie alegerea rațională. Pentru site-uri mai simple, care au nevoie în primul rând de o platformă mai curată, Web Hosting-ul ServerSpan este pasul logic. Pentru cazuri mai complexe, unde ai nevoie de izolare, acces la loguri și control real asupra mediului, un server virtual administrat corect este o variantă mult mai onestă decât să pretinzi că un cont slab de găzduire partajată este suficient.

Când DIY nu mai este rațional

Fii direct cu tine. Oprește-te din a trata situația în regim DIY când una sau mai multe dintre următoarele sunt adevărate:

• fake CAPTCHA-ul sau scriptul suspect revine după cleanup
• continui să găsești administratori necunoscuți
• nu poți identifica mecanismul real care încarcă injecția
• nu ai acces suficient ca să verifici logurile ori configurația web serverului
• site-ul deservește trafic real, leaduri, rezervări sau plăți
• nu poți spune cu încredere că vizitatorii sunt în siguranță chiar acum

Din acel punct, munca nu mai înseamnă „șterg un fișier și gata”. Înseamnă recuperare WordPress, investigație la nivel de server, întărire de mediu și validare externă. Exact acolo ajutorul administrat încetează să mai fie un moft și devine mai ieftin decât cleanup-urile incomplete repetate și decât pierderea de încredere.

Un arbore de decizie simplu și practic

• Dacă fake CAPTCHA-ul a apărut o singură dată, ai găsit mecanismul de încărcare, ai reinstalat cod curat, iar paginile publice se verifică drept curate din mai multe medii, atunci întărește și monitorizează.
• Dacă fake CAPTCHA-ul revine sau reapar conturi de administrator necunoscute, presupune persistență și verifică imediat stratul de server.
• Dacă nu poți verifica în mod serios logurile, configurația și inventarul scripturilor externe, treci la ajutor administrat.
• Dacă încrederea vizitatorilor și traficul de business contează, nu paria pe încă un ciclu de cleanup făcut în grabă.

Concluzie

Un site WordPress compromis prin ClickFix nu este curat doar pentru că homepage-ul arată normal din nou. Este curat abia când CAPTCHA-ul fals injectat a dispărut, mecanismul care îl încarcă a fost eliminat, persistența nu mai există, paginile publice nu mai livrează lanțuri ostile de scripturi, iar mediul a fost întărit suficient încât să poți explica de ce același atac nu ar trebui să revină în zilele următoare.

Dacă nu vrei să pariezi pe siguranța vizitatorilor, pe reinfectare sau pe ghicit la nivel de server, contactează ServerSpan pentru ajutor hands-on cu cleanup WordPress, întărire la nivel de hosting și, dacă este cazul, migrare într-un mediu mai curat în care poți demonstra cu adevărat că site-ul este sigur. Începe cu pagina de contact și tratează problema ca pe un incident real, nu ca pe un defect cosmetic.