Pe scurt: Conturile de administrator străine le găsiți doar dacă verificați toate nivelurile: CMS-ul sau magazinul, panoul de hosting, utilizatorii de sistem ai serverului, accesurile SSH și utilizatorii bazei de date. Nu vă bazați pe lista de utilizatori din backend, deoarece codul introdus poate ascunde acolo conturi. Constatările se documentează și se blochează mai întâi, apoi se clarifică cauza, abia după aceea se șterg.
De ce este un administrator necunoscut atât de periculos
Un cont suplimentar de administrator este pentru atacatori cea mai comodă ușă din spate. Nu are nevoie de cod malițios, nu iese în evidență la scanările de fișiere și supraviețuiește oricărei actualizări. Cine se autentifică mai târziu cu acest cont arată în jurnal ca un redactor obișnuit.
După PHP2Shell, această verificare câștigă în importanță. Vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 permit executarea de cod malițios fără autentificare. Cine poate executa cod pe server poate scrie și în baza de date și poate astfel crea conturi. O actualizare PHP închide vulnerabilitatea, dar nu elimină niciun cont apărut înainte.
Pentru PHP2Shell nu există Indicators of Compromise publicate și confirmate, adică nicio listă de urme tipice. Un cont necunoscut nu este deci o dovadă PHP2Shell, ci un indiciu clar de acces neautorizat, indiferent pe ce cale. O privire de ansamblu asupra altor semne se află la Sunt deja compromis?.
Unde se pot afla conturi de administrator străine
Mulți operatori se uită doar în CMS. Atacatorii gândesc pe niveluri, iar fiecare nivel are conturi proprii:
| Nivel | Unde vă uitați | La ce fiți atenți |
|---|---|---|
| CMS sau magazin | Administrarea utilizatorilor și tabelul bazei de date cu utilizatori | Rol de administrator, data creării, adresă de e-mail străină |
| Panou de hosting | Utilizatori, conturi suplimentare, conturi FTP | Conturi pe care nimeni din echipă nu le-a creat |
| Server Linux | /etc/passwd, grupurile sudo sau wheel, sudoers |
alte conturi cu UID 0, shell-uri de autentificare noi |
| SSH | authorized_keys ale tuturor utilizatorilor |
Chei fără proprietar cunoscut |
| Bază de date | Tabelul de utilizatori al serverului de baze de date | Utilizatori cu drepturi globale sau host % |
| Servicii externe | Domeniu, DNS, Search Console, CDN | proprietari sau persoane autorizate suplimentare |
Nivelul SSH este suficient de independent pentru un articol propriu: Găsirea și eliminarea cheilor SSH necunoscute.
Găsirea conturilor de administrator străine în CMS, inclusiv a celor ascunse
Lista de utilizatori din backend este generată de aplicația însăși. Dacă rulează și cod introdus, el poate filtra intrări individuale. Mai de încredere sunt de aceea uneltele care se uită direct la datele stocate. Pentru WordPress, WP-CLI listează toți administratorii cu data creării:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Un nivel mai adânc merge o interogare de citire în baza de date. Ea arată fiecare cont căruia i-a fost atribuit rolul de administrator, indiferent de ce afișează interfața. Prefixul tabelului wp_ îl adaptați la instalarea dumneavoastră:
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;
Comparați rezultatele din backend, WP-CLI și baza de date. Dacă un cont apare doar în baza de date, este un semnal puternic de alarmă, deoarece atunci este implicat în plus un cod care îl ascunde. La alte sisteme precum Shopware, TYPO3 sau Joomla se aplică același principiu: interogați direct tabelul de utilizatori și comparați cu afișarea din backend. Ce tabele sunt acestea se află în documentația producătorului.
Verificarea utilizatorilor de sistem și ai bazei de date
Pe server vă interesează în primul rând conturile cu drepturi de root și conturile care se pot autentifica. Comenzile următoare doar citesc:
# Conturi cu UID 0 (în mod normal doar root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Conturi cu un shell de autentificare real
grep -vE '(nologin|false)$' /etc/passwd
# Membrii grupurilor de administratori
getent group sudo wheel
# Reguli sudo suplimentare
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Ultimele autentificări cu data completă
last -F | head -30
Pe serverul de baze de date verificați ce utilizatori există și ce drepturi au:
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
O aplicație are nevoie de regulă de un utilizator cu drepturi asupra exact unei baze de date. Un utilizator suplimentar cu drepturi globale, care are voie să acceseze de pe orice host (%), trebuie clarificat.
Nu uitați conturile din afara serverului. Cine are acces la contractul domeniului sau la administrarea DNS poate redirecționa vizitatorii sau poate emite certificate pe servere străine. Un proprietar suplimentar în Google Search Console poate trimite sitemap-uri și modifica setări. Parcurgeți de aceea, la registrar, furnizorul DNS, CDN și Search Console, lista persoanelor autorizate și comparați-o cu ceea ce cunoaște echipa dumneavoastră.
Cum tratați corect o constatare
Primul impuls este să ștergeți imediat contul străin. Odată cu el dispare însă și o urmă importantă: data creării delimitează adesea când a fost atacatorul în sistem. Mai bună este această ordine:
- Documentați: Consemnați numele de utilizator, ID-ul, e-mailul, data creării, rolul și ultima activitate cu ora, cel mai bine ca captură de ecran și export.
- Blocați în loc să ștergeți: Retrageți rolul, înlocuiți parola cu o valoare aleatorie sau dezactivați contul.
- Delimitați perioada: Verificați logurile în jurul datei creării. Ce cereri au existat cu puțin timp înainte, ce fișiere s-au modificat?
- Verificați alte niveluri: Cine creează un cont rareori lasă doar unul. Priviți și fișierele, cronjob-urile, cheile SSH și baza de date.
- Curățați și reînnoiți accesurile: Abia după curățare și actualizarea PHP reînnoiți toate parolele, cheile și sesiunile.
O indicație de prudență: nu orice cont necunoscut este rău intenționat. Agențiile, prestatorii anteriori sau pluginurile de mentenanță creează uneori conturi proprii. Clarificați aceasta înainte de a da alarma, dar clarificați-o prompt.
Prevenirea revenirii
După curățare, conturile de administrator ar trebui să fie excepția, nu regula. S-au dovedit utile conturile personale în loc de accesuri partajate, cât mai puțini administratori posibil și o autentificare în doi pași pentru accesurile de administrator. Stabiliți în plus cine are voie să creeze conturi noi de administrator și unde se documentează aceasta.
O interogare regulată, precum cele de mai sus, de exemplu săptămânal și cu comparație cu săptămâna anterioară, face rapid vizibile conturile noi. La WordPress ajută suplimentar ghidul Găsirea backdoor-urilor în WordPress.
Cum ajută PHP SOS concret?
- Verificăm toate nivelurile de conturi, de la CMS prin server până la baza de date, și comparăm afișarea din backend cu datele stocate.
- Păstrăm constatările cu marcaje de timp înainte ca conturile să fie blocate sau eliminate.
- Clarificăm în cadrul răspunsului la incidente cum a apărut contul și dacă există alte uși din spate.
- Reînnoim accesurile în ordinea corectă și configurăm un control continuu al conturilor noi de administrator.
Întrebări frecvente
Ar trebui să șterg imediat un cont de administrator necunoscut?
Mai bine nu imediat. Documentați mai întâi numele de utilizator, data creării, adresa de e-mail și ultima activitate și blocați contul. Se șterge abia după ce urmele sunt păstrate, deoarece data creării este adesea un indiciu important pentru momentul intruziunii.
Poate un cont de administrator să fie invizibil în backend?
Da. Codul introdus poate ascunde conturi individuale din lista de utilizatori a interfeței. O interogare directă a bazei de date sau o unealtă din linia de comandă arată în schimb toate conturile stocate. De aceea nu ar trebui să vă uitați doar în backend.
Ce niveluri trebuie să verific în afară de CMS?
Panoul de hosting, accesurile FTP și SFTP, utilizatorii de sistem ai serverului, inclusiv drepturile sudo, cheile SSH, utilizatorii bazei de date, precum și conturile la domeniu, DNS și Search Console. Un atacator are nevoie de o singură dintre aceste uși pentru a reveni.
Este suficient să schimb toate parolele după constatare?
Nu. Un cont străin arată că cineva a avut acces. Atunci trebuie clarificate și poarta de intrare, alte uși din spate și eventuale scurgeri de date. Parolele le schimbați abia după curățare și de pe un dispozitiv curat.