Röviden: Idegen admin-fiókokat csak akkor talál, ha minden szintet ellenőriz: a CMS-t vagy a webshopot, a tárhelypanelt, a szerver rendszerfelhasználóit, az SSH-hozzáféréseket és az adatbázis-felhasználókat. Ne hagyatkozzon a backend felhasználólistájára, mert a beszúrt kód ott elrejthet fiókokat. A leleteket először dokumentálja és zárolja, azután tisztázza az okot, és csak ezután törölje.
Miért olyan veszélyes egy ismeretlen adminisztrátor
Egy további admin-fiók a támadók számára a legkényelmesebb hátsó kapu. Nincs szüksége kártékony kódra, a fájlvizsgálatoknál nem tűnik fel, és minden frissítést átvészel. Aki később ezzel a fiókkal jelentkezik be, a naplóban egy normális szerkesztőnek látszik.
A PHP2Shell után ez az ellenőrzés nagyobb súlyt kap. A CVE-2026-109618 és a CVE-2026-109619 rések bejelentkezés nélkül lehetővé teszik kártékony kód végrehajtását. Aki a szerveren kódot tud végrehajtani, az az adatbázisba is tud írni, és így fiókokat tud létrehozni. A PHP-frissítés bezárja a rést, de nem távolít el olyan fiókot, amely korábban keletkezett.
A PHP2Shellre nincsenek közzétett, megerősített Indicators of Compromise, vagyis a tipikus nyomok listája. Egy ismeretlen fiók ezért nem PHP2Shell-bizonyíték, de egyértelmű jelzés illetéktelen hozzáférésre, bármilyen úton is. További jelek áttekintése a Megfertőzték már a rendszeremet? oldalon található.
Hol rejtőzhetnek idegen admin-fiókok
Sok üzemeltető csak a CMS-be néz bele. A támadók szintekben gondolkodnak, és minden szintnek saját fiókjai vannak:
| Szint | Hol nézzen utána | Mire figyeljen |
|---|---|---|
| CMS vagy webshop | a felhasználókezelés és a felhasználók adatbázistáblája | az adminisztrátor szerepkör, a létrehozás dátuma, idegen e-mail-cím |
| Tárhelypanel | felhasználók, kiegészítő fiókok, FTP-fiókok | olyan fiókok, amelyeket a csapatban senki sem hozott létre |
| Linux-szerver | /etc/passwd, a sudo vagy wheel csoportok, sudoers |
további UID 0 fiókok, új bejelentkezési shellek |
| SSH | az összes felhasználó authorized_keys fájlja |
ismert tulajdonos nélküli kulcsok |
| Adatbázis | az adatbázis-szerver felhasználói táblája | globális jogokkal vagy % hosttal rendelkező felhasználók |
| Külső szolgáltatások | domain, DNS, Search Console, CDN | további tulajdonosok vagy jogosultak |
Az SSH-szint elég önálló egy külön cikkhez: Ismeretlen SSH-kulcsok keresése és eltávolítása.
Idegen admin-fiókok keresése a CMS-ben, a rejtettekét is
A backend felhasználólistáját maga az alkalmazás állítja elő. Ha beszúrt kód is fut, az egyes bejegyzéseket kiszűrheti. Megbízhatóbbak ezért azok az eszközök, amelyek közvetlenül a tárolt adatokra néznek. WordPressnél a WP-CLI kilistázza az összes adminisztrátort a létrehozás dátumával:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Még egy szinttel mélyebbre megy egy olvasó lekérdezés az adatbázisban. Minden olyan fiókot megmutat, amelyhez az adminisztrátori szerepkört rendelték, függetlenül attól, hogy a felület mit jelenít meg. A wp_ táblaelőtagot igazítsa a saját telepítéséhez:
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;
Vesse össze a backend, a WP-CLI és az adatbázis eredményeit. Ha egy fiók csak az adatbázisban jelenik meg, az erős figyelmeztető jel, mert akkor egy azt elrejtő kód is játékban van. Más rendszerekre, például a Shopware-re, a TYPO3-ra vagy a Joomlára ugyanez az elv érvényes: közvetlenül kérdezze le a felhasználói táblát, és vesse össze a backend kijelzésével. Hogy melyek ezek a táblák, azt a gyártó dokumentációja tartalmazza.
A rendszer- és adatbázis-felhasználók ellenőrzése
Magán a szerveren elsősorban a root jogosultságú és a bejelentkezni képes fiókok érdekesek. A következő parancsok csak olvasnak:
# UID 0 fiókok (normálisan csak a root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Valódi bejelentkezési shellel rendelkező fiókok
grep -vE '(nologin|false)$' /etc/passwd
# Az admin csoportok tagjai
getent group sudo wheel
# További sudo-szabályok
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Utolsó bejelentkezések teljes dátummal
last -F | head -30
Az adatbázis-szerveren azt ellenőrizze, mely felhasználók léteznek, és milyen jogaik vannak:
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
Egy alkalmazásnak általában egy olyan felhasználóra van szüksége, amelynek jogai pontosan egy adatbázisra szólnak. Egy további, globális jogokkal rendelkező felhasználót, amely tetszőleges hostokról (%) is hozzáférhet, tisztázni kell.
Ne feledkezzen meg a szerveren kívüli fiókokról sem. Aki hozzáfér a domain-szerződéshez vagy a DNS-kezeléshez, átirányíthatja a látogatókat, vagy idegen szervereken állíttathat ki tanúsítványokat. Egy további tulajdonos a Google Search Consoleban sitemapeket adhat be, és beállításokat módosíthat. Ezért a regisztrátornál, a DNS-szolgáltatónál, a CDN-nél és a Search Consoleban nézze át a jogosultak listáját, és vesse össze azzal, amit a csapata ismer.
Így kezelje helyesen a leletet
Az első késztetés az idegen fiók azonnali törlése. Ezzel azonban egy fontos nyom is eltűnik: a létrehozás dátuma gyakran behatárolja, mikor járt a támadó a rendszerben. Jobb ez a sorrend:
- Dokumentálás: Rögzítse a felhasználónevet, az azonosítót, az e-mailt, a létrehozás dátumát, a szerepkört és az utolsó tevékenységet időponttal, a legjobb képernyőfotóként és exportként.
- Zárolás törlés helyett: Vonja meg a szerepkört, cserélje a jelszót véletlenszerű értékre, vagy kapcsolja ki a fiókot.
- Az időszak behatárolása: Ellenőrizze a naplókat a létrehozás dátuma körül. Milyen kérések voltak röviddel előtte, mely fájlok változtak?
- További szintek ellenőrzése: Aki fiókot hoz létre, ritkán hagy hátra csak egyet. Nézze át a fájlokat, a cron-feladatokat, az SSH-kulcsokat és az adatbázist is.
- Tisztítás és a hozzáférések megújítása: Csak a tisztítás és a PHP-frissítés után újítsa meg az összes jelszót, kulcsot és munkamenetet.
Egy figyelmeztetés az óvatosságról: nem minden ismeretlen fiók rosszindulatú. Az ügynökségek, a korábbi szolgáltatók vagy a karbantartó pluginok olykor saját fiókokat hoznak létre. Tisztázza ezt, mielőtt riadót fúj, de tisztázza haladéktalanul.
A visszatérés megakadályozása
A tisztítás után az admin-fiókoknak kivételnek kell lenniük, nem szabálynak. Bevált a személyes fiókok a megosztott hozzáférések helyett, a lehető legkevesebb adminisztrátor és a Kéttényezős bejelentkezés admin-hozzáférésekhez. Rögzítse emellett, ki hozhat létre új admin-fiókokat, és hol dokumentálják ezt.
Egy rendszeres lekérdezés, mint a fentiek, például hetente és az előző héttel való összehasonlítással, gyorsan láthatóvá teszi az új fiókokat. WordPressnél ezenkívül az útmutató Hátsó kapuk keresése a WordPressben segít.
Hogyan segít konkrétan a PHP SOS?
- Ellenőrizzük az összes fiókszintet a CMS-től a szerveren át az adatbázisig, és összevetjük a backend kijelzését a tárolt adatokkal.
- A leleteket időbélyegekkel mentjük, mielőtt a fiókokat zárolnák vagy eltávolítanák.
- Az Incident Response keretében tisztázzuk, hogyan keletkezett a fiók, és vannak-e további hátsó kapuk.
- A hozzáféréseket a helyes sorrendben megújítjuk, és beállítjuk az új admin-fiókok folyamatos ellenőrzését.
Gyakori kérdések
Azonnal törölnöm kell egy ismeretlen admin-fiókot?
Inkább ne azonnal. Először dokumentálja a felhasználónevet, a létrehozás dátumát, az e-mail-címet és az utolsó tevékenységet, és zárolja a fiókot. Csak akkor törölje, ha a nyomok biztonságban vannak, mert a létrehozás dátuma gyakran fontos jelzés a behatolás időpontjára.
Lehet egy admin-fiók láthatatlan a backendben?
Igen. A beszúrt kód egyes fiókokat elrejthet a felület felhasználólistájából. Az adatbázis közvetlen lekérdezése vagy egy parancssori eszköz ezzel szemben az összes tárolt fiókot megmutatja. Ezért ne csak a backendben nézzen utána.
Mely szinteket kell ellenőriznem a CMS-en kívül?
A tárhelypanelt, az FTP- és SFTP-hozzáféréseket, a szerver rendszerfelhasználóit a sudo-jogosultságokkal együtt, az SSH-kulcsokat, az adatbázis-felhasználókat, valamint a domain, a DNS és a Search Console fiókjait. A támadónak csak egy ilyen ajtóra van szüksége a visszatéréshez.
Elég a lelet után minden jelszót megváltoztatni?
Nem. Egy idegen fiók azt mutatja, hogy valaki hozzáfért. Ilyenkor a bejutási pontot, a további hátsó kapukat és a lehetséges adatszivárgásokat is tisztázni kell. A jelszavakat csak a tisztítás után és egy tiszta eszközről változtassa meg.