# Iskanje tujih skrbniških računov v CMS in na strežniku

> Poiščite tuje skrbniške račune: preverite CMS, nadzorno ploščo gostovanja, strežnik Linux in podatkovno bazo glede neznanih dostopov ter pravilno ravnajte z najdbami.

Vir: https://phpsos.de/sl/blog/fremde-admin-konten-finden/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Tuje skrbniške račune najdete samo, če preverite vse ravni: CMS ali spletno trgovino, nadzorno ploščo gostovanja, sistemske uporabnike strežnika, dostope SSH in uporabnike podatkovne baze. Ne zanašajte se na seznam uporabnikov v zaledju, saj lahko vnesena koda tam skriva račune. Najdbe najprej dokumentirajte in zaklenite, nato razjasnite vzrok, šele potem izbrišite.

## Zakaj je neznan skrbnik tako nevaren

Dodatni skrbniški račun je za napadalce najudobnejša stranska vrata. Ne potrebuje škodljive kode, pri pregledih datotek ne izstopa in preživi vsako posodobitev. Kdor se pozneje prijavi s tem računom, je v dnevniku videti kot običajen urednik.

Po PHP2Shell to preverjanje pridobiva težo. Ranljivosti CVE-2026-109618 in CVE-2026-109619 omogočata izvajanje škodljive kode brez prijave. Kdor lahko na strežniku izvaja kodo, lahko piše tudi v podatkovno bazo in s tem ustvarja račune. Posodobitev PHP ranljivost zapre, ne odstrani pa računa, ki je nastal prej.

Za PHP2Shell ni objavljenih, potrjenih indikatorjev ogroženosti (Indicators of Compromise), torej seznama tipičnih sledi. Neznan račun zato ni dokaz za PHP2Shell, je pa jasen namig na nepooblaščen dostop, ne glede na pot. Pregled nadaljnjih znakov je na strani [Ali smo že ogroženi?](https://phpsos.de/sl/php2shell/bin-ich-gehackt-anzeichen/).

## Kje so lahko tuji skrbniški računi

Mnogi upravljavci gledajo samo v CMS. Napadalci mislijo v ravneh in vsaka raven ima lastne račune:

| Raven | Kje pogledati | Na kaj paziti |
|---|---|---|
| CMS ali spletna trgovina | Upravljanje uporabnikov in tabela uporabnikov v podatkovni bazi | Vloga skrbnik, datum ustvaritve, tuj e-poštni naslov |
| Nadzorna plošča gostovanja | Uporabniki, dodatni računi, računi FTP | Računi, ki jih nihče v ekipi ni ustvaril |
| Strežnik Linux | `/etc/passwd`, skupini `sudo` ali `wheel`, sudoers | dodatni računi z UID 0, nove prijavne lupine |
| SSH | `authorized_keys` vseh uporabnikov | Ključi brez znanega lastnika |
| Podatkovna baza | Tabela uporabnikov strežnika podatkovne baze | Uporabniki z globalnimi pravicami ali gostiteljem `%` |
| Zunanje storitve | Domena, DNS, Search Console, CDN | dodatni lastniki ali pooblaščenci |

Raven SSH je dovolj samostojna za lasten prispevek: [Iskanje in odstranjevanje neznanih ključev SSH](https://phpsos.de/sl/blog/ssh-schluessel-pruefen/).

## Iskanje tujih skrbniških računov v CMS, tudi skritih

Seznam uporabnikov v zaledju ustvari aplikacija sama. Če teče vnesena koda, lahko posamezne vnose odfiltrira. Zanesljivejša so zato orodja, ki gledajo neposredno shranjene podatke. Za WordPress WP-CLI našteje vse skrbnike z datumom ustvaritve:

```bash
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
```

Še globlje gre poizvedba za branje v podatkovni bazi. Pokaže vsak račun, ki mu je dodeljena skrbniška vloga, ne glede na to, kaj prikazuje vmesnik. Predpono tabel `wp_` prilagodite svoji namestitvi:

```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;
```

Rezultate zaledja, WP-CLI in podatkovne baze primerjajte. Če se račun pojavi samo v podatkovni bazi, je to močan opozorilni znak, ker je potem v igri še koda, ki ga skriva. Za druge sisteme, kot so Shopware, TYPO3 ali Joomla, velja isto načelo: tabelo uporabnikov neposredno povprašajte in primerjajte s prikazom v zaledju. Katere tabele so to, piše v dokumentaciji proizvajalca.

## Preverite sistemske uporabnike in uporabnike podatkovne baze

Na samem strežniku so zanimivi predvsem računi s pravicami root in računi, ki se lahko prijavijo. Naslednji ukazi samo berejo:

```bash
# Računi z UID 0 (običajno samo root)
awk -F: '$3 == 0 {print $1}' /etc/passwd

# Računi z pravo prijavno lupino
grep -vE '(nologin|false)$' /etc/passwd

# Člani skrbniških skupin
getent group sudo wheel

# Dodatna pravila sudo
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/

# Zadnje prijave s polnim datumom
last -F | head -30
```

Na strežniku podatkovne baze preverite, kateri uporabniki obstajajo in kakšne pravice imajo:

```sql
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
```

Aplikacija praviloma potrebuje uporabnika s pravicami na natanko eni podatkovni bazi. Dodatni uporabnik z globalnimi pravicami, ki sme dostopati s poljubnih gostiteljev (`%`), zahteva razjasnitev.

Ne pozabite računov zunaj strežnika. Kdor ima dostop do pogodbe o domeni ali upravljanja DNS, lahko obiskovalce preusmeri ali pridobi izdajo certifikatov na tujih strežnikih. Dodatni lastnik v Google Search Console lahko vlaga zemljevide strani in spreminja nastavitve. Zato pri registrarju, ponudniku DNS, CDN in Search Console preglejte seznam pooblaščencev in ga primerjajte s tem, kar pozna vaša ekipa.

## Kako pravilno ravnati z najdbo

Prvi impulz je, da tuj račun takoj izbrišete. Pri tem pa izgine tudi pomembna sled: datum ustvaritve pogosto zoži, kdaj je bil napadalec v sistemu. Bolje je ta vrstni red:

1. **Dokumentirajte:** Uporabniško ime, ID, e-pošto, datum ustvaritve, vlogo in zadnjo dejavnost zabeležite s časom, najbolje kot posnetek zaslona in izvoz.
2. **Zaklenite namesto izbrišite:** Odvzemite vlogo, geslo zamenjajte z naključno vrednostjo ali račun deaktivirajte.
3. **Zožite obdobje:** Preverite dnevnike okoli datuma ustvaritve. Katere zahteve so bile malo prej, katere datoteke so se spremenile?
4. **Preverite druge ravni:** Kdor ustvari račun, redko pusti samo enega. Preglejte tudi datoteke, cronjobe, ključe SSH in podatkovno bazo.
5. **Očistite in obnovite dostope:** Šele po čiščenju in posodobitvi PHP obnovite vsa gesla, ključe in seje.

Opozorilo za previdnost: ni vsak neznan račun zlonameren. Agencije, prejšnji izvajalci ali vtičniki za vzdrževanje včasih ustvarijo lastne račune. To razjasnite, preden dvignete alarm, a razjasnite pravočasno.

## Preprečitev ponovitve

Po čiščenju naj bodo skrbniški računi izjema, ne pravilo. Obnesli so se osebni računi namesto deljenih dostopov, čim manj skrbnikov in [dvofaktorska prijava za skrbniške dostope](https://phpsos.de/sl/ratgeber/zwei-faktor-admin/). Določite tudi, kdo sme ustvarjati nove skrbniške račune in kje je to dokumentirano.

Redna poizvedba, kot so zgornje, na primer tedensko in s primerjavo s prejšnjim tednom, hitro naredi nove račune vidne. Pri WordPressu pomaga še vodnik [Iskanje stranskih vrat v WordPressu](https://phpsos.de/sl/ratgeber/backdoor-wordpress-finden/).

## Kako PHP SOS pomaga konkretno?

- Preverimo vse ravni računov od CMS prek strežnika do podatkovne baze in primerjamo prikaz v zaledju s shranjenimi podatki.
- Najdbe zavarujemo s časovnimi žigi, preden se računi zaklenejo ali odstranijo.
- V okviru [odziva na incidente](https://phpsos.de/sl/leistungen/incident-response/) razjasnimo, kako je račun nastal in ali obstajajo nadaljnja stranska vrata.
- Dostope obnovimo v pravem vrstnem redu in vzpostavimo tekoče preverjanje novih skrbniških računov.


## Pogosta vprašanja

**Ali naj neznan skrbniški račun takoj izbrišem?**  
Raje ne takoj. Najprej dokumentirajte uporabniško ime, datum ustvaritve, e-poštni naslov in zadnjo dejavnost ter račun zaklenite. Izbrisati ga je treba šele, ko so sledi zavarovane, saj je datum ustvaritve pogosto pomemben namig na čas vdora.

**Ali je skrbniški račun v zaledju lahko nevidno?**  
Da. Vnesena koda lahko posamezne račune skrije iz seznama uporabnikov v vmesniku. Neposredna poizvedba po podatkovni bazi ali orodje ukazne vrstice pa pokaže vse shranjene račune. Zato ne glejte samo v zaledju.

**Katere ravni moram poleg CMS še preveriti?**  
Nadzorno ploščo gostovanja, dostope FTP in SFTP, sistemske uporabnike strežnika vključno s pravicami sudo, ključe SSH, uporabnike podatkovne baze ter račune pri domeni, DNS in Search Console. Napadalec potrebuje samo ena od teh vrat, da se vrne.

**Ali zadošča po najdbi zamenjati vsa gesla?**  
Ne. Tuj račun kaže, da je nekdo imel dostop. Potem je treba razjasniti tudi vstopno točko, nadaljnja stranska vrata in morebitno odtekanje podatkov. Gesla zamenjajte šele po čiščenju in s čiste naprave.

## Viri

- [WordPress](https://wordpress.org/)
- [php.net: varnostna obvestila](https://www.php.net/)
- [BSI: napotki k varnostnim incidentom v IT (Nemčija)](https://www.bsi.bund.de/)
