Recunoașterea cronjob-urilor ascunse ca ușă din spate

Pe scurt: Un cronjob ascuns este una dintre cele mai frecvente uși din spate pe serverele Linux: încarcă regulat cod malițios sau repornește procese, chiar și după o actualizare PHP. Verificați toate locurile sarcinilor programate, nu doar crontab -l: crontab-urile tuturor utilizatorilor, /etc/crontab, /etc/cron.d, directoarele cron, timerele systemd și sarcinile at. Păstrați constatările înainte de a le elimina.

De ce sunt cronjob-urile o ușă din spate atât de iubită

După o intruziune reușită, atacatorul are o problemă: accesul lui este fragil. O actualizare închide vulnerabilitatea, un administrator șterge webshell-ul, o repornire încheie procesul. Un cronjob rezolvă această problemă. Pornește comenzi la ore fixe, fără ca cineva să intervină, și restabilește astfel accesurile pierdute.

Pentru PHP2Shell nu există Indicators of Compromise confirmate. Cronjob-urile noi se numără însă, conform rapoartelor de care dispunem, printre semnalele generale de alarmă după intruziuni prin aplicații web. Cine a căutat deja webshell-uri ar trebui să verifice odată cu ele și sarcinile programate. Celelalte etape ale unei post-intervenții le enumeră Lista de verificare după un atac.

Unde se pot ascunde sarcinile programate

Linux cunoaște mai multe mecanisme pentru sarcini programate. Multe verificări eșuează pentru că se privește doar unul dintre ele.

Important pentru serverele web: utilizatorul serverului web își poate crea de regulă propriul crontab, fără drepturi de root. Un atacator cu drepturile lui www-data nu are deci nevoie pentru aceasta de o altă vulnerabilitate. Intrările din /etc/cron.d sau unit-urile systemd indică în schimb că a obținut drepturi de root.

Panourile de hosting precum Plesk sau cPanel oferă o interfață proprie pentru sarcini programate. În spatele ei se află de regulă tot crontab-urile utilizatorilor de sistem respectivi. Cine se uită doar în interfață nu recunoaște de aceea fiecare intrare creată direct pe server. Verificați în caz de îndoială ambele.

Cum verificați complet toate locurile

Comenzile următoare doar citesc. Rulați-le ca root și păstrați rezultatele cu data.

# Afișarea crontab-urilor tuturor utilizatorilor
for u in $(cut -d: -f1 /etc/passwd); do
  out=$(crontab -l -u "$u" 2>/dev/null) && printf '### %s\n%s\n' "$u" "$out"
done

# Intrările la nivel de sistem și orele modificărilor
cat /etc/crontab
ls -la --time-style=full-iso /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

# Timere systemd și sarcini at
systemctl list-timers --all
atq 2>/dev/null

# Căutarea tiparelor tipice în toate fișierele cron
grep -rnE "curl|wget|base64|/tmp/|/dev/shm|\| *(ba)?sh" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null

Două trucuri merită o atenție deosebită. Unele intrări ascund comenzile în spatele a multor spații, astfel încât în editor ies în dreapta din imagine. Altele folosesc caractere de control care suprascriu textul la afișare. Cu cat -A astfel de caractere devin vizibile:

cat -A /var/spool/cron/crontabs/www-data 2>/dev/null | less

O a doua perspectivă sunt jurnalele serviciului cron. Pe multe sisteme, cron consemnează fiecare execuție cu utilizatorul și comanda. Astfel vedeți și intrările pe care un atacator le-a eliminat între timp și recunoașteți de când rulează o comandă suspectă:

# Comenzile cron executate de utilizatorul serverului web (Debian/Ubuntu, respectiv jurnalul systemd)
grep -h "CRON" /var/log/syslog* 2>/dev/null | grep -E "\((www-data|apache|nginx)\) CMD"
journalctl -u cron -u crond --since "2026-10-17" --no-pager 2>/dev/null | grep CMD | head -100

Cum recunoașteți o ușă din spate prin cronjob

1. Reîncărcare din internet: O descărcare al cărei rezultat este transmis direct unui shell.
2. Conținut codificat: Șiruri lungi de caractere care sunt decodificate abia la rulare.
3. Căi neobișnuite: Programe în /tmp, /dev/shm, foldere ascunse sau directoare de upload.
4. Utilizator greșit: Sarcini sub utilizatorul serverului web, deși aplicația nu are nevoie de ele.
5. Ritm remarcabil: Execuție în fiecare minut sau la fiecare repornire prin @reboot.
6. Marcaje de timp nepotrivite: Fișier modificat într-o perioadă în care nimeni nu a lucrat pe server, de exemplu după 17 octombrie.

Să nu uitați: și aplicațiile au programări proprii. WordPress, de exemplu, administrează sarcinile programate în baza de date. Cum verificați acolo descrie Găsirea backdoor-urilor în WordPress.

Păstrați constatarea, înțelegeți-o, apoi eliminați-o

Un cronjob malițios este o piesă de probă valoroasă. Arată adresa de reîncărcare, momentul creării lui și adesea utilizatorul prin care a venit atacatorul. Păstrați fișierul cu suma de control și marcajele de timp înainte de a-l elimina. Marcajul de timp ajută ulterior la reconstituirea desfășurării; cum se face arată Întocmirea cronologiei unui incident. Și pentru o eventuală notificare către autoritatea de protecție a datelor sau pentru asigurător, constatarea este o dovadă importantă a momentului de la care un atacator a avut acces.

Eliminarea singură nu este suficientă. Dacă mai rulează un proces care rescrie intrarea, ea revine după următorul minut. Iar atât timp cât vulnerabilitatea inițială este deschisă, atacatorul poate relua oricând. Ordinea este de aceea: păstrați, închideți cauza, eliminați toate componentele, schimbați accesurile, monitorizați.

Securizarea preventivă a cronjob-urilor

Pentru ca o ușă din spate prin cronjob să nu apară deloc sau să iasă repede în evidență, ajută trei măsuri. Prima: se poate stabili ce utilizatori au voie în general să creeze un crontab. Dacă există fișierul /etc/cron.allow, doar utilizatorii menționați acolo au voie să folosească crontab. Dacă aplicația dumneavoastră nu are nevoie de un cronjob sub utilizatorul serverului web, acest utilizator nu aparține listei. Verificați în prealabil ce sarcini necesită efectiv aplicația și creați-le deliberat sub un utilizator propriu.

A doua: merită monitorizarea fișierelor. O unealtă de verificare a integrității raportează de îndată ce se schimbă un fișier din directoarele cron sau de sub /var/spool/cron. A treia: sarcinile programate aparțin documentației serverului. Cine știe ce intrări ar trebui să existe recunoaște imediat una străină.

Cum ajută PHP SOS concret?

• Verificare completă: Examinăm toate mecanismele pentru sarcini programate, inclusiv timerele systemd, sarcinile at și programările aplicațiilor.
• Încadrarea constatărilor: Evaluăm intrările suspecte fără a le executa și derivăm alte urme.
• Curățare corectă: Prin eliminarea malware-ului eliminăm toate componentele și închidem cauza.
• Recunoașterea revenirii: Configurăm o monitorizare care raportează sarcinile programate noi sau modificate.

Întrebări frecvente

Surse

• BSI: Oficiul Federal German pentru Securitatea Informației
• BSI IT-Grundschutz (protecția de bază IT, Germania)
• OWASP Cheat Sheet Series