Cielený SEO cloaking vo WordPress: keď sa škodlivý kód ukáže len Googlebotu (a ešte si overí IP)

V poslednom období sa pri kompromitovaných WordPress weboch čoraz častejšie stretávam s trendom, ktorý je pre majiteľa aj vývojára frustrujúci: stránka sa „správa normálne“ pri bežnom prehliadaní, ale vyhľadávače (najmä Google) vidia injektovaný spam alebo úplne iný obsah. Útočníci sa posúvajú od jednoduchých redirectov k selektívnemu doručovaniu payloadu – tak, aby bol útok čo najmenej viditeľný pre človeka.

Zaujímavý detail z nedávno analyzovaného prípadu: škodlivý kód v hlavnom index.php nefiltruje Googlebot len cez HTTP_USER_AGENT, ale robí si aj overenie IP adresy proti rozsiahlej, natvrdo zakódovanej knižnici IP rozsahov patriacich Googlu (ASN rozsahy v CIDR formáte). Výsledok je cloaking, ktorý sa veľmi ťažko replikuje manuálne a často unikne aj základným kontrolám.

Čo sa v praxi deje: kompromitovaný index.php ako „vrátnik“

V klasickom WordPress flow je index.php štartovací bod, ktorý na konci typicky includuje wp-blog-header.php a tým spustí celý WordPress. V tomto incidente bol index.php upravený tak, že sa najprv rozhodne, kto prišiel:

• bežný návštevník → uvidí čistý obsah (alebo je presmerovaný na legitímnu homepage)
• Googlebot a príbuzné Google nástroje → dostanú úplne iný obsah stiahnutý z externého zdroja
• „fake“ Googlebot (spoofnutý User-Agent) → kód ho odhalí cez IP kontrolu a správa sa ako pri bežnom návštevníkovi (často aj s logovaním tejto situácie)

Prečo je IP overenie zásadný rozdiel oproti starému cloakingu

Mnohé staršie cloaking skripty sa spoliehali na jednoduchú podmienku typu „ak User-Agent obsahuje Googlebot, ukáž spam“. To sa dá ľahko otestovať aj bez kompromitácie: stačí zmeniť User-Agent v DevTools alebo cez curl -A a vidíš, čo vidí bot.

V tomto prípade je to robustnejšie: škodlivý kód si k User-Agent filtru pridáva kontrolu, či request naozaj prichádza z infraštruktúry Googlu. Na to používa ASN (Autonomous System Number) rozsahy – zjednodušene „internetovú identitu“ organizácie, ktorá zastrešuje jej IP bloky. Ak IP adresa requestu patrí do Google ASN, skript to vyhodnotí ako legitímneho bota.

CIDR v skratke (prečo to útočníci radi používajú)

IP rozsahy sú uložené v CIDR tvare (napr. 192.168.1.0/24). CIDR je kompaktný zápis bloku adries – namiesto vypisovania tisícok IP len povieš sieť a veľkosť bloku. Útočník tak môže mať v kóde knižnicu rozsahov, ktorú vie rýchlo prechádzať.

Ako skript overuje IP: bitové operácie namiesto porovnávania reťazcov

Ďalší detail, ktorý stojí za pozornosť: namiesto jednoduchých „startsWith“/regex kontrol robí overenie matematikou cez bitové operácie. Pri IPv4 ide o klasickú kontrolu, či IP spadá do siete podľa masky (netmask):

// princíp, ktorý sa v podobných skriptoch používa
// (ip & mask) == (range & mask)
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

// princíp, ktorý sa v podobných skriptoch používa
// (ip & mask) == (range & mask)
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

Z pohľadu obrany to znamená, že skript sa správa presnejšie a menej sa dá „obabrať“ náhodným IP rozsahom alebo jednoduchým spoofingom. Navyše v analyzovanom prípade bola implementácia pripravená aj na IPv6, čo staršie cloakingy často ignorovali.

Doručenie payloadu: remote obsah cez cURL a „native“ výstup

Keď návšteva prejde filtrami (User-Agent aj IP), kód stiahne obsah z externého webu a priamo ho vypíše do odpovede. V popísanom incidente šlo o doménu:

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

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

Dôležité je, že výsledok vyzerá pre crawler ako normálny obsah hostovaný na tvojej doméne. Google ho môže zaindexovať, priradiť mu reputáciu a následne penalizovať tvoj web – aj keď reálne ten spam fyzicky „nebýva“ v databáze WordPressu.

Rozšírené filtrovanie User-Agentov: nejde len o „Googlebot“

Útočníci v tomto type kampaní často necielia iba na klasický Googlebot. Filtre bývajú rozšírené aj o reťazce súvisiace s verifikačnými a kontrolnými nástrojmi Googlu (napr. inspection/validation a API crawlery), aby sa injektovaný obsah dostal cez rôzne kontrolné mechanizmy a bol „dôveryhodne“ spracovaný naprieč službami.

Pre kontext: HTTP User-Agent je hlavička, ktorú klient posiela pri každom requeste a identifikuje typ prehliadača alebo bota. Je jednoduché ju spoofnuť – práve preto dáva zmysel, že malvér pridáva aj IP validáciu.

Podmienky, presmerovania a logovanie: útok chce byť stabilný

Zaujímavým prvkom bola aj „prevádzková hygienа“ škodlivého kódu: rozhodovacia logika, presmerovania na bezpečné URL a dokonca aj error handling/logovanie. Cieľ je jasný – aby Google nevidel broken page a aby útočník mal prehľad, či sa payload načítal.

• Ak je bot legitímny: načíta remote obsah; pri zlyhaní načítania môže nasledovať presmerovanie (napr. na /home/), aby crawler nevidel chybu.
• Ak je User-Agent spoofnutý, ale IP nesedí: skript situáciu vyhodnotí ako „fake bot“ a zvyčajne presmeruje na legitímnu stránku.
• Bežní používatelia: dostanú štandardný obsah alebo okamžité presmerovanie na homepage.

Prečo útočník siaha po WordPress core súboroch (wp-load.php, wp-blog-header.php)

Aj keď je úprava v index.php, skript nechce „zabiť“ web. Naopak, potrebuje, aby všetko pre ľudí fungovalo normálne. Preto často využije core súbory:

• wp-load.php – jeho includom (require_once __DIR__ . '/wp-load.php';) sa nabootuje WordPress prostredie, konfigurácia a prístup k DB. Malvér tak môže používať nastavenia webu a zároveň sa tváriť ako súčasť aplikácie.
• wp-blog-header.php – typicky sa includuje na konci legitímneho index.php, aby WordPress vyrenderoval stránku. Útočník si ponechá tento „fallback“, keď podmienky na cloaking nesedia.

Typické symptómy: kedy sa oplatí spozornieť

Pri takomto type infekcie často nefunguje princíp „však otvorím web v incognite a uvidím“. Indície bývajú skôr nepriamo viditeľné:

• Zvláštne alebo zhoršené výsledky vo vyhľadávaní (nečakané title/snippety, spammy stránky, pokles indexácie).
• Neočakávane zmenené súbory v root-e (najmä index.php).
• Podozrivé externé URL/domény v kóde alebo v logoch.
• Neštandardné záznamy v access/error logoch (presmerovania, cURL requesty, opakované pokusy „tváriť sa ako Googlebot“).

V analyzovanom prípade bol škodlivý endpoint amp-samaresmanor[.]pages[.]dev evidovaný na VirusTotal (v čase analýzy ho blocklistovali 2 vendori) a podľa verejného vyhľadávania sa tento reťazec nachádzal na viacerých infikovaných weboch.

Rýchly postup nápravy a prevencie (prakticky pre WP vývojára)

1. Skontroluj integritu core súborov: začni index.php a súbormi v root-e. Pri podozrení porovnaj s čistou distribúciou WordPressu (rovnaká verzia) a odstráň neznáme bloky kódu.
2. Vyhoď neznáme súbory a adresáre: čokoľvek, čo tam nepribudlo z deploy procesu alebo oficiálnych pluginov/tém.
3. Audit používateľov: odstráň podozrivých adminov a „help“ účty, ktoré tam nemajú čo robiť.
4. Reset prihlasovacích údajov: WP admin, FTP/SFTP, hosting panel, databáza. Ak útočník získal prístup raz, často sa vracia cez rovnaké poverenia.
5. Skenuj aj vlastný počítač: kompromitované zariadenie vývojára/administrátora je častý zdroj opakovaných infekcií (ukradnuté heslá, session, SSH kľúče).
6. Aktualizuj všetko: WordPress core, pluginy, témy. Zanedbané aktualizácie sú stále najčastejšia vstupná brána.
7. Nasadiť WAF (Web Application Firewall): WAF vie blokovať komunikáciu na známe škodlivé hosty a znížiť šancu, že sa malvér na web vôbec dostane alebo že bude úspešne volať C2/payload endpointy.
8. Zaveď File Integrity Monitoring: monitorovanie zmien súborov (najmä core) je pri týchto tichých infekciách často najrýchlejší alarm.
9. Pravidelne kontroluj Google Search Console: podozrivé URL v indexe sú často prvý signál, že web servíruje crawlerom niečo iné.

Zhrnutie: tichý útok, ktorý zneužíva dôveru vyhľadávačov

Tento typ infekcie je ukážkou posunu od „hlasných“ kompromitácií k selektívnym technikám, ktoré cielia na SEO a reputáciu webu. Kľúčová obrana je kombinácia: kontrola integrity súborov, audit prístupov, aktualizácie a ochranná vrstva typu WAF. Ak riešiš nevysvetliteľné SEO problémy a pritom na webe „nič nevidíš“, kontrola index.php a root súborov by mala byť medzi prvými krokmi.