Lyhyesti: Sitä, onko palvelimeen murtauduttu PHP2Shellin kautta, ei voi lukea yksittäisestä tunnusmerkistä. Vahvistettuja, julkaistuja Indicators of Compromise -tunnisteita ei ole; havaitseminen perustuu käyttäytymisanalyysiin. Tyypillisiä merkkejä ovat uudet PHP-tiedostot, tuntemattomat cron-tehtävät ja epätavalliset yhteydet. Turvatkaa ensin lokit 20. lokakuuta alkaen, ennen kuin muutatte mitään.
Onko PHP2Shell-hyökkäyksestä yksiselitteisiä merkkejä?
Ei, ja se on rehellinen vastaus. Moniin tunnettuihin haavoittuvuuksiin valmistajat tai tietoturvayritykset julkaisevat konkreettisia jälkiä: tiedostonimiä, tarkistussummia, IP-osoitteita. PHP2Shellille tällaisia vahvistettuja Indicators of Compromise -tunnisteita ei ole toistaiseksi.
Mitä tiedetään: mediaraporttien mukaan ensimmäinen hyökkäysyritys havaittiin 17. lokakuuta, neljä päivää ennen 21. lokakuuta julkaistuja korjauksia. Cloudflare ilmoitti lisää yrityksiä. Vahvistettuja onnistuneita laajoja hyökkäyksiä ei BSI:n (Saksan liittovaltion tietoturvavirasto) mukaan aluksi tunnettu. Joka oli tavoitettavissa suojaamattomana 17. lokakuuta ja oman korjauksensa välisenä aikana, kannattaa siksi tarkistaa eikä toivoa.
Arvioinnissa ratkaisee ennen kaikkea ajanjakso. Ensimmäisen havaitun hyökkäysyrityksen 17. lokakuuta ja korjausten 21. lokakuuta välillä virallista päivitystä ei ollut. Jokainen julkisesti tavoitettavissa oleva PHP-palvelin oli tuona aikana mahdollinen kohde. Kuinka kauan palvelimenne oli sen jälkeen auki, riippuu siitä, milloin päivitys asennettiin ja PHP käynnistettiin uudelleen. Mitä pidempi ajanjakso ja mitä arkaluonteisempia tiedot, kuten asiakastilit, tilaukset tai hakemukset, sitä perusteellisempi tarkistuksen tulisi olla.
Tyypillisiä merkkejä siitä, että palvelimeen on murtauduttu
Onnistuneen koodin suorittamisen jälkeen hyökkääjät yrittävät yleensä pesiytyä ja käyttää palvelinta. Siitä seuraa merkkejä, jotka eivät ole PHP2Shell-spesifisiä mutta kuuluvat jokaiseen murtotarkistukseen:
- Uudet tai muuttuneet PHP-tiedostot, erityisesti lataus-, välimuisti- tai kuvahakemistoissa, joissa ei muuten ole PHP-tiedostoja.
- Tuntemattomat cron-tehtävät tai ajastetut tehtävät, esimerkiksi verkkopalvelimen käyttäjälle.
- Epätavalliset lähtevät yhteydet tuntemattomiin osoitteisiin, korkea verkkokuormitus tai sähköpostin lähetys, jota kukaan ei ole käynnistänyt.
- Uudet ylläpitäjätilit CMS:ssä tai verkkokaupassa, muutetut salasanat, tuntemattomat SSH-avaimet.
- Poikkeava kuormitus: pysyvästi korkea suorittimen käyttö tuntemattomien prosessien vuoksi, usein vihje kryptolouhinnasta.
- Näkyvät seuraukset: uudelleenohjaukset vieraille sivuille, roskapostisivut Googlen hakemistossa, varoitukset selaimessa tai Search Consolessa.
Mikään näistä merkeistä ei yksinään todista murtoa, eikä niiden puuttuminen todista päinvastaista. Ratkaisevaa on kokonaiskuva.
Ensimmäiset tarkistukset jälkiä tuhoamatta
Ennen kuin poistatte mitään tai käynnistätte uudelleen: turvatkaa lokit. Ammattilehdistö neuvoo säilyttämään palvelinlokit 20. lokakuuta alkaen. Kopioikaa verkkopalvelimen, PHP:n ja järjestelmän lokit turvalliseen paikkaan palvelimen ulkopuolelle.
Sen jälkeen auttavat pelkästään lukevat tarkistukset. Polut ja käyttäjänimet vaihtelevat järjestelmän mukaan:
# PHP-tiedostot, joita on muutettu 17.10. jälkeen
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# PHP-tiedostot latauskansioissa (esimerkki WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# Verkkopalvelimen käyttäjän ja koko järjestelmän cron-tehtävät
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# aktiiviset verkkoyhteydet prosesseineen
ss -tunp
# viimeisimmät kirjautumiset
last -n 30
Huomatkaa: hyökkääjät voivat väärentää tiedostojen aikaleimoja. Siksi find-komennon huomaamaton tulos ei ole vapauttava. Miten analysoitte lokit kohdennetusti, kuvataan sivulla Verkkopalvelimen lokien analysointi hyökkäyksen jälkeen; miten löydätte takaovet, sivulla Web shellien tunnistaminen ja poisto.
Jos löydätte konkreettisia viitteitä, esimerkiksi tuntemattoman PHP-tiedoston latauskansiosta: älkää poistako, älkää asentako uudelleen, älkää „korjatko nopeasti“ sovellusta. Irrottakaa palvelin verkosta tai eristäkää se, turvatkaa lokit ja järjestelmän levykuva ja aloittakaa jäsennelty poikkeaman käsittely.
Mitä ette saa tehdä
- Vain korjata ja jatkaa. Korjaus ei poista jo asennettua haittaohjelmaa.
- Poistaa epäilyttäviä tiedostoja heti. Silloin katoavat todisteet siitä, mitä tapahtui ja mitkä tiedot voivat olla vaarantuneet.
- Asentaa palvelinta uudelleen ennen turvaamista. Syy jää epäselväksi, ja tietokannassa oleva takaovi tai tunnukset selviävät uudelleenasennuksesta.
- Palauttaa vanhoja varmuuskopioita tarkistamatta. Myös varmuuskopio voi jo sisältää takaoven.
- Unohtaa tunnukset. Koodin suorittamisen jälkeen tietokannan salasanat, API-avaimet ja muut tunnukset ovat voineet valua ulos asetustiedostoista. Uusikaa ne puhdistuksen jälkeen, ei ennen, jotta yhä aktiivinen hyökkääjä ei lue uusia samalla.
Kun epäily vahvistuu
Silloin kyse on muustakin kuin tekniikasta. Selvittäkää tietosuojavastaavanne kanssa, tarvitaanko GDPR:n mukainen ilmoitus; määräaika on 72 tuntia tiedon saamisesta, yksityiskohdat sivulla GDPR:n ilmoitusvelvollisuus. Informoikaa kybervakuutuksenantajaa ajoissa, jos sellainen on, ja selvittäkää lakimiehen kanssa, tehdäänkö rikosilmoitus. Annamme siitä yleisiä ohjeita, emme oikeudellista neuvontaa.
Miten PHP SOS auttaa konkreettisesti?
Incident responsellamme käsittelemme epäilyn jäsennellysti:
- Turvaaminen: lokit 20. lokakuuta alkaen ja tarvittaessa järjestelmän levykuva, ennen kuin mitään muutetaan.
- Tutkinta: tiedostojen, prosessien, yhteyksien ja tilien käyttäytymisanalyysi; tarvittaessa oikeuskelpoisesti IT-forensiikalla.
- Puhdistus ja sulkeminen: takaovien poisto, PHP:n päivitys, tunnusten uusiminen, palvelimen koventaminen.
- Dokumentointi, kunnes tapaus on päätetty ja dokumentoitu, perustaksi tietosuojalle, vakuutukselle ja johdolle.
Usein kysytyt kysymykset
Todistaako PHP-päivitys, että palvelimeni on puhdas?
Ei. Korjaus sulkee haavoittuvuuden tulevaisuutta varten mutta ei poista jo asennettua haittaohjelmaa. Se ei myöskään kerro, onko joku päässyt sisään ennen korjausta.
Onko olemassa skanneria, joka havaitsee PHP2Shell-hyökkäykset varmasti?
Toistaiseksi ei. Vahvistettuja, julkaistuja Indicators of Compromise -tunnisteita, joita skanneri voisi kohdennetusti etsiä, ei ole. Haittaohjelmaskannerit löytävät tunnetut web shellit, mutta palvelimen arviointi perustuu käyttäytymisanalyysiin.
Pitääkö epäilystä ilmoittaa tietosuojaviranomaiselle?
Se riippuu siitä, voivatko henkilötiedot olla vaarassa. GDPR säätää ilmoitettaville tietosuojaloukkauksille 72 tunnin määräajan tiedon saamisesta. Selvittäkää asia ajoissa tietosuojavastaavanne tai lakimiehen kanssa; emme anna siitä oikeudellista neuvontaa.
Pitäisikö hakkeroitu palvelin vain asentaa uudelleen?
Ei ensimmäisenä askeleena. Turvatkaa ensin lokit ja, jos mahdollista, järjestelmän levykuva. Joka asentaa heti uudelleen, menettää jäljet, jotka osoittavat, mitä tapahtui ja mitkä tiedot voivat olla vaarantuneet.