---
title: "WordPress-haittaohjelma kohdistaa sisällön Googlebotille: User-Agent ei enää riitä, mukaan tulee ASN- ja CIDR-tarkistus"
url: "https://helloblog.io/fi/wordpress-haittaohjelma-kohdistaa-sisallon-googlebotille-asn-cidr-tarkistus/"
date: "2026-01-13"
modified: "2026-01-20"
author: "Emilia Korhonen"
language: "fi_FI"
categories: ["Tietoturva"]
tags: ["Googlebot", "incident response", "malware", "SEO cloaking", "WordPress security"]
featured_image: "https://helloblog.io/app/uploads/sites/15/2026/01/featured-3-1024x572.jpg"
excerpt: "Yhä useampi hyökkäys ei näy sivuston omistajalle lainkaan: ihmisille näytetään normaali etusivu, mutta Googlebotille tarjoillaan etäpalvelusta haettu roskasisältö. Tässä puretaan auki, miten IP-alueisiin (ASN/CIDR) perustuva “valikoiva injektointi” toimii ja mitä se tarkoittaa WordPress-sivuston ylläpidolle."
---

# WordPress-haittaohjelma kohdistaa sisällön Googlebotille: User-Agent ei enää riitä, mukaan tulee ASN- ja CIDR-tarkistus

WordPressin haittaohjelmissa on pitkään nähty yksinkertaisia uudelleenohjauksia ja näkyviä roskasivuja. Nyt trendi on selvästi hienovaraisempi: hyökkääjä tekee sivustosta portinvartijan, joka päättää vierailijan perusteella, mitä sisältöä palautetaan. Tavalliselle käyttäjälle kaikki näyttää siistiltä — mutta hakukoneen indeksoijalle (crawler) syötetään aivan eri payload.

Sucurin tapauskuvauksessa vastaan tuli poikkeuksellisen “huolellinen” cloaking (sisällön peittäminen): botin tunnistus ei perustu pelkkään `User-Agent`-headeriin, vaan liikenne varmistetaan Googlen oman IP-infrastruktuurin kautta. Tämä tekee hyökkäyksestä vaikean havaita käsin selailemalla tai peruscheckeillä.

## Mitä tässä löydöksessä oli pielessä?

Tutkittu infektio oli tehty WordPress-sivuston juureen, pääasialliseen `index.php`-tiedostoon. Idea oli yksinkertainen mutta tehokas: `index.php` ei aina käynnistä WordPressiä normaalisti, vaan tarkistaa ensin, kuka on tulossa sisään.

Jos tulija näyttää “oikealta” Googlelta, sivu hakee ulkopuolista sisältöä ja tulostaa sen suoraan vastaukseen. Jos tulija on tavallinen käyttäjä (tai botti, joka yrittää esittää Googlebotia), kävijä ohjataan tai päätyy normaaliin, puhtaaseen sivuun.

## Miksi tämä on kehittäjälle kiinnostava (ja ikävä) muutos?

Moni cloaking-skripti tekee vain tämän: `if (strpos($_SERVER['HTTP_USER_AGENT'], 'Googlebot') !== false) { ... }`. Se on helppo kiertää ja myös helppo löytää.

Tässä kampanjassa haittakoodi sisälsi suuren, kovakoodatun listan Googlen ASN:ään (Autonomous System Number) liittyvistä IP-alueista CIDR-muodossa ja tarkisti kävijän IP:n matemaattisesti (bitwise-operaatioilla). Lisäksi mukana oli IPv6-tuki, joka puuttuu monista vanhemmista toteutuksista.

### ASN ja CIDR pähkinänkuoressa

- **ASN (Autonomous System Number)**: käytännössä organisaation “verkkoidentiteetti” internetissä. Kun liikenne tulee Googlen ASN:n IP-alueilta, se on todennäköisemmin oikeasti Googlen infrastruktuuria eikä pelkkä feikki User-Agent.
- **CIDR**: tiivis tapa kuvata IP-osoiteblokkeja (esim. `192.168.1.0/24`). Suffixi `/24` kertoo verkon koon ja rajaa osoiteavaruuden.

## Mitä haittaohjelma käytännössä tekee sivustolle?

Tämän infektion “päävahinko” kohdistuu näkyvyyteen ja hakukonemaineriskiin. Koska Google näkee eri sisällön kuin käyttäjä, seurausketju voi olla ruma: indeksiin ilmestyy roskasivuja, sivuston luottamus heikkenee, hakutulokset voivat muuttua, ja pahimmillaan seurauksena on deindeksointi tai jonkinlainen blacklistaus.

Lisäongelma on viive: koska omistaja selaa sivustoa normaalina käyttäjänä, hän ei välttämättä näe mitään poikkeavaa. Ongelma huomataan vasta Search Consolesta, SERP:istä tai ulkopuolisesta hälytyksestä.

## Tyypilliset varoitusmerkit (joita kannattaa oikeasti katsoa)

- Hakutuloksissa näkyy outoja otsikoita/kuvauksia tai sivuja, joita et tunnista
- Ydintiedostoissa (erityisesti `index.php`) on äkillisiä muutoksia tai epäselviä lisäyksiä
- Lokissa näkyy epäilyttäviä pyyntöjä tai uudelleenohjauksia, joita et ole konffannut
- Sivustolta löytyy kutsuja ulkoisiin URL-osoitteisiin, joita koodipohjassa ei pitäisi olla

Tapauksessa etäsisältöä haettiin domainista `amp-samaresmanor[.]pages[.]dev` (kirjoitan sen tarkoituksella “rikottuna”). Sucurin mukaan URL oli analyysihetkellä VirusTotalissa useamman toimijan blocklistalla, ja samaa endpointia löytyi käytössä useammalta infektoidulta sivustolta.

## Miten hyökkäys oli rakennettu: portinvartija `index.php`:ssä

Alla on konseptitasolla se logiikka, jonka vuoksi tämä hyökkäys on hankala havaita. En ole kiinnostunut kopioimaan haittakoodia, vaan siitä, mitä komponentteja se käyttää ja miksi.

### 1) Monikerroksinen tunnistus: ensin User-Agent, sitten IP-varmennus

Ensimmäinen suodatin on `HTTP_USER_AGENT`. Mutta koska User-Agent on helppo väärentää, tämä on vain “esisuodatin”: sen jälkeen tehdään varsinainen varmistus IP-osoitteesta.

Tässä tapauksessa User-Agent-suodatus ei rajoittunut pelkkään `Googlebot`-merkkijonoon, vaan mukana oli myös muita Googlen työkaluja ja crawler-tyyppisiä tunnisteita, jotta roskasisältö päätyisi indeksoiduksi ja “näkyisi” Googlen eri prosesseille.

### 2) CIDR-alueen tarkistus bitwise-operaatioilla (IPv4)

Tunnistuksen ydin on IP-osoitteen sovittaminen CIDR-verkkoon matemaattisesti, ei merkkijonoja vertailemalla. IPv4:ssä tämä tehdään tyypillisesti muuttamalla IP ja verkko desimaalimuotoon ja vertaamalla maskattuja arvoja. Sucurin esimerkissä logiikka on tätä tyyppiä:

```
// Konsepti: tarkistetaan, kuuluuko IP CIDR-verkkoon
// (ip & netmask) == (range & netmask)

$isMatch = (
    ($ip_decimal & $netmask_decimal) === ($range_decimal & $netmask_decimal)
);
```

Keskeinen pointti: hyökkääjä ei luota siihen, että “näyttää Googlelta”, vaan siihen että tulee Googlen IP-avaruudesta (ASN/CIDR). Lisäksi IPv6 huomioitiin, mikä nostaa hyökkäyksen onnistumisprosenttia nykyverkossa.

### 3) Etä-payload sisään cURLilla ja tulostus suoraan vastaukseen

Kun kävijä on varmennettu aidoksi botiksi, haittakoodi hakee ulkoisesta palvelusta sisällön (payload) cURLilla ja `echo`-tyyppisesti tulostaa sen sivulle. Hakukoneen näkökulmasta näyttää siltä, että sivusto itse hostaa sisällön.

```
// Konsepti: hae etäsisältö ja tulosta se botille
// (URL jätetty tässä tarkoituksella esimerkkitasolle)

$remote = 'hxxps://amp-samaresmanor[.]pages[.]dev';

// cURL:lla haetaan sisältö ja tulostetaan se vastaukseen
// ...
```

### 4) Ehdollinen logiikka + lokitus: “onnistumisen” seuranta

Tämän kampanjan ikävin piirre oli päätöksenteko ja virheenkäsittely. Haittaohjelma ei vain palvele sisältöä, vaan myös ohjaa tilanteissa, joissa jokin menee pieleen:

- Jos botin User-Agent ja IP täsmäävät: palvellaan etäpayload ja kirjataan onnistuminen; jos haku epäonnistuu, botti ohjataan esim. `/home/`-polkuun, ettei Google näe rikkinäistä sivua.
- Jos User-Agent väittää olevansa Google, mutta IP ei täsmää: kirjataan “Fake GoogleBot detected” -tyyppinen tapahtuma ja ohjataan normaaliin etusivuun.
- Kaikki muut: ohjataan suoraan normaaliin sisältöön.

## Miksi juuri WordPressin ydintiedostot ovat tässä hyökkäyksessä avainasemassa?

Kun muutos tehdään `index.php`:hen, hyökkääjä pääsee kiinni kaikkeen liikenteeseen heti sisääntulossa. Sucurin kuvauksen mukaan haittakoodi hyödynsi myös WordPressin ydintiedostoja pitääkseen sivuston “toimivana” omistajalle:

- `wp-load.php`: tämän lataaminen bootstrappaa WordPress-ympäristön (asetukset, tietokantayhteys ym.), mikä helpottaa hyökkääjää rakentamaan logiikkaa tutun WP-runtime:n päälle.
- `wp-blog-header.php`: normaali `index.php` päätyy lopulta tähän. Haittakoodi voi tehdä tarkistuksensa ennen normaalia WP-ketjua ja antaa “puhtaan” polun jatkua tavallisille käyttäjille.

## Korjaus ja torjunta: mitä tekisin ensimmäisenä tuotantoympäristössä?

Jos epäilet vastaavaa, tärkeintä on katkaista hyökkääjän kontrolli ja palauttaa luotettava koodipohja. Sucurin suositukset ovat käytännönläheiset ja sopivat hyvin incident response -checklistiksi:

1. Poista tuntemattomat tiedostot ja hakemistot (erityisesti juuresta ja `wp-includes`/`wp-admin`-alueilta).
2. Auditoin käyttäjät: poista apu-/huoltotilit ja epäilyttävät adminit.
3. Nollaa tunnukset: WP-admin, FTP/SFTP, hosting-paneeli ja tietokanta.
4. Skannaa oma työasema (haitta voi olla myös kehittäjän koneessa varastettujen tunnusten kautta).
5. Päivitä kaikki: WordPress core, teemat, lisäosat.
6. Ota käyttöön WAF (Web Application Firewall): se voi estää yhteyksiä tunnettuun C2-/payload-infraan ja myös vaikeuttaa alkuperäistä uploadia/eksploitointia.

#### Erityinen huomio: file integrity

Tässä hyökkäyksessä “paha” asuu ydintiedostossa (`index.php`), ei välttämättä pluginissa. Siksi File Integrity Monitoring (tiedostojen eheyden valvonta) on käytännössä paras tapa huomata muutos nopeasti.

## Yhteenveto: hiljainen SEO-kaappaus on uusi normaali

Tämä tapaus on hyvä muistutus siitä, että moderni WordPress-haittaohjelma ei aina yritä huijata ihmistä — se yrittää huijata hakukonetta. Kun tunnistus tehdään ASN/CIDR-IP-alueiden avulla ja payload tarjoillaan vain aidoille indeksoijille, manuaalinen “näyttääkö sivu oudolta” -tarkistus ei riitä.

Käytännön puolustus on yhdistelmä: ydintiedostojen eheyden seuranta, säännöllinen käyttäjä- ja lisäosauditointi, sekä näkyvyyden tarkkailu (erityisesti Google Search Console) siltä varalta, että indeksiin ilmestyy sivuja, joita et ole koskaan julkaissut.

![Kaavio IP-varmennetusta ehdollisesta logiikasta, jossa botti tunnistetaan ja sille näytetään eri sisältö kuin käyttäjälle](https://helloblog.io/app/uploads/sites/15/2026/01/IP-Verified-Conditional-Logic.png)

*Hyökkäyslogiikka: tunnista botti, varmista IP-alue, palvele etäpayload. — *Forrás: Sucuri Blog**

![Esimerkki siitä, miten Google näkee roskasisältöä samalla kun käyttäjä näkee normaalin sivun](https://helloblog.io/app/uploads/sites/15/2026/01/What-Google-sees.png)

*Cloaking näkyy usein vasta hakukoneen näkymässä. — *Forrás: Sucuri Blog**

![Kuvitus CIDR-muotoisesta IP-alueesta ja verkkomaskista](https://helloblog.io/app/uploads/sites/15/2026/01/CIDR-format.png)

*CIDR tiivistää IP-alueen määrittelyn muotoon verkko/prefix. — *Forrás: Sucuri Blog**

![Kaavio monikerroksisesta identiteetin varmistuksesta: User-Agent ja IP-tarkistus](https://helloblog.io/app/uploads/sites/15/2026/01/Multi-Layer-Identity-Verification.png)

*User-Agent on vain ensimmäinen kerros; varsinainen varmistus tehdään IP-alueella. — *Forrás: Sucuri Blog**

![Kuvitus bitwise-pohjaisesta IP-alueen validoinnista CIDR-verkkoon](https://helloblog.io/app/uploads/sites/15/2026/01/Bitwise-IP-Range-Validation.png)

*Bitwise-tarkistus varmistaa, että IP todella kuuluu haluttuun verkkoon. — *Forrás: Sucuri Blog**

![Kaavio etäpayloadin hakemisesta cURLilla ja sisällön tulostamisesta botille](https://helloblog.io/app/uploads/sites/15/2026/01/Remote-Payload-Execution-via-cURL.png)

*Etäcontent tuodaan sisään dynaamisesti ja esitetään hakukoneelle. — *Forrás: Sucuri Blog**

![Kuvitus User-Agent-suodatuksesta, jossa tunnistetaan useita Googlen botteja ja työkaluja](https://helloblog.io/app/uploads/sites/15/2026/01/User-Agent-Filtering.png)

*Suodatus voi kattaa useita Googlen crawler- ja tarkistustyökaluja. — *Forrás: Sucuri Blog**

![Kaavio ehdollisesta logiikasta ja lokituksesta, jossa erotellaan oikea botti, feikkibotti ja tavallinen käyttäjä](https://helloblog.io/app/uploads/sites/15/2026/01/Conditional-Logic-and-Error-Logging.png)

*Päätöksenteko + lokitus tekee hyökkäyksestä luotettavamman hyökkääjälle. — *Forrás: Sucuri Blog**

## Viitteet / Lähteet

- [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)
- [Japanese Spam on a Cleaned WordPress Site: The Hidden Sitemap Problem](https://blog.sucuri.net/2025/01/japanese-spam-on-a-cleaned-wordpress-site-the-hidden-sitemap-problem.html)