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

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

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

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.