Când infrastructura funcționează, dar fișierele nu se mai deschid: recuperarea unui file server criptat de ransomware pe Nutanix AHV cu Rubrik

„Folderele sunt acolo, dar fișierele nu se mai pot deschide!”

Este luni dimineață, aproximativ ora 08:15. Primesc un apel de la Elena, din departamentul financiar. Îmi spune că are acces pe share-ul companiei și că folderele sunt acolo, dar că nu i se deschide fișierul la care lucrează zi de zi, bugeteQ4-2026.xlsx. Cei din departamentul financiar lucrează pe un drive, mapat la share-ul \\FS-PROD-07\Financiar. Mai spune Elena și că iconițele fișierelor s-au schimbat. O rog să-mi citească numele complet al fișierului și îmi spune că este bugeteQ4-2026.xlsx.locked. O rog să verifice și un alt fișier din același folder. Acesta apare acum cu următoarea denumire: contract-furnizor-2026.pdf.locked. Numele originale și extensiile .xlsx sau .pdf sunt încă vizibile, dar tuturor fișierelor le-a fost adăugată aceeași extensie necunoscută: .locked.

În acel moment,  primul gând care îmi trece prin cap este… ransomware!

Mă apuc să verific. De pe o stație cu drepturi de administrator, accesez direct share-urile serverului. Pot lista folderele și conținutul lor. Verific \\FS-PROD-07\Financiar și \\FS-PROD-07\Achizitii. Fișierele sunt vizibile, la fel și dimensiunile lor. Numele lor sunt încă recognoscibile, dar aceeași extensie a fost adăugată fișierelor. Apoi găsesc câte un fișier README_TO_RESTORE.txt în mai multe foldere verificate din share-urile Financiar și Achiziții. Îl deschid. Mesajul din interior cere să îi contactăm pe atacatori. Extensiile schimbate, fișierele care nu se mai deschid și mesajul de răscumpărare reprezintă dovada clară că datele au fost criptate în urma unui atac ransomware.

Luni, ora 08.15: infrastructura este disponibilă, datele nu

Pentru a-mi face o imagine generală a incidentului, deschid Prism Central, interfața centrală de administrare a infrastructurii virtuale, Nutanix. Toate nodurile sunt online. Nu există alarme critice pentru clusterul Nutanix format din 3 servere Lenovo ThinkAgile HX care găzduiește mașina virtuală FS-PROD-07. Cel mai probabil, Nutanix nu este cauza indisponibilității. Deschid consola VM-ului din Prism. Consola este echivalentul virtual al conectării unui monitor și a unei tastaturi direct la un server fizic. Windows Server rulează normal. După câteva verificări trag concluzia că nodurile fizice sunt online. Clusterul funcționează. AHV rulează VM-ul. AOS pune la dispoziție disk-urile virtuale. Windows-ul pe VM-ul cu pricina e pornit. Rețeaua ajunge la VM. SMB răspunde. Dar niciuna dintre aceste verificări nu demonstrează că fișierele sunt și utilizabile. Nimic nu indică o problemă a platformei Nutanix care să explice incidentul. VM-ul Windows încă rulează, dar datele din interiorul lui au fost criptate. Primul lucru pe care îl fac este să deconectez vNIC-ul de la rețeaua de producție și să opresc VM-ul. Prin deconectare elimin imediat accesul la rețea, iar oprirea VM-ului blochează orice activitate în interiorul sistemului de operare. Întrebarea este: ce restaurez și din ce recovery point? Pentru a înțelege opțiunile de recovery disponibile luni dimineață, trebuie să ne întoarcem cu șase luni în urmă.

Cu șase luni în urmă: migrarea de la VMware la Nutanix AHV

Compania folosea VMware și a decis să migreze o mare parte din mediul virtual pe Nutanix AHV, instalat pe servere Lenovo ThinkAgile HX.

Lenovo ThinkAgile HX oferă platforma fizică. Nodurile HX conțin procesoarele, memoria, disk-urile locale și interfețele de rețea folosite de cluster. Acestea formează platforma pe care funcționează software-ul Nutanix.

Nutanix AOS (Acropolis Operating System) oferă storage distribuit la nivelul clusterului. Practic, AOS combină resursele de stocare ale nodurilor din cluster și prezintă VM-urilor spațiul de storage de care au nevoie. Un VM precum FS-PROD-07 folosește astfel disk-uri virtuale furnizate de platforma Nutanix, în loc să depindă de un storage separat.

Nutanix AHV (Acropolis Hypervisor) este hypervisorul. Un hypervisor este layer-ul software care creează și rulează mașini virtuale și le alocă resurse de procesare, memorie și rețea. În acest mediu, AHV are un rol similar cu ESXi într-un mediu VMware.

Prism Element administrează un singur cluster individual Nutanix. Oferă vizibilitate detaliată pentru operațiuni precum verificarea hosturilor, a storage-ului și a VM-urilor locale.

Prism Central în schimb oferă vizibilitate și administrare centralizată pentru mai multe clustere. Este primul loc în care se verifică starea generală a infrastructurii.

La nivelul workload-ului, FS-PROD-07 este un VM Windows Server care rulează pe AHV și folosește storage AOS. Nutanix oferă deja reziliență la nivelul infrastructurii, snapshot-uri și capabilități de disaster recovery. Rubrik oferă însă un layer independent de backup și recovery, cu propriile recovery points, politici de retenție și workflow-uri de restaurare.

Compania a implementat infrastructură fizică Rubrik pe hardware HPE ProLiant DL360 Gen11, într-o configurație validată și suportată conform cerințelor de compatibilitate Rubrik. Infrastructura este conectată la Rubrik Security Cloud (RSC). Rubrik Security Cloud este o platforma SaaS din care se pot administra centralizat workload-urile, politicile SLA, recovery point-urile, joburile și Data Threat Analytics. Infrastructura Rubrik a fost conectată la Prism Central. Astfel, Rubrik putea descoperi clusterele Nutanix administrate prin Prism Central și VM-urile care rulau pe ele. Discovery-ul însemna că platforma de backup putea vedea obiecte precum VM-ul FS-PROD-07. Acest lucru nu însemna că fiecărui VM descoperit îi era și aplicată automat o protecție. Protecția era controlată printr-un Rubrik SLA Domain. Un SLA Domain definește cât de des este protejat un workload și cât timp sunt păstrate recovery point-urile sale. Politica SLA poate include și alte cerințe legate de ciclul de viață al datelor. Am activat și Rubrik Data Threat Analytics – Anomaly Detection. Această funcție analizează automat snapshot-urile protejate și compară modificările apărute între două recovery point-uri succesive. Astfel, Rubrik poate identifica un volum neobișnuit de fișiere modificate, indicii asociate criptării sau snapshot-uri în care apare activitate suspectă.

Înapoi la ziua de luni: cel mai nou recovery point nu este automat și cel mai bun

Luni dimineață, Rubrik afișa patru recovery point-uri recente ale VM-ului FS-PROD-07: unul de duminică ora 22:00 și altele de luni ora 01:00, ora 04:00 și ora 07:00. Fișierele criptate au fost descoperite cu puțin timp înainte de ora 08:00. Nimeni nu știe dacă procesul de criptare a început la 07:50 sau mai devreme. Extensiile ciudate ne arată ce s-a întâmplat cu documentele, nu momentul exact în care au avut loc modificările. Un coleg propune restaurarea celui mai nou recovery point, cel de la ora 07:00, motivând că cea mai recentă copie ar duce la cea mai mică pierdere de date. Este însă posibil ca acel snapshot să conțină deja fișierele criptate. Deschid în Rubrik Security Cloud informațiile de anomalie pentru VM-ul FS-PROD-07. Snapshot-urile de la 04:00 și 07:00 sunt semnalate ca anormale. Recovery point-ul de la 01:00 este cel care pare curat, iar Rubrik îl sugerează drept candidat pentru recovery. Asta nu înseamnă că snapshot-ul de la 01:00 este garantat curat. Funcționalitate de Anomaly Detection îmi arată unde apar schimbările suspecte și mă ajută să evit snapshot-urile afectate. Nu poate demonstra însă cu precizie că înainte de ora 01:00 nu exista deja o modificare nedorită sau un fișier malițios care nu produsese o anomalie. După o analiză, decidem că snapshot-ul de luni, ora 01:00, este primul candidat pentru testarea recovery-ului. Informațiile disponibile ne oferă suficientă încredere pentru a-l valida. Alegerea recovery point-ului de la 01:00 în locul celui de la 07:00 duce la pierderea a până la șase ore de change-uri legitime.

Recovery pentru FS-PROD-07

Pasul 1: VM-ul compromis rămâne izolat

Înainte să execut orice operațiune în Rubrik, mă întorc în Prism Central și verific din nou VM-ul original FS-PROD-07. Confirm că VM-ul original este oprit și că vNIC-ul său este deconectat de la rețeaua de producție. Starea oprită împiedică să se facă modificări malițioase pe acel VM. vNIC-ul deconectat împiedică guest OS-ul compromis să comunice în rețeaua de producție dacă cineva pornește accidental VM-ul. VM-ul nu se va șterge, se va păstra pentru o analiză ulterioară.

Pasul 2: Selectarea recovery point-ului

În Rubrik verific cele patru recovery points disponibile și îl selectez pe cel de luni, ora 01:00. Un snapshot este o stare a VM-ului, capturată la un anumit moment. Conține informațiile de care Rubrik are nevoie pentru procedura de recovery. Nu este încă un VM aflat în funcțiune.

Pasul 3: Crearea unui Live Mount

Creez un Live Mount în Rubrik pe care îl denumesc: FS-PROD-07-RECOVERY. Live Mount permite pornirea unui VM Nutanix AHV direct din storage-ul Rubrik, fără să aștept copierea completă a VM-ului pe storage-ul Nutanix. Pentru un file server de 4 TB, timpul câștigat este esențial. Astfel, în loc să aștept finalizarea unui restore complet pot deja începe verificarea VM-ului care rulează direct pe storage-ul de backup. Pot alege dacă VM-ul va fi pornit automat după creare, dar aleg să rămână oprit. Un VM recuperat din backup păstrează în mod normal hostname-ul și configurația IP salvată în snapshot. Nu vreau ca acesta să ajungă cumva în rețeaua de producție. Când FS-PROD-07-RECOVERY apare în Prism, verific mai întâi că este oprit. Apoi verific starea vNIC-ului. Mă asigur să fie deconectat de la rețeaua de producție și îl conectez la o rețea izolată de recovery. De abia apoi pornesc VM-ul.

Pasul 4: Verific VM-ul din consolă

Mă conectez prin consola Prism. În acest fel am acces direct la VM, fără să depind de adresa lui IP de producție. Windows începe secvența de boot și ajunge la ecranul de login. Prima observație este deci că punctul de recuperare de la 01:00 conține un guest OS care poate porni. Este o condiție necesară, dar nu suficientă. Un file server poate porni și, în același timp, poate conține date criptate. Verific volumele Windows. Volumul de sistem este prezent, iar volumul de date D: este online. Capacitatea raportată corespunde cu cea la care mă aștept pentru FS-PROD-07. Faptul că volumul este online demonstrează că Windows recunoaște disk-ul de date recuperat. Asta nu demonstrează că directoarele sau documentele din interior sunt cele corecte.

Accesez D:\Shares\Financiar. Navighez prin mai multe directoare. Confirm astfel că ierarhia corectă  a fost păstrată în recovery point-ul de la ora 1. În continuare, verific dacă serviciul Windows de file sharing a pornit. Verific dacă share-urile există și indică spre folderele locale corecte. Share-ul Financiar, de exemplu, trebuie să indice spre directorul Financiar corespunzător din D:\Shares.

Verific apoi permisiunile NTFS. Permisiunile NTFS sunt reguli configurate în Windows care stabilesc ce utilizatori și grupuri pot citi, modifica sau administra un fișier sau folder. Financiarul trebuie să primească același acces pe care îl avea înainte, iar utilizatorii neautorizați nu trebuie să obțină drepturi mai largi în urma procesului de recovery. Abia acum verific fișierele. Încep cu numele lor. Extensiile suplimentare observate pe VM-ul compromis nu mai apar. Numele se termină normal în .xlsx sau .pdf. Verific aceleași foldere și pentru mesajul de răscumpărare README_TO_RESTORE.txt; fișierul nu este prezent. Verific și că fișierele pot fi deschise și citite.

În acest moment am demonstrat câteva lucruri practice despre punctul de recuperare de luni, ora 01:00:

• Windows pornește;
• Volumul de date este accesibil și are capacitatea corectă;
• Serviciul Windows de file sharing este funcțional;
• Permisiunile NTFS verificate corespund accesului configurat;
• Fișierele pot fi deschise sau executate;
• Folderele nu mai conțin extensiile .locked sau mesajul de răscumpărare.

Nu am demonstrat că toate documentele de pe file server-ul de 4 TB sunt cele corecte. Am însă suficiente dovezi pentru a cere aprobarea de către management al acestui recovery point de la ora 1 noaptea.

Pasul 5: Migrarea VM-ului recuperat înapoi pe storage-ul Nutanix

Live Mount mi-a permis să pornesc și să validez rapid VM-ul. Este însă doar o stare temporară, un file server de producție nu poate rămâne pe storage-ul Rubrik. VM-ul recuperat trebuie să devină din nou un workload în infrastructura de Nutanix, ale cărui disk-uri virtuale se află în storage containerul Nutanix. Un storage container este o zonă logică din AOS folosită pentru păstrarea disk-urilor VM-urilor și aplicarea configurației de storage relevante. Pornesc din Rubrik procedura care migrează Live Mount-ul către storage-ul Nutanix. Verific destinația înainte de pornire și monitorizez jobul până la finalizare. După ce Rubrik finalizează jobul, mă întorc în Prism Central. Confirm că disk-urile VM-ului se află acum pe storage-ul Nutanix și nu mai depind de Live Mount. Confirm că Windows funcționează corect după migrare și că volumul D:, serviciul de file sharing și share-ul sunt disponibile. Dacă VM-ul a funcționat în timpul Live Mount, cel mai probabil va funcționa și după migrare.

Pasul 6: Verificarea identității VM-ului înainte de reconectarea în producție

În Prism, VM-ul recuperat se numește FS-PROD-07-RECOVERY. În Windows hostname-ul este însă tot FS-PROD-07, deoarece acest hostname era cel salvat în recovery point. Înainte să reconectez ceva, confirm încă o dată că VM-ul original compromis este oprit și izolat. Cele două VM-uri nu au voie să fie pornite simultan în aceeași rețea de producție. După migrare, verific din nou că Windows funcționează, volumul D: este accesibil, serviciul de file sharing este pornit, iar share-urile răspund. Verific și partea de networking, adresarea IP și că VM-ul este înrolat in Active Directory. Migrarea este considerată finalizată numai după aceste verificări. Verific și vNIC-urile și MAC-urile VM-ului recuperat în Prism.

Pasul 7: Reconectez producția

Recovery point-ul selectat a fost validat. Datele au fost migrate în storage-ul Nutanix. VM-ul original rămâne oprit și izolat. Identitatea și configurația de rețea ale VM-ului recuperat au fost verificate. Următorul pas este să conectez vNIC-urile VM-ului recuperat la rețeaua de producție. Verific că DNS-ul rezolvă FS-PROD-07. Conectivitatea de bază funcționează. Testez din nou portul TCP 445 și confirm că SMB este accesibil. Apoi deschid direct fiecare share, printre care și \\FS-PROD-07\Financiar și \\FS-PROD-07\Achizitii. O sun pe Elena și o rog să deschidă fișierul. Acesta se încarcă iar datele sunt vizibile. Abia în acel moment serviciul poate fi considerat restabilit pentru utilizatorii din Financiar. Nodurile Lenovo ThinkAgile HX au rămas funcționale. AHV a continuat să ruleze mediul virtual. AOS a continuat să furnizeze storage-ul centralizat. Prism Central a continuat să raporteze starea întregii infrastructuri Nutanix. Rubrik a fost cel care a furnizat un recovery point. Live Mount mi-a permis să pornesc și să validez starea de luni, ora 01:00, înainte de a o readuce în producție. VM-ul validat a fost apoi migrat înapoi în storage-ul Nutanix. După câteva verificări file serverul a redevenit disponibil.

Avantajele soluției Nutanix și Rubrik

Nutanix oferă: platforma de compute, virtualizarea AHV, storage-ul distribuit AOS și administrarea prin Prism. Aceste componente rulează și administrează VM-ul, dar o platformă ca aceasta nu garantează că fișiere din interiorul guest OS-ului sunt utilizabile.

Rubrik oferă: recovery point-uri protejate și independente, protecție și retenție, Live Mount pentru validare rapidă și un workflow suportat pentru migrarea VM-ului montat înapoi în storage-ul Nutanix. Și multe altele.

În cazul unui incident, inginerul trebuie să ofere: izolarea VM-ului compromis, selectarea unui punct de recuperare, validarea funcționalității VM-ului, migrarea pe storage-ul inițial, prevenirea conflictelor de IP și reconectarea în producție.

Nici Nutanix și nici Rubrik nu sunt soluții care opresc ransomware-ul. Valoarea acestei arhitecturi este că am la dispoziție recovery point-uri independente și o metodă prin care le pot testa înainte să îl readuc în producție, atunci când datele din interiorul unui VM nu mai sunt utilizabile, dar infrastructura încă funcționează.

Dacă doriți să aflați mai multe despre soluțiile potrivite pentru protecția și recuperarea datelor organizației dumneavoastră, scrieți-ne la [email protected].