Ransomware a folosit un driver malitios semnat de Microsoft pentru a dezactiva EDR: 10 calculatoare afectate înainte de criptare

O operațiune ransomware care a evoluat în tăcere timp de patru ani a realizat ceva ce cercetătorii în securitate spun că nu au mai văzut până acum: a obținut un driver kernel semnat legitim de Microsoft, destinat exclusiv distrugerii software-ului de securitate endpoint — și l-a utilizat pentru a orbi apărările pe cel puțin 10 mașini dintr-o singură organizație victimă, înainte ca cineva să poată reacționa. Potrivit techtimes.com, echipa Symantec Threat Hunter de la Broadcom a dezvăluit campania pe 9 iulie 2026, numind ransomware-ul GodDamn și driverul kernel PoisonX.

👉 Impactul asupra securității endpoint-urilor în organizații

Dezvăluirea este crucială pentru orice organizație care utilizează endpoint-uri Windows, deoarece tehnica descrisă face ca software-ul standard de securitate endpoint să fie operațional structural inoperabil — nu evitat, nu ocolit, ci dezactivat forțat — înainte ca un singur fișier să fie criptat. Grupul din spatele GodDamn, monitorizat de Symantec sub numele de Hyadina, operează continuu din martie 2022. Produsele anterioare — ransomware-ul Monster, apoi ransomware-ul Beast după o rebranding în iunie 2024 — au vizat organizații din domeniul sănătății, manufacturii și educației din Statele Unite, evitând deliberat mașinile din țările CSI.

👉 Ce este PoisonX și cum funcționează?

PoisonX reprezintă cel de-al treilea produs al grupului, iar adăugarea sa marchează o escaladare tehnică pe care versiunile anterioare nu o aveau: o armă la nivel de kernel pe care orice instrument de securitate care rulează în spațiul utilizator este incapabil să o reziste. Pentru a înțelege ce face PoisonX și de ce funcționează, trebuie să știți un lucru despre modul în care Windows gestionează încrederea între straturile software.

Sistemul de operare își împarte mediul de execuție în inele de privilegiu. Aplicațiile obișnuite — procesatoare de texte, browsere, chiar și interfețele tabloului de bord ale produselor de securitate — rulează în Ring 3, de asemenea, numit modul utilizator. Acestea pot citi și scrie doar în memoria proprie și trebuie să ceară kernel-ului pentru acces mai sensibil. Codul kernel-mode rulează în Ring 0. Acesta are acces necondiționat la toată memoria, la tot hardware-ul și capacitatea de a termina orice proces de pe mașină — așa cum este explicat în arhitectura kernel-mode Windows.

👉 Detalii despre PoisonX

PoisonX (stocat pe disc ca g11.sys) nu este un driver defect pe care atacatorii l-au găsit și l-au armaizat — este un driver scris specific pentru a ucide software-ul de securitate, cu o interfață IOCTL nedeclarată care primește comenzi de ucidere de la codul controlat de atacatori. Când symantec.exe — un executabil pe care atacatorii l-au numit după produsul Symantec — plasează PoisonX în magazinul de drivere Windows și îl înregistrează ca un serviciu, driverul se încarcă imediat și începe să elimine apelurile kernel pe care instrumentele EDR le utilizează pentru a primi notificări despre evenimentele sistemului. Instrumentele continuă să ruleze. Tablourile lor de bord arată verde. Dar au devenit oarbe — sistemul de operare nu le mai spune ce se întâmplă pe mașină.

Cel mai neliniștitor detaliu în dezvăluirea Symantec de pe 9 iulie nu este că PoisonX există. Este că PoisonX poartă o semnătură validă "Microsoft Windows Hardware Compatibility Publisher" — ceea ce înseamnă că programul de Compatibilitate Hardware al Microsoft a procesat și semnat acest driver. Acest lucru este suficient de neobișnuit încât Brigid O Gorman a abordat direct: "este ușor de spus că nu ar fi trebuit semnat de Microsoft. Totuși, nu știm pașii parcurși de atacatori pentru a obține semnătura driverului sau cum ar putea să-l fi înșelat pe Microsoft în a face acest lucru." Gap-ul pe care această explicație îl relevă este structural.

Programul de semnare a driverelor Microsoft verifică identitatea editorului — confirmă că cel care a trimis acest driver a trecut prin procesul de verificare a Centrului de Dezvoltare a Hardware-ului. Nu analizează comportamentul driverului sau scanează interfețele IOCTL malitioase. Un dezvoltator care trece cu succes de verificarea identității și trimite un driver prezentat ca un instrument de cercetare în securitate poate primi o semnătură pentru cod destinat exclusiv terminării proceselor antivirus. Sistemul nu este rupt; funcționează exact așa cum a fost proiectat. Designul pur și simplu nu ia în considerare un dezvoltator care acționează cu rea-voință în timp ce prezintă acreditive legitime.

👉 Atacul din iunie 2026

Incidentul analizat de Symantec în detaliu a avut loc între 29 mai și 3 iunie 2026 și reprezintă o intruziune deliberată, etapizată, nu o acțiune impulsivă. Metoda exactă prin care Hyadina a obținut pentru prima dată acces la organizația victimă era necunoscută — vectorul inițial de acces nu a fost niciodată identificat. Prima activitate malițioasă confirmată a apărut pe 29 mai, când o instalare AnyDesk a apărut pe Computer 1 din organizație, într-un director neobișnuit. Pe 30 mai, operatorii s-au mutat pe un al doilea host și au aranjat symantec.exe în același loc, care a dus la plasarea PoisonX în magazinul de drivere de sistem ca g11.sys.

Prin 2 iunie, operatorii au folosit PsExec pentru a se deplasa lateral și au instalat AnyDesk pe cel puțin 10 hosturi din organizație. Pe 3 iunie, payload-ul de criptare a apărut pe un segment de rețea separat, renunțând fișierele criptate folosind numele organizației victimă ca extensie de fișier.

👉 Recomandări pentru echipele de securitate

Gap-ul blocklistului nu înseamnă că protecția endpoint-ului este inutilă — înseamnă că nu poate fi singurul strat de protecție. La activarea HVCI (Hypervisor-Protected Code Integrity) pe endpoint-urile Windows unde nu este deja activ, ar trebui să fie o prioritate. Politicile WDAC (Windows Defender Application Control) pot preveni încărcarea driverelor neautorizate înainte ca un driver să ajungă la kernel. Monitoarele evenimentului de instalare a driverului oferă o alertă timpurie care nu depinde de cunoștințele despre semnătură.

Organizațiile ar trebui să treacă în revistă aceste hash-uri împotriva inventarului lor de endpoint-uri și magazinelor de drivere, indiferent dacă EDR-ul lor a semnalat ceva. Întregul punct al PoisonX este că un EDR care a fost orbit nu va semnala ceea ce a venit ulterior.