PEERSTITCH: cum o breșă în FortiManager a dus la implanturi doar în memorie pe firewall-urile FortiGate

Un grup de atacatori pe care Palo Alto Networks Unit 42 îl urmărește sub numele CL-STA-0954 (cunoscut și ca UNC5820) a compromis un furnizor de servicii gestionate din telecomunicații, țintind exact echipamentul care le controlează pe toate celelalte: consola FortiManager. De acolo, atacatorii au trecut pe firewall-urile FortiGate administrate și au instalat PEERSTITCH, un implant care trăiește în procese legitime FortiOS, nu pe disc.

Ce s-a întâmplat

Pasul 1: compromiterea consolei de management. În septembrie 2024, atacatorii au exploatat CVE-2024-47575 („FortiJump”), o vulnerabilitate de autentificare lipsă în canalul de management al FortiManager, care permite executarea de comenzi de la distanță fără autentificare. Au înregistrat un FortiGate fals, au împachetat datele echipamentului și le-au scos din rețea.

Arhiva acoperea peste 500 de firewall-uri administrate: configurații, numere de serie, IP-uri publice, rute, reguli de firewall, plus credențialele criptate de administrare și VPN și certificatele prin care FortiManager „are încredere” în dispozitive. Unit 42 spune că parolele de administrare și VPN au putut fi recuperate din fișierele furate. Atenție însă: cercetătorii precizează că furtul nu confirmă, în sine, compromiterea tuturor firewall-urilor clienților.

Pasul 2: recunoaștere discretă. După o perioadă de inactivitate, atacatorii au folosit FortiManager pentru a trimite reguli neautorizate de captură de pachete către anumite firewall-uri, vizând trafic HTTP necriptat, TFTP, RADIUS și LDAP, adică trafic care poate expune fișiere, date de autentificare și activitate din director. Cu credențialele recuperate, au deschis apoi sesiuni SSL-VPN neautorizate către zone interne de management.

Pasul 3: acces root pe firewall. Potrivit Unit 42, grupul a folosit o a doua vulnerabilitate, CVE-2025-61624, de tip path traversal în funcția system.auto-script din FortiOS. Cu drepturi de administrator, un nume de script manipulat (ex. ../../../../setup) scrie fișiere în afara directorului permis și le rulează ca root, astfel că o interfață de administrare restricționată devine control total asupra sistemului de operare.

Pasul 4: implantul PEERSTITCH. Un loader a descărcat un runner Node.js, componente JavaScript/WebAssembly și un binar nativ ARM64 numit lldprx. După o întârziere, lldprx s-a atașat prin ptrace la două procese esențiale, miglogd (jurnalizare) și iked (VPN IKE/IPsec). În fiecare a alocat o zonă de memorie de 16 KB cu drepturi de citire-scriere-execuție, și-a încărcat payload-ul și a deturnat execuția. Cele două procese au schimbat apoi etichete de sesiune prin /proc/<pid>/mem, astfel încât traficul VPN cu anumite marcaje să poată ocoli verificările normale de securitate FortiOS.

Pericolul stă în design: niciun binar persistent, niciun port deschis, nicio conexiune proprie spre exterior. Se ascunde în procese și trafic pe care apărătorii se așteaptă oricum să le vadă.

Pasul 5: un canal de rezervă și ștergerea urmelor. Atacatorii au abuzat și de modulul Apache mod_md (gestiune automată a certificatelor), astfel încât validarea certificatelor să ruleze comenzi prin Node.js și să contacteze infrastructura lor, obținând astfel un al doilea canal de control. Pentru a-și acoperi urmele, au oprit jurnalizarea, au șters jurnalele de crash, conturile și scripturile auto-script folosite, au înlocuit o configurație Apache malițioasă cu text aparent inofensiv, iar lldprx s-a șters singur la final.

De ce contează

Consolele de management centralizat sunt un punct unic de încredere. Odată căzut FortiManager, atacatorii au avut harta completă a infrastructurii clienților și cheile pentru a se autentifica în ea. Pentru un MSP, o singură breșă devine breșa tuturor clienților. Implanturile doar în memorie, ascunse în procese de sistem, trec și de verificările obișnuite de tip „scanează discul, verifică porturile”, așa că o configurație aparent curată nu dovedește că dispozitivul e curat.

Ce trebuie făcut

1. Aplicați patch-urile pentru ambele vulnerabilități. Verificați că FortiManager este corectat pentru CVE-2024-47575 și că FortiOS rulează o versiune care rezolvă CVE-2025-61624. Nu expuneți interfața FGFM a FortiManager pe internet.
2. Auditați FortiManager. Căutați înregistrări de dispozitive necunoscute (seriale sau IP-uri pe care nu le recunoașteți), conturi de administrator nefamiliare și modificări neașteptate de politici sau capturi de pachete.
3. Căutați urme pe FortiGate. Verificați obiectele auto-script pentru șiruri de tip ../../, profiluri de sniffer/captură neașteptate și corelați login-urile SSL-VPN cu utilizatorii și locațiile cunoscute.
4. Verificați memoria proceselor. Conform recomandărilor Unit 42, inspectați hărțile de memorie ale miglogd și iked pentru zone anonime de ~16 KB cu drepturi RWX, scrieri între procese în /proc/<pid>/mem și crash-uri inexplicabile ale acestor procese.
5. Comparați configurațiile cu backup-uri sigure, inclusiv setările Apache/ACME (mod_md) de pe echipament.
6. Presupuneți expunerea și schimbați secretele. Dacă serverul de management a fost compromis, tratați ca expuse toate credențialele, certificatele și secretele stocate: parole de admin și VPN, chei pre-partajate, certificate.
7. Blocați și căutați IoC-urile publicate. Unit 42 indică infrastructură precum 23.240.77[.]233 și 47.18.167[.]159 (găzduire malware/ACME), 45.32.41[.]202 și 198.199.122[.]22 (activitate FortiGate falsă), plus fișierele lldprx, pM.js, index.js, index.wasm și ipssem.js. Importați lista completă de hash-uri din cercetarea originală în SIEM sau platforma TI.

Vreți să aflați dacă infrastructura Fortinet este expusă? Monitorizarea suprafeței de atac și evaluările de vulnerabilitate 4Tify identifică interfețele de management expuse și firmware-ul vulnerabil înaintea atacatorilor.

Pe baza relatărilor Cyber Security News și a cercetării tehnice publicate de Palo Alto Networks Unit 42.