# Idegen admin-fiókok keresése a CMS-ben és a szerveren

> Idegen admin-fiókok keresése: így ellenőrzi a CMS-t, a tárhelypanelt, a Linux-szervert és az adatbázist ismeretlen hozzáférésekre, és kezeli helyesen a leleteket.

Forrás: https://phpsos.de/hu/blog/fremde-admin-konten-finden/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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?](https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/) 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](https://phpsos.de/hu/blog/ssh-schluessel-pruefen/).

## 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:

```bash
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:

```sql
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:

```bash
# 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:

```sql
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:

1. **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.
2. **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.
3. **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?
4. **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.
5. **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](https://phpsos.de/hu/ratgeber/zwei-faktor-admin/). 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](https://phpsos.de/hu/ratgeber/backdoor-wordpress-finden/) 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](https://phpsos.de/hu/leistungen/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.

## Források

- [WordPress](https://wordpress.org/)
- [php.net: biztonsági közlemények](https://www.php.net/)
- [BSI: tudnivalók informatikai biztonsági incidensekről](https://www.bsi.bund.de/)