Când Googlebot vede altceva decât utilizatorii: cloaking malware cu verificare IP pe ASN (WordPress)

În ultimii ani, multe infecții WordPress au mers pe varianta „zgomotoasă”: redirecturi evidente, pop-up-uri dubioase, pagini care se rup în fața utilizatorilor. Tot mai des însă apare o altă direcție: atacuri selective, care îți lasă site-ul să pară perfect normal pentru tine și vizitatori, dar livrează alt conținut către motoarele de căutare.

Un caz analizat de Sucuri arată o versiune mai avansată de cloaking (tehnică SEO în care crawlerul vede altceva decât omul): cod injectat în index.php care „interceptează” Googlebot și îi servește un payload dintr-un domeniu extern, dar doar după ce confirmă că IP-ul chiar aparține infrastructurii Google.

Ce a fost compromis: index.php ca „gatekeeper” pentru trafic

În loc să lase WordPress să booteze normal, index.php a fost modificat astfel încât să decidă ce răspuns primește vizitatorul. Practic, fișierul devine un filtru la intrare:

• dacă vizitatorul pare a fi Google (nu doar prin User-Agent, ci și prin IP), primește conținut injectat dintr-o sursă remote;
• dacă nu, site-ul se comportă normal și încarcă WordPress ca de obicei.

Din perspectiva proprietarului, problema poate trece complet neobservată: navighezi site-ul, totul arată bine. În schimb, în indexarea Google apar pagini/fragmente care nu există în mod real pe site.

De ce e diferit față de cloaking-ul „clasic”

Majoritatea scripturilor de cloaking se bazează pe verificări simpliste pe headerul HTTP_USER_AGENT (de exemplu, dacă include „Googlebot”). Asta e ușor de păcălit: îți schimbi User-Agent-ul și reproduci comportamentul.

În cazul acesta, partea interesantă e că malware-ul include o listă hardcodata de intervale IP asociate ASN-urilor Google (Autonomous System Number), în format CIDR, și validează matematic apartenența IP-ului la acel range. Cu alte cuvinte, nu îi ajunge să „spui” că ești Googlebot — vrea să vadă că vii din rețeaua Google.

ASN pe scurt

ASN (Autonomous System Number) este, practic, identitatea unei rețele pe internet — un set de IP-uri controlate de o organizație (aici, Google) și folosite de serviciile ei. Dacă un request vine dintr-un ASN de Google, probabilitatea să fie crawlerul real (sau infrastructură Google legitimă) crește drastic.

CIDR pe scurt

CIDR este notația compactă pentru un bloc de IP-uri, de tipul 192.168.1.0/24. Sufixul /24 descrie masca de rețea și mărimea blocului, evitând listarea fiecărui IP individual.

Cum funcționează atacul, pe etape

Scriptul din index.php combină mai multe straturi de verificare și, abia la final, decide dacă servește conținutul malițios sau încarcă site-ul curat.

1) Verificare multi-layer: User-Agent + IP

Mai întâi, se verifică HTTP_USER_AGENT pentru mai multe string-uri asociate ecosistemului Google (nu doar „Googlebot”, ci și unelte de verificare/inspecție și crawleri API). Pentru că User-Agent-ul poate fi spoof-uit ușor, pasul al doilea este validarea IP-ului în intervalele Google.

2) Validare IP cu operații bitwise (IPv4/IPv6)

În loc de simple comparații de string, codul face calcule bitwise pentru a determina dacă IP-ul se încadrează exact într-un bloc CIDR. Pentru IPv4, logica centrală arată așa:

// Ideea: dacă (IP & netmask) == (range & netmask), IP-ul aparține blocului
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

// Ideea: dacă (IP & netmask) == (range & netmask), IP-ul aparține blocului
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

Detaliul care ridică ștacheta aici este suportul robust pentru IPv6, pe care multe scripturi mai vechi îl ignoră. Asta reduce mult șansele să „prinzi” infecția prin testare manuală, pentru că atacatorul poate restrânge livrarea payload-ului la infrastructura reală Google.

3) Payload remote livrat prin cURL

După ce vizitatorul este confirmat ca fiind „Google legitim”, scriptul cere conținut extern prin cURL și îl afișează direct în răspunsul paginii. Domeniul menționat în analiză este:

hxxps://amp-samaresmanor[.]pages[.]dev

hxxps://amp-samaresmanor[.]pages[.]dev

Ideea e simplă și eficientă: Google crede că pagina site-ului tău găzduiește acel conținut (pentru că îl vede în HTML-ul final), deși el este de fapt injectat la runtime din altă parte.

4) Filtrare extinsă pe User-Agent (nu doar Googlebot)

Un alt semn că scriptul a fost gândit pentru rezultate SEO: lista de User-Agent-uri acoperă inclusiv instrumente de verificare și indexare, astfel încât atacatorul să obțină conținutul malițios înregistrat și validat în cât mai multe fluxuri Google.

5) Logică condițională + logging de erori

Scriptul are și mecanisme de decizie cu fallback și logging, ca să reducă riscul de pagini „stricate” pentru crawler. Conform descrierii:

• dacă User-Agent-ul și IP-ul sunt valide: servește payload-ul remote și loghează succesul; dacă payload-ul nu se poate încărca, redirecționează botul către /home/ ca să nu expună o pagină goală;
• dacă User-Agent-ul arată a Google, dar IP-ul nu se potrivește: loghează „Fake GoogleBot detected” și redirecționează către pagina legitimă;
• pentru utilizatori obișnuiți: redirecționează direct către home/pagina normală.

De ce sunt atinse fișierele core WordPress (și de ce e grav)

Un motiv pentru care astfel de infecții sunt greu de detectat: atacatorul păstrează funcționalitatea normală a site-ului, „bootstrappând” WordPress doar când are nevoie. În analiza Sucuri apar explicit două fișiere:

• wp-load.php – încărcat prin require_once __DIR__ . '/wp-load.php' pentru a inițializa mediul WordPress (config, DB, etc.);
• wp-blog-header.php – parte din fluxul normal al index.php standard, inclus la final în mod obișnuit.

Când un fișier core precum index.php este modificat, efectul se propagă imediat: orice request intră prin acel „punct de control”. Din acest motiv, monitorizarea integrității fișierelor (file integrity monitoring) devine o măsură critică, nu un nice-to-have.

Impactul real: SEO, reputație și timp mare până la detecție

Scopul principal aici nu este neapărat furtul de date, ci compromiterea indexării și a reputației în căutare. Pentru că Google vede conținut diferit față de utilizatori, consecințele tipice includ:

• blacklisting sau semnale de spam/malware în search;
• deindexare sau scăderi bruște de vizibilitate;
• „resource hijacking” (site-ul tău devine vehicul pentru conținutul altcuiva);
• detecție întârziată, pentru că proprietarul nu vede nimic suspect în browsing normal.

Semne că ai putea avea o infecție de tip „crawler interception”

În practică, indicatorii sunt mai degrabă indirecți. Dacă suspectezi o compromitere de tipul acesta, merită verificat:

• rezultate dubioase în Google (titluri/descrieri care nu corespund, pagini noi pe care nu le-ai creat);
• fișiere modificate recent, în special în rădăcina site-ului (ex. index.php);
• URL-uri suspecte în cod sau în loguri;
• loguri neobișnuite (requesturi către domenii externe, redirecturi condiționale, erori care apar doar pentru anumite User-Agent-uri).

Remediere: ce are sens să faci imediat

În astfel de cazuri, „șterg doar un snippet” rar e suficient. Abordarea corectă e să tratezi incidentul ca o compromitere completă:

1. Elimină fișiere și directoare necunoscute sau care nu aparțin deployment-ului tău. Atenție specială la fișiere core modificate (ex. index.php).
2. Auditează utilizatorii WordPress: elimină conturi de ajutor („help account”) sau admini suspecți.
3. Resetează credențiale: admin WordPress, FTP/SFTP, hosting panel, DB. (Dacă rămâne o parolă expusă, reinfectarea e foarte probabilă.)
4. Rulează scanare antivirus/malware pe stația ta de lucru. Un laptop compromis poate reintroduce fișiere modificate prin FTP sau tokenuri salvate.
5. Actualizează tot: WordPress core, pluginuri, teme. (Plus eliminarea componentelor abandonate.)
6. Pune un WAF (Web Application Firewall) în față. Un WAF bun poate bloca comunicarea cu infrastructură malițioasă (C2) și poate reduce șansele de upload inițial sau exploatare repetată.

Prevenție pragmatică pentru site-uri WordPress

Două măsuri ies în evidență în contextul acestui tip de atac:

• File Integrity Monitoring pentru fișiere core (în special index.php) – vrei să afli imediat când ceva s-a schimbat, nu după săptămâni, când SEO-ul deja a fost afectat.
• Audit regulat în Google Search Console – verifică pagini neașteptate, creșteri anormale în numărul de URL-uri indexate, query-uri spam, sitemap-uri ciudate.

Linia de fund: malware-ul modern nu mai are nevoie să fie vizibil ca să producă pagube. Dacă atacatorul poate abuza încrederea motorului de căutare fără să te alerteze prin simptome evidente, detectarea devine o problemă de procese (monitorizare, audit, controlul schimbărilor), nu doar de „noroc” sau browsing manual.