Malver koji “propušta” samo Googlebot: IP-verificirano cloaking ubrizgavanje u WordPressu

U WordPress incidentima smo se navikli na očite signale: preusmjeravanja, pop-upove, sumnjive skripte u headeru. No napadači sve češće idu u suprotnom smjeru: umjesto da “zaprljaju” iskustvo posjetitelja, ciljaju tražilice i crawlers (automatizirane botove koji indeksiraju sadržaj). Rezultat je perfidan: ti i korisnici vidite ispravnu stranicu, a Google vidi spam ili potpuno drugi sadržaj.

U jednom nedavnom slučaju, injekcija je bila u glavnom WordPress index.php i ponašala se kao gatekeeper: odlučuje hoće li se učitati normalni WordPress ili će se, ali samo za Google infrastrukturu, povući udaljeni sadržaj s treće domene i “poslužiti” ga kao da je dio tvoje stranice.

Što je drugačije u ovoj varijanti cloakinga?

Cloaking (serviranje različitog sadržaja tražilici i ljudima) nije nov, ali ovdje je zanimljiv nivo verifikacije identiteta posjetitelja. Mnogi skripteri se za detekciju bota oslanjaju samo na User-Agent header. Problem: User-Agent je trivijalno lažirati.

Ovaj malver ide korak dalje: uz User-Agent provjerava i je li IP adresa zaista iz Googleove mreže. Konkretno, ima ugrađenu (hardcodanu) listu Google ASN (Autonomous System Number) IP raspona u CIDR formatu, te provodi matematičku provjeru pripadnosti IP-a rasponu. Uz to, uključuje i podršku za IPv6, što stariji cloaking kod često zanemaruje.

ASN i CIDR u dvije rečenice (kontekst za developere)

ASN možeš gledati kao “internet identitet” velikog sustava (npr. Google) – skup mreža i IP adresa koje pripadaju toj organizaciji. CIDR je zapis poput 192.168.1.0/24 koji opisuje blok IP adresa (raspon) kompaktnije od nabrajanja svake IP adrese.

Kako izgleda napad u praksi (zašto ga je teško uočiti)

Najveća vrijednost ovakvog napada napadaču je nevidljivost. Ako ručno otvoriš web u browseru, najčešće ćeš vidjeti uredan, “čist” site. Čak i ako si svjestan da trebaš provjeriti Googlebot, samo promjena User-Agenta neće pomoći jer IP neće proći provjeru.

U Sucurijevom primjeru, razlika je bila jasna tek kad se usporedi ono što se prikazuje u indeksu/previewu tražilice i ono što vidi čovjek. Google je dobivao spam/payload sadržaj, dok su posjetitelji ostajali na legitimnom sadržaju.

Anatomija malvera: pet ključnih koraka

1) Višeslojna provjera identiteta

Prva linija je provjera HTTP_USER_AGENT stringa za Googleove crawlere i prateće alate (npr. razni verifikacijski/inspection agenti). To omogućava da napadačev sadržaj bude indeksiran i verificiran u više Google servisa, ali se ne oslanja samo na to.

2) Bitwise validacija IP raspona (umjesto jednostavnog matchanja)

Umjesto da radi string usporedbu ili površno provjerava prefiks, skripta radi bitwise (bitovne) operacije kako bi matematički utvrdila pripada li IP točno određenom CIDR rasponu. Za IPv4 logika se tipično svodi na maskiranje IP-a i usporedbu s maskiranim rasponom.

// Pojednostavljeni primjer ideje (konceptualno)
// Provjera pripada li IP određenom CIDR bloku preko netmask-a
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

// Pojednostavljeni primjer ideje (konceptualno)
// Provjera pripada li IP određenom CIDR bloku preko netmask-a
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

3) Dohvat udaljenog payloada preko cURL-a

Kad “prođe” identitet (Googleov User-Agent + IP iz Google ASN raspona), malver radi cURL request prema vanjskoj domeni i sadržaj direktno ispisuje u response. Time crawler dobiva dojam da je sadržaj hostan na kompromitiranoj domeni.

U analiziranom slučaju, spominje se udaljena domena amp-samaresmanor[.]pages[.]dev (u izvornom zapisu namjerno obfuscan s uglatim zagradama).

// Konceptualno: nakon verifikacije bota, povuci HTML s udaljenog hosta
// i echo-aj ga u response (crawleri će ga indeksirati)
// hxxps://amp-samaresmanor[.]pages[.]dev

// Konceptualno: nakon verifikacije bota, povuci HTML s udaljenog hosta
// i echo-aj ga u response (crawleri će ga indeksirati)
// hxxps://amp-samaresmanor[.]pages[.]dev

4) Šire filtriranje User-Agent stringova

Script ne traži samo “Googlebot”. Uključeni su i stringovi za razne Googleove servise povezane s validacijom, inspekcijom i API crawlingom. To povećava šansu da se zlonamjerni sadržaj pojavi u indeksu i prođe Googleove procese provjere.

5) Uvjetna logika, fallback ponašanje i logiranje grešaka

Ovo je dio koji napad čini “urednim” iz perspektive napadača. Ako je bot legitiman, dobiva udaljeni sadržaj i uspjeh se logira. Ako dohvat payloada zakaže, bot se preusmjerava na /home/ kako Google ne bi vidio broken page.

Ako netko lažira User-Agent (fake Googlebot), ali IP ne prođe verifikaciju, skripta može zapisati poruku tipa “Fake GoogleBot detected” i poslati korisnika na normalnu početnu stranicu. Za sve ostale posjetitelje ponašanje je isto: brzo ih vodi na legitimni sadržaj.

Zašto se napad često “parkira” baš u core datotekama

U ovom incidentu kompromitiran je index.php na razini roota WordPress instalacije. To je pametan izbor: index.php je ulazna točka i napadač dobiva potpunu kontrolu nad time što će se servirati prije nego WordPress uopće normalno krene.

Skripta može i dalje “bootstrappati” WordPress kada joj to odgovara. Primjer iz analize spominje require_once __DIR__ . '/wp-load.php' kako bi se inicijalizirao WordPress runtime (konfiguracija, DB pristup). U čistom WordPressu, standardni index.php završava s uključivanjem wp-blog-header.php – napadači to često ostave ili uvjetno izvršavaju kako bi site radio normalno za ljude.

Posljedice: više SEO incident nego “klasični malware” (ali jednako ozbiljan)

Primarni cilj ovdje nije krađa podataka posjetitelja, nego kompromitacija reputacije domene i manipulacija indeksom. Tipične posljedice su:

• deindeksiranje ili rušenje pozicija zbog spam sadržaja
• blacklisting (tražilice ili sigurnosni alati)
• “resource hijacking” – tvoja domena postaje kanal za tuđi sadržaj
• odgođena detekcija jer vlasnik ne vidi problem u browseru

Signali koji upućuju na ovakav tip kompromitacije

Kod crawler-interception napada, najbolji tragovi su često izvan samog frontenda:

• neočekivani ili loši rezultati u Google Searchu (naslovi/opisi/URL-ovi koji nisu tvoji)
• nedavno mijenjane core datoteke (posebno index.php) bez jasnog razloga
• sumnjivi vanjski URL-ovi/domene u kodu ili logovima
• neobični zapisi u access/error logovima (redirecti, pokušaji dohvaćanja vanjskog sadržaja)

Sanacija i prevencija (praktični check-list za WordPress tim)

Ako sumnjaš na ovakav napad, prioritet je vratiti integritet aplikacije i zatvoriti vektor upada. Fokusiraj se na ove korake:

1. Ukloni nepoznate datoteke i direktorije: sve što nije dio WordPress corea, teme ili provjerenih pluginova.
2. Provjeri i očisti index.php i ostale core datoteke: svaka neautorizirana promjena je crvena zastavica.
3. Audit korisnika: ukloni sumnjive admin račune i “help” račune koji se ne koriste.
4. Resetiraj kredencijale: WordPress admin lozinke, FTP/SFTP, hosting panel, baze podataka.
5. Skeniraj lokalno računalo: kompromitiran dev stroj često je skriveni uzrok ponovne infekcije.
6. Update svega: WordPress core, teme, pluginovi – posebno ako su ranije bili zapušteni.
7. Uvedi WAF (Web Application Firewall): sloj koji može blokirati komunikaciju s poznatim zlonamjernim endpointima i spriječiti inicijalni upload/eksploit.

Što ponijeti iz ovog slučaja

Ova kampanja je dobar podsjetnik da moderno WordPress zlonamjerno ponašanje često nije “glasno”. Napadač može pretvoriti legitimnu stranicu u kontrolirani gateway koji servira drugi sadržaj isključivo tražilicama, dok vlasnik mjesecima vidi sve normalno.

U praksi, to znači da uz klasične sigurnosne mjere (update, najmanje privilegije, hardening) vrijedi imati i kontrolu integriteta datoteka (File Integrity Monitoring) te redovito pratiti Google Search Console za neočekivane URL-ove u indeksu. Core datoteke poput index.php su posebno osjetljive jer jedna mala injekcija može promijeniti cijeli tok requesta.