Nulaužta WordPress svetainė: ką daryti žingsnis po žingsnio

Raudonas įspėjimas Chrome, peradresacija į svetimą domeną ir valdymo skydelis, kuriame viskas atrodo kaip visada. Skubių veiksmų planas būtent WordPress svetainei: ko negalima daryti pirmą valandą, kur užkratas iš tikrųjų slepiasi ir kaip atsikratyti Google įspėjimo.

Ketvirtadienio rytą paskambina klientas ir sako, kad Chrome jo ekrane vietoj jūsų parduotuvės rodo raudoną viso ekrano įspėjimą; atsidarote svetainę telefone, ir naršyklė po pusantros sekundės permeta į visiškai svetimą domeną, o darbiniame kompiuteryje, kuriame valdymo skydelis atidarytas dar nuo pirmadienio, viskas atrodo lygiai taip pat kaip visada. Būtent taip dažniausiai ir atrodo nulaužta WordPress svetainė — ne sugadintas pradžios puslapis su užpuoliko parašu, o svetainė, kuri savininkui rodo vieną veidą, o lankytojui kitą, todėl pirmosios valandos neretai praeina ginčijantis, ar problema apskritai egzistuoja.

Klausimai, į kuriuos čia atsakoma, paprastai užduodami būtent tokia tvarka: ką galima ir ko negalima daryti pirmą valandą, kol dar nežinia, kaip giliai užpuolikas pateko; kur būtent WordPress diegime paprastai slepiamas kodas, nes be to valymas tėra spėliojimas; ir kaip pasiekti, kad Google panaikintų įspėjimą, nesugadinus sau antrojo bandymo. Per vidurį lieka tai, ką savininkai praleidžia dažniausiai — prisijungimo duomenų keitimas tinkamu momentu ir tinkama tvarka.

Viskas, ką reikia padaryti artimiausiomis valandomis, yra čia, ir niekur kitur pakeliui eiti nereikės. Už straipsnio ribų lieka tik tai, kas praverčia po to, kai svetainė jau vėl veikia — atsarginių kopijų strategija, sistemos saugumo stiprinimas ir apsauga nuo kito karto, vienoda nepriklausomai nuo platformos —, o atskirą vadovą apie tai nurodome toliau. Kalbame apie tai, kuo WordPress skiriasi nuo kitų sistemų: apie įskiepių ekosistemą, aplanką wp-content, duomenų bazės lenteles, kuriose užkratas išgyvena failų valymą, ir komandas, kurios žada daugiau, nei iš tikrųjų patikrina. Mūsų praktikoje būtent šie keturi dalykai lemia, ar svetainė švari po vienos dienos, ar po trečio bandymo.

Pirmoji valanda: netrinkite nieko

Pirmoji reakcija beveik visada būna viena iš dviejų — atsidaryti prieglobos failų tvarkyklę, rasti joje kažką svetimo ir tai ištrinti arba paspausti mygtuką, atkuriantį vakarykštę atsarginę kopiją. Prašome nedaryti nei vieno, nei kito, ir priežastis čia praktinė, o ne biurokratinė. Skubėjimas suprantamas, nes kiekviena valanda su raudonu įspėjimu kainuoja lankytojus, tačiau būtent skubant priimami tie du sprendimai, kurie aštuonių valandų atkūrimą ištęsia iki savaitės, ir abu yra negrįžtami.

Ištrynus užkrėstus failus, dingsta ir vienintelė medžiaga, pagal kurią vėliau nustatomas įsilaužimo taškas: failų keitimo laikai, užpuoliko įkeltų skriptų turinys ir serverio prieigos žurnalo įrašai, sutampantys su tais laikais. Be įsilaužimo taško valymas tėra simptomų šalinimas, o kaina už tai yra išmatuota — Google ir Kalifornijos universiteto Berklyje tyrime, apėmusiame 760 935 įsilaužimo atvejus nuo 2014 m. liepos iki 2015 m. birželio, 12 % svetainių per 30 dienų buvo nulaužtos pakartotinai, nes buvo pašalinti tik simptomai, o ne priežastis (Li ir kt., WWW 2016).

Todėl pirmasis darbas — pilna kopija, visi failai ir visa duomenų bazė vienu ypu, dar nepalietus nė vieno baito, nes matoma peradresacija ar sugadintas pradžios puslapis retai būna viskas, kas svetainėje vyksta: Sucuri duomenimis, 2023 m. bent vienerios užpakalinės durys (backdoor) rastos 49,21 % užkrėstų svetainių, o per metus jų komanda pašalino 21 062 tokias programas (Sucuri, "2023 Hacked Website & Malware Threat Report", 2024 m. birželis). Kopiją laikykite ne tame pačiame serveryje, nes būtent jame užpuolikas tebeturi prieigą.

Kitas skambutis — prieglobos paslaugų teikėjui, ir ne mandagumo dėlei: jis turi prieigos žurnalus, kuriuose jūsų paskyroje paprastai matyti tik kelios paskutinės dienos, o bendrai naudojamame serveryje jis privalo patikrinti, ar tas pats nevyksta gretimose paskyrose. Jei svetainėje priimami mokėjimai arba įvedami asmens duomenys, ją šiuo momentu reikia išjungti arba įjungti techninės priežiūros režimą — kiekvienas lankytojas, kuris per artimiausią valandą suves kortelės duomenis, yra atskira problema, kurios dar neturite. Techninės priežiūros režimas kainuoja vienos dienos apyvartą; pavėlavimas — laišką klientams.

Jei wp-admin nebeatsidaro — nulaužtoje svetainėje taip nutinka —, techninės priežiūros režimo iš skydelio įjungti nepavyks, ir lieka du keliai: svetainės šakniniame .htaccess faile įrašyti taisyklę, kuri visus, išskyrus jūsų IP adresą, nusiunčia į vieną statinį puslapį su pranešimu apie techninius darbus, arba tame pačiame pokalbyje paprašyti prieglobos įmonės laikinai sustabdyti paskyrą. Antrasis variantas atrodo grubus, bet suveikia ir tada, kai prie failų nebeprieinate.

Vakarykštė atsarginė kopija atrodo kaip greičiausias kelias atgal, ir kartais tai iš tiesų teisingas žingsnis, bet tik tada, kai žinoma, kurią dieną užpuolikas pateko. Mūsų praktikoje užkratą pastebi gerokai vėliau, nei jis prasidėjo — iš pradžių kodas kurį laiką tyli, paskui ima rodyti šlamšto puslapius ar peradresacijas —, o tai reiškia, kad vakarykštėje kopijoje užpakalinės durys greičiausiai jau yra viduje. Atkūrimas tokiu atveju porai valandų paslepia simptomus ir grąžina svetainę būtent į tą būseną, kurioje ji kadaise buvo nulaužta, todėl nulaužtos svetainės atkūrimą paprastai pradedame per kelias valandas ir net skubėdami pradedame nuo kopijos, o ne nuo trynimo, net tada, kai klientas skambina ir prašo tiesiog greitai viską išvalyti.

Požymiai, pagal kuriuos atpažįstama nulaužta WordPress svetainė

Peradresacija, kuri suveikia lankytojui, atėjusiam iš Google rezultato, bet nesuveikia įvedus adresą naršyklės juostoje, nėra nesusipratimas, o sąmoningas užpuoliko pasirinkimas: Google šlamšto politikose peradresacijos atskirai įvardytos kaip nulaužto turinio rūšis, kai užpuolikai įterpia kodą, kuris "dalį naudotojų nukreipia į kenkėjiškus arba šlamšto puslapius" (Google Search Central, tikrinta 2026 m. rugpjūtį). Būtent žodis "dalį" savininką ir klaidina. Patikrinimas užtrunka minutę: atsidarykite svetainę inkognito lange, tada raskite ją Google rezultatuose ir atsidarykite iš ten, o paskui abu kartus pakartokite telefone.

Antra požymių grupė yra administravimo pusėje ir daug konkretesnė: wp-admin staiga grąžina 404, prisijungimo forma po teisingo slaptažodžio tiesiog įkeliama iš naujo, naudotojų sąraše yra administratoriaus paskyra, kurios niekas iš jūsų komandos nekūrė, arba skiltyje Nustatymai → Bendrieji svetainės adresas nebėra jūsiškis. Duomenų bazėje paskutinis iš šių požymių tėra dvi eilutės lentelėje wp_options — siteurl ir home —, ir būtent todėl adresas, kurį matote nustatymuose, ir adresas, į kurį patenka lankytojas, gali skirtis.

Trečia grupė ateina iš šalies ir yra skaudžiausia, nes apie svetainės būklę jums pasako kas nors kitas: prieglobos įmonė be įspėjimo sustabdo paskyrą, iš kurios išėjo šlamštas, Search Console atsiranda įrašas apie saugumo problemą arba paieškos rezultatuose šalia svetainės pasirodo žyma "Ši svetainė gali būti nulaužta" (angl. "This site may be hacked"), kurią Google rodo tada, kai mano, kad užpuolikas pakeitė esamus puslapius arba pridėjo naujų šlamšto puslapių (Google Search Help, tikrinta 2026 m. rugpjūtį). Šią žymą Google prideda pats, o ne pagal kieno nors skundą, ir ji atsiranda net tada, kai svetainė jums pačiam atrodo nepriekaištinga.

Pavadinimai čia nėra akademinis klausimas, nes pagal juos ieškosite sprendimo ir vertinsite, ar rangovas supranta jūsų atvejį: Google savo dokumentacijoje įvardija tris — gibberish hack, Japanese keyword hack ir cloaked keywords and links hack, kai užpuoliko sukurti puslapiai paieškos sistemai rodo vieną turinį, o lankytojui kitą. Tarp specialistų paplitęs pavadinimas "pharma hack" kilo iš saugumo bendrovės Sucuri (2020 m.), o Google dokumentacijoje jo nėra. Praktinis patikrinimas vis dėlto vienodas visiems trims: įveskite paieškoje site: užklausą su savo domenu, ir puslapius, kurių niekas jūsų įmonėje nerašė, pamatysite iš karto. Japoniškame variante tai automatiškai sugeneruoti puslapiai japoniškomis antraštėmis atsitiktinai pavadintuose aplankuose ir su jūsų domenu adrese.

O dabar nemaloni dalis: švarus nuskaitymo rezultatas neįrodo, kad svetainė švari, nes skeneris mato tik tai, ką serveris jam parodo, o užpuoliko kodas dažnai atpažįsta skenerius ir paieškos sistemas; Google savo vadove apie maskuojamų raktažodžių puslapius įspėja, kad įsilaužimas neretai slepiamas taip, jog savininkui atrodytų, kad problema jau praėjo. Jei nuskaitymas švarus, bet prieglobos įmonė skundžiasi išeinančiu paštu, tikėkite prieglobos įmone. Tada laikas svetainės saugumo auditui su rankiniu failų ir žurnalų patikrinimu, nes skeneris atsako į klausimą, ar svetainėje yra kas nors iš žinomų pavyzdžių sąrašo, o ne į tai, ar svetainėje kas nors tebėra.

Kur WordPress rizika iš tikrųjų slypi

Mūsų praktikoje, kai priežastis galiausiai randama, tai beveik niekada nebūna pats WordPress branduolys. Patchstack apžvalgoje "State of WordPress Security in 2026" suskaičiuoti 11 334 nauji pažeidžiamumai, aptikti WordPress ekosistemoje 2025 m. — 42 % daugiau nei metais anksčiau —, ir būtent šių skaičių pasiskirstymas jums dabar svarbus: 91 % jų buvo įskiepiuose, 9 % temose, o pačiame WordPress branduolyje per visus metus pranešta tik apie šešis, be to, visi buvo žemo prioriteto. Vadinasi, beveik kiekvienas naujai aptiktas pažeidžiamumas yra ne tame WordPress, kurį kadaise įdiegėte, o tame, kas prie jo bėgant metams buvo prikabinta.

Kiekvienas įskiepis yra atskira kodo bazė, kurią rašo atskiras autorius su atskira — ir gana dažnai jau nutraukta — atnaujinimo disciplina, todėl svetainė su keturiasdešimčia įskiepių nėra svetainė su vienu saugumo klausimu, o svetainė su keturiasdešimčia tarpusavyje nepriklausomų saugumo klausimų. Mūsų praktikoje tipinei įmonės svetainei visiškai užtenka dešimties–penkiolikos įskiepių, o likusieji ten paprastai liko nuo seniai pamirštų užduočių: galerijos, kuri nebėra rodoma, formos, pakeistos kita, slankiklio, kurio dabartinis dizainas nebenaudoja. Kai perimame WordPress svetainių kūrimą ir priežiūrą, įskiepių skaičiaus mažinimas yra pirmas darbas, o ne paskutinis.

Ir štai klaida, kuri kartojasi dažniau už bet kurią kitą: nereikalingas įskiepis išjungiamas, o ne ištrinamas — išjungimas pasako WordPress, kad jo nebeįkeltų, tačiau failai lieka serveryje savo vietoje, dalis jų tebepasiekiama tiesiogiai per HTTP, o užpuoliko skriptui pakanka žinoti kelią. Wordfence 2021 m. birželį užfiksavo aktyviai naudojamą nulinės dienos pažeidžiamumą įskiepyje Fancy Product Designer, kuris "kai kuriose konfigūracijose išnaudojamas net ir tada, kai įskiepis išjungtas", ir patarė jį ne išjungti, o visiškai pašalinti. Jei įskiepio jums nebereikia, jo vieta yra ne įskiepių sąraše pilkomis raidėmis, o už serverio ribų.

Kodėl visa tai vyksta automatiškai ir be jokios asmeninės priežasties, paaiškina mastas: W3Techs duomenimis, 2026 m. rugpjūčio 5 d. WordPress pagrindu veikia 41,2 % visų žiniatinklio svetainių. Tokio dydžio ekosistemoje kiekvienas paskelbtas įskiepio pažeidžiamumas iš karto panaudojamas prieš labai didelį skaičių vienodos sandaros svetainių, todėl atakas apsimoka automatizuoti, o ne nukreipti į konkretų taikinį — skriptas peržiūri versijų numerius, o ne įmonių pavadinimus. Niekas nepasirinko būtent jūsų svetainės, ir kaip tik todėl nedidelė reprezentacinė svetainė be klientų duomenų ir be mokėjimų nulaužiama taip pat ramiai kaip didelė el. parduotuvė.

Kur užpuolikas slepia kodą WordPress diegime

Pirmoji vieta, kurią atveriame, yra wp-content/uploads — aplankas, kuriame iš esmės guli tik paveikslėliai, PDF failai ir vaizdo įrašai ir kuriame niekada neturėtų būti vykdomas nė vienas PHP failas. Jei ten tarp 2019 m. produktų nuotraukų guli failas su plėtiniu .php, jis atsidūrė ne atsitiktinai: beveik visada tai arba įkėlimo skriptas, kuriuo užpuolikas atsigabena į serverį kitus failus, arba apvalkalas (web shell), leidžiantis vykdyti komandas jūsų serverio vardu. Kad problema reali, o ne teorinė, matyti jau iš to, kad ir Sucuri, ir Wordfence siūlo atskirą saugumo stiprinimo nustatymą, kuris .htaccess taisykle išjungia PHP variklį būtent šiame aplanke.

Antra vieta — wp-content/mu-plugins. Ten įdėti įskiepiai aktyvuojami automatiškai, jų neįmanoma išjungti iš valdymo skydelio ir — kas šiuo atveju svarbiausia — jie nerodomi įprastame įskiepių sąraše, todėl svetainės savininkas gali mėnesius žiūrėti į tariamai švarų skydelį; Sucuri 2025 m. liepą aprašė būtent tokį atvejį su užpakalinėmis durimis šiame aplanke. Be to, visada tikriname .htaccess tiek šaknyje, tiek poaplankiuose, nes peradresacija, kuri suveikia tik lankytojams iš paieškos sistemos arba tik mobiliuosiuose įrenginiuose, dažniausiai įrašyta būtent ten — ir kaip tik dėl to savo svetainę matote visiškai normalią.

Kodas neretai įrašomas ir į esamų, visiškai teisėtų failų pirmąsias eilutes, dažniausiai wp-config.php pradžioje ir temos functions.php faile, ir beveik niekada neatrodo kaip kenkėjiškas kodas: tai viena ilga eilutė su base64_decode, gzinflate ar eval iškvietimu, po kurios eina šimtai tuščių eilučių, kad redaktoriuje atrodytų, jog failas jau baigėsi. Todėl failų palyginimas su švariu originalu vertingesnis už skaitymą akimis: akimis šios eilutės neranda niekas, nes niekas neslenka žemyn iki devynšimtosios failo eilutės.

Ir dar yra duomenų bazė, į kurią failų skeneris nežiūri ir kurioje tikrintinos trys vietos: wp_options eilutės siteurl ir home, kurias užpuolikas perrašo, kad jūsų puslapio ištekliai būtų įkeliami iš svetimo serverio; lentelė wp_users, kurioje neretai atsiranda administratoriaus paskyra patikimai skambančiu vardu; ir įrašų turinys wp_posts, kur paslėptos nuorodos ir iframe kodai įterpiami senų straipsnių viduryje, kurių niekas nebeatidaro. Jei failai išvalomi, o injekcija duomenų bazėje lieka, užkratas grįžta tą pačią dieną. Pati eilutė savaime neįvykdoma — kiekvieno įkėlimo metu ją nuskaito ir paleidžia nedidelis paleidiklis temos functions.php faile arba mu-plugins aplanke —, ir būtent ši pora atkuria ištrintus failus greičiau, nei spėjate patikrinti rezultatą. Kaip tik todėl nulaužtos svetainės atkūrime failų ir duomenų bazės valymas mums yra vienas darbas, o ne du.

Failų palyginimas su patikrintais originalais

Pirmas įrankis, kurio imamės po to, kai pilna failų ir duomenų bazės kopija jau padaryta, yra wp core verify-checksums: ši komanda palygina kiekvieno failo maišos reikšmę su WordPress.org paskelbtomis kontrolinėmis sumomis ir iškart parodo, kurie failai pakeisti ir kurių diegime apskritai neturėtų būti. Problema prasideda ten, kur baigiasi jos aprėptis — komanda tikrina tik wp-admin/, wp-includes/ ir šakninius wp-* failus, o visą wp-content aplanką, taigi įskiepius, temas ir įkeltus failus, pirminis kodas sąmoningai praleidžia (WP-CLI checksum-command pirminis kodas, žiūrėta 2026 m. rugpjūčio 5 d.). Vieną šakninį failą tas pats pirminis kodas praleidžia atskirai — wp-config.php —, todėl failas, į kurio pirmąsias eilutes kodas įrašomas dažniausiai, šiam patikrinimui nematomas. Švarus komandos rezultatas nereiškia švarios svetainės.

Įskiepiams yra atskira komanda wp plugin verify-checksums, tačiau ir ji lygina failus tik su WordPress.org saugyklos kontrolinėmis sumomis, todėl komercinis įskiepis, pirktas tiesiai iš kūrėjo, patikroje paprasčiausiai praleidžiamas; temoms lygiavertės komandos WP-CLI dokumentacijoje nėra apskritai (WP-CLI dokumentacija, žiūrėta 2026 m. rugpjūčio 5 d.). Automatiniam patikrinimui tad nepasiduoda nei temos, nei už saugyklos ribų įsigyti įskiepiai, o wp core verify-checksums praleidžia visą wp-content — tą kodo dalį, kurioje atsirado visi 11 334 Patchstack 2025 m. suskaičiuoti pažeidžiamumai, išskyrus branduolio šešis. Svetainėse, kurias perimame, būtent tema neretai būna vienintelė, kurios niekas niekada netikrino.

Mūsų praktikoje kontrolinės sumos todėl yra atskaitos taškas, o ne metodas: branduolio ir įskiepių negydome, o pakeičiame, tai yra atsisiunčiame tas pačias versijas iš originalaus šaltinio ir perrašome aplankus visiškai, o ne po vieną failą. Iš senojo diegimo pasiliekame wp-content/uploads, ir tik patikrinę, ar tarp paveikslėlių nėra PHP failų — dėl tos pačios priežasties, dėl kurios PHP variklį šiame aplanke apskritai verta išjungti. Temą atkuriame iš versijų kontrolės, jei tokia yra; jei ne, imame kūrėjo pateiktą kopiją ir pritaikymus dedame ant viršaus sąmoningai, po vieną, nes tik taip vėliau galima pasakyti, kuri eilutė svetainėje yra mūsų, o kuri ne.

Surasti ir ištrinti blogąją eilutę atrodo pigiau, ir kaip tik todėl tai dažniausiai kartojama klaida: užpuolikas retai palieka vieną įėjimą, o vienerios nepastebėtos užpakalinės durys visą kitą darbą paverčia bergždžiu. Kodas neretai išskaidytas į kelis failus, paslėptas už base64 ar gzinflate iškvietimo, įrašytas į duomenų bazės parinkčių lentelę arba įdėtas į tą patį mu-plugins aplanką, kurio valdymo skydelis nerodo. Paieška pagal pavyzdį randa tai, ką jau pažįstate; visiškas pakeitimas pašalina ir tai, ko nepažįstate.

Yra ir darbas, kurio šiame etape nedarome: nepasikliaujame įskiepiu, siūlančiu užkrėstus failus "išgydyti" vienu mygtuku, nes jis dirba su tuo pačiu žinomų pavyzdžių sąrašu ir dar toje pačioje aplinkoje, kurioje užpuolikas tebeturi prieigą. Nelyginame failų ranka ir tada, kai svetainė yra įprastos vizitinės kortelės ar tinklaraščio apimties, nes švarus diegimas su perkeltu turiniu užima mažiau valandų nei dviejų katalogų lyginimas eilutė po eilutės, o rezultatas yra patikrinamas. Kruopštus rankinis lyginimas pateisinamas ten, kur tema ar įskiepis unikalus, o versijų kontrolės nėra; kaip elgtis su atsarginėmis kopijomis, kad šis pasirinkimas apskritai egzistuotų, aprašėme bendrajame atkūrimo vadove.

Raktai, seansai ir slaptažodžiai: kas ką iš tikrųjų daro

Autentifikacijos raktai ir salts (security keys and salts) wp-config.php faile nieko nešifruoja, nors taip tvirtina bene kiekvienas vadovas: WordPress jais remiasi kaip pagrindu raktui, kuriuo funkcija wp_generate_auth_cookie() HMAC-SHA256 algoritmu pasirašo autentifikacijos slapuką, o pats slapukas yra atviras tekstas su naudotojo vardu, galiojimo laiku ir seanso žetonu (WordPress Developer Resources, žiūrėta 2026 m. rugpjūčio 5 d.). Todėl pakeitus šias reikšmes kiekvienas anksčiau išduotas parašas tampa nepatikrinamas ir serveris atmeta bet kurį iki šiol išduotą slapuką, net jei pats seansas formaliai dar nesibaigė.

Praktinis padarinys yra būtent tas, kurio įsilaužimo akimirką ir reikia: oficiali WordPress dokumentacija raktų keitimą aprašo kaip būdą išmesti lauk kiekvieną, kuris dar galėtų būti prisijungęs (WordPress.org, "FAQ My site was hacked", atnaujinta 2026 m. liepos 26 d.), taigi, jei užpuolikas laiko rankose galiojantį seansą, jis baigiasi tą pačią akimirką. Kartu su seansais nustoja galioti ir visi išduoti nonce žetonai, todėl pradėtos formos ir pusiaukelėje likę užsakymų žingsniai tuo metu nutrūksta — keitimo momentą renkamės sąmoningai, o ne atsitiktinai darbo dienos viduryje.

Raktų ir salts keitimas nepakeičia nė vieno slaptažodžio. Slaptažodžių maišos reikšmes WordPress skaičiuoja bcrypt algoritmu, kiekvienam slaptažodžiui priskirdamas atskirą atsitiktinį salt, kuris su wp-config.php konstantomis nesusijęs (funkcija wp_hash_password(); bcrypt pagal numatytuosius nustatymus nuo WordPress 6.8), todėl užpuolikas, žinantis administratoriaus slaptažodį arba spėjęs susikurti paskyrą, po raktų keitimo tiesiog prisijungia iš naujo. Slaptažodžius reikia keisti atskirai ir visus, taip pat ir tuos, kurių neva niekas nežino, o kartu peržiūrėti naudotojų sąrašą ieškant paskyrų, kurių niekas iš jūsų komandos nekūrė.

Su WordPress prisijungimo duomenų sąrašas nesibaigia: vienu ypu keistinas prieglobos valdymo skydelio slaptažodis, FTP ir SFTP prisijungimo duomenys, duomenų bazės naudotojo slaptažodis kartu su atitinkamu įrašu wp-config.php, taip pat SSH raktai, kurie ne keičiami slaptažodžio principu, o generuojami iš naujo, iš serverio failo authorized_keys ištrinant seną viešąjį raktą. Galiausiai keistini visi svetainėje saugomi API raktai — mokėjimų vartų, el. laiškų siuntimo paslaugos, pristatymo ir buhalterijos integracijų —, nes jie paprastai lieka nepaliesti ilgiausiai: kasdien jų niekas nemato jokiame ekrane.

Laikykite, kad užpuolikas turi pilną duomenų bazės kopiją, nes tai pigiausias žingsnis visoje atakoje: visą jos turinį — klientų el. pašto adresus, užsakymų istoriją, slaptažodžių maišos reikšmes ir įskiepių nustatymuose įrašytus raktus — nuo šiol reikia vertinti kaip patekusį į svetimas rankas. Jei kuris nors iš tų slaptažodžių naudotas dar kur nors, ir ta vieta yra kompromituota, ir paprastai būtent tada pokalbis nuo svetainės pereina prie el. pašto paskyrų, buhalterinės sistemos ir parduotuvės mokėjimų paskyros.

Eiliškumas čia toks pat svarbus kaip ir pats sąrašas: raktai ir slaptažodžiai keistini po to, kai užpakalinės durys jau pašalintos, nes priešingu atveju užpuolikas naujas reikšmes perskaito ten pat, wp-config.php faile, arba tiesiog perima kitą prisijungimą. Būtent ši seka — pirmiausia pilna kopija, tada priežastis, tada valymas ir tik pačiame gale prisijungimo duomenys — yra ta vieta, kur savo jėgomis pradėtas atkūrimas dažniausiai sustoja arba susipainioja, todėl šio etapo imamės patys, o pabaigoje pateikiame rašytinę ataskaitą apie tai, kas buvo pakeista, kada ir kodėl.

Kaip pasiekti, kad Google įspėjimas dingtų, ir ką daryti paskui

Google Search Console skiltis "Saugumo problemos" (Security Issues) yra vienintelė vieta, kur galima pamatyti, ką būtent Google jūsų svetainėje rado: ten nurodyta grėsmės rūšis ir konkrečių paveiktų puslapių pavyzdys, o nuo to priklauso ir tai, ką šiuo metu mato lankytojas. Grėsmės rūšis nekeičia to, ką mato lankytojas: Chrome nebesirenka įspėjimo antraštės pagal tai, ar aptiktas sukčiavimas, kenkėjiška ar nepageidaujama programinė įranga, bet visais atvejais rodo tą patį viso ekrano įspėjimą — lietuviškai "Pavojinga svetainė" — ir taip žmogaus į svetainę tiesiog neįleidžia, o jau minėta žyma "Ši svetainė gali būti nulaužta" paieškos rezultatuose tėra užrašas šalia nuorodos, pro kurį galima praspausti (Google Chrome pagalbos puslapis apie pavojingas svetaines, tikrintas 2026 m. rugpjūtį). Senesnių, pagal grėsmės rūšį besiskyrusių antraščių — pavyzdžiui, "Deceptive site ahead" — Chrome nebenaudoja, nors jų vis dar galima rasti dalyje Google dokumentacijos. Pirmasis blokuoja, antrasis įspėja, ir tai keičia, kiek laiko iš tikrųjų turite.

Prieš spaudžiant mygtuką "Prašyti peržiūros" (Request Review), reikia įsitikinti, kad svetainė iš tiesų švari, o ne tik atrodo švari jūsų naršyklėje. Google savo vadove apie cloaked keywords hack tiesiogiai įspėja, kad užpuolikai stengiasi sudaryti įspūdį, jog puslapis jau ištrintas arba sutaisytas, todėl kiekvieną buvusį šlamšto puslapį reikia patikrinti URL patikros įrankiu, kuris rodo Googlebot vaizdą, o ne jūsiškį. Antras žingsnis, praleidžiamas dažniausiai, yra savininkų sąrašas: per Japanese keyword hack užpuolikas prideda save kaip patvirtintą Search Console savininką (Google dokumentacija svetainėje web.dev), ir tol, kol jis iš to sąrašo neišbrauktas, apie svetainės būklę jis žino lygiai tiek pat, kiek jūs.

Ieškomas mygtukas yra "Prašyti peržiūros" saugumo problemų ataskaitoje, o ne "pakartotinio svarstymo prašymas" (reconsideration request), kurį Google taiko rankiniams veiksmams, ir prašymo tekste verta parašyti tris dalykus: kas buvo rasta, kaip užpuolikas pateko ir kas konkrečiai padaryta, kad tai būtų pašalinta. Termino nežadame, nes jo nežada ir Google: jos dokumentacijos puslapis apie socialinę inžineriją sako, kad peržiūra "gali užtrukti kelias dienas", o Search Console pagalbos puslapis apie saugumo problemas rašo "nuo kelių dienų iki kelių savaičių" (abu tikrinti 2026 m. rugpjūtį). Jei kas nors jums įvardija konkrečias 24 ar 72 valandas, jis kartoja skaičių, kurio nėra nė viename Google šaltinyje.

Skubėjimas šiame žingsnyje kainuoja brangiau nei laukimas. Tame pačiame Google ir Kalifornijos universiteto Berklyje tyrime 80 % svetainių savininkų pasiekė, kad svetainė būtų pripažinta švaria, jau per pirmąjį bandymą, o likusiems 20 % prireikė kelių bandymų, ir laiko, kurį jie praleido peršukuodami užpuoliko paliktą kodą, mediana siekė visą savaitę. Duomenys yra iš 2014–2015 m. ir taip juos ir reikia skaityti, tačiau aritmetika nepasikeitė: atmestas prašymas reiškia, kad įspėjimas lieka dar vienam ciklui, o antrą prašymą teikiate jau ne nuo švaraus lapo.

Panaikinus įspėjimą darbas dar nebaigtas, nes indekse lieka užpuoliko sukurti puslapiai, ir jų negalima peradresuoti į pradžios puslapį — jie turi grąžinti 404 arba 410, kad Google juos išimtų visiškai, o Search Console šalinimo įrankis juos tik laikinai paslepia. Pozicijos negrįžta pasukus jungiklį: puslapius reikia indeksuoti iš naujo, ir tai vyksta Google, o ne jūsų tempu. Kaip šiame etape panaudoti žurnalo failus ir atsargines kopijas, kad kitą kartą atskaitos taškas būtų geresnis, aprašėme atskirame vadove apie nulaužtų svetainių atkūrimą.

Kada liautis daryti pačiam ir kiek tai kainuoja

Dalį to, kas čia aprašyta, patyręs svetainės savininkas padaro pats, ir mes tai be užuolankų sakome ir žmonėms, kurie mums skambina su atidaryta Search Console ir jau rastu kaltu įskiepiu. Jei užkratas yra vienas sugadintas pradžios puslapis, jei žurnalo failuose matyti, kuris įskiepis jį įleido, jei naudotojų sąraše nėra svetimų administratorių ir jei yra vakarykštė atsarginė kopija, kurią kadaise iš tikrųjų atkūrėte testinėje aplinkoje, tai aštuonios apmokamos valandos jums nupirks ramesnį miegą, o ne greitesnį rezultatą.

Yra keturios situacijos, kuriose patariame sustoti, ir pirmoji — pakartotinis užkrėtimas po valymo: jei svetainė nulaužiama antrą kartą, tai ne nesėkmės klausimas, o įrodymas, kad įsilaužimo taškas tebėra atviras, ir trečias valymas toje pačioje aplinkoje kainuos lygiai tiek, kiek pirmieji du. Antroji — bet koks įtarimo šešėlis dėl klientų ar mokėjimų duomenų, nes ten šalia techninio darbo atsiranda ir pareigos priežiūros institucijai bei terminai, kurių gera valia pratęsti negalima. Trečioji — svetainė, iš kurios įmonė uždirba kiekvieną dieną, o ketvirtoji — paprasčiausias laiko trūkumas: valymas nėra intelektualiai sudėtingas, bet jis ilgas, monotoniškas ir neatleidžia nė vieno praleisto failo.

Mūsų nulaužtų svetainių atkūrimas kainuoja 90 € per valandą be PVM, taikant aštuonių darbo valandų minimumą, kuris apmokamas iš anksto. Darbą paprastai pradedame per kelias valandas nuo užklausos, o visas procesas nuo pradžios iki perdavimo paprastai trunka 8–72 valandas, be to, skirtumą tarp aštuonių ir septyniasdešimt dviejų valandų beveik visada lemia tai, kaip giliai užpuolikas spėjo įsikurti ir kokia sena yra paskutinė švari kopija. Minimumas nėra rinkodaros skaičius: pilna kopija, priežasties paieška žurnalo failuose, valymas ir patikra per trumpesnį laiką telpa retai.

Tvarka ta pati, kuri aprašyta aukščiau, tik be jūsų savaitgalio. Prieš ką nors paliesdami, pasidarome pilną failų ir duomenų bazės kopiją, kad incidentą vėliau apskritai būtų įmanoma tirti, ir tik tada svetainė izoliuojama; toliau ji išvaloma nuo kenkėjiškos programinės įrangos ir užpakalinių durų, duomenų bazė patikrinama, prisijungimo duomenys ir raktai pakeičiami, surandama ir uždaroma įsilaužimo priežastis, pateikiamas prašymas Google peržiūrai ir nustatoma stebėsena, o pabaigoje gaunate rašytinę ataskaitą apie tai, kas įvyko ir kas buvo pakeista. Jei svetainė šiuo metu neveikia arba nesate tikras dėl to, ką matote, galite užsakyti skubią svetainės patikrą, ir mes pasakysime, ar čia apskritai yra už ką mokėti.

Daugeliu atvejų tikrasis atsakymas vis dėlto yra ne atkūrimas, o tai, kas vyksta po jo: jei svetainė sukaupė dvidešimt įskiepių, kurių pusei niekas nebeprisimena priežasties, tai problema yra priežiūroje, ir ją sprendžia WordPress kūrimas ir priežiūra, o ne dar vienas valymo ciklas po pusmečio. Pigiausia valanda visoje šioje istorijoje yra ta, kuri išleista iš anksto: nenaudojamo įskiepio ištrynimas iš wp-content/plugins, o ne jo išjungimas, ir atsarginė kopija, kurią kas nors kartą iš tiesų atkūrė testinėje aplinkoje, kartu kainuoja mažiau nei viena mūsų darbo diena.