Gunra ransomware: exercițiul de awareness pe care trebuie să-l facă IT, managementul și help desk-ul

Pe 10 august 2026, CISA, FBI, NSA, U.S. Secret Service, DC3 și Poliția Națională din Coreea de Sud au publicat o alertă comună despre Gunra ransomware. Documentul tehnic descrie acces prin echipamente firewall și VPN, furt de sesiuni și credențiale, modificarea autentificării, exfiltrare din OneDrive și SharePoint, criptare și ștergerea backupurilor.

De ce un curs generic nu acoperă acest scenariu

Alerta nu atribuie intrarea inițială unei campanii de phishing pentru fiecare victimă. Autoritățile au observat exploatarea unor vulnerabilități cunoscute în echipamente FortiOS/FortiProxy, probleme de control al accesului în gateway-uri VPN și folosirea unor credențiale implicite. A inventa un scenariu cu „angajatul care a dat click” ar muta atenția de la controalele care au eșuat efectiv.

• IT operations trebuie să știe cine răspunde de fiecare appliance expus și cum demonstrează versiunea și configurația curentă.
• Help desk-ul și identity team trebuie să poată revoca sesiuni, nu doar să reseteze o parolă.
• SOC-ul trebuie să distingă folosirea legitimă de cea neobișnuită a RDP, Impacket, RClone, AnyDesk, 7-Zip sau FileZilla.
• Echipa de backup trebuie să poată demonstra restaurarea dintr-o copie separată, nu doar existența unui job „verde”.
• Managementul trebuie să poată decide rapid izolarea, continuitatea, comunicarea și raportarea fără să aștepte certitudine perfectă.

Scenariul tabletop în patru injecturi

Rulează exercițiul cu reprezentanți din IT, SOC, help desk, legal/compliance, comunicare și management. Nu le arăta tot incidentul de la început. Oferă informația în patru etape și cere pentru fiecare: decizie, owner, termen, dovadă și criteriu de escaladare.

• Inject 1 — la 02:15 apare o autentificare administrativă neobișnuită pe SSL-VPN și un tunel SSH. Cine validează schimbarea și în cât timp?
• Inject 2 — un utilizator are MFA activ, dar sesiunea VDI apare din alt context. Este resetarea parolei suficientă? Ce sesiuni și tokenuri sunt revocate?
• Inject 3 — apar arhive mari și trafic către un serviciu legitim de transfer. Ce loguri păstrezi, ce izolezi și cine decide dacă este exfiltrare?
• Inject 4 — fișierele sunt criptate, iar backupul din disaster recovery nu mai este disponibil. Ce copie rămâne, cât durează restaurarea și cine pornește raportarea?

MFA a fost ocolit: ce trebuie să învețe help desk-ul

Într-un incident descris în alertă, actorii au reutilizat informații de sesiune și au modificat fișierele portalului de autentificare astfel încât o valoare OTP aleasă de ei să fie acceptată. Mesajul corect pentru echipă este că MFA reduce riscul, dar nu repară un server de autentificare compromis și nu invalidează automat sesiunile deja furate.

• Nu confirma identitatea apelantului doar fiindcă știe numele managerului, structura echipei sau detalii interne.
• Folosește un canal verificat separat pentru cereri urgente de resetare, dezactivare MFA sau acces privilegiat.
• La suspiciune de furt de sesiune, escaladează pentru revocarea tokenurilor și verificarea endpointului și a serviciului de autentificare.
• Nu transmite parole temporare, chei sau coduri de recuperare în același chat sau e-mail în care a apărut solicitarea.

Ce măsori după exercițiu

• Timp până la identificarea ownerului pentru gateway-ul afectat.
• Timp până la izolarea sistemului și revocarea sesiunilor privilegiate.
• Procentul de participanți care separă resetarea parolei de revocarea sesiunii și verificarea integrității MFA.
• Timpul demonstrat de restaurare din copia offline sau imuabilă.
• Calitatea cronologiei: ce s-a observat, ce s-a decis, cine a aprobat și pe ce dovadă.
• Numărul de contacte, pași sau permisiuni lipsă descoperite în playbook.

Un rezultat bun nu este o sală care a memorat numele Gunra. Este o echipă care reduce timpul dintre semnal și decizia corectă, fără să distrugă dovezi și fără să lase recuperarea sau raportarea pentru momentul în care criptarea este deja completă.