Lyhyesti: Vieraat ylläpitäjätilit löydätte vain tarkistamalla kaikki tasot: CMS:n tai verkkokaupan, hosting-paneelin, palvelimen järjestelmäkäyttäjät, SSH-pääsyt ja tietokantakäyttäjät. Älkää luottako hallintanäkymän käyttäjäluetteloon, sillä lisätty koodi voi piilottaa tilejä siellä. Dokumentoikaa ja estäkää löydöt ensin, selvittäkää sitten syy, poistakaa vasta sen jälkeen.
Miksi tuntematon ylläpitäjä on niin vaarallinen
Ylimääräinen ylläpitäjätili on hyökkääjälle kätevin takaovi. Se ei tarvitse haittakoodia, ei herätä huomiota tiedostoskannauksissa ja säilyy jokaisen päivityksen yli. Joka kirjautuu myöhemmin tällä tilillä, näyttää lokissa tavalliselta toimittajalta.
PHP2Shellin jälkeen tämä tarkistus painaa enemmän. Aukot CVE-2026-109618 ja CVE-2026-109619 sallivat haittakoodin suorittamisen ilman kirjautumista. Joka voi suorittaa koodia palvelimella, voi myös kirjoittaa tietokantaan ja luoda siten tilejä. PHP-päivitys sulkee aukon mutta ei poista tiliä, joka on syntynyt aiemmin.
PHP2Shellille ei ole julkaistuja, vahvistettuja Indicators of Compromise -tunnisteita, eli luetteloa tyypillisistä jäljistä. Tuntematon tili ei siksi ole PHP2Shell-todiste, mutta selvä vihje luvattomasta pääsystä, riippumatta siitä, mitä kautta. Yleiskatsauksen muista merkeistä antaa Olenko jo vaarantunut?.
Missä vieraat ylläpitäjätilit voivat olla
Monet ylläpitäjät katsovat vain CMS:ää. Hyökkääjät ajattelevat tasoina, ja jokaisella tasolla on omat tilinsä:
| Taso | Mistä katsotaan | Mihin kiinnitetään huomiota |
|---|---|---|
| CMS tai verkkokauppa | käyttäjähallinta ja käyttäjien tietokantataulu | rooli ylläpitäjä, luontipäivä, vieras sähköpostiosoite |
| Hosting-paneeli | käyttäjät, lisätilit, FTP-tilit | tilit, joita kukaan tiimistä ei ole luonut |
| Linux-palvelin | /etc/passwd, ryhmät sudo tai wheel, sudoers |
muut tilit, joilla UID 0, uudet kirjautumisshellit |
| SSH | kaikkien käyttäjien authorized_keys |
avaimet ilman tunnettua omistajaa |
| Tietokanta | tietokantapalvelimen käyttäjätaulu | käyttäjät, joilla on yleiset oikeudet tai isäntä % |
| Ulkoiset palvelut | domain, DNS, Search Console, CDN | lisäomistajat tai oikeutetut |
SSH-taso on riittävän itsenäinen omaan artikkeliinsa: Tuntemattomien SSH-avainten löytäminen ja poistaminen.
Vieraiden ylläpitäjätilien löytäminen CMS:stä, myös piilotettujen
Hallintanäkymän käyttäjäluettelon tuottaa sovellus itse. Jos lisätty koodi pyörii mukana, se voi suodattaa yksittäisiä merkintöjä pois. Luotettavampia ovat siksi työkalut, jotka katsovat suoraan tallennettua dataa. WordPressille WP-CLI luettelee kaikki ylläpitäjät luontipäivän kanssa:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Vielä syvemmälle pääsee lukevalla kyselyllä tietokannassa. Se näyttää jokaisen tilin, jolle on liitetty ylläpitäjärooli, riippumatta siitä, mitä käyttöliittymä näyttää. Taulun etuliitteen wp_ mukautatte asennukseenne:
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;
Verratkaa hallintanäkymän, WP-CLI:n ja tietokannan tuloksia. Jos tili ilmestyy vain tietokantaan, se on vahva varoitusmerkki, sillä silloin mukana on lisäksi koodia, joka piilottaa sen. Muissa järjestelmissä kuten Shopware, TYPO3 tai Joomla pätee sama periaate: kysykää käyttäjätaulua suoraan ja verratkaa hallintanäkymän näyttöön. Mitkä taulut ne ovat, kerrotaan valmistajan dokumentaatiossa.
Järjestelmä- ja tietokantakäyttäjien tarkistus
Palvelimella itsellään kiinnostavia ovat ennen kaikkea tilit, joilla on root-oikeudet, ja tilit, jotka voivat kirjautua. Seuraavat komennot vain lukevat:
# Tilit, joilla UID 0 (normaalisti vain root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Tilit, joilla on oikea kirjautumisshell
grep -vE '(nologin|false)$' /etc/passwd
# Ylläpitäjäryhmien jäsenet
getent group sudo wheel
# Lisäsudo-säännöt
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Viimeisimmät kirjautumiset täydellä päivämäärällä
last -F | head -30
Tietokantapalvelimella tarkistatte, mitä käyttäjiä on ja millaiset oikeudet niillä on:
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
Sovellus tarvitsee yleensä käyttäjän, jolla on oikeudet täsmälleen yhteen tietokantaan. Ylimääräinen käyttäjä yleisillä oikeuksilla, jolla on pääsy mistä tahansa isännästä (%), on selvitettävä.
Älkää unohtako palvelimen ulkopuolisia tilejä. Joka pääsee käsiksi domain-sopimukseen tai DNS-hallintaan, voi ohjata kävijöitä muualle tai antaa myöntää varmenteita vieraille palvelimille. Lisäomistaja Google Search Consolessa voi lähettää sivustokarttoja ja muuttaa asetuksia. Käykää siksi läpi rekisterinpitäjän, DNS-toimittajan, CDN:n ja Search Consolen oikeutettujen luettelo ja verratkaa sitä siihen, mitä tiiminne tuntee.
Näin toimitte löydön kanssa oikein
Ensimmäinen impulssi on poistaa vieras tili heti. Silloin katoaa kuitenkin tärkeä jälki: luontipäivä rajaa usein, milloin hyökkääjä oli järjestelmässä. Parempi järjestys on tämä:
- Dokumentoikaa: Kirjatkaa käyttäjätunnus, ID, sähköposti, luontipäivä, rooli ja viimeinen aktiivisuus kellonajan kanssa, parhaiten kuvakaappauksena ja vientinä.
- Estäkää poistamisen sijaan: Poistakaa rooli, korvatkaa salasana satunnaisella arvolla tai poistakaa tili käytöstä.
- Rajatkaa ajanjakso: Tarkistakaa lokit luontipäivän ympäriltä. Mitä pyyntöjä oli juuri ennen, mitkä tiedostot muuttuivat?
- Tarkistakaa muut tasot: Joka luo tilin, jättää harvoin vain yhden. Käykää läpi myös tiedostot, cron-työt, SSH-avaimet ja tietokanta.
- Siivotkaa ja uusikaa tunnukset: Vasta siivouksen ja PHP-päivityksen jälkeen uusikaa kaikki salasanat, avaimet ja istunnot.
Varovaisuushuomautus: kaikki tuntemattomat tilit eivät ole pahantahtoisia. Toimistot, aiemmat palveluntarjoajat tai huoltoliitännäiset luovat joskus omia tilejään. Selvittäkää asia, ennen kuin hälytätte, mutta selvittäkää se pian.
Paluun estäminen
Siivouksen jälkeen ylläpitäjätilien pitäisi olla poikkeus, ei sääntö. Hyväksi ovat osoittautuneet henkilökohtaiset tilit jaettujen tunnusten sijaan, mahdollisimman vähän ylläpitäjiä ja kaksivaiheinen tunnistautuminen ylläpitäjäpääsyille. Määrittäkää lisäksi, kuka saa luoda uusia ylläpitäjätilejä ja missä se dokumentoidaan.
Säännöllinen kysely, kuten yllä olevat, esimerkiksi viikoittain ja viikkoa aiempaan verraten, tekee uudet tilit nopeasti näkyviksi. WordPressissä auttaa lisäksi opas Takaovien löytäminen WordPressistä.
Miten PHP SOS auttaa konkreettisesti?
- Tarkistamme kaikki tilitasot CMS:stä palvelimen kautta tietokantaan ja vertaamme hallintanäkymän näyttöä ja tallennettua dataa.
- Varmistamme löydöt aikaleimoineen, ennen kuin tilejä estetään tai poistetaan.
- Selvitämme Incident Response -palvelun puitteissa, miten tili syntyi ja onko muita takaovia.
- Uusimme pääsyt oikeassa järjestyksessä ja otamme käyttöön uusien ylläpitäjätilien jatkuvan seurannan.
Usein kysytyt kysymykset
Pitäisikö tuntematon ylläpitäjätili poistaa heti?
Mieluummin ei heti. Dokumentoikaa ensin käyttäjätunnus, luontipäivä, sähköpostiosoite ja viimeinen aktiivisuus ja estäkää tili. Poistetaan vasta, kun jäljet on varmistettu, sillä luontipäivä on usein tärkeä vihje murron ajankohdasta.
Voiko ylläpitäjätili olla hallintanäkymässä näkymätön?
Kyllä. Lisätty koodi voi piilottaa yksittäisiä tilejä käyttöliittymän käyttäjäluettelosta. Suora tietokantakysely tai komentorivityökalu sen sijaan näyttää kaikki tallennetut tilit. Siksi ei pidä katsoa vain hallintanäkymää.
Mitä tasoja pitää tarkistaa CMS:n lisäksi?
Hosting-paneeli, FTP- ja SFTP-tunnukset, palvelimen järjestelmäkäyttäjät sudo-oikeuksineen, SSH-avaimet, tietokantakäyttäjät sekä tilit domainin, DNS:n ja Search Consolen yhteydessä. Hyökkääjä tarvitsee vain yhden näistä ovista palatakseen.
Riittääkö, että vaihdan kaikki salasanat löydön jälkeen?
Ei. Vieras tili osoittaa, että joku on päässyt käsiksi. Silloin on selvitettävä myös sisääntulotie, muut takaovet ja mahdolliset tietovuodot. Salasanat vaihdatte vasta siivouksen jälkeen ja puhtaalta laitteelta.