---
title: "Когато Googlebot вижда друго: WordPress malware с IP-верифицирано „cloaking“ през ASN и CIDR"
url: "https://helloblog.io/bg/wordpress-malware-googlebot-ip-verifikaciya-asn-cidr-cloaking/"
date: "2026-01-13"
modified: "2026-01-20"
author: "Георги Петров"
language: "bg_BG"
categories: ["Сигурност"]
tags: ["cloaking", "Googlebot", "malware", "SEO", "WordPress"]
featured_image: "https://helloblog.io/app/uploads/sites/21/2026/01/featured-3-1024x572.jpg"
excerpt: "Атакуващите все по-рядко разчитат на груби пренасочвания. Вместо това инжектират код, който показва спам само на реалния Googlebot (проверен по IP), а на хората – напълно нормален сайт."
---

# Когато Googlebot вижда друго: WordPress malware с IP-верифицирано „cloaking“ през ASN и CIDR

Един от най-неприятните сценарии при компрометиран WordPress сайт е, когато собственикът (и екипът) отварят началната страница и всичко изглежда наред, но в Google резултатите излизат спам страници, странни заглавия и описания или дори деиндексиране. В последните кампании се вижда еволюция: вместо „шумни“ редиректи, злонамереният код започва да обслужва payload селективно – основно към търсачки и техните краулъри, и то по начин, който е труден за репродуциране при ръчен тест.

Конкретният случай, който ще разгледам, е от разследване на Sucuri: модифициран `index.php` в WordPress, който играе ролята на gatekeeper. Ако „посетителят“ е реален Googlebot, сайтът връща външно съдържание (включително spam/SEO payload). Ако е нормален потребител – WordPress се зарежда стандартно и всичко изглежда чисто.

## Какво прави атаката различна от класическото cloaking

SEO cloaking (показване на различно съдържание на търсачки и на хора) не е новост. Новото тук е нивото на верификация. Много стари скриптове се доверяват само на `User-Agent` (например съдържа „Googlebot“). Това се фалшифицира елементарно.

В разглеждания malware има хардкодната „библиотека“ от IP диапазони на Google, описани през ASN и CIDR, и валидиране с битови операции (bitwise). Така атакуващият не просто проверява текстов стринг, а математически потвърждава дали IP адресът на заявката попада в очакван мрежов блок. Плюс: има и поддръжка за IPv6 – нещо, което доста „масови“ cloaking имплементации игнорират.

![Схема на IP-верифицирана условна логика за селективно показване на съдържание](https://helloblog.io/app/uploads/sites/21/2026/01/IP-Verified-Conditional-Logic.png)

*При реални ботове се връща външен payload; при нормални посетители – легитимният сайт. — *Forrás: Sucuri Blog**

## Бързи дефиниции: ASN, CIDR и защо ги използват атакуващите

**ASN (Autonomous System Number)** е идентификатор на автономна система – най-практичното обяснение за нас е „официалната интернет идентичност“ на голяма инфраструктура (в случая Google). Тя обхваща набор от IP адреси, използвани от услуги като Search, Gmail, Google Cloud и реалните краулъри.

**CIDR (Classless Inter-Domain Routing)** е формат за описване на IP диапазон като мрежов блок, напр. `192.168.1.0/24`. Суфиксът `/24` определя размера на блока (маската) и позволява проверка „дали IP-то е в този диапазон“ без да се изброяват всички адреси.

![Пример за CIDR формат и как описва IP блок](https://helloblog.io/app/uploads/sites/21/2026/01/CIDR-format.png)

*CIDR дава компактно описание на мрежов диапазон. — *Forrás: Sucuri Blog**

## Как работи инфекцията: gatekeeper в index.php

Откритият код е в основния `index.php` на WordPress – място, което по принцип очакваме да е стабилно и рядко пипано. Вместо винаги да boot-ва WordPress, файлът първо прави серия проверки кой е посетителят и едва после решава какво да върне.

![Многостепенна проверка на идентичност: User-Agent и IP верификация](https://helloblog.io/app/uploads/sites/21/2026/01/Multi-Layer-Identity-Verification.png)

*User-Agent филтър + IP проверка правят откриването значително по-трудно. — *Forrás: Sucuri Blog**

### 1) Многостепенна верификация: User-Agent + реален IP диапазон

Логиката започва с проверка на **HTTP User-Agent** (текстовият идентификатор, който браузърът/ботът изпраща при всяка заявка и който обикновено описва клиент, устройство, ОС). Това е първи филтър. След това идва същинската защита срещу spoofing: сравнение на IP адреса спрямо списък от мрежови блокове на Google (в CIDR), за да се потвърди, че заявката идва от реалната инфраструктура, а не от някой, който просто се представя за Googlebot.

![Филтриране по User-Agent за Googlebot и свързани инструменти](https://helloblog.io/app/uploads/sites/21/2026/01/User-Agent-Filtering.png)

*Скриптът търси не само „Googlebot“, а и други Google User-Agent варианти за инспекция/верификация. — *Forrás: Sucuri Blog**

### 2) Bitwise валидиране на IP диапазон (CIDR match)

Ключовият момент е, че проверката не е „дали IP-то започва с…“, а реален мрежов match чрез маска (netmask). За IPv4 примерната формула е от типа:

```
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal)
// Ако двете страни съвпадат, IP адресът попада в CIDR блока.
```

![Илюстрация на bitwise проверка за съвпадение на IP с CIDR блок](https://helloblog.io/app/uploads/sites/21/2026/01/Bitwise-IP-Range-Validation.png)

*Математическа проверка вместо string matching. — *Forrás: Sucuri Blog**

### 3) Зареждане на външен payload през cURL

След като „посетителят“ бъде потвърден като легитимен Google bot, скриптът извлича remote съдържание през cURL от външен домейн и го отпечатва директно в отговора. Така за търсачката изглежда, че съдържанието е част от сайта, а реално се хоства и контролира отвън.

#### Индикатор за компрометиране

В случая е използван домейнът `amp-samaresmanor[.]pages[.]dev` като източник на remote payload (описан в разследването на Sucuri).

![Схема на извличане на външен payload през cURL и отпечатване в страницата](https://helloblog.io/app/uploads/sites/21/2026/01/Remote-Payload-Execution-via-cURL.png)

*Това е типичен pattern за SEO spam инжекции, но селективно насочен към ботове. — *Forrás: Sucuri Blog**

### 4) Условна логика + логване на грешки (за да се „самокоригира“)

Този тип malware често има „операторска“ логика: ако проверките минат, сервира payload и логва успех; ако payload не може да се зареди, вместо да остави търсачката да види счупена страница, прави fallback (например редирект към `/home/`). Ако някой се опитва да се представи за Googlebot само с User-Agent, но IP проверката се провали, се логва нещо от сорта на „Fake GoogleBot detected“ и заявката се праща към нормалната начална страница. За всички останали посетители – показва се легитимният сайт.

![Диаграма на условната логика: легитимен бот, фалшив бот и нормален посетител](https://helloblog.io/app/uploads/sites/21/2026/01/Conditional-Logic-and-Error-Logging.png)

*Идеята е да остане невидим за собственика, но максимално ефективен за индексиране. — *Forrás: Sucuri Blog**

## Защо точно index.php и как се „вписва“ в WordPress

Причината атакуващите да харесват core entrypoint като `index.php` е проста: това е точка, през която минава почти целият трафик. В описания случай кодът използва WordPress файлове, за да не „счупи“ сайта и да може да зарежда нормално, когато реши.

- `wp-load.php` – включва се, за да boot-не WordPress средата и да даде достъп до конфигурация и база (типичен pattern е `require_once __DIR__ . '/wp-load.php'`).
- `wp-blog-header.php` – стандартно се изисква в края на легитимния WordPress `index.php`, така че при „нормален“ режим посетителите да получат чистата страница.

## Какъв е ефектът: SEO удар, репутационен риск и забавено откриване

Този клас инфекции са фокусирани върху SEO и доверие. Тъй като Google индексира друго съдържание от това, което виждат хората и екипът, последствията често са неприятни и неочаквани:

- деиндексиране или понижаване на позиции поради спам/манипулативно съдържание;
- blacklisting и предупреждения в търсачки/браузъри;
- „resource hijacking“ – сайтът става канал за чуждо съдържание, контролирано отвън;
- забавено откриване, защото ръчните проверки показват нормален сайт.

![Пример какво вижда Google спрямо нормалните посетители при cloaking атака](https://helloblog.io/app/uploads/sites/21/2026/01/What-Google-sees.png)

*Типичен симптом: SERP изглежда „отровен“, а сайтът визуално е нормален. — *Forrás: Sucuri Blog**

## Сигнали, че нещо не е наред (дори когато сайтът изглежда „чист“)

- Подозрителни резултати в Google (непознати заглавия/описания, спам страници, странни sitelinks).
- Неочаквано модифицирани файлове – особено в root (`index.php`) и в `wp-includes/`, `wp-admin/`.
- Съмнителни външни URL-и в код/логове, които не са част от проекта.
- Странни логове и редиректи, които се проявяват само при конкретни User-Agent-и.

## Практични стъпки за реакция и превенция

При подобни инфекции целта е двойна: (1) да премахнеш инжекцията и всички точки за повторно заразяване; (2) да намалиш шанса да се случи пак. От препоръките в разследването изпъкват няколко задължителни хигиенни действия:

1. Премахни непознати файлове и директории: всичко, което не е част от темата/плъгините/ядрото и не можеш да обясниш откъде е дошло.
2. Одит на потребители: премахни „help“ акаунти и всякакви подозрителни администратори.
3. Ресет на креденшъли: WordPress админи, FTP/SFTP, хостинг панел, база данни (и по възможност ключове/соли в `wp-config.php` според вътрешната ви практика).
4. Сканирай локалната машина: ако dev машината е компрометирана, чистенето на сървъра няма да е достатъчно.
5. Обновявай всичко: core, плъгини, теми – особено ако има изоставени компоненти.
6. Ползвай WAF (Web Application Firewall): може да блокира комуникация към известни злонамерени крайни точки и да спре част от първоначалните опити за качване на malware.

#### Какво да наблюдаваш дългосрочно

File Integrity Monitoring (мониторинг на целостта на файловете) за core файлове като `index.php` е особено полезен при тихи инфекции. Допълнително: редовно проверявай Google Search Console за неочаквани URL-и в индекса.

## Изводът: „тиха“ атака, която използва доверието към търсачките

Този случай е добър пример за модерния подход при WordPress компрометирането: вместо да се афишира с видими редиректи и popups, malware-ът превръща сайта в контролиран gateway за съдържание и разчита на това, че собствениците тестват основно като „обикновен посетител“. Комбинацията от User-Agent филтър, ASN/CIDR списъци и bitwise IP проверка прави инфекцията селективна и трудна за хващане без систематичен мониторинг и одит на файловете.

## Препратки / Източници

- [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)