PEERSTITCH: implant care rulează doar în memorie și deturnează VPN-ul FortiOS

Un actor de amenințare suspectat a fi avansat a fost surprins rulând un implant nou, rezident în memorie, pe firewall-urile Fortinet FortiGate (ARM64). Botezat PEERSTITCH de Palo Alto Networks Unit 42, malware-ul nu lasă fișiere pe disc, nu deschide porturi și nu inițiază conexiuni proprii — în schimb, modifică discret modul în care daemonul VPN al firewall-ului tratează anumite sesiuni marcate.

Ce s-a întâmplat

Unit 42 a descoperit activitatea investigând o intruziune de lungă durată la un furnizor de servicii gestionate din telecomunicații. Gruparea este urmărită ca CL-STA-0954 (cunoscută și ca UNC5820). Conform raportării, lanțul de atac a arătat așa:

• Acces inițial prin FortiManager. Atacatorii au exploatat FortiJump (CVE-2024-47575), o vulnerabilitate critică FortiManager, pentru a prelua consola centrală de management.
• Furt masiv de date de management. Din FortiManager au extras configurațiile active pentru peste 500 de firewall-uri FortiGate (rețele interne și ale clienților), numere de serie asociate cu IP-uri publice, baze de date SQLite, hărți de topologie și rutare, credențiale criptate (admin, locale, SSL-VPN), plus certificate și chei private.
• Pivotare spre perimetru. Cu aceste date au cartografiat rețeaua, au deschis sesiuni SSL-VPN neautorizate, au interceptat trafic, au instalat backdoor-uri și au folosit CVE-2025-61624 — o vulnerabilitate de tip path traversal în CLI-ul FortiOS (CVSS 5.4, corectată de Fortinet în aprilie 2026) — pentru escaladarea privilegiilor și instalarea PEERSTITCH.
• Un al doilea canal C2. Separat, atacatorii au abuzat modulul Apache mod_md integrat în FortiGate pentru un reverse shell prin SSH și s-au dat drept FortiManager pentru a extrage date de pe alte firewall-uri gestionate.

Unit 42 menționează CVE-2024-26008 și CVE-2024-26009 ca vectori posibili, dar subliniază că acest lucru nu este confirmat — aceste vulnerabilități necesită înrolare în FortiCloud SSO, pe care niciunul dintre firewall-urile afectate nu o avea.

Cum funcționează PEERSTITCH

Un auto-script descarcă cinci componente (două fișiere JavaScript, un runtime Emscripten, un modul WebAssembly și un injector nativ ARM64) de pe infrastructura atacatorului, le plasează în /data2/template/, apoi:

1. Injectorul (lldprx) se atașează la daemonii miglogd și iked prin ptrace, îi oprește temporar, alocă un mic buffer executabil și plantează câte un hook în fiecare.
2. Cele două hook-uri comunică prin /proc/<pid>/mem, formând o punte ascunsă, în memorie, între două procese FortiOS legitime.
3. miglogd caută în datele care trec un marcaj (valoarea de port TCP 8550 inclusă în trafic și adresa link-local 169.254.0.1) și transmite identificatorul sesiunii către iked.
4. Când o sesiune VPN poartă acest marcaj, iked urmează o cale alternativă care ocolește validările de securitate standard FortiOS.
5. Injectorul șterge apoi toate fișierele și se oprește.

În plus, operatorii au oprit generarea syslog, au șters crash log-urile, au perturbat telemetria și au eliminat automat conturile de admin și auto-script-urile folosite.

De ce contează

• O consolă, sute de firewall-uri. Compromiterea FortiManager a oferit acces la întreaga flotă gestionată, inclusiv la rețelele clienților — un risc clasic de lanț de aprovizionare pentru MSP-uri.
• Construit să evite EDR și NDR. Fără fișier pe disc, fără port deschis, fără beacon: detecția clasică are prea puțin de prins.
• Secretele furate rămân valabile după patch. Odată exfiltrate configurațiile, credențialele și cheile private, simpla actualizare nu elimină atacatorul.

Ce trebuie făcut

1. Actualizați FortiManager și FortiOS — verificați corecțiile pentru CVE-2024-47575 și CVE-2025-61624 (și pentru FortiPAM, FortiProxy, FortiSwitchManager, dacă le folosiți).
2. Scoateți interfețele de management de pe internet. FortiManager și interfețele de administrare FortiGate (inclusiv FGFM) trebuie accesibile doar dintr-o rețea dedicată de management.
3. Considerați compromise secretele dintr-un FortiManager afectat. Schimbați credențialele admin, locale și SSL-VPN, reemiteți certificatele și cheile private și verificați fiecare dispozitiv gestionat.
4. Căutați urme direct pe echipamente. Auto-script-uri necunoscute, conturi de admin efemere, fișiere în /data2/template/, activitate neobișnuită mod_md, goluri sau tăceri bruște în syslog și crash log-uri. Pentru implanturi doar în memorie, verificările de integritate Fortinet și un reboot/reinstalare sunt mai sigure decât analiza log-urilor.
5. Monitorizați comportamentul VPN, nu doar fișierele. Stabiliți o linie de bază pentru sesiunile SSL-VPN/IKE și alertați la autentificări din surse neobișnuite sau sesiuni care ocolesc MFA/verificările de conformitate.
6. Blocați infrastructura raportată — de ex. 23.240.77[.]233:8085 — știind că IOC-urile se schimbă rapid.
7. MSP-uri: segmentați clienții. Un singur plan de management nu trebuie să fie cheia către toți clienții.

Vreți o perspectivă externă asupra expunerii echipamentelor de perimetru și a interfețelor de management? Echipa 4Tify poate realiza o evaluare autorizată a perimetrului dumneavoastră.

Sursă: acest material se bazează pe cercetarea publicată de Palo Alto Networks Unit 42 și relatată inițial de The Hacker News (Ravie Lakshmanan, 16 oct. 2026). Articolul este rezumatul și analiza proprie 4Tify.