Lyhyesti: Web shellin tunnistatte uusista tai muuttuneista PHP-tiedostoista epätyypillisissä paikoissa, verkkopalvelimen käyttäjän vieraista prosesseista ja epätavallisista yhteyksistä. Varmistakaa jäljet ennen kuin poistatte mitään, ja palauttakaa koodi puhtaasta lähteestä. Pelkkä korjaus ei poista takaovea.
Miksi web shellit ovat ajankohtaisia PHP2Shellin jälkeen
PHP:n omat haavoittuvuudet CVE-2026-109618 ja CVE-2026-109619 sallivat haittakoodin suorittamisen etänä ilman kirjautumista. Onnistuneen hyökkäyksen ilmeinen tavoite on pysyvä takaovi eli web shell. Se säilyy, vaikka PHP olisi sillä välin päivitetty.
Mediaraporttien mukaan ensimmäinen hyökkäysyritys havaittiin jo 17.10.2026, ja korjaukset tulivat 21.10. Jos olitte tänä aikana haavoittuvia, katsokaa asiaa kohdennetusti. Vahvistettuja Indicators of Compromise -tunnisteita ei ole toistaiseksi julkaistu. Etsintä perustuu siksi käyttäytymisen poikkeamiin, ei valmiiseen luetteloon.
Jos löydätte web shellin palvelimelta, jolla on asiakastietoja: älkää poistako mitään hätiköiden. Varmistakaa ensin todisteet, eristäkää sitten palvelin ja suunnitelkaa jatkokäsittely.
Miten web shellin tunnistaa: tiedostojen tarkistus
Useimmat web shellit ovat PHP-tiedostoja verkkohakemistossa. Epäilyttäviä ovat tiedostot, jotka ovat syntyneet tai muuttuneet 17.10. jälkeen, PHP-tiedostot upload- ja välimuistikansioissa sekä tiedostot, joissa on hämärrettyä koodia. Seuraavat komennot eivät muuta mitään, ne vain listaavat:
# PHP-tiedostot, jotka on muutettu 17.10.2026 jälkeen
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls
# PHP-tiedostot upload-, välimuisti- tai tmp-kansioissa
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls
# Tyypillinen hämärtäminen: eval yhdistettynä dekoodaukseen
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"
# Epätavallisen pitkät rivit viittaavat usein pakattuun koodiin
grep -rlE ".{3000,}" /var/www --include="*.php"
Osumat ovat vihjeitä, eivät todisteita. Jotkin lisäosat käyttävät laillisesti koodattua koodia. Vertailkaa epäilyttäviä tiedostoja valmistajan alkuperäiseen pakettiin. Luotettavinta on vertailu tarkistussummiin tai versionhallintajärjestelmään kuten Gitiin:
# Poikkeamat viimeiseen tunnettuun tilaan Git-repositoriossa
git -C /var/www/projekt status --porcelain
Aikaleima voi olla väärennetty. Älkää siksi luottako pelkkään tiedoston muutospäivään.
Mitkä piirteet tekevät tiedostosta epäilyttävän
| Piirre | Miksi se herättää huomiota |
|---|---|
| PHP-tiedosto upload- tai kuvakansiossa | Siellä pitäisi olla vain mediaa |
Kaksoispääte kuten .jpg.php tai .php.png |
Naamioituminen harmittomaksi tiedostoksi |
| Hyvin pitkiä rivejä ilman rivinvaihtoa | Tyypillistä pakatulle tai salatulle koodille |
| Tiedostonimi muistuttaa ydintiedostoa, mutta ei ole alkuperäisessä paketissa | Naamioituminen tutussa ympäristössä |
| Omistaja tai oikeudet poikkeavat viereisistä tiedostoista | Tiedosto on luotu toista kautta |
Mitä useampi piirre täyttyy, sitä todennäköisempi löytö on. Avatkaa epäilyttävät tiedostot vain tekstinä, älkää koskaan selaimen kautta, sillä kutsu verkkosivuston kautta suorittaisi koodin.
Prosessien, yhteyksien ja cron-tehtävien tarkistus
Aktiivinen web shell jättää usein jälkiä tiedostojärjestelmän ulkopuolelle. Verkkopalvelimen käyttäjä, esimerkiksi www-data, apache tai nginx, ei tavallisesti käynnistä komentotulkkeja, verkkotyökaluja tai kääntäjiä.
# Tyypillisten verkkopalvelinkäyttäjien prosessit
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"
# Avoimet verkkoyhteydet ja niihin kuuluva prosessi
sudo ss -tunap | grep -E "php|www-data|apache|nginx"
# Verkkopalvelinkäyttäjän ajastetut tehtävät
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
Epäilyttäviä ovat pysyvät lähtevät yhteydet tuntemattomiin kohteisiin, kryptisillä nimillä varustetut prosessit ja cron-tehtävät, jotka lataavat tiedostoja internetistä. Tarkistakaa lisäksi pääsylokeista pyynnöt tiedostoihin, joita ei aiemmin ollut. Miten se tehdään, kuvaa opas Verkkopalvelimen lokien analysointi hyökkäyksen jälkeen.
Varmistakaa jäljet ennen poistamista
Joka poistaa ensin, menettää vastaukset tärkeimpiin kysymyksiin: miten hyökkääjä pääsi sisään, mitä hän näki, mitkä tiedot ovat vaarantuneet? Näitä vastauksia tarvitsette mahdolliseen GDPR-ilmoitukseen, vakuutusyhtiölle ja päätökseen siitä, ovatko muut järjestelmät vaarassa.
Järkevä järjestys:
- Dokumentoikaa tila: prosessilista, verkkoyhteydet, kirjautuneet käyttäjät.
- Kopioikaa epäilyttävät tiedostot ja lokit tarkistussummin avaamatta tai suorittamatta niitä.
- Luokaa mahdollisuuksien mukaan järjestelmän levykuva tai virtuaalikoneen tilannekuva.
- Irrottakaa palvelin verkosta tai rajoittakaa pääsy voimakkaasti.
Järjestelmissä, joissa on arkaluonteisia tietoja tai mahdollinen oikeusriita, varmistus on tehtävä forensisesti oikein. Taustatietoa löydätte sivulta IT-forensiikka verkkopalvelinhyökkäyksen jälkeen.
Web shellien asianmukainen poistaminen
Yksittäisen tiedoston poistaminen on harvoin loppu. Hyökkääjät luovat usein useita pääsyreittejä: lisää tiedostoja piilopaikkoihin, merkintöjä asetustiedostoihin kuten .htaccess tai .user.ini, uusia ylläpitäjätilejä sovellukseen tai cron-tehtäviä. Luotettava puhdistus noudattaa näitä vaiheita:
- Viekää PHP korjattuun tilaan (8.5.12, 8.4.27, 8.3.36, 8.2.35 tai vahvistettu backport) ja käynnistäkää kaikki PHP-prosessit uudelleen.
- Asentakaa sovelluskoodi uudelleen puhtaasta lähteestä sen sijaan, että korjaisitte yksittäisiä tiedostoja.
- Ottakaa mukaan vain tarkistettua sisältöä, kuten uploadit ja tietokanta, ja etsikää niistä kohdennetusti lisättyä koodia.
- Vaihtakaa kaikki tunnukset: tietokanta, SSH, FTP, ylläpitäjätilit, API-avaimet.
- Rajoittakaa verkkopalvelimen kirjoitusoikeudet välttämättömään ja estäkää PHP:n suoritus upload-kansioissa.
WordPressillä on omat tyypilliset piilopaikkansa, jotka kuvataan oppaassa Takaovien löytäminen WordPressistä. Sen jälkeen verkkosivustoa kannattaa valvoa tavallista tarkemmin jonkin aikaa, jotta uusi pääsy huomataan ajoissa.
Miten PHP SOS auttaa konkreettisesti?
- Varmistamme lokit, tiedostot ja järjestelmän tilan jäljitettävästi, ennen kuin mitään muutetaan.
- Etsimme takaovia tiedostoista, tietokannasta, cron-tehtävistä ja asetuksista ja arvioimme löydöt.
- Asennamme sovelluksen uudelleen puhtaasta lähteestä, vaihdamme tunnukset ja koventamme palvelimen.
- Dokumentoimme tapauksen sen päättymiseen asti pohjaksi ilmoituksille ja vakuutusyhtiölle.
Puhdistuksen kulun kuvaa palvelu Haittaohjelmien ja web shellien poisto.
Usein kysytyt kysymykset
Mikä on web shell?
Web shell on palvelimelle lisätty tiedosto, yleensä PHP-tiedosto, jonka kautta hyökkääjät voivat ohjata palvelinta etänä. Se naamioituu usein harmittomaksi tiedostoksi huomaamattomalla nimellä ja pysyy aktiivisena myös päivityksen jälkeen.
Löytääkö virustorjuntaohjelma jokaisen web shellin?
Ei. Skannerit tunnistavat tunnetut mallit, uudet tai voimakkaasti hämärretyt muunnelmat livahtavat läpi. PHP2Shellistä ei lisäksi ole julkaistu vahvistettuja Indicators of Compromise -tunnisteita, joten käyttäytymisanalyysi on tärkeämpi kuin allekirjoituslista.
Riittääkö, että löydetty tiedosto poistetaan?
Yleensä ei. Hyökkääjät luovat usein useita pääsyreittejä, esimerkiksi lisää tiedostoja, cron-tehtäviä tai uusia ylläpitäjätilejä. Ilman syyn selvitystä ja kaikkien tunnusten vaihtoa uusi pääsy on todennäköinen.
Onko web shellin löydettyäni jotain ilmoitettava?
Jos henkilötiedot voivat olla vaarantuneet, GDPR:n mukainen ilmoitusvelvollisuus voi olla voimassa, yleensä 72 tunnin kuluessa. Selvittäkää asia tietosuojavastaavanne tai asianajajan kanssa; tämä ei ole oikeudellista neuvontaa.