Un secret scurs online, șapte minute pentru a șterge totul

A fost nevoie de o singură credențială scursă — un client ID, un secret și un tenant ID publicate în clar într-un issue public de GitHub — pentru ca un grup de atacatori urmărit sub numele Storm-3168 să obțină acces în mediul Azure al unei victime. Ce a urmat este o lecție clasică despre cât de rapid poate automatizarea transforma o credențială scursă într-un incident distructiv: în aproximativ șapte minute, atacatorul a șters zeci de conturi de stocare, alături de un Key Vault, o aplicație Function și un plan App Service.

Ce s-a întâmplat

Storm-3168 nu s-a grăbit. Prima identitate compromisă a petrecut aproximativ 15 ore și 30 de minute cartografiind discret mediul — peste 300 de operațiuni de citire reușite pe mașini virtuale, subscripții, grupuri de resurse și alte resurse, parte a unei ferestre de activitate ARM întinsă pe circa 18 ore.

Aproximativ 90 de minute mai târziu, o a doua identitate a preluat recunoașterea, verificând mașini virtuale și grupuri de resurse pe două subscripții în doar cinci secunde, apoi trecând la magaziile de configurare Azure App Configuration — probabil în căutarea altor secrete expuse — și interogând, fără succes, resurse Azure OpenSearch.

La aproximativ 16 ore de la primele citiri, aceeași identitate a rulat un ultim inventar înainte de impact, apoi a încercat să extragă o cheie dintr-un cont de stocare care nu exista. La mai puțin de o secundă după acest eșec, a început faza distructivă: în aproximativ șapte minute, atacatorul a făcut peste 100 de încercări de ștergere a conturilor de stocare, reușind să elimine majoritatea, alături de un Key Vault, o aplicație Function și un plan App Service din același grup de resurse.

Încercările paralele de a șterge baze de date Azure SQL au eșuat toate — foloseau o versiune de API nesuportată — iar atacatorul a vizat separat și blocările de protecție Site Recovery și Azure Backup, semn clar că obiectivul era să facă recuperarea cât mai dificilă, nu doar să provoace pagube. Blocările de resurse (resource locks) și protecția la ștergere la nivel de cont au oprit o parte din încercări — cea mai clară dovadă din tot acest episod că protecțiile suplimentare încă funcționează chiar și după compromiterea completă a unei identități.

La aproximativ 28 de minute după finalul distrugerii, aceeași identitate a revenit și a trimis peste 30 de cereri reușite de recuperare a cheilor pentru conturile de stocare rămase — mai multe dintre ele cu nume legate de Terraform și de backup — oferind atacatorului o cale de acces continuu chiar și după valul de ștergeri. Telemetria a arătat cinci token-uri distincte asociate service principal-ului folosit pentru distrugere și colectarea cheilor, cu două token-uri de ștergere active în aceeași fereastră de 70 de secunde — un tipar care indică unelte automate și coordonate, nu un operator manual.

Nu a fost confirmată nicio notă de răscumpărare sau furt de date, dar combinația dintre ștergerea în masă, colectarea țintită de chei de acces și atacurile asupra sistemelor de backup și recuperare sugerează un scenariu de extorcare: distrugere mai întâi, apoi folosirea cheilor furate ca pârghie sau cale de reintrare.

De ce contează

Acest incident este o reamintire că, în cloud, distanța dintre „un secret scurs undeva public” și „datele de producție au dispărut” se poate măsura în ore, nu în săptămâni — iar faza distructivă în sine se poate măsura în minute. Arată și că identitatea este noul perimetru: acest atac nu a avut nevoie de nicio vulnerabilitate în Azure, ci doar de un service principal valid, cu prea multe permisiuni, pe care nimeni nu l-a rotit după ce a fost expus. Vizarea deliberată a Site Recovery și Azure Backup arată că atacatorii înțeleg tot mai bine că ștergerea mediului principal nu e suficientă — dacă victima poate restaura din backup, backup-ul devine următoarea țintă.

Ce este de făcut

• Tratați orice secret expus ca fiind deja compromis, imediat. Revocați și rotiți orice credențială găsită într-un repository public, tichet, log sau fișier de configurare în momentul descoperirii — ștergerea postării nu o elimină din istoric și nici de la cei care au copiat-o deja.
• Aplicați principiul privilegiului minim identităților de workload. Service principal-urile folosite pentru automatizare ar trebui să dețină strict permisiunile necesare — asta limitează cât de departe poate ajunge un singur token scurs.
• Protejați separat infrastructura de backup și recuperare. Restricționați cine poate modifica sau elimina blocările de resurse, configurațiile Site Recovery și protecția Backup, și generați alerte la orice încercare de modificare.
• Căutați tiparul, nu doar payload-ul. O perioadă lungă și discretă de recunoaștere urmată de un val rapid de ștergeri și colectare masivă de chei este o semnătură recognoscibilă — construiți detecții pentru volume neobișnuite de enumerare, rafale rapide de ListKeys și încercări de ștergere asupra resurselor protejate.
• Folosiți blocările de resurse și protecția la ștergere oriunde sunt disponibile. Nu vor opri un atacator determinat cu permisiunile potrivite, dar acest caz arată că reduc măsurabil impactul chiar și după compromiterea completă a unei identități.