PHP2Shell nulaužė serverį? Skambinkite. Padėsime.

Trumpai: Jei įtariate, kad jūsų serveris buvo nulaužtas per PHP2Shell, susisiekite dabar. Ar tai jus palietė? Skambinkite. Padėsime. Nuo pirmos žinutės perimame incidento suvaldymą, išsaugome pėdsakus, uždarome spragą, pašaliname kenkėjišką kodą ir dokumentuojame incidentą iki jo pabaigos.

Ar tai jus palietė? Požymiai, kad PHP2Shell jau išnaudotas

PHP2Shell yra dviejų kritinių pačiame PHP spragų pavadinimas, kuriomis užpuolikai be prisijungimo gali nuotoliu vykdyti kenkėjišką kodą. Vienareikšmio pirštų atspaudo kol kas nėra. Todėl svarbu tai, ką daro serveris, o ne tai, ką randa skaitytuvas. Įsilaužimo požymiai:

• Žiniatinklio serverio ar PHP-FPM procesai, paleidžiantys shell, pavyzdžiui, sh ar bash. Tai stiprus perspėjimo ženklas.
• Nauji ar pakeisti PHP failai įkėlimų, talpyklos ar laikinuosiuose aplankuose, kurių niekas nesukūrė.
• Cron užduotys, tarnybos ar SSH raktai, kurių nepažįstate.
• Išeinantys ryšiai į nežinomus adresus, staiga didelė apkrova ar neįprastas duomenų srautas.
• Užklausos žurnaluose nuo 2026 m. spalio 17 d., ypač įtartini įkėlimai ir sesijų užklausos prieš įdiegiant pataisą.
• Hostingo teikėjo, naršyklės ar paieškos sistemos pranešimai apie šlamštą, kenkėjišką programinę įrangą ar peradresavimus.

Daugiau rasite skyriuje Ar jau esu kompromituotas?. Jei nė vieno požymio nėra, tai dar neįrodo, kad serveris švarus. Tai tik reiškia, kad kol kas nieko nepastebėta.

Ką daryti nedelsiant

1. Nieko nekeiskite. Netrinkite failų, neatkurkite atsarginės kopijos, neįrenkite iš naujo, kol nieko neišsaugota.
2. Išsaugokite žurnalus. Paprašykite hostingo teikėjo ar savo IT neperrašyti prieigos, klaidų ir sistemos žurnalų. Specializuota spauda pataria saugoti žurnalus nuo 2026 m. spalio 20 d.
3. Nuspręskite dėl pasiekiamumo. Jei gali nutekėti duomenys ar būti pavojuje lankytojai, išjunkite svetainę arba įjunkite priežiūros režimą.
4. Surinkite prieigas. Užsirašykite, kas turi prieigą prie serverio, valdymo skydelio, CMS ir duomenų bazės. Slaptažodžius keiskite tik pasitarę ir iš švaraus įrenginio.
5. Informuokite žmones. Vadovybę, duomenų apsaugos pareigūną, o jei turite polisą, ir draudiką.
6. Paskambinkite arba parašykite mums. Kuo anksčiau žinosime padėtį, tuo daugiau bus galima įrodyti.

Kaip PHP SOS padeda konkrečiai?

Dirbame nuotoliu, be atvykimo, visoje Vokietijoje ir Europoje.

1. Įvertiname padėtį: išsiaiškiname, kokios sistemos veikia, koks PHP veikimo režimas naudojamas, kas buvo pastebėta ir kokie duomenys galėjo būti paveikti.
2. Išsaugome ir uždarome: išsaugome failus, duomenų bazę ir žurnalus bei užfiksuojame būseną prieš bet kokį pakeitimą. Po to spragą uždarome pataisa arba, jei jos dar neįmanoma įdiegti, pereinamosiomis priemonėmis, ir iš naujo paleidžiame visus PHP procesus.
3. Tikriname ir valome: ieškome webshell, užpakalinių durų, cron užduočių ir svetimų prieigų ir jas pašaliname arba atstatome būseną iš patikimų šaltinių. Eigą aprašo Kenkėjiškos programinės įrangos ir webshell šalinimas.
4. Sutvirtiname ir pateikiame ataskaitą: pakeičiame paveiktas paslaptis, papildome apsaugos priemones ir pateikiame ataskaitą, kurioje atskirta, kas įrodyta, kas tikėtina ir kas nežinoma.

Jei incidentas išauga už vieno serverio ribų, pereiname prie struktūruoto incidentų valdymo (Incident Response). Jei reikia įrodymų, kurie išlaikytų teisme, pasitelkiame IT forensiką.

Kodėl po atakos vien pataisos nepakanka

Spragos yra PHP interpretatoriuje, o ne CMS. PHP projektas 2026 m. spalio 21 d. išleido versijas 8.5.12, 8.4.27, 8.3.36 ir 8.2.35. Kas po to atnaujino ir iš naujo paleido visus darbinius procesus (worker), nuo naujų atakų šiuo keliu apsaugotas. Tačiau tai, ką užpuolikas paliko anksčiau, lieka: webshell, papildoma paskyra, suplanuota užduotis. Būtent todėl dienos nuo spalio 17 iki 21 d. yra ypač svarbios.

Yra ir antras dalykas: webshell dažnai yra tik pirmas žingsnis. Kas galėjo vykdyti kodą žiniatinklio serveryje, galėjo skaityti ir konfigūracijos failus bei iš jų perimti duomenų bazės, pašto ir API prieigas. Šias paslaptis reikia pakeisti, kitaip durys lieka atviros, nors PHP pataisytas. Kaip protingai tikrinti failus ir laiką, aprašo vadovas apie webshell atpažinimą.

Pranešimo pareiga ir dokumentavimas

Jei galėjo būti paveikti asmens duomenys, gali tekti per 72 valandas pranešti priežiūros institucijai. Laikas teka nuo sužinojimo, o ne nuo tyrimo pabaigos. Ar jūsų atvejis reikalauja pranešimo, sprendžia duomenų apsaugos pareigūnas ar teisininkas; teisinių konsultacijų neteikiame. Mūsų dokumentacija tam suteikia pagrindą. Daugiau apie terminą rasite skyriuje BDAR pranešimo pareiga per 72 valandas, o tolesnius žingsnius kontroliniame sąraše po įsilaužimo.

Ką mums atsiųsti

• Aprašymas, kas ir nuo kada kelia įtarimą ir kas tai pastebėjo
• Serverio tipas: nuosavas serveris, valdomas serveris (managed server) ar hostingo paketas, taip pat hostingo teikėjas
• php -v rezultatas ir, jei žinoma, veikimo režimas (PHP-FPM, mod_php, LiteSpeed)
• PHP atnaujinimo laikas, jei jau įdiegtas
• Prieiga prie serverio arba leidimas kalbėtis su jūsų hostingo teikėju
• Kontaktinis asmuo, galintis priimti sprendimus dėl išjungimo ir paleidimo iš naujo

Kodėl PHP SOS

Dirbame Made in Germany ir kartu su savo kibernetinių specialistų partnerių tinklu daugiau nei 25 metus specializuojamės IT saugumo srityje. Turite vieną kontaktinį asmenį, kuris lydi jus nuo pirmos žinutės iki pabaigos. Viskas, ką darome, dokumentuojama, kad galėtumėte tai pagrįsti vadovybei, draudikui ir institucijoms. Nežadame to, ko niekas negali pažadėti: jei žurnalų trūksta, tai sakome atvirai ir įvardijame, kas įrodyta, o kas lieka prielaida.

Ar tai jus palietė? Skambinkite. Padėsime.

Nelaukite, kol įtarimas taps tikrumu. Paskambinkite arba parašykite per WhatsApp. Perimame darbą nuo pirmos žinutės ir pasiliekame, kol incidentas bus užbaigtas ir dokumentuotas. Pranešti apie avariją dabar.

Dažni klausimai

Šaltiniai

• BSI (Vokietijos federalinė informacijos saugumo tarnyba)
• php.net: saugumo pranešimai
• BDAR 33 straipsnis: pranešimas priežiūros institucijai