Pe scurt: Un criptominer pe server se arată de obicei printr-o încărcare CPU mare permanent, fără motiv vizibil, prin procese străine, adesea sub utilizatorul serverului web, și prin conexiuni de ieșire către ținte necunoscute. Nu încheiați procesul pripit: păstrați mai întâi urmele, căutați mecanismele care îl repornesc și închideți poarta de intrare. Un miner înseamnă că cineva a putut executa cod pe serverul dumneavoastră.
Când factura furnizorului cloud este primul avertisment
Adesea un criptominer nu iese în evidență printr-o alarmă de securitate, ci în treacăt. Site-ul devine lent, furnizorul de hosting raportează o depășire a timpului de calcul, ventilatorul din propriul centru de date merge permanent sau decontul de la furnizorul cloud crește fără proiecte noi. Pentru atacatori, un miner este o cale simplă de a face bani dintr-un server compromis.
Mining înseamnă a folosi puterea de calcul a unui sistem străin pentru generarea de criptomonedă. Paguba pare limitată, deoarece nu sunt criptate date. Aceasta înșală: cine poate porni un miner poate citi și date de acces, copia baze de date și crea alte uși din spate.
După PHP2Shell, verificarea merită în mod deosebit. Vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 permit executarea de cod malițios fără autentificare. Nu există Indicators of Compromise confirmate, iar un miner nu este un semn specific pentru aceste vulnerabilități. Încărcarea mare cauzată de procese necunoscute face însă parte dintre semnele generale descrise la Sunt deja compromis?.
Interpretarea corectă a semnelor unui criptominer
Încărcarea mare are multe cauze inofensive. Tabelul ajută la prima încadrare:
| Observație | Posibilă explicație inofensivă | Ce verificați |
|---|---|---|
| CPU permanent aproape de utilizarea completă | backup, prelucrarea imaginilor, construirea indexului | Încărcarea rulează uniform și noaptea și în weekend? |
| Proces cu nume ca al unui serviciu de sistem | rar | Se află fișierul de program în calea de sistem așteptată? |
Proces sub www-data, apache sau nginx, care nu este PHP |
aproape niciodată | Cine l-a pornit, din ce director? |
Program în /tmp, /var/tmp sau /dev/shm |
aproape niciodată | De când există fișierul, cui aparține? |
| Conexiune de ieșire permanentă către o țintă necunoscută | monitorizare, actualizări | Aparține ținta unui serviciu cunoscut? |
| Încărcarea scade de îndată ce vă autentificați | rar | Unele programe malițioase fac pauză când rulează unelte de monitorizare |
Cu cât se potrivesc mai multe rânduri, cu atât este mai probabilă o constatare. Faptul că utilizatorul serverului web pornește în general programe străine este, în sine, un semnal puternic de alarmă, așa cum arată articolul Serverul web pornește un shell.
Cum verificați procesele și conexiunile
Comenzile următoare doar citesc. Notați rezultatul și ora înainte de a schimba orice:
# Procese după consumul de CPU, cu utilizator, ora de pornire și comanda completă
ps -eo pid,ppid,user,lstart,%cpu,%mem,args --sort=-%cpu | head -20
# Fișierul de program și directorul de lucru al unui proces suspect (introduceți PID-ul)
sudo ls -l /proc/PID/exe /proc/PID/cwd
# Conexiuni de ieșire cu proces
sudo ss -tnp state established
# Fișiere executabile în directoare temporare
sudo find /tmp /var/tmp /dev/shm -type f -perm -u+x -ls 2>/dev/null
Dacă /proc/PID/exe indică un fișier cu adaosul (deleted), programul a fost șters după pornire. Aceasta este o tentativă tipică de camuflaj. Procesul continuă să ruleze, iar atât timp cât rulează, fișierul de program poate fi încă păstrat prin /proc. Aceasta ar trebui s-o preia cineva care știe să lucreze cu programe malițioase; nu executați niciodată fișierul.
Cum parcurgeți sistematic procesele dincolo de miner descrie Găsirea proceselor suspecte pe serverele Linux.
De ce minerul revine mereu
Mulți operatori încheie procesul, se bucură de încărcarea în scădere și constată a doua zi că totul începe din nou. Minerele sunt aproape întotdeauna instalate cu un mecanism de repornire. Locuri tipice sunt:
- Cronjob-uri ale utilizatorului serverului web sau la nivel de sistem, care verifică la câteva minute dacă minerul rulează și îl reîncarcă altfel.
- Servicii de sistem cu nume discrete, care pornesc la boot.
- Un webshell în directorul web, prin care atacatorul repornește oricând minerul.
- Scripturi de pornire modificate sau fișiere de profil ale utilizatorilor.
- Chei SSH străine, cu care atacatorul se autentifică din nou direct.
# Cronjob-urile utilizatorului serverului web și intrările la nivel de sistem
sudo crontab -u www-data -l
ls -la /etc/cron.d /etc/cron.hourly /var/spool/cron 2>/dev/null
# Unit-urile systemd modificate cel mai recent
sudo find /etc/systemd/system /lib/systemd/system -name '*.service' -newermt "2026-10-17" -ls
Abia când toate mecanismele sunt găsite, serverul rămâne liniștit permanent. Dacă atacatorul a avut drepturi de root, o reconstruire pe un sistem proaspăt este de obicei mai de încredere decât căutarea fiecărei ascunzători.
Ordinea corectă după constatare
Un miner pare un neajuns tehnic, dar este un incident de securitate. Procedați de aceea ordonat:
- Păstrați: Copiați lista de procese, conexiunile, fișierele suspecte și logurile cu suma de control, înainte de a încheia ceva.
- Izolați: Izolați serverul sau blocați conexiunile de ieșire, dacă acest lucru este posibil fără pierdere de date.
- Închideți cauza: Aduceți PHP la un nivel corectat (8.5.12, 8.4.27, 8.3.36, 8.2.35 sau backport confirmat), reporniți toți workerii, actualizați CMS-ul și extensiile.
- Curățați sau reconstruiți: Eliminați minerul, mecanismele de repornire și ușile din spate, în caz de îndoială reinstalați.
- Verificați consecințele: Au putut fi citite date de acces sau date cu caracter personal? Atunci clarificați protecția datelor și, eventual, obligațiile de notificare.
Implicați din timp furnizorul de hosting sau cloud. Mulți furnizori blochează preventiv serverele cu încărcare sau trafic de rețea remarcabile. Cine informează el însuși furnizorul și stabilește procedura de comun acord păstrează mai probabil controlul asupra momentului opririi. Întrebați acolo și despre jurnalele de rețea și de acces ale furnizorului, deoarece ele se află în afara serverului dumneavoastră și sunt greu de modificat pentru un atacator.
Pentru conducere este importantă o încadrare scurtă, sinceră: minerul însuși costă în primul rând timp de calcul și performanță. Adevărata întrebare este însă ce a mai văzut atacatorul. Până la clarificare, incidentul nu ar trebui considerat încheiat, chiar dacă încărcarea este din nou normală.
Un criptominer arată că s-a executat cod pe serverul dumneavoastră. Tratați toate datele de acces care se aflau pe server ca posibil scurse și reînnoiți-le după curățare.
Cum ajută PHP SOS concret?
- Încadrăm încărcarea și facem diferența între cauze inofensive și procese străine.
- Păstrăm procesele, fișierele și conexiunile înainte ca minerul să fie încheiat.
- Căutăm toate mecanismele de repornire și ușile din spate și curățăm serverul în cadrul eliminării malware-ului sau îl reconstruim.
- Închidem poarta de intrare, reînnoim accesurile și configurăm o monitorizare a încărcării care raportează din timp tiparele neobișnuite.
Întrebări frecvente
Cum recunosc un criptominer pe serverul meu?
Tipică este o încărcare CPU mare permanent, care nu se potrivește cu numărul de vizitatori sau cu sarcinile programate. Se adaugă procese cu nume necunoscute sau cu sonoritate inofensivă, adesea sub utilizatorul serverului web, și conexiuni de ieșire către adrese străine. O singură trăsătură nu este încă o dovadă.
Este suficient să încheiu procesul de mining?
Nu. Minerele sunt pornite de obicei din nou și din nou prin cronjob-uri, servicii de sistem sau un webshell. Cine încheie doar procesul îl vede adesea din nou după scurt timp. În plus, rămâne deschisă poarta de intrare prin care a ajuns minerul pe server.
Este un criptominer inofensiv pentru că doar fură putere de calcul?
Nu. Cine a putut instala un miner a putut executa cod pe server. Prin aceasta erau accesibile de regulă și fișierele de configurare, datele de acces și bazele de date. Minerul este simptomul vizibil al unei intruziuni.
Ce cauze inofensive are o încărcare mare a serverului?
Backupurile, prelucrarea imaginilor, construirea indexului de căutare, crawlerele agresive sau o extensie defectuoasă pot consuma și ele mult timp de calcul. Aceste cauze pot fi de obicei atribuite unui proces și unui program cunoscut. Dacă încărcarea rămâne fără explicație, ar trebui să verificați mai atent.