Ransomware folosește un driver malițios semnat de Microsoft pentru a dezactiva EDR
O operațiune de ransomware care a evoluat în liniște timp de patru ani a reușit ceva ce cercetătorii în securitate spun că nu au mai văzut înainte: a obținut un driver de kernel Microsoft semnat legitim, proiectat exclusiv pentru a distruge software-ul de securitate endpoint — și l-a folosit pentru a blinda 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.
👉 Descrierea campaniei GodDamn și caracteristicile driverului PoisonX
Echipa de Threat Hunter de la Symantec, parte a Broadcom, a făcut publică această campanie pe 9 iulie 2026, numind ransomware-ul GodDamn și driverul kernel PoisonX. Această dezvăluire este importantă pentru orice organizație care utilizează puncte finale Windows, deoarece tehnica descrisă face ca software-ul de securitate standard să devină structural ineficient — nu ocolit, nu evitat, ci dezactivat cu forța — înainte ca vreun fișier să fie criptat.
Grupul din spatele GodDamn, urmărit de Symantec sub denumirea Hyadina, a operat continuu din martie 2022. Produsele sale anterioare — ransomware-ul Monster, apoi ransomware-ul Beast după o rebranding din iunie 2024 — au vizat organizații din domeniul sănătății, fabricației și educației din Statele Unite, evitând deliberate mașinile din țările Comunității Statelor Independente. GodDamn reprezintă al treilea produs al grupului, iar adăugarea lui PoisonX marchează o escaladare tehnică pe care versiunile anterioare nu o aveau: o armă la nivel de kernel la care orice instrument de securitate care rulează în spațiul utilizatorului este incapabil să reziste.
👉 Mecanismul de funcționare și impactul asupra securității endpoint
Pentru a înțelege ce face PoisonX și de ce funcționează, trebuie să știm un aspect despre cum Windows gestionează încrederea între straturile de software. Sistemul de operare împarte mediul său de execuție în inele de privilegiu. Aplicațiile obișnuite — procesatoare de text, browsere, chiar și interfețele instrumentelor de securitate — rulează în Ring 3, numit și modul utilizator. Acestea pot citi și scrie doar în memoria proprie și trebuie să ceară kernel-ului tot ce este mai sensibil. Codul kernel-operat rulează în Ring 0, având acces necondiționat la toată memoria și hardware-ul, precum și capacitatea de a închide orice proces de pe mașină.
Produsele EDR (Detectare și răspuns endpoint) se protejează de interferență folosind o caracteristică numită Protected Process Light, care împiedică administratorii de modul utilizator să le oprească. Totuși, protecția împotriva intervenției operează în Ring 3. Un proces care rulează în Ring 0 nu trebuie să ceară — se poate conecta direct la memoria unui proces de securitate și îl poate termina, indiferent de protecțiile pe care acel proces le-a setat pentru sine. Exact asta face PoisonX.
Cel mai îngrijorător detaliu în dezvăluirea din 9 iulie a Symantec nu este existența lui PoisonX. Este faptul că acesta poartă o semnătură validă "Microsoft Windows Hardware Compatibility Publisher" — ceea ce înseamnă că propriul program de compatibilitate hardware al Microsoft a procesat și semnat acest driver. Aceasta este o situație îndeajuns de neobișnuită încât Brigid O Gorman a abordat-o direct: "este ușor să spui că nu ar fi trebuit să fie semnat de Microsoft. Totuși, nu știm pașii urmați de atacatori pentru a obține semnătura driverului sau cum ar fi putut înșela Microsoft în a face asta."
Explicația relevă o lacună structurală. Programul de semnare a driverelor Microsoft verifică identitatea editorului — confirmând că cel care a trimis acest driver a trecut prin procesul de verificare a centrului de dezvoltare hardware. Nu analizează comportamentul driverului sau scanează pentru interfețe IOCTL malițioase. Un dezvoltator care trece cu succes de verificarea identității și trimite un driver înfățișat ca un instrument de cercetare în securitate poate obține o semnătură pentru cod conceput exclusiv pentru a termina procese antivirus. Sistemul nu este defect; funcționează exact așa cum este proiectat. Designul pur și simplu nu ia în calcul un dezvoltator care acționează de rea-credință, prezentând acreditive legitime.
Incidentul analizat în detaliu de Symantec a avut loc între 29 mai și 3 iunie 2026 și reprezintă o intruziune deliberată, etapizată, nu o acțiune pe repede înainte. Metoda exactă prin care Hyadina a obținut pentru prima dată accesul la organizația victimă este necunoscută — vectorul de acces inițial nu a fost niciodată identificat. Prima activitate malițioasă confirmată a apărut pe 29 mai, când o instalare AnyDesk pentru desktop la distanță a apărut pe Computer 1 din organizație. Fișierul nu se afla în directorul de instalare standard — era în folderul Muzica utilizatorului, o locație inconsistentă cu desfășurarea autorizată IT. Acesta făcea conexiuni externe către adrese IP necunoscute. Atacatorii erau deja în interior.
Pe 30 mai, operatorii au trecut la un al doilea gazdă și au stageat symantec.exe în folderul Muzica. Fișierul a plasat PoisonX în magazinul de drivere de sistem ca g11.sys. Pe aceeași gazdă, un kit de 14 instrumente de colectare a acreditivelor a apărut într-un subdirector al profilului utilizatorului. Treisprezece dintre aceste instrumente proveneau de la NirSoft, un site legitim de utilitare Windows. Al paisprezecelea era Mimikatz. Împreună, acestea au extras acreditive din browsere, Windows Credential Manager, logările de domeniu cache, sesiunile VNC, clienții de e-mail, profilurile Wi-Fi și traficul rețelei active, conform echipei de Threat Hunter Symantec.
Până pe 2 iunie, operatorii au folosit PsExec pentru a se deplasa lateral și a instala AnyDesk — ca un serviciu Windows autostart înregistrat — pe cel puțin 10 gazde din organizație. După finalizarea fiecărei instalări AnyDesk, au încheiat procesul AnyDesk aflat în rulare, au așteptat puțin și au repornit mașina. Rezultatul a fost o pată sură persistentă de acces la distanță, care a supraviețuit repornirilor, distribuită pe o zecime de sisteme. Pe 3 iunie, payload-ul de criptare a apărut pe un segment de rețea separat.
Tehnica utilizată de GodDamn are un nume în industria de securitate: Bring Your Own Vulnerable Driver (BYOVD). Forma standard a atacului implică găsirea unui driver semnat dar defect — o utilitate grafică, componenta anti-cheat a unui joc, un instrument de monitorizare a hardware-ului — și exploatarea vulnerabilităților sale pentru a ajunge în Ring 0. BlackByte, AvosLocker, grupul Lazarus, Qilin, Warlock și DeadLock au desfășurat toate operațiuni BYOVD. PoisonX reprezintă o variantă diferită: nu un driver legitim defect, ci un driver malițios deliberat care a trecut cumva de revizuirea semnăturii Microsoft.
Distincția este importantă operațional. Instrumentele BYOVD convenționale exploatează o eroare într-un driver care are un anumit scop legitim — ceea ce înseamnă că driverul ar putea fi în cele din urmă reparat și patch-ul reduce suprafața de atac. PoisonX nu are o eroare de reparat. Face exact ceea ce autorul său a proiectat să facă. Singura măsură de atenuare este blocarea acestuia după hash sau certificatul editorului — ceea ce este exact ceea ce face Vulnerable Driver Blocklist.
Gapul în actualizarea listei de blocare nu înseamnă că protecția endpoint este inutilă — înseamnă că nu poate fi singura strat care contează. Cercetarea Symantec și literatura mai largă privind BYOVD converg asupra mai multor controale care funcționează independent de faptul dacă un driver specific a fost blocat. HVCI (Hypervisor-Protected Code Integrity) este cel mai important. Prin mutarea aplicării integrității codului în hypervisor — un strat sub Ring 0 — HVCI poate bloca codul kernel care nu a fost explicit permis, chiar dacă acel cod poartă o semnătură Microsoft.
Acțiunile propuse includ activarea HVCI pe implementările Windows enterprise unde nu este deja activ, configurarea politicilor WDAC pentru a bloca încărcarea driverelor neautorizate, aplicarea regulilor de blocare recomandate de Microsoft și monitorizarea evenimentelor de instalare a driverelor. Instalarea event monitoring oferă o avertizare timpurie care nu depinde de cunoașterea semnăturii.