Hakkeroitu WordPress-sivusto: mitä tehdä askel askeleelta

Punainen varoitus Chromessa, uudelleenohjaus vieraalle verkkotunnukselle ja hallintapaneeli, jossa kaikki näyttää entiseltä. Hätätilanteen kulku juuri WordPress-sivustolle: mitä ensimmäisellä tunnilla ei saa tehdä, missä tartunta oikeasti piilee ja miten Googlen varoituksesta pääsee eroon.

Torstaiaamuna asiakas soittaa ja kertoo, että Chrome näyttää hänen ruudullaan kauppasi sijasta punaista koko ruudun varoitusta; avaat sivuston puhelimella, ja selain heittää puolentoista sekunnin kuluttua täysin vieraalle verkkotunnukselle, mutta työkoneella, jolla hallintapaneeli on ollut auki maanantaista asti, kaikki näyttää täsmälleen samalta kuin aina. Juuri tältä hakkeroitu WordPress-sivusto useimmiten näyttää — ei rikottu etusivu hyökkääjän allekirjoituksella, vaan sivusto, joka näyttää omistajalle yhdet kasvot ja kävijälle toiset, ja siksi ensimmäiset tunnit kuluvat yleensä kiistelyyn siitä, onko ongelmaa lainkaan olemassa.

Kysymykset, joihin tässä vastataan, esitetään yleensä juuri tässä järjestyksessä: mitä ensimmäisellä tunnilla saa ja mitä ei saa tehdä, kun vielä ei tiedetä, kuinka syvälle hyökkääjä pääsi; missä kohtaa WordPress-asennusta koodi tavallisesti piilee, koska ilman sitä puhdistus on arvailua; ja miten Google saadaan poistamaan varoitus pilaamatta itseltään toista yritystä. Väliin jää se, minkä omistajat useimmiten ohittavat — tunnusten ja avainten vaihto oikealla hetkellä ja oikeassa järjestyksessä.

Kaikki, mitä lähituntien aikana on tehtävä, on tässä, eikä välissä tarvitse poiketa muualle. Artikkelin ulkopuolelle jää vain se, mistä on hyötyä vasta kun sivusto toimii taas — varmuuskopiostrategia, järjestelmäkovennus ja suojautuminen seuraavaa kertaa vastaan, joka on sama alustasta riippumatta —, ja siihen osoitamme erillisen oppaan tuonnempana. Kyse on siitä, mikä tekee WordPressistä erilaisen: lisäosien ekosysteemistä, wp-content-kansiosta, tietokantatauluista, joissa tartunta selviää tiedostojen puhdistuksesta hengissä, ja komennoista, jotka lupaavat enemmän kuin tosiasiassa tarkistavat. Meidän työssämme juuri nämä neljä asiaa ratkaisevat, onko sivusto puhdas yhden päivän vai kolmannen yrityksen jälkeen.

Ensimmäinen tunti: älä poista mitään

Ensimmäinen reaktio on lähes aina toinen kahdesta — avata webhotellin tiedostonhallinta, löytää sieltä jotain vierasta ja poistaa se, tai painaa nappia, joka palauttaa eilisen varmuuskopion. Pyydämme jättämään molemmat tekemättä, ja syy on käytännöllinen, ei byrokraattinen. Kiire on ymmärrettävä, koska jokainen tunti punaisen varoituksen kanssa maksaa kävijöitä, mutta juuri kiireessä tehdään ne kaksi päätöstä, jotka venyttävät palautuksen kahdeksasta tunnista viikoksi, ja molemmat ovat peruuttamattomia.

Kun tartunnan saaneet tiedostot on poistettu, katoaa samalla ainoa aineisto, josta murtautumiskohta myöhemmin selvitetään: tiedostojen muutosajat, hyökkääjän lataamien skriptien sisältö ja palvelimen lokimerkinnät, jotka näihin aikoihin osuvat. Ilman murtautumiskohtaa puhdistus on pelkkää oireiden poistamista, ja siitä on mitattu hinta — Googlen ja Kalifornian yliopiston (Berkeley) tutkimuksessa, joka kävi läpi 760 935 murtotapausta heinäkuun 2014 ja kesäkuun 2015 väliltä, 12 % sivustoista murrettiin 30 päivän kuluessa uudelleen, koska korjattu oli vain oire eikä syy (Li ym., WWW 2016).

Ensimmäinen työ on siksi täysi kopio — kaikki tiedostot ja koko tietokanta yhdellä kertaa, ennen kuin yhteenkään tavuun kosketaan, sillä näkyvä uudelleenohjaus tai rikottu etusivu on harvoin kaikki, mitä sivustolla tapahtuu: Sucurin mukaan vuonna 2023 tartunnan saaneista sivustoista 49,21 %:sta löytyi vähintään yksi takaovi (backdoor), ja vuoden aikana sen tiimi poisti 21 062 tällaista ohjelmaa (Sucuri, ”2023 Hacked Website & Malware Threat Report”, kesäkuu 2024). Säilytä kopio saman palvelimen ulkopuolella, koska juuri siellä hyökkääjällä on yhä pääsy.

Seuraava soitto on webhotellille, eikä kohteliaisuudesta: sillä on pääsylokit, jotka omalla tilillä näkyvät yleensä vain muutaman päivän taaksepäin, ja jaetulla palvelimella sen on tarkistettava, tapahtuuko viereisillä tileillä sama. Jos sivustolla otetaan vastaan maksuja tai syötetään henkilötietoja, se on tässä vaiheessa suljettava tai laitettava huoltotilaan — jokainen kävijä, joka seuraavan tunnin aikana syöttää korttitietonsa, on erillinen ongelma, jota sinulla ei vielä ole. Huoltotila maksaa yhden päivän myynnin; myöhästynyt hetki maksaa kirjeen asiakkaille.

Jos wp-admin ei enää aukea — murretulla sivustolla niin käy usein —, huoltotilaa ei paneelista saa päälle, ja jäljelle jää kaksi tietä: sivuston juuren .htaccess-tiedostoon lisätään sääntö, joka ohjaa kaikki muut paitsi oman IP-osoitteesi yhdelle staattiselle huoltoilmoitussivulle, tai samassa puhelussa pyydetään webhotellia jäädyttämään tili tilapäisesti. Jälkimmäinen kuulostaa karulta, mutta se toimii silloinkin, kun tiedostoihin ei enää pääse käsiksi.

Eilinen varmuuskopio näyttää nopeimmalta tieltä takaisin, ja toisinaan se todella on oikea askel, mutta vain silloin kun tiedetään, minä päivänä hyökkääjä pääsi sisään. Meidän työssämme tartunta huomataan huomattavasti myöhemmin kuin se on alkanut — koodi on ensin jonkin aikaa hiljaa ja alkaa vasta sitten näyttää roskasivuja tai uudelleenohjauksia —, ja se tarkoittaa, että eilisessä kopiossa takaovi on mitä todennäköisimmin jo sisällä. Palautus piilottaa siinä tapauksessa oireet pariksi tunniksi ja palauttaa sivuston täsmälleen siihen tilaan, jossa se aikanaan murrettiin, ja siksi aloitamme hakkeroidun sivuston palautuksen yleensä muutamassa tunnissa ja aloitamme kiireessäkin kopiosta emmekä poistamisesta, silloinkin kun asiakas soittaa ja pyytää vain siivoamaan kaiken nopeasti.

Mistä tunnistat hakkeroidun WordPress-sivuston

Uudelleenohjaus, joka laukeaa Googlen tuloksesta tulleelle kävijälle mutta ei silloin, kun osoite kirjoitetaan selaimen osoiteriville, ei ole väärinkäsitys vaan hyökkääjän tietoinen valinta: Googlen roskasisältökäytännöissä uudelleenohjaukset on nimetty erikseen hakkeroidun sisällön lajiksi, jossa hyökkääjän lisäämä koodi ohjaa vain osan kävijöistä haitallisille tai roskasivuille (Google Search Central, tarkistettu elokuussa 2026). Juuri tuo ”vain osan” on se, joka omistajaa harhauttaa. Tarkistus vie minuutin: avaa sivusto incognito-ikkunassa, etsi se sitten Googlen tuloksista ja avaa sieltä, ja toista molemmat vielä puhelimella.

Toinen tunnusmerkkien ryhmä on hallinnan puolella ja paljon konkreettisempi: wp-admin palauttaa yhtäkkiä 404:n, kirjautumislomake latautuu oikean salasanan jälkeen vain uudelleen, käyttäjälistalla on pääkäyttäjätili, jota kukaan tiimistäsi ei ole luonut, tai Asetukset → Yleiset -kohdassa sivuston osoite ei ole enää sinun. Tietokannassa viimeksi mainittu on vain kaksi riviä wp_options-taulussa — siteurl ja home —, ja juuri siksi asetuksissa näkyvä osoite ja se osoite, johon kävijä päätyy, voivat olla eri.

Kolmas ryhmä tulee ulkopuolelta ja on kaikkein kivuliain, koska sivuston tilasta kertoo sinulle joku muu: webhotelli jäädyttää varoittamatta tilin, jolta on lähtenyt roskapostia, Search Consoleen ilmestyy merkintä tietoturvaongelmasta, tai hakutuloksiin sivuston viereen ilmestyy merkintä ”Tämä sivusto voi olla hakkeroitu”, jonka Google näyttää, kun sillä on syytä uskoa hyökkääjän muuttaneen olemassa olevia sivuja tai lisänneen uusia roskasivuja (Googlen haun ohje, tarkistettu elokuussa 2026). Merkinnän lisää Google itse, ei kenenkään valituksen perusteella, ja se ilmestyy myös silloin, kun sivusto näyttää sinusta itsestäsi moitteettomalta.

Nimet eivät ole tässä akateeminen kysymys, koska niillä haet ratkaisua ja arvioit, ymmärtääkö tekijä tapaustasi: Google nimeää dokumentaatiossaan kolme — gibberish hack, Japanese keyword hack ja cloaked keywords and links hack, jossa hyökkääjän luomat sivut näyttävät hakukoneelle yhtä sisältöä ja kävijälle toista. Alalla suosittu ”pharma hack” on peräisin tietoturvayhtiö Sucurilta (2020), eikä sitä ole Googlen dokumentaatiossa. Käytännön tarkistus on kuitenkin kaikille kolmelle sama: syötä hakuun site:-kysely omalla verkkotunnuksellasi, niin näet heti sivut, joita kukaan yrityksessäsi ei ole kirjoittanut. Japanilaisessa muunnelmassa ne ovat automaattisesti luotuja sivuja japaninkielisin otsikoin satunnaisesti nimetyissä kansioissa ja oman verkkotunnuksesi osoitteessa.

Ja sitten epämiellyttävä osa: puhdas skannaustulos ei todista sivustoa puhtaaksi, koska skanneri näkee vain sen, minkä palvelin sille näyttää, ja hyökkääjän koodi tunnistaa usein skannerit ja hakukoneet — Google varoittaa maskattuja avainsanasivuja käsittelevässä oppaassaan, että murto pyritään piilottamaan niin, että omistajasta näyttäisi ongelman jo menneen ohi. Jos skannaus on puhdas mutta webhotelli valittaa lähtevästä postista, usko webhotellia. Silloin on paikallaan tietoturva-auditointi, jossa tiedostot ja lokit käydään läpi käsin, sillä skanneri vastaa kysymykseen, onko sivustolla jotain tunnettujen näytteiden listalta, ei siihen, onko sivustolla yhä joku.

Missä WordPressin riski oikeasti on

Meidän työssämme syy, kun se lopulta löytyy, ei ole juuri koskaan WordPressin ydin itse. Patchstackin katsauksessa ”State of WordPress Security in 2026” on laskettu 11 334 uutta haavoittuvuutta, jotka WordPressin ekosysteemistä löydettiin vuonna 2025 — 42 % enemmän kuin vuotta aiemmin —, ja juuri näiden lukujen jakauma on se, mikä sinulle nyt on tärkeää: 91 % niistä koski lisäosia ja 9 % teemoja, mutta itse WordPressin ytimestä raportoitiin koko vuoden aikana vain kuusi, ja nekin kaikki matalan prioriteetin tapauksia. Lähes jokainen uusi haavoittuvuus ei siis ole siinä WordPressissä, jonka aikanaan asensit, vaan siinä, mitä sen päälle on vuosien varrella lisätty.

Jokainen lisäosa on erillinen koodikanta, jonka kirjoittaa erillinen tekijä erillisellä — ja melko usein jo katkenneella — päivityskurilla, joten sivusto, jolla on neljäkymmentä lisäosaa, ei ole sivusto, jolla on yksi tietoturvakysymys, vaan sivusto, jolla on neljäkymmentä toisistaan riippumatonta tietoturvakysymystä. Kokemuksemme mukaan tavallinen yrityssivusto tulee täysin toimeen kymmenellä tai viidellätoista lisäosalla, ja loput ovat sinne yleensä jääneet aikaa sitten unohtuneista tehtävistä: galleriasta, jota ei enää näytetä, lomakkeesta, joka on korvattu toisella, liukukuvasta, jota nykyinen ulkoasu ei enää käytä. Kun otamme hoitaaksemme WordPress-sivuston toteutuksen ja ylläpidon, lisäosien määrän karsiminen on ensimmäinen työ, ei viimeinen.

Ja tässä on virhe, joka toistuu useammin kuin mikään muu: tarpeeton lisäosa poistetaan käytöstä mutta ei poisteta kokonaan — käytöstä poistaminen kertoo WordPressille, ettei sitä enää ladata, mutta tiedostot jäävät palvelimelle paikoilleen, osa niistä on yhä saavutettavissa suoraan HTTP:n yli, ja hyökkääjän skriptille riittää, että se tietää polun. Wordfence dokumentoi kesäkuussa 2021 aktiivisessa hyväksikäytössä olleen nollapäivähaavoittuvuuden Fancy Product Designer -lisäosassa; se oli yhtiön mukaan joissakin kokoonpanoissa hyödynnettävissä silloinkin, kun lisäosa oli poistettu käytöstä, ja se kehotti poistamaan lisäosan kokonaan eikä vain kytkemään sitä irti. Jos lisäosaa ei enää tarvita, sen paikka ei ole lisäosalistalla harmaana vaan palvelimen ulkopuolella.

Sen, miksi tämä kaikki tapahtuu automaattisesti ja ilman minkäänlaista henkilökohtaista syytä, selittää mittakaava: W3Techsin mukaan WordPress pyörittää 5. elokuuta 2026 41,2 % kaikista verkkosivustoista. Tämän kokoluokan ekosysteemissä jokainen julkaistu lisäosan haavoittuvuus on heti käytettävissä hyvin suurta joukkoa samalla tavalla rakennettuja sivustoja vastaan, joten hyökkäys kannattaa automatisoida eikä kohdentaa — skripti käy läpi versionumeroita, ei yritysten nimiä. Kukaan ei ole valinnut juuri sinun sivustoasi, ja juuri siksi myös pieni yrityssivusto ilman asiakastietoja ja ilman maksuja murretaan yhtä rauhallisesti kuin iso verkkokauppa.

Mihin hyökkääjä piilottaa koodin WordPress-asennuksessa

Ensimmäinen paikka, jonka avaamme, on wp-content/uploads — kansio, jossa on luonteensa puolesta vain kuvia, PDF-tiedostoja ja videoita ja jossa ei pitäisi koskaan suorittua yhtäkään PHP-tiedostoa. Jos siellä makaa vuoden 2019 tuotekuvien seassa tiedosto päätteellä .php, se ei ole päätynyt sinne sattumalta: lähes aina se on joko latain, jolla hyökkääjä tuo palvelimelle seuraavat tiedostot, tai kuori, jolla komentoja voi suorittaa palvelimesi nimissä. Että ongelma on todellinen eikä teoreettinen, näkyy jo siitä, että sekä Sucuri että Wordfence tarjoavat erillisen kovennusasetuksen, joka kytkee .htaccess-säännöllä PHP-moottorin pois juuri tästä kansiosta.

Toinen paikka on wp-content/mu-plugins. Sinne sijoitetut lisäosat aktivoituvat automaattisesti, niitä ei voi kytkeä pois hallintapaneelista ja — mikä tässä tapauksessa on tärkeintä — ne eivät näy tavallisella lisäosalistalla, joten sivuston omistaja voi katsoa kuukausia näennäisen puhdasta paneelia; Sucuri kuvasi heinäkuussa 2025 juuri tällaisen tapauksen, jossa takaovi oli tässä kansiossa. Sen rinnalla tarkistamme aina .htaccess-tiedostot sekä juuresta että alikansioista, koska uudelleenohjaus, joka laukeaa vain hakukoneesta tuleville kävijöille tai vain mobiililaitteilla, on useimmiten kirjoitettu sinne — ja se on syy siihen, että oma sivustosi näyttää sinusta täysin normaalilta.

Koodi kirjoitetaan usein myös olemassa olevien, täysin laillisten tiedostojen ensimmäisille riveille, yleisimmin wp-config.php-tiedoston alkuun ja teeman functions.php-tiedostoon, eikä se juuri koskaan näytä haitalliselta koodilta: se on yksi pitkä rivi base64_decode-, gzinflate- tai eval-kutsuineen, jonka perässä on satoja tyhjiä rivejä, jotta editorissa näyttäisi siltä kuin tiedosto olisi loppunut. Siksi tiedostojen vertaaminen puhtaaseen alkuperäiseen on arvokkaampaa kuin silmällä lukeminen: silmällä tuota riviä ei löydä kukaan, koska kukaan ei vieritä tiedostoa riville yhdeksänsataa.

Ja sitten on tietokanta, johon tiedostoskanneri ei katso ja jossa tarkistettavia paikkoja on kolme: wp_options-taulun rivit siteurl ja home, jotka hyökkääjä kirjoittaa uusiksi, jotta sivujesi resurssit ladattaisiin vieraalta palvelimelta; taulu wp_users, johon ilmestyy usein pääkäyttäjätili uskottavalla nimellä; ja merkintöjen sisältö wp_posts-taulussa, jonne piilotetut linkit ja iframe-koodit rakennetaan vanhojen artikkelien keskelle, joita kukaan ei enää avaa. Jos tiedostot puhdistetaan mutta injektio jää tietokantaan, tartunta palaa samana päivänä. Rivi ei itse suoritu — sen lukee ja käynnistää jokaisella latauksella pieni latain teeman functions.php-tiedostossa tai mu-plugins-kansiossa —, ja juuri tämä pari palauttaa poistetut tiedostot nopeammin kuin ehdit tarkistaa tuloksen. Juuri siksi tiedostojen ja tietokannan puhdistus on meille hakkeroidun sivuston palautuksessa yksi työ eikä kaksi.

Tiedostojen vertaaminen varmennettuihin alkuperäisiin

Ensimmäinen työkalu, johon tartumme sen jälkeen kun täysi tiedosto- ja tietokantakopio on varmistettu, on wp core verify-checksums: se vertaa jokaisen tiedoston tiivistettä WordPress.orgin julkaisemiin tarkistussummiin ja näyttää heti, mitkä tiedostot on muutettu ja mitä asennukseen ei ylipäätään kuulu. Ongelma alkaa siitä, mihin sen kattavuus loppuu — komento tarkistaa vain hakemistot wp-admin/ ja wp-includes/ sekä juuren wp-*-tiedostot, mutta koko wp-content-kansion eli lisäosat, teemat ja lataukset lähdekoodi jättää tietoisesti väliin (WP-CLI:n checksum-command-lähdekoodi, katsottu 5. elokuuta 2026). Yhden juuritiedoston sama lähdekoodi sulkee pois erikseen — wp-config.php —, joten tiedosto, jonka ensimmäisille riveille koodia useimmin kirjoitetaan, ei näy tälle tarkistukselle. Puhdas komennon tulos ei tarkoita puhdasta sivustoa.

Lisäosille on oma komentonsa wp plugin verify-checksums, mutta sekin vertaa tiedostoja vain WordPress.orgin repositorion tarkistussummiin, joten kaupallinen lisäosa, jonka olet ostanut kehittäjältä, jää tarkistuksessa yksinkertaisesti väliin; teemoille vastaavaa komentoa ei WP-CLI:n dokumentaatiossa ole lainkaan (WP-CLI:n dokumentaatio, katsottu 5. elokuuta 2026). Automaattisen tarkistuksen ulottumattomissa ovat siis sekä teemat että repositorion ulkopuolelta ostetut lisäosat, ja wp core verify-checksums ohittaa koko wp-content-kansion — sen koodin osan, jossa syntyivät kaikki Patchstackin vuodelta 2025 laskemat 11 334 haavoittuvuutta ytimen kuutta lukuun ottamatta. Haltuun ottamillamme sivustoilla juuri teema on usein ainoa, jota kukaan ei ole koskaan tarkistanut.

Tarkistussummat ovat meille siksi lähtökohta eivätkä menetelmä: ydintä ja lisäosia emme hoida vaan korvaamme, eli lataamme samat versiot alkuperäisestä lähteestä ja kirjoitamme kansiot kokonaan uusiksi emmekä tiedosto kerrallaan. Vanhasta asennuksesta säilytämme wp-content/uploads-kansion, ja senkin vasta kun on tarkistettu, ettei kuvien seassa ole PHP-tiedostoja — samasta syystä, jonka vuoksi PHP-moottori kannattaa tuosta kansiosta ylipäätään kytkeä pois. Teeman palautamme versionhallinnasta, jos sellainen on; jos ei, otamme kehittäjän toimittaman kopion ja lisäämme mukautukset päälle tietoisesti, yksi kerrallaan, koska vain siten voi myöhemmin sanoa, mikä rivi sivustolla on meidän ja mikä ei.

Huonon rivin etsiminen ja poistaminen kuulostaa halvemmalta, ja juuri siksi se on useimmin toistettu virhe: hyökkääjä jättää harvoin yhden sisäänkäynnin, ja yksi huomaamatta jäänyt takaovi tekee kaiken muun työn turhaksi. Koodi on usein jaettu useaan tiedostoon, piilotettu base64- tai gzinflate-kutsun taakse, kirjoitettu tietokannan asetustauluun tai sijoitettu samaan mu-plugins-kansioon, jota hallintapaneeli ei näytä. Näytteen perusteella etsiminen löytää sen, minkä jo tunnet; täysi korvaaminen vapauttaa myös siitä, mitä et tunne.

On myös työtä, jota emme tässä vaiheessa tee: emme luota lisäosaan, joka tarjoutuu ”parantamaan” tartunnan saaneet tiedostot yhdellä napilla, koska se toimii samalla tunnettujen näytteiden listalla ja lisäksi samassa ympäristössä, johon hyökkääjällä on yhä pääsy. Emme myöskään vertaa tiedostoja käsin silloin, kun sivusto on tavallisen käyntikortti- tai blogisivuston kokoinen, koska tuore asennus ja sisällön siirto vievät vähemmän tunteja kuin kahden hakemiston vertaaminen rivi riviltä, ja tulos on tarkistettavissa. Huolellinen käsityö on paikallaan siellä, missä teema tai lisäosa on ainutlaatuinen eikä versionhallintaa ole; miten varmuuskopioiden kanssa toimitaan, jotta tämä valinta ylipäätään olisi olemassa, on kuvattu yleisessä palautusoppaassa.

Avaimet, istunnot ja salasanat: mikä tekee mitäkin

Salaiset avaimet ja suolat (keys and salts) wp-config.php-tiedostossa eivät salaa mitään, vaikka niin väittää lähes jokainen opas: WordPress käyttää niitä pohjana avaimelle, jolla funktio wp_generate_auth_cookie() allekirjoittaa todennusevästeen HMAC-SHA256:lla, mutta itse eväste on selkokielistä tekstiä, jossa on käyttäjätunnus, voimassaoloaika ja istuntotunniste (WordPress Developer Resources, katsottu 5. elokuuta 2026). Kun nämä arvot vaihdetaan, jokaisesta aiemmin annetusta allekirjoituksesta tulee tarkistuskelvoton ja palvelin hylkää jokaisen tähän asti myönnetyn evästeen, vaikka istunto itsessään ei muodollisesti olisi vielä päättynyt.

Käytännön seuraus on juuri se, mitä murron hetkellä tarvitaan: WordPressin virallinen dokumentaatio kuvaa avainten vaihdon tapana heittää ulos jokainen, joka saattaisi vielä olla kirjautuneena (WordPress.org, ”FAQ My site was hacked”, päivitetty 26. heinäkuuta 2026), eli jos hyökkääjällä on kädessään voimassa oleva istunto, se päättyy samalla hetkellä. Istuntojen mukana kelvottomiksi käyvät myös kaikki annetut nonce-tunnisteet, joten kesken olevat lomakkeet ja puolivälissä olevat tilausvaiheet katkeavat silloin — vaihdon hetken valitsemme tietoisesti emmekä sattumanvaraisesti keskeltä työpäivää.

Avainten ja suolojen vaihto ei muuta yhtäkään salasanaa. Salasanojen tiivisteet WordPress muodostaa bcryptillä ja jokaiselle salasanalle erillisellä satunnaisella suolalla, jolla ei ole yhteyttä wp-config.php-tiedoston vakioihin (funktio wp_hash_password(); bcrypt oletuksena WordPress 6.8:sta lähtien), joten hyökkääjä, joka tietää pääkäyttäjän salasanan tai on ehtinyt luoda itselleen tilin, kirjautuu avainten vaihdon jälkeen yksinkertaisesti uudelleen. Salasanat vaihdetaan erikseen ja kaikki, myös ne, joita kukaan muka ei tiedä, ja samalla käydään käyttäjälista läpi etsien tilejä, joita kukaan tiimistäsi ei ole luonut.

WordPressiin tunnusten lista ei lopu: samalla kertaa vaihdetaan webhotellin hallintapaneelin salasana, FTP- ja SFTP-tunnukset, tietokantakäyttäjän salasana yhdessä vastaavan merkinnän kanssa wp-config.php-tiedostossa sekä SSH-avaimet, joita ei vaihdeta salasanan tapaan vaan luodaan uudelleen poistamalla vanha julkinen avain palvelimen authorized_keys-tiedostosta. Lopuksi vaihdetaan kaikki sivustolle tallennetut API-avaimet — maksunvälittäjän, sähköpostipalvelun sekä toimitus- ja kirjanpitointegraatioiden —, koska ne jäävät yleensä pisimmäksi aikaa koskematta: kukaan ei näe niitä arjessa yhdelläkään ruudulla.

Oleta, että hyökkääjällä on täysi kopio tietokannasta, koska se on koko hyökkäyksen halvin askel: kaikkea, mitä tietokannassa on ollut — asiakkaiden sähköpostiosoitteet, tilaushistoria, salasanojen tiivisteet ja lisäosien asetuksiin kirjoitetut avaimet —, on pidettävä vieraisiin käsiin joutuneena. Jos jotakin näistä salasanoista on käytetty vielä jossain muualla, myös se paikka on vaarantunut, ja tavallisesti juuri siinä kohdassa keskustelu siirtyy sivustolta sähköpostitileihin, kirjanpito-ohjelmaan ja kaupan maksutilille.

Järjestys on yhtä tärkeä kuin itse lista: avaimet ja salasanat vaihdetaan vasta sen jälkeen, kun takaovet on poistettu, koska muuten hyökkääjä lukee uudet arvot samasta wp-config.php-tiedostosta tai kaappaa yksinkertaisesti seuraavan kirjautumisen. Juuri tämä rivi — ensin täysi kopio, sitten syy, sitten puhdistus ja vasta viimeiseksi tunnukset — on se, johon omin voimin aloitettu palautus useimmiten pysähtyy tai sekoaa, ja siksi otamme tämän vaiheen itsellemme ja luovutamme lopuksi kirjallisen raportin siitä, mitä muutettiin, milloin ja miksi.

Miten Googlen varoitus saadaan pois ja mitä sen jälkeen tehdään

Search Consolen tietoturvaongelmaraportti on ainoa paikka, jossa näkee, mitä Google sivustoltasi tarkalleen on löytänyt: siinä kerrotaan uhkan laji ja näyte konkreettisista sivuista, joita se koskee, ja siitä riippuu myös se, mitä kävijä juuri nyt näkee. Uhkan laji ei muuta sitä, mitä kävijä näkee: Chrome ei enää erottele varoituksen otsikkoa sen mukaan, onko löytynyt tietojenkalastelua, haittaohjelma vai ei-toivottu ohjelmisto, vaan näyttää kaikissa tapauksissa yhtä ja samaa koko ruudun varoitusta — suomeksi ”Vaarallinen sivusto” —, joka ei yksinkertaisesti päästä ihmistä sivustolle, kun taas jo mainittu merkintä ”Tämä sivusto voi olla hakkeroitu” hakutuloksissa on vain teksti linkin vieressä, jonka läpi voi klikata (Google Chromen ohjesivu vaarallisista sivustoista, tarkistettu elokuussa 2026). Vanhempia, uhkan lajin mukaan vaihtelevia otsikoita — esimerkiksi ”Deceptive site ahead” — Chrome ei enää käytä, vaikka ne ovat osassa Googlen dokumentaatiota yhä tallella. Ensimmäinen estää, toinen varoittaa, ja se muuttaa sen, kuinka paljon aikaa sinulla todella on.

Ennen kuin painat tarkastuspyynnön nappia, on varmistettava, että sivusto todella on puhdas eikä vain näytä puhtaalta sinun selaimessasi. Google varoittaa maskattuja avainsanoja käsittelevässä oppaassaan nimenomaan siitä, että hyökkääjät yrittävät luoda vaikutelman, että sivu on jo poistettu tai korjattu, ja siksi jokainen entinen roskasivu on tarkistettava URL-tarkistustyökalulla, joka näyttää Googlebotin näkymän eikä sinun. Toinen useimmin ohitettu askel on omistajalista: Japanese keyword hack -tapauksessa hyökkääjä lisää itsensä vahvistetuksi Search Consolen omistajaksi (Googlen dokumentaatio web.dev-sivustolla), ja niin kauan kuin häntä ei ole listalta poistettu, hän tietää sivuston tilasta täsmälleen yhtä paljon kuin sinä.

Etsimäsi painike on tietoturvaongelmaraportin ”Pyydä tarkastusta”, ei uudelleenarviointipyyntö, jonka Google varaa manuaalisille toimenpiteille, ja pyynnön tekstiin kannattaa kirjoittaa kolme asiaa: mitä löytyi, miten hyökkääjä pääsi sisään ja mitä konkreettisesti on tehty sen korjaamiseksi. Määräaikaa emme lupaa, koska ei lupaa Googlekaan: sen sosiaalista manipulointia käsittelevä dokumentaatiosivu sanoo tarkastuksen voivan kestää useita päiviä, kun taas Search Consolen tietoturvaongelmien ohjesivu puhuu muutamasta päivästä muutamaan viikkoon (molemmat tarkistettu elokuussa 2026). Jos joku nimeää sinulle täsmälliset 24 tai 72 tuntia, hän toistaa lukua, jota ei ole yhdessäkään Googlen lähteessä.

Kiire maksaa tässä vaiheessa enemmän kuin odottaminen. Samassa Googlen ja Kalifornian yliopiston (Berkeley) tutkimuksessa 80 % sivustojen omistajista sai sivustonsa hyväksytyksi puhtaaksi jo ensimmäisellä yrityksellä, mutta lopuilta 20 %:lta se vaati useita yrityksiä, ja mediaaniaika, jonka he käyttivät hyökkääjän jättämän koodin kampaamiseen, oli kokonainen viikko. Aineisto on vuosilta 2014–2015 ja niin se on luettavakin, mutta laskutoimitus ei ole muuttunut: hylätty pyyntö tarkoittaa, että varoitus jää vielä yhdeksi kierrokseksi, etkä toisella kerralla ole enää ensikertalainen.

Kun varoitus on poistettu, työ ei vielä ole ohi, sillä indeksiin jäävät hyökkääjän luomat sivut, eikä niitä saa ohjata etusivulle — niiden on palautettava 404 tai 410, jotta Google poistaa ne kokonaan, kun taas Search Consolen poistotyökalu vain piilottaa ne väliaikaisesti. Sijoitukset eivät palaa katkaisijaa kääntämällä: sivut on indeksoitava uudelleen, ja se tapahtuu Googlen tahdissa eikä sinun. Miten lokitiedostoja ja varmuuskopioita tässä vaiheessa käytetään, jotta lähtökohta olisi ensi kerralla parempi, on kuvattu erillisessä oppaassa hakkeroitujen sivustojen palauttamisesta.

Milloin kannattaa lopettaa itse tekeminen ja mitä se maksaa

Osan tässä kuvatusta kokenut sivuston omistaja tekee itse, ja sanomme sen kiertelemättä myös ihmisille, jotka soittavat meille Search Console auki ja syyllinen lisäosa jo löydettynä. Jos tartunta on yksi rikottu etusivu, jos lokeista näkyy, mikä lisäosa sen päästi sisään, jos käyttäjälistalla ei ole vieraita pääkäyttäjiä ja jos on eilinen varmuuskopio, jonka joku on joskus oikeasti palauttanut testiympäristöön, kahdeksan laskutettua tuntia ostaa sinulle rauhallisemmat yöunet eikä nopeampaa tulosta.

Tilanteita, joissa kehotamme pysähtymään, on neljä, ja ensimmäinen on uusi tartunta puhdistuksen jälkeen: jos sivusto murretaan toistamiseen, kyse ei ole epäonnesta vaan todisteesta siitä, että murtautumiskohta on yhä auki, ja kolmas puhdistus samassa ympäristössä maksaa täsmälleen saman kuin kaksi ensimmäistä. Toinen on mikä tahansa epäilyksen varjo asiakas- tai maksutiedoista, koska siinä teknisen työn rinnalle tulevat velvollisuudet valvontaviranomaista kohtaan ja määräajat, joita ei hyvälläkään tahdolla voi venyttää. Kolmas on sivusto, josta yritys ansaitsee joka päivä, ja neljäs yksinkertainen ajanpuute: puhdistus ei ole älyllisesti vaikeaa, mutta se on pitkä ja yksitoikkoinen työ, joka ei anna anteeksi yhtäkään väliin jäänyttä tiedostoa.

Hakkeroitujen sivustojen palautus maksaa meillä 90 € tunnissa ilman arvonlisäveroa, ja vähimmäismäärä on kahdeksan työtuntia, jotka laskutetaan etukäteen. Aloitamme työn yleensä muutaman tunnin kuluessa yhteydenotosta, ja koko prosessi alusta luovutukseen kestää tavallisesti 8–72 tuntia; ero kahdeksan ja seitsemänkymmenenkahden tunnin välillä on lähes aina siinä, kuinka syvälle hyökkääjä ehti asettua ja kuinka vanha viimeinen puhdas kopio on. Vähimmäismäärä ei ole markkinointiluku: täysi kopio, syyn etsiminen lokeista, puhdistus ja tarkistus mahtuvat harvoin lyhyempään aikaan.

Järjestys on sama kuin edellä kuvattu, vain ilman sinun viikonloppuasi. Ennen kuin kosketaan mihinkään, otetaan täysi tiedosto- ja tietokantakopio, jotta tapaus olisi myöhemmin ylipäätään tutkittavissa, ja vasta sitten sivusto eristetään; sen jälkeen se puhdistetaan haittaohjelmista ja takaovista, tietokanta tarkistetaan, tunnukset ja avaimet vaihdetaan, murron syy etsitään ja suljetaan, Googlelle lähetetään tarkastuspyyntö ja seuranta kytketään päälle, ja lopuksi saat kirjallisen raportin tapahtuneesta ja siitä, mitä muutettiin. Jos sivusto ei juuri nyt toimi tai et ole varma siitä, mitä näet, voit tilata kiireellisen sivuston tarkistuksen, ja sanomme, onko tässä ylipäätään mitään mistä maksaa.

Monessa tapauksessa oikea vastaus ei kuitenkaan ole palautus vaan se, mitä sen jälkeen tapahtuu: jos sivustolle on kertynyt kaksikymmentä lisäosaa, joista puolen syytä ei kukaan enää muista, ongelma on ylläpidossa, ja sen ratkaisee WordPress-toteutus ja ylläpito eikä uusi puhdistuskierros puolen vuoden päästä. Halvin tunti koko tässä tarinassa on se, joka on käytetty etukäteen: käyttämättömän lisäosan poistaminen wp-content/plugins-kansiosta eikä sen kytkeminen pois päältä, ja varmuuskopio, jonka joku on kerran oikeasti palauttanut testiympäristöön, maksavat yhdessä vähemmän kuin yksi meidän työpäivämme.