Když malware „krmí“ Googlebot: selektivní cloaking s ověřením IP přes ASN a CIDR ve WordPressu

V poslední době narážím na zajímavý posun v „SEO malwaru“: nejde o agresivní přesměrování, které si všimneš hned. Útočník raději potichu upraví vstupní bod webu (typicky index.php) a začne rozhodovat, komu ukáže jakou verzi stránky. Běžní uživatelé vidí čistý web. Vyhledávač ale dostane úplně jiný obsah – často spam nebo doorway stránky – které mají ovlivnit indexaci a reputaci domény.

Konkrétní incident popsaný Sucuri je zajímavý tím, že útočník neověřoval Googlebot jen podle User-Agent hlavičky (to jde snadno podvrhnout), ale navíc kontroloval, jestli IP adresa návštěvníka opravdu patří do IP rozsahů Googlu. A to velmi technicky: přes seznam ASN rozsahů v CIDR a bitové operace, včetně podpory IPv6.

Co bylo kompromitované: WordPress index.php jako „vrátný“

V popsaném případě byl injektovaný kód přímo v hlavním index.php WordPressu. To je pro útočníka ideální místo: jde o soubor, kterým projde většina požadavků, a zároveň může skript při „nezajímavém“ návštěvníkovi nenápadně předat řízení standardnímu bootstrappingu WordPressu.

Výsledek je klasický cloaking (maskování): Google vidí jiný obsah než člověk. Jenže realizace je mnohem selektivnější a hůř se odhaluje běžným ručním testováním.

Proč nestačí kontrola User-Agent a proč útočníci sahají po ASN

User-Agent je textový řetězec posílaný klientem (prohlížečem nebo crawlerem) v HTTP požadavku. Weby ho běžně používají pro analýzu, personalizaci nebo kompatibilitu. Z pohledu útočníka je to ale jen první filtr – a hlavně je triviálně spoofovatelný.

Proto v tomto incidentu následovalo druhé síto: ověření, že IP adresa opravdu patří do Google infrastruktury. V praxi to útočník řešil tak, že měl v kódu „zadrátovaný“ seznam IP rozsahů asociovaných s Google ASN (Autonomous System Number). ASN si můžeš představit jako internetovou identitu organizace: seskupuje IP adresy, které daný subjekt provozuje.

CIDR v kostce (a proč je pro malware praktický)

CIDR (Classless Inter-Domain Routing) je zápis rozsahu IP adres, typicky ve tvaru 192.168.1.0/24. Místo vyjmenování všech adres říká, jak velký blok to je. Pro útočníka je to ideální: stačí uložit několik desítek/stovek CIDR rozsahů a otestovat, jestli IP návštěvníka do některého spadá.

Co je na tomhle útoku „nové“: bitové ověřování rozsahu a IPv6

Spousta cloaking skriptů dělá primitivní kontrolu typu „obsahuje User-Agent řetězec Googlebot?“. Tady šel útočník dál: ověřoval IP adresu matematicky tak, aby přesně seděla do síťového bloku. Pro IPv4 používal bitové operace (AND s netmaskou) – tedy robustní test, který se běžně používá i v síťových nástrojích.

<?php
// Pseudokód / zjednodušené schéma logiky z incidentu:

$userAgent = $_SERVER['HTTP_USER_AGENT'] ?? '';
$ip        = $_SERVER['REMOTE_ADDR'] ?? '';

// 1) První filtr: User-Agent (snadno spoofovatelný)
$isGoogleUA = preg_match('~Googlebot|Google-InspectionTool|Google-Site-Verification~i', $userAgent);

// 2) Druhý filtr: IP musí spadat do Google ASN rozsahů v CIDR
// (v incidentu byl seznam rozsáhlý a zadrátovaný přímo v souboru)
$isGoogleIP = ip_in_cidr_ranges($ip, $googleCidrs);

if ($isGoogleUA && $isGoogleIP) {
    // 3) Pro ověřeného bota stáhnout vzdálený obsah a poslat ho jako „nativní“ HTML
    $payload = curl_fetch('hxxps://amp-samaresmanor[.]pages[.]dev');
    if ($payload) {
        echo $payload;
        exit;
    }

    // 4) Fail-safe: když payload selže, neukazovat botovi rozbitou stránku
    header('Location: /home/');
    exit;
}

// 5) Pro běžné uživatele: standardní WordPress
require_once __DIR__ . '/wp-blog-header.php';

<?php
// Pseudokód / zjednodušené schéma logiky z incidentu:

$userAgent = $_SERVER['HTTP_USER_AGENT'] ?? '';
$ip        = $_SERVER['REMOTE_ADDR'] ?? '';

// 1) První filtr: User-Agent (snadno spoofovatelný)
$isGoogleUA = preg_match('~Googlebot|Google-InspectionTool|Google-Site-Verification~i', $userAgent);

// 2) Druhý filtr: IP musí spadat do Google ASN rozsahů v CIDR
// (v incidentu byl seznam rozsáhlý a zadrátovaný přímo v souboru)
$isGoogleIP = ip_in_cidr_ranges($ip, $googleCidrs);

if ($isGoogleUA && $isGoogleIP) {
    // 3) Pro ověřeného bota stáhnout vzdálený obsah a poslat ho jako „nativní“ HTML
    $payload = curl_fetch('hxxps://amp-samaresmanor[.]pages[.]dev');
    if ($payload) {
        echo $payload;
        exit;
    }

    // 4) Fail-safe: když payload selže, neukazovat botovi rozbitou stránku
    header('Location: /home/');
    exit;
}

// 5) Pro běžné uživatele: standardní WordPress
require_once __DIR__ . '/wp-blog-header.php';

Klíčová část je kontrola „IP ∈ CIDR rozsah“. V analýze Sucuri je zmíněná logika ve stylu bitového porovnání (u IPv4) – v principu jde o to, že se IP adresa i síťová adresa „oříznou“ netmaskou a porovnají. Skript navíc počítal i s IPv6, což je detail, který starší malware často ignoruje, a tím je jednodušší odhalit.

Doručení payloadu: cURL a vzdálený obsah jako „nativní“ stránka

Po úspěšném ověření identity (Google User-Agent + IP v Google rozsazích) malware stáhl obsah z externího endpointu přes cURL a rovnou ho vypsal do response. Z pohledu crawleru to vypadá, jako by daný spam/doorway obsah hostoval přímo napadený web.

V incidentu se zmiňuje konkrétní doména amp-samaresmanor[.]pages[.]dev (ve zdrojích je uvedeno, že byla v době psaní blocklistovaná vybranými bezpečnostními vendor y). Důležité je, že tento typ kampaně může endpointy rotovat – takže samotné blokování jedné domény není systémové řešení.

Filtrace Google ekosystému: nejde jen o „Googlebot“

Další detail, který dává smysl: útočník necílil jen na řetězec „Googlebot“. Zahrnul i různé identifikátory související s kontrolními nástroji, verifikací webu nebo API crawlery. Cíl je jasný – zajistit, aby se podvržený obsah dostal do indexu a zároveň prošel interními kontrolami Googlu.

Rozhodovací logika a logování: útočník chce zpětnou vazbu

Tohle není „jednorázový“ skript. Podle popisu měl útočník i ošetření chyb a logování, aby viděl, kdy se podařilo servírovat payload, a kdy naopak někdo zkoušel podvrhnout Google User-Agent, ale neseděla IP.

• Legitimní bot (UA + IP sedí): zobrazí vzdálený obsah; pokud se nepodaří stáhnout, přesměruje na /home/, aby Google neviděl chybu.
• Fake bot (UA sedí, IP nesedí): zaloguje pokus a přesměruje na legitimní obsah, aby analýza byla těžší.
• Běžní uživatelé: typicky okamžitě uvidí standardní web (nebo jsou přesměrováni na „čistou“ landing page).

Proč se to dotýká hlavně SEO (a proč je to problém i pro vývojáře)

Dopad je primárně reputační a SEO: web začne vyhledávači servírovat něco, co s ním nesouvisí. Následky bývají tvrdé – od zhoršení výsledků vyhledávání až po blacklist nebo deindexaci. Zároveň platí, že takový útok se detekuje pozdě, protože majitel webu při ruční kontrole vidí „všechno v pořádku“.

Varovné signály: co zkontrolovat jako první

• Divné výsledky v Google (nečekané title/description, cizojazyčný spam, podivné landing pages).
• Nedávno změněné core soubory – hlavně index.php a další vstupní body.
• Podezřelé externí URL v kódu a v serverových logách (např. volání na neznámé domény).
• Neočekávané záznamy v logách (redirecty, cURL requesty, „fake bot“ hlášky apod.).

Jak to funguje ve vztahu k WordPress core souborům

Z pohledu WordPressu je zajímavé, jak útočník balancuje mezi škodlivou logikou a zachováním funkčnosti webu. V popsané variantě si malware pomáhal i standardními soubory:

• wp-load.php: jeho includování „nastartuje“ WordPress prostředí (konfigurace, DB připojení, constants), což útočníkovi otevírá dveře k dalším možnostem.
• wp-blog-header.php: typický závěr čistého index.php – pokud skript rozhodne, že nemá servírovat payload, předá řízení běžnému vykreslení webu.

Remediace a prevence: co má reálný efekt

U podobných kompromitací je důležité dělat úklid systematicky, ne jen „smazat jednu podezřelou věc“. Přímo ve zdroji jsou doporučené tyto kroky:

• Odstranit neznámé soubory/adresáře a vrátit změněné soubory do čistého stavu (ideálně z ověřeného zdroje / balíčku).
• Zkontrolovat uživatele ve WordPressu a odstranit podezřelé administrátory (typicky „pomocný“ účet vytvořený útočníkem).
• Resetovat přístupy: WordPress admin, FTP/SFTP, hosting panel, databáze.
• Zkontrolovat vlastní pracovní stanici (AV/malware scan) – kompromitace často začíná od ukradených přístupů.
• Udržovat aktualizace WordPressu, pluginů a šablon.
• Nasadit WAF (Web Application Firewall) – pomáhá blokovat komunikaci na známé škodlivé endpointy a často i prvotní upload zranitelného pluginu nebo webshellu.

Shrnutí: selektivní cloaking už není „jen UA string“

Tahle kampaň dobře ilustruje trend: útočníci přestávají dělat nápadné věci a raději z napadeného webu udělají řízenou bránu pro obsah určený vyhledávačům. Ověření Googlebotu přes ASN/CIDR a bitové operace (navíc s IPv6) výrazně snižuje šanci, že se problém projeví při běžné kontrole.

Pro vývojáře a správce WordPressu z toho plyne jednoduchá priorita: hlídat změny v core souborech (zejména index.php), mít přehled o tom, co se indexuje, a incident řešit jako kompromitaci celé instalace – ne jako izolovaný „divný redirect“.