Ukratko: Tuđe administratorske račune pronaći ćete samo ako provjerite sve razine: CMS ili shop, hosting panel, sistemske korisnike poslužitelja, SSH pristupe i korisnike baze podataka. Ne oslanjajte se na popis korisnika u backendu, jer ubačeni kod tamo može skriti račune. Nalaze najprije dokumentirajte i blokirajte, zatim razjasnite uzrok, a tek nakon toga brišite.
Zašto je nepoznati administrator toliko opasan
Dodatni administratorski račun napadačima su najudobnija stražnja vrata. Ne treba zlonamjerni kod, ne upada u oči kod skeniranja datoteka i preživljava svako ažuriranje. Tko se kasnije prijavi tim računom, u zapisniku izgleda kao običan urednik.
Nakon PHP2Shella ta provjera dobiva na težini. Ranjivosti CVE-2026-109618 i CVE-2026-109619 omogućuju izvršavanje zlonamjernog koda bez prijave. Tko može izvršavati kod na poslužitelju, može pisati i u bazu podataka i tako stvarati račune. PHP ažuriranje zatvara ranjivost, ali ne uklanja račun nastao prije toga.
Za PHP2Shell nema objavljenih, potvrđenih Indicators of Compromise, dakle ni popisa tipičnih tragova. Nepoznati račun stoga nije dokaz PHP2Shella, ali je jasna naznaka neovlaštenog pristupa, bez obzira na put. Pregled daljnjih znakova nalazi se pod Jesam li već kompromitiran?.
Gdje se tuđi administratorski računi mogu kriti
Mnogi operateri gledaju samo u CMS. Napadači razmišljaju po razinama, a svaka razina ima vlastite račune:
| Razina | Gdje pogledati | Na što paziti |
|---|---|---|
| CMS ili shop | upravljanje korisnicima i tablica korisnika u bazi podataka | uloga administratora, datum stvaranja, strana adresa e-pošte |
| Hosting panel | korisnici, dodatni računi, FTP računi | računi koje nitko u timu nije stvorio |
| Linux poslužitelj | /etc/passwd, grupe sudo ili wheel, sudoers |
dodatni računi s UID 0, nove prijavne ljuske |
| SSH | authorized_keys svih korisnika |
ključevi bez poznatog vlasnika |
| Baza podataka | tablica korisnika poslužitelja baze podataka | korisnici s globalnim pravima ili hostom % |
| Vanjske usluge | domena, DNS, Search Console, CDN | dodatni vlasnici ili ovlaštene osobe |
SSH razina dovoljno je samostalna za zaseban članak: Pronaći i ukloniti nepoznate SSH ključeve.
Pronaći tuđe administratorske račune u CMS-u, i skrivene
Popis korisnika u backendu generira sama aplikacija. Ako radi ubačeni kod, on može izdvojiti pojedine unose. Pouzdaniji su stoga alati koji izravno gledaju spremljene podatke. Za WordPress WP-CLI navodi sve administratore s datumom stvaranja:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Još jednu razinu dublje ide upit u bazu podataka koji samo čita. Prikazuje svaki račun kojem je dodijeljena uloga administratora, neovisno o tome što prikazuje sučelje. Prefiks tablice wp_ prilagodite svojoj instalaciji:
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;
Usporedite rezultate backenda, WP-CLI-ja i baze podataka. Ako se račun pojavljuje samo u bazi podataka, to je jak znak upozorenja, jer je tada u igri i kod koji ga skriva. Za druge sustave poput Shopwarea, TYPO3-a ili Joomle vrijedi isto načelo: izravno upitati tablicu korisnika i usporediti s prikazom u backendu. Koje su to tablice, piše u dokumentaciji proizvođača.
Provjeriti sistemske korisnike i korisnike baze podataka
Na samom poslužitelju zanimaju prije svega računi s root pravima i računi koji se mogu prijaviti. Sljedeće naredbe samo čitaju:
# Računi s UID 0 (normalno samo root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Računi s pravom prijavnom ljuskom
grep -vE '(nologin|false)$' /etc/passwd
# Članovi administratorskih grupa
getent group sudo wheel
# Dodatna sudo pravila
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Zadnje prijave s punim datumom
last -F | head -30
Na poslužitelju baze podataka provjerite koji korisnici postoje i koja imaju prava:
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
Aplikaciji u pravilu treba korisnik s pravima na točno jednu bazu podataka. Dodatnog korisnika s globalnim pravima koji smije pristupati s bilo kojeg hosta (%) treba razjasniti.
Ne zaboravite račune izvan poslužitelja. Tko ima pristup ugovoru o domeni ili upravljanju DNS-om, može preusmjeravati posjetitelje ili dati izdati certifikate na strane poslužitelje. Dodatni vlasnik u Google Search Consoleu može podnositi sitemape i mijenjati postavke. Zato kod registrara, DNS pružatelja, CDN-a i Search Consolea prođite popis ovlaštenih osoba i usporedite ga s onim što Vaš tim poznaje.
Kako ispravno postupiti s nalazom
Prvi impuls je tuđi račun odmah obrisati. Time nestaje i važan trag: datum stvaranja često sužava kada je napadač bio u sustavu. Bolji je ovaj redoslijed:
- Dokumentirati: Korisničko ime, ID, e-poštu, datum stvaranja, ulogu i zadnju aktivnost zabilježiti s vremenom, najbolje kao snimku zaslona i izvoz.
- Blokirati umjesto brisati: Oduzeti ulogu, lozinku zamijeniti nasumičnom vrijednošću ili deaktivirati račun.
- Suziti razdoblje: Provjeriti zapisnike oko datuma stvaranja. Kakvih je zahtjeva bilo malo prije, koje su se datoteke promijenile?
- Provjeriti daljnje razine: Tko stvori račun, rijetko ostavlja samo jedan. Pregledati i datoteke, cron poslove, SSH ključeve i bazu podataka.
- Očistiti i obnoviti pristupe: Tek nakon čišćenja i PHP ažuriranja obnoviti sve lozinke, ključeve i sesije.
Napomena o oprezu: nije svaki nepoznati račun zlonamjeran. Agencije, raniji pružatelji usluga ili dodaci za održavanje ponekad stvaraju vlastite račune. To razjasnite prije nego dignete uzbunu, ali razjasnite pravodobno.
Spriječiti povratak
Nakon čišćenja administratorski računi trebaju biti iznimka, ne pravilo. Dokazali su se osobni računi umjesto zajedničkih pristupa, što manje administratora i dvofaktorska prijava za administratorske pristupe. Uz to odredite tko smije stvarati nove administratorske račune i gdje se to dokumentira.
Redoviti upit poput gornjih, primjerice tjedno i s usporedbom s prethodnim tjednom, brzo čini vidljivima nove račune. Kod WordPressa dodatno pomaže vodič Pronaći stražnja vrata u WordPressu.
Kako PHP SOS konkretno pomaže?
- Provjeravamo sve razine računa od CMS-a preko poslužitelja do baze podataka i uspoređujemo prikaz backenda i spremljene podatke.
- Nalaze osiguravamo s vremenskim žigovima prije nego se računi blokiraju ili uklone.
- U okviru odgovora na incidente razjašnjavamo kako je račun nastao i postoje li daljnja stražnja vrata.
- Pristupe obnavljamo pravim redoslijedom i postavljamo trajnu kontrolu novih administratorskih računa.
Česta pitanja
Trebam li nepoznati administratorski račun odmah obrisati?
Bolje ne odmah. Najprije dokumentirajte korisničko ime, datum stvaranja, adresu e-pošte i zadnju aktivnost te blokirajte račun. Briše se tek kad su tragovi osigurani, jer je datum stvaranja često važna naznaka trenutka provale.
Može li administratorski račun u backendu biti nevidljiv?
Da. Ubačeni kod može pojedine račune sakriti iz popisa korisnika u sučelju. Izravan upit u bazu podataka ili alat naredbenog retka, nasuprot tome, prikazuje sve spremljene račune. Zato ne biste smjeli gledati samo u backendu.
Koje razine moram provjeriti osim CMS-a?
Hosting panel, FTP i SFTP pristupe, sistemske korisnike poslužitelja uključujući sudo prava, SSH ključeve, korisnike baze podataka te račune kod domene, DNS-a i Search Consolea. Napadaču je za povratak dovoljna jedna od tih vrata.
Je li dovoljno nakon nalaza promijeniti sve lozinke?
Ne. Tuđi račun pokazuje da je netko imao pristup. Tada treba razjasniti i ulaznu točku, daljnja stražnja vrata i moguće odljeve podataka. Lozinke mijenjajte tek nakon čišćenja i s čistog uređaja.